JPIP

JPEG2000 Interactive Protocol (JPIP)
Entry courtesy of Eric Goodall from the Google DICOM Protocols Group

The heart of the JPIP standard is that it provides selective access to the image metadata that may be contained within JPEG2000 files.

The typical use cases for JPIP imagine that an interactive viewing application will request images via the DICOM JPIP transfer syntax in order to use the information contained in the non-pixel DICOM attributes to determine such things as: screen layouts; text information; and spatial and logical relationships among the images without moving the bulk of the DICOM object (pixel data) via DICOM Transfer.

The viewing application uses the JPIP URLs to interactively retrieve pixel data at the time, and in the format/resolution necessary, when it is requested for display.

Note that DICOM does not specify when the requesting application will begin using the JPIP URLs to retrieve pixel data, or how the application will manage the combined JPIP and DICOM attribute information, when it retrieves these “hollow” DICOM objects.
There is some consideration that JPIP could be utilized for a push-style workflow. For example, a Storage SCU could push DICOM objects containing JPIP URLs (the presumption being that the Storage SCP could accept the JPIP transfer syntax). However, DICOM does not specify how the receiving application will store and manage these objects.

This opens the possibilities for storing these in separate files or keeping them together as the same object. Another option is to shred the objects into database tables/columns and store the JPIP URL in the same place that one would store a file directory path/name/file, with the JPIP URL pointing to the stored DICOM object. The exception being, of course, that the JPIP URL would point back to the SCU that originally transmitted the objects, not to the local storage resource.