[Insight-developers] GDCM2 transition testing

Mathieu Malaterre mathieu.malaterre at gmail.com
Mon Oct 6 10:48:14 EDT 2008


Luis,

On Mon, Oct 6, 2008 at 2:57 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> Hi Mathieu,
>
> Thanks for laying out the transition plan.
>
>
> About your points for discussion:
>
> 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 ?
>
>   Images with lookup tables has been a feature request for a
>   long time, but we have not hit a pressing need for them so far.


See my answer to Karthik. I will not perform any color space conversion.

>
> 2) I'm not sure I understand the options here...
>   Does this refer to the process of writing out a DICOM image ?

It does affect reading too. And to some extent will change 'behavior'.
Imagine that you have a unsigned 12bits (read : mav value = 4096 at
most) images on disk, and you need to apply a linear transform of y =
1 * x - 1024. Obviously signed short will be enough for storage.
However the previous behavior was to use INT in a lot of case where
signed short could store all information.

> 4) I didn't understand this entry.
>   What is the relationship between MONOCHROME1 and the fact
>   that ITK has one color space for grayscale images ?
>   (BTW: by color space are you referring to the RGB images
>         as above ? or to the fact that there are no LUT images
>         natively implemented ?)

Again I do not feel confident enough with this one. So people working
with only MONOCHROME1 will load them as MONOCHROME1. And all algorithm
should work fine.
Only people doing cross registration (one dataset in MONOCHOMRE1 and
one in MONOCHROME2) will have to convert from one grayscale space to
the other.
The real issue is that most information store in the DICOM file (like
window level and such) apply to the relative photometric
interpretation. Thus converting (arbitrarily) a MONOCHROME1 image to
MONOCHROME2 means I have to go over all attributes stored in the DICOM
and make sure there meaning is still accurate.

-- 
Mathieu


More information about the Insight-developers mailing list