[Insight-developers] GDCM2 transition testing

[Luis Ibanez]

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.


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


3) Killing bugs is always a good thing   :-)

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 ?)


   Thanks


     Luis


-------------------------

Mathieu Malaterre wrote:
> Hi there,
> 
>   Here is my current plan for transitioning:
> 
> http://gdcm.svn.sf.net/viewvc/gdcm/Sandbox/GDCM_ITK/
> 
> you can retrieve it via:
> 1.
> svn co https://gdcm.svn.sourceforge.net/svnroot/gdcm/Sandbox/GDCM_ITK
> 
> 2. via the viewvc, tarball generation:
> http://gdcm.svn.sf.net/viewvc/gdcm/Sandbox/GDCM_ITK.tar.gz?view=tar
> 
>   This external project can be build with any ITK. The idea is to
> build it twice, once with a default gdcm 1.2.4 build and once with a
> system installed gdcm 2.x version.
>   When the main executable runs, it produces md5 checksums of the
> in-memory itk::Image (this is not portable across little/big endian
> platforms):
> 
> For instance using GDCM 1.2.4 I get:
> http://gdcm.svn.sf.net/viewvc/gdcm/Sandbox/GDCM_ITK/table1.cxx?view=markup
> 
> While with GDCM 2.x
> http://gdcm.svn.sf.net/viewvc/gdcm/Sandbox/GDCM_ITK/table2.cxx?view=markup
> 
> 
> You'll find out that there are still some differences with gdcm 2.x.
> Which I'd like to discuss here.
> 
> 1. What is the 3 component color space of ITK ?
> AFAIK this is assumed to be RGB. Therefore when a user is reading a
> YBR image, the code in itk::GDCMImage has to convert one color space
> to the other. In GDCM 1.2.4 the conversion would be integer based, and
> thus would be lossy.
> So my question is: do I keep the previous implementation, or should I
> do the right thing and actually run the lossless color space
> conversion. The side effect will be that image will now be floating
> point type.
> 
> I could also imagine case where people would want to keep there image
> as stored: integer type, but with a YBR color space...
> 
> 
> 2. The previous implementation of shift/rescale would consume a tad
> more memory. For a lot of cases, an output INT image would be chosen,
> while signed short would have been enough. The new behavior is to
> compute the correct interval and find the best fit. It will be
> extremely hard to reproduce the old behavior. Is this ok ?
> 
> 3. There is still a bug in the shift/rescale code where one has to
> round of to the next integer when doing the inverse rescale/shift.
> This bug is not present in GDCM 2.x (and therefore not ITK/GDCM 2.x)
> 
> 4. There are two type of grayscale in DICOM: MONOCHROME1 & MONOCHROME2
> (Min is black is MONOCHROME2). GDCM 1.2.4 would always run over all
> pixel and convert MONOCHROME1 image to MONOCHROME2 image. Since there
> is also one color space for grayscale image in ITK, I would say this
> still the best behavior. Such an image will always be written out as
> MONOCHROME2, which may or may not break with third party tools...
> 
> Thanks
>