Implicit Color Space Transformation (during compression)
Mathieu Malaterre
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/mediawiki/gdcm/index.php?title=Color_Space_Transformations
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
Marco Eichelberg
> 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
Mathieu Malaterre
[If anyone could/would answer my color space transformation, I knew
it would be you, thanks :)]
On Nov 3, 2:33 pm, Marco Eichelberg <eichelberg_nos...@offis.de>
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
Marco Eichelberg
> 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 ;-)
Chuck McCrobie
> 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/mediawiki/gdcm/index.php?title=Color_Space_Transformations
>
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/Archive/Comp/comp.protocols.dicom/2005-12/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.
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
Marco Eichelberg
> 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
Mathieu Malaterre
> 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:
>
>
> 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:
>
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-uncompressed-littleendian-implicit...
thank you very much !
-Mathieu
Mathieu Malaterre
wrote:
How Do You Kill That Which Has No Life
-South Park, Make Love, Not Warcraft