[Insight-developers] GDCM2 transition testing

[Mathieu Malaterre]

'lo

On Mon, Oct 6, 2008 at 4:30 PM, Karthik Krishnan
<karthik.krishnan at kitware.com> wrote:
> On Mon, Oct 6, 2008 at 8:57 AM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>>
> Thanks a lot Mathieu.
>
>>
>> 1) ITK doesn't have an official color space representation.
>>   We have several filters intended for RGB images.
>>
>>   I would vote for "doing the right thing", particularly
>>   when doing the wrong thing will involve loosing information
>>   from a medical image.  :-/
>>
>>   Do we need a new type of image ?
>>   E.g.
>>   a YBRImage that will internally have a color lookup table ?
>
> Multiple YBR images, I suspect to handle the various chroma
> subsamplings as well.
>
> Typically with JPEG/J2k compression, YCbCr is the best used color
> space. This usually also involves chroma subsampling often 4:2:2,
> since the luminance visually has more information than the color
> components. So the memory organization for each pixel needs in 4:2:2
> is
>
>    Y Y Cb Cr Y Y Cb Cr ......
>
> Or we can simplify and ignore chroma sampling and always store in
> memory the duplicate Cb Cr images.
>
> The list of Dicom Photometric interpretations is:
>  http://www.medicalconnections.co.uk/wiki/YBR_FULL_422

I did not meant to confuse people with those low level details. BTW
YCrBr is too generic, you did not specify which spec you used. Some
are reversible some are not.

Anyway, bottom line is that ITK is not a viz toolkit. So I would think
the right thing is to: do *NOT* perform the color space conversion
esp. when you know this is going to be lossy.
I can imaging that a 4 components image in ITK does not necessarily
means RGBA image in ITK. So I'd like to go ahead and load the image
just as stored on disk. gdcm do provide simple routines to convert
colorspace, so this should not be an issue for anyone. This will not
be backward compatible with the previous behavior of rounding the
image into RGB space (lossy).


-- 
Mathieu