JPEG2000LossLessOnly Transfer Syntax with native Icon Image

[Roelant]

I have written a program for JPEG2000 compression of DICOM files, but it does not work when an icon image is present.

I chose not to compress the icon image, because it is not required by the DICOM standard (PS 3.5-2004, page 63: "Pixel Data within an Icon Image Sequence may or may not be compressed"). Further, I think an icon image is especially useful if it is easily accessible.

When debugging the software I found the following code in the file dcpixel.cxx:

Code: Select all

    if (xferSyn.isEncapsulated() && (! isIconImage))
    {
      if (fTransferState == ERW_init)
      {
        DcmRepresentationListIterator found;
        errorFlag = findConformingEncapsulatedRepresentation(xferSyn, NULL, found);
    .
    .
    .

The problem is that isIconImage turns out to be false for my icon image. Therefore an error is produced because the encapsulated representation for the pixel data (of the icon image) is not found.

isIconImage is false because it is not set when reading the original image. In stead of checking for an Icon Image Sequence, the decision is based on the presence of unencapsulated pixel data in a file with encapsulated transfer syntax:

Code: Select all

        if (Length == DCM_UndefinedLength)
        {
         ....
        }
        else
        {
            /* the pixel data is captured in native (uncompressed) format */

            /* if the transfer state is ERW_init, we need to prepare */
            /* the reading of the pixel data from the stream. */
            if (fTransferState == ERW_init)
            {
                current = original = repListEnd;
                unencapsulatedVR = Tag.getEVR();
                recalcVR();
                existUnencapsulated = OFTrue;

                if (ixferSyn.isEncapsulated())
                {
                  /* Special case: we have encountered an uncompressed image
                   * although we're decoding an encapsulated transfer syntax.
                   * This is probably an icon image.
                   */
                  isIconImage = OFTrue;
                }
            }

Because of this part of the code an icon image will only get the isIconImage mark if it is a native icon image within a file with encapsulated transfer syntax.

My question is:
Is my analysis correct, or did I forget something? And if you think I am right, do you think it could be an item on the 'to do list' for the next version?

[Marco Eichelberg]

Your analysis is correct. The question is what you would like to have on the "to do list" for the next version. The problem you describe is only manifest with compression codecs that do not compress icon images (all codecs in DCMTK always do compress icon images, for good reason ). One could add a method that allows to manually enable the isIconImage flag, and that could be called by your codec whenever it decides not to compress an icon image. By the way, the reason why the parser enables this flag only based on the presence of unencapsulated pixel data in a compressed transfer syntax is that there is no guarantee that you find something like that only in the Icon Image Sequence. It could as well be present in some private attribute (private sequence), with the same consequences.

[Roelant]

Adding a function to enable the user to set or unset the isIconImage mark would indeed solve my problem, but I think it is an (ugly) work-around.
Personally, I would prefer having all (and only) Icon Images marked with isIconImage, and maybe private elements with isPrivate. This would be clearer and less sensitive to causing this kind of problems.

If the choice for DCMTK is to always compress icon images, isIconImage would not be needed at all. But from the code I read that the possibility NOT to compress the icon image was partly implemented. When the mark isIconImage is present the software does not need encapsulated data to save a file. This implements the option in the DICOM standard (I mentioned it in my first message) NOT to compress the icon image (or pixel data in private sequences).

For now, I changed my code to also compress the icon images, but I would still prefer not to do that. In my case (I work with mammography images only) the amount of data in the icon images I encounter is negligible. Even after JPEG2000 compression the images are about 500 times larger than the uncompressed icon images. But maybe you can convince me that it is still better to compress the icon images too?

As a last remark I would like to add that I think it is very dangerous to use lossy compression on pixel data in private sequences, since the content is unknown. If a manufacturer would for example choose to store a defect pixel map in a private sequence, lossy compression would most certainly destroy it.

[Marco Eichelberg]

From the perspective of the parser, "isIconImage" and "isPrivate" would be synonymous. The only meaning of this flag is that it tags instances of the DcmPixelData class that may be written with explicit length (i.e. with uncompressed content) in encapsulated (compressed) transfer syntaxes. The parser does not care at which point this happens (icon image sequence, private data, something the DICOM committee is going to invent in the future, whatever) - however, if the flag is absent then the parser will refuse to write the object to file or to send it over a network if a compressed representation of this object is not available. This is why I think a single flag is and will be sufficient. This code was not implemented because DCMTK supports not compressing icon images, but because otherwise DCMTK would not be able to correctly handled such images when received from somewhere else. The reason why our codecs always encode icons is quite simple, by the way. The option not to compress icons in a compressed transfer syntax was added to DICOM after the fact (some CP), when our codecs were already implemented. This option also breaks the separation between OSI layer 7 and OSI layer 6 (the transfer syntax level), which means that from a conceptual perspective it is a quirky thing anyway. I agree that there are use cases where compression of icons does not help a lot. Regarding your comment on the compression of pixel data in private tags, well, this brings us deeply into "undefined behaviour" land. When a vendor uses the official attribute (7fe0,0010) inside some private group then the vendor must expect this attribute to become compressed, because compression of this attribute is the normal case and not the exception in encapsulated transfer syntaxes. If this is not desirable, the vendor should not use the official attribute within a private sequence in the first place. But that is a rather philosophical discussion.

[Roelant]

Ok, I still think the name isIconImage is confusing , but at least I understand why it was implemented this way now. Thanks for the explanation.