Implicit Color Space Transformation (during compression) - DICOM

This is a discussion on Implicit Color Space Transformation (during compression) - DICOM ; Hi there, I am trying to summarize the color space transformation that takes place during compression. Basically when presented an uncompressed image, with a particular photometric interpretation, I am trying to describe what is the expected output photometric interpretation. The ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Implicit Color Space Transformation (during compression)

  1. Implicit Color Space Transformation (during compression)

    Hi there,


    I am trying to summarize the color space transformation that takes
    place during compression. Basically when presented an uncompressed
    image, with a particular photometric interpretation, I am trying to
    describe what is the expected output photometric interpretation.

    The output photometric interpretation is well defined when
    converting to (true) lossless compression, but could be multiple when
    converting to lossy transformation. So this leave some flexibility to
    the user.

    Anyway the table is there:

    http://apps.sourceforge.net/mediawik...ransformations

    What I would really like to finish up are the lossless columns. The
    modes I am really struggling to understand are the following:

    1. Input is RGB, what is the output photometric interpretation when
    compressed in (true) lossless jpeg (eg. 1.2.840.10008.1.2.4.70).
    2. Input is YBR_FULL, what is the output photometric interpretation
    when compressed in (true) lossless jpeg 2000 (1.2.840.10008.1.2.4.90).

    When I explicitly specify 'true' it means that no floating point
    operation (with potential round off error) should table place, when
    doing the color space transformation.

    For (1) I would say YBR_FULL, but afaik the standard did not defined a
    reversible color space transform at that point, so you cannot encode
    the whole rgb range in (old) jpeg.
    For (2), the standard mandates the use of YBR_RCT, but that does not
    make any sense as my input is YBR_FULL.

    Thank you very *very* much

  2. Re: Implicit Color Space Transformation (during compression)

    Mathieu,

    > 1. Input is RGB, what is the output photometric interpretation when
    > compressed in (true) lossless jpeg (eg. 1.2.840.10008.1.2.4.70).


    Since the only color space transformation that is truly lossless is
    the conversion to YBR_RCT, which is defined only for JPEG 2000, the
    output here is neccessarily RGB.

    The transformation from RGB to YBR_FULL is always lossy in integer
    space due to rounding errors.

    Also note that, although not formally forbidden, DICOM does not specify
    an encoding for the following photometric interpretations in uncompressed
    form (e.g. ordering of sub-sampled components, handling of images with
    an odd number of columns etc.), so these should never "happen":
    YBR_FULL_422, YBR_PARTIAL_422, YBR_PARTIAL_420.

    Also note that YBR_RCT cannot exist in uncompressed form by definition,
    since this encoding requires a different bit depth for the "Y" component
    than for the other components.

    > 2. Input is YBR_FULL, what is the output photometric interpretation
    > when compressed in (true) lossless jpeg 2000 (1.2.840.10008.1.2.4.90).


    Output is YBR_FULL.

    > For (2), the standard mandates the use of YBR_RCT, but that does not
    > make any sense as my input is YBR_FULL.


    Absolutely right. Conversion to YBR_RCT makes sense if and only if
    the input is RGB, since the transformation is a lossless approximation
    of the RGB to YCbCr transformation and thus meant to provide a better
    de-coupling of color components, which would not work with YBR_FULL input
    (and would most probably degrade compression performance).

    Regards,
    Marco Eichelberg
    OFFIS


  3. Re: Implicit Color Space Transformation (during compression)

    Hi Marco,

    [If anyone could/would answer my color space transformation, I knew
    it would be you, thanks ]

    On Nov 3, 2:33 pm, Marco Eichelberg
    wrote:
    > Mathieu,
    >
    > > 1. Input is RGB, what is the output photometric interpretation when
    > > compressed in (true) lossless jpeg (eg. 1.2.840.10008.1.2.4.70).

    >
    > Since the only color space transformation that is truly lossless is
    > the conversion to YBR_RCT, which is defined only for JPEG 2000, the
    > output here is neccessarily RGB.


    That's what I thought. But tools like dciodvfy returns an error when
    PhotoInter is RGB within a jpeg compressed syntax dataset.

    > The transformation from RGB to YBR_FULL is always lossy in integer
    > space due to rounding errors.


    yup.

    > Also note that, although not formally forbidden, DICOM does not specify
    > an encoding for the following photometric interpretations in uncompressed
    > form (e.g. ordering of sub-sampled components, handling of images with
    > an odd number of columns etc.), so these should never "happen":
    > YBR_FULL_422, YBR_PARTIAL_422, YBR_PARTIAL_420.


    cool.

    > Also note that YBR_RCT cannot exist in uncompressed form by definition,
    > since this encoding requires a different bit depth for the "Y" component
    > than for the other components.


    alright !

    > > 2. Input is YBR_FULL, what is the output photometric interpretation
    > > when compressed in (true) lossless jpeg 2000 (1.2.840.10008.1.2.4.90).

    >
    > Output is YBR_FULL.


    And again, tools such as dciodvfy would complain this should not
    happen (I did not check), since only YBR_RCT/YBR_ICT should happen.

    > > For (2), the standard mandates the use of YBR_RCT, but that does not
    > > make any sense as my input is YBR_FULL.

    >
    > Absolutely right. Conversion to YBR_RCT makes sense if and only if
    > the input is RGB, since the transformation is a lossless approximation
    > of the RGB to YCbCr transformation and thus meant to provide a better
    > de-coupling of color components, which would not work with YBR_FULL input
    > (and would most probably degrade compression performance).




    Thank you ! That really cleared some doubts.

    -Mathieu

  4. Re: Implicit Color Space Transformation (during compression)

    Hi Mathieu,

    > That's what I thought. But tools like dciodvfy returns an error when
    > PhotoInter is RGB within a jpeg compressed syntax dataset.


    Quis custodiat ipsos custodes...

    I cannot speak for dciodvfy, but for our "counterpart" DCMCHECK there
    is a good reason why we always manually check the error messages produced
    by that tool. Of course checkers can be wrong and in this case I would
    tend to say dciodvfy is wrong.

    Best regards,
    Marco

    PS: Sometimes I really wonder where you take the time to dig that deeply
    into the most obscure details of DICOM. Not that I want to criticize - your
    observations are most helpful - I'm just a little envious ;-)

  5. Re: Implicit Color Space Transformation (during compression)

    Mathieu Malaterre wrote:
    > Hi there,
    >
    >
    > I am trying to summarize the color space transformation that takes
    > place during compression. Basically when presented an uncompressed
    > image, with a particular photometric interpretation, I am trying to
    > describe what is the expected output photometric interpretation.
    >
    > The output photometric interpretation is well defined when
    > converting to (true) lossless compression, but could be multiple when
    > converting to lossy transformation. So this leave some flexibility to
    > the user.
    >
    > Anyway the table is there:
    >
    > http://apps.sourceforge.net/mediawik...ransformations
    >


    My apologies for such a long post...

    1) I was under the impression that PALETTE COLOR should never be lossy
    compressed due to the possibility that the index values may actually get
    changed, thus referencing the wrong palette color. From Mr. Eichelberg:

    http://newsgroups.derkeiler.com/Arch.../msg00090.html

    Perhaps a footnote to your table is in order: When lossy compressing
    PALETTE COLOR, first convert to RGB, then lossy compress via color space
    transform to YBR_FULL and pass to jpeg compressor.


    2) I was also under the impression that the PHOTOMETRIC INTERPRETATION
    must represent the actual encapsulated pixel data: For example, when
    the pixel data is JPEG LOSSY compressed, the PHOTOMETRIC INTERPRETATION
    must accurately reflect with MONOCHROME* or YBR_FULL and _NOT_ RGB -
    unless one actually ran RGB data through the JPEG LOSSY compressor.

    Please see:
    Can Uncompressed LITTLEENDIAN IMPLICIT image has photometric interpretation of YBR_FULL?


    3) I was under the impression that the allowable PHOTOMETRIC
    INTERPRETATION _varies_ based on the SOP Class _AND_ encapsulation. For
    example:

    Secondary Capture True Color Image: Part 3, Appendix A.8.5.4:
    RGB for uncompressed or lossless compressed that do not involve color
    space transformations, YBR_ICT for irreversible JPEG 2000, YBR_RCT for
    reversible JPEG 2000, YBR_PARTIAL_420 for MPEG2, and YBR_FULL_422 for
    other lossy compressed transfer syntaxes.

    However, Part 3, Appendix C.8.5.6.1.2 (US Images), Photometric
    Interpretation may be MONOCHROME2, PALETTE COLOR, RGB, YBR_FULL,
    YBR_FULL_422, YBR_PARTIAL_422, YBR_RCT, YBR_ICT, YBR_PARTIAL_420.

    Also, Part 3 (2008) Appendix C.8.17.2.1.3 (Photometric Interpretation
    for Ophthalmic Images):
    Enumerated values shall be: MONOCHROME2, RGB, YBR_FULL_422,
    YBR_PARTIAL_420, YBR_ICT, and YBR_RCT.

    Now, given all these together, we can _NOT_ have: Secondary capture true
    color that specifies YBR_FULL for _uncompressed_ (but may be YBR_FULL
    for compressed jpeg lossy)

    We could have: US Images, uncompressed, with YBR_FULL

    Thus, given a jpeg lossy compressed US Image, we could simply decompress
    and leave it in YBR_FULL. However, given a jpeg lossy compressed
    Secondary Capture Image, not only do we have to decompress it, we also
    have to transform the color space to RGB.

    I suppose one could argue that US Images _may_ traverse the entire
    pipeline and also be decompressed AND color space converted, just like
    the secondary capture - but that seems a bit ambiguous. Isn't all this
    stuff supposed to be consistent, simple, and unambiguous?

    My apologies if my impressions are wrong - I have also struggled with
    the PHOTOMETRIC INTERPRETATION vs. SOP CLASS vs. COMPRESSION.

    Chuck

  6. Re: Implicit Color Space Transformation (during compression)

    Chuck McCrobie wrote:

    > 1) I was under the impression that PALETTE COLOR should never be lossy
    > compressed due to the possibility that the index values may actually get
    > changed, thus referencing the wrong palette color.


    Correct. You cannot apply lossy compression to the palette index values.

    > 2) I was also under the impression that the PHOTOMETRIC INTERPRETATION
    > must represent the actual encapsulated pixel data: For example, when
    > the pixel data is JPEG LOSSY compressed, the PHOTOMETRIC INTERPRETATION
    > must accurately reflect with MONOCHROME* or YBR_FULL and _NOT_ RGB -
    > unless one actually ran RGB data through the JPEG LOSSY compressor.


    It is correct that PhotometricInterpretation is intended to represent the
    color model used inside the encoded bitstream. It is not correct, however,
    to assume that JPEG color image are always encoded in YCbCr (YBR_FULL).
    While YBR_FULL is the most logical choice for color images when using lossy
    JPEG compression, RGB can be used with the JPEG process, both lossless and
    lossy. In practice, however, images with lossy JPEG compression that claim
    to use a color model of "RGB" are much more likely to actually be encoded
    in YCbCr and simply have a wrong value for PhotometricInterpretation.

    > 3) I was under the impression that the allowable PHOTOMETRIC
    > INTERPRETATION _varies_ based on the SOP Class _AND_ encapsulation. For
    > example:


    Correct. Some SOP classes limit the encoders' choices for PhotometricInterpretation
    based on the transfer syntax used.

    > Now, given all these together, we can _NOT_ have: Secondary capture true
    > color that specifies YBR_FULL for _uncompressed_ (but may be YBR_FULL
    > for compressed jpeg lossy)


    Correct, but this applies only to the "revised" Multiframe Secondary Capture
    SOP Class. Images of the "traditional" Secondary Capture SOP Class may very
    well be uncompressed with YBR_FULL.

    > Thus, given a jpeg lossy compressed US Image, we could simply decompress
    > and leave it in YBR_FULL. However, given a jpeg lossy compressed
    > Secondary Capture Image, not only do we have to decompress it, we also
    > have to transform the color space to RGB.


    Yes, and we also need to consider PlanarConfiguration, where some SOP
    classes also require certain values. Since PlanarConfiguration (i.e., the
    ordering of the uncompressed sample values) has no meaning for the compressed
    bitstream, it is the task of the decompressor to "sort" components correctly
    upon decompression. Basically you end up with a table of "special cases"
    that the decompressor needs to keep in mind.

    > I suppose one could argue that US Images _may_ traverse the entire
    > pipeline and also be decompressed AND color space converted, just like
    > the secondary capture - but that seems a bit ambiguous.


    This would be a valid implementation strategy since uncompressed US images
    may use either RGB or YBR_FULL (and dumb DICOM viewers are very likely
    to choke on either form of image).

    > Isn't all this stuff supposed to be consistent, simple, and unambiguous?


    Who said that? :-)


    Best regards,
    Marco Eichelberg

  7. Re: Implicit Color Space Transformation (during compression)

    On Nov 4, 4:15 am, Chuck McCrobie wrote:
    > Mathieu Malaterre wrote:
    > > Hi there,

    >
    > > I am trying to summarize the color space transformation that takes
    > > place during compression. Basically when presented an uncompressed
    > > image, with a particular photometric interpretation, I am trying to
    > > describe what is the expected output photometric interpretation.

    >
    > > The output photometric interpretation is well defined when
    > > converting to (true) lossless compression, but could be multiple when
    > > converting to lossy transformation. So this leave some flexibility to
    > > the user.

    >
    > > Anyway the table is there:

    >
    > >http://apps.sourceforge.net/mediawik...tle=Color_Spac...

    >
    > My apologies for such a long post...
    >
    > 1) I was under the impression that PALETTE COLOR should never be lossy
    > compressed due to the possibility that the index values may actually get
    > changed, thus referencing the wrong palette color. From Mr. Eichelberg:
    >
    > http://newsgroups.derkeiler.com/Arch...cols.dicom/200...


    oh !
    nasty indeed. Thanks I updated the table.

    > Perhaps a footnote to your table is in order: When lossy compressing
    > PALETTE COLOR, first convert to RGB, then lossy compress via color space
    > transform to YBR_FULL and pass to jpeg compressor.
    >
    > 2) I was also under the impression that the PHOTOMETRIC INTERPRETATION
    > must represent the actual encapsulated pixel data: For example, when
    > the pixel data is JPEG LOSSY compressed, the PHOTOMETRIC INTERPRETATION
    > must accurately reflect with MONOCHROME* or YBR_FULL and _NOT_ RGB -
    > unless one actually ran RGB data through the JPEG LOSSY compressor.
    >
    > Please see:http://fixunix.com/dicom/51079-can-u...ndian-implicit...
    >
    > 3) I was under the impression that the allowable PHOTOMETRIC
    > INTERPRETATION _varies_ based on the SOP Class _AND_ encapsulation. For
    > example:
    >
    > Secondary Capture True Color Image: Part 3, Appendix A.8.5.4:
    > RGB for uncompressed or lossless compressed that do not involve color
    > space transformations, YBR_ICT for irreversible JPEG 2000, YBR_RCT for
    > reversible JPEG 2000, YBR_PARTIAL_420 for MPEG2, and YBR_FULL_422 for
    > other lossy compressed transfer syntaxes.
    >
    > However, Part 3, Appendix C.8.5.6.1.2 (US Images), Photometric
    > Interpretation may be MONOCHROME2, PALETTE COLOR, RGB, YBR_FULL,
    > YBR_FULL_422, YBR_PARTIAL_422, YBR_RCT, YBR_ICT, YBR_PARTIAL_420.
    >
    > Also, Part 3 (2008) Appendix C.8.17.2.1.3 (Photometric Interpretation
    > for Ophthalmic Images):
    > Enumerated values shall be: MONOCHROME2, RGB, YBR_FULL_422,
    > YBR_PARTIAL_420, YBR_ICT, and YBR_RCT.
    >
    > Now, given all these together, we can _NOT_ have: Secondary capture true
    > color that specifies YBR_FULL for _uncompressed_ (but may be YBR_FULL
    > for compressed jpeg lossy)
    >
    > We could have: US Images, uncompressed, with YBR_FULL
    >
    > Thus, given a jpeg lossy compressed US Image, we could simply decompress
    > and leave it in YBR_FULL. However, given a jpeg lossy compressed
    > Secondary Capture Image, not only do we have to decompress it, we also
    > have to transform the color space to RGB.
    >
    > I suppose one could argue that US Images _may_ traverse the entire
    > pipeline and also be decompressed AND color space converted, just like
    > the secondary capture - but that seems a bit ambiguous. Isn't all this
    > stuff supposed to be consistent, simple, and unambiguous?
    >
    > My apologies if my impressions are wrong - I have also struggled with
    > the PHOTOMETRIC INTERPRETATION vs. SOP CLASS vs. COMPRESSION.


    thank you very much !

    -Mathieu

  8. Re: Implicit Color Space Transformation (during compression)

    On Nov 3, 4:34 pm, Marco Eichelberg
    wrote:
    > Hi Mathieu,
    >
    > > That's what I thought. But tools like dciodvfy returns an error when
    > > PhotoInter is RGB within a jpeg compressed syntax dataset.

    >
    > Quis custodiat ipsos custodes...
    >
    > I cannot speak for dciodvfy, but for our "counterpart" DCMCHECK there
    > is a good reason why we always manually check the error messages produced
    > by that tool. Of course checkers can be wrong and in this case I would
    > tend to say dciodvfy is wrong.
    >
    > Best regards,
    > Marco
    >
    > PS: Sometimes I really wonder where you take the time to dig that deeply
    > into the most obscure details of DICOM. Not that I want to criticize - your
    > observations are most helpful - I'm just a little envious ;-)


    How Do You Kill That Which Has No Life
    -South Park, Make Love, Not Warcraft

+ Reply to Thread