Re: Implicit Color Space Transformation (during compression)
- From: Mathieu Malaterre <mathieu.malaterre@xxxxxxxxx>
- Date: Mon, 3 Nov 2008 05:40:47 -0800 (PST)
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 <eichelberg_nos...@xxxxxxxx>
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
.
- Follow-Ups:
- Re: Implicit Color Space Transformation (during compression)
- From: Marco Eichelberg
- Re: Implicit Color Space Transformation (during compression)
- References:
- Implicit Color Space Transformation (during compression)
- From: Mathieu Malaterre
- Re: Implicit Color Space Transformation (during compression)
- From: Marco Eichelberg
- Implicit Color Space Transformation (during compression)
- Prev by Date: Re: Implicit Color Space Transformation (during compression)
- Next by Date: HL7 Question
- Previous by thread: Re: Implicit Color Space Transformation (during compression)
- Next by thread: Re: Implicit Color Space Transformation (during compression)
- Index(es):
Relevant Pages
|