[Insight-developers] GDCM2 transition testing

[Mathieu Malaterre]

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

-- 
Mathieu