[Insight-developers] BUG: GDCMImageIO should respect the rescale intersept/slope when writing data

[Mathieu Malaterre]

This is fixed:

http://vtk.org/Bug/view.php?id=6144

The test using dicom-sc_cs-1.dcm is now applying the rescale transform
back and forth without any loss.

When the shift/scale is specified in the DICOM tags they are now
properly taken into account. I have tried to avoid duplicated code as
much as possible, by replacing the Duff's device code with a single
macro. I have added some simple template argument to internal code to
specify if the transform is direct (reading) or inverse (when
writing).

I have still one remaining piece of code where I can reduce the code
size, Brad King send me a trick that should also compile on the
beloved VS6.

NOTE: Users *have to* specify the transform completely (how the pixel
is stored on disk: uchar, char, short, ushort) and what parameters to
use (shift/scale). There is no magic code in the internals that will
compute a generic shift/scale from the min/max of the image (this is
dumb most of the time anyway).

Matthias:
You need to upgrade your code, your previous 'hack' of passing a
preprocess shift/scale image to the writer will produce incorrect
result as the writer is now also applying the shift scale. Sorry for
the troubles, but this is AFAIK the correct behavior. But you still
need to set the shift/scale explicitely as you were already doing.

Enjoy !
-Mathieu

On Nov 29, 2007 3:39 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> I understand now.
>
> Thanks,
>
> Bill
>
>
>
> On Nov 29, 2007 8:48 AM, Mathieu Malaterre <mathieu.malaterre at gmail.com>
> wrote:
>
> > The reading behavior is not changing, whenever we find a rescale
> > slope/interspect we take them into account. But as of now, when we are
> > *writing* an image with a rescale slope/interspect we discard it (we
> > were storing the pixel data buffer directly without affine transform).
> > This used to work well, but for people willing to store floating point
> > data this is an outstanding issue preventing them to store the image.
> >
> > -Mathieu
> >
> >
> >
> >
> > On Nov 29, 2007 2:34 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> > > Mathieu,
> > >
> > > Are you saying that we will no longer call RescaleFuntion in
> GDCMImageIO?
> > > This would be a huge change and break everyone's applications I believe.
> > > Maybe I am misunderstanding.
> > >
> > > Bill
> > >
> > >
> > > On Nov 29, 2007 8:21 AM, Mathieu Malaterre <
> mathieu.malaterre at gmail.com>
> > > wrote:
> > >
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > >  Just FYI after discussing with Matthias, my previous fix in ITK for
> > > > the rescale intersept/slope was clearly a hack and should be removed
> > > > ASAP. The correct patch should be that ITK is consistant at write
> > > > time, and respect the slope/intersept value as found in the metadata
> > > > header.
> > > >  What this means is, we will continue to not support floating point
> > > > Image, but allow user to apply a shift/scale by hand to have total
> > > > control over the data loss and then store the data as DICOM.
> > > >  I should find some time in the next days to implement the correct
> patch.
> > > >
> > > > thanks,
> > > > --
> > > > Mathieu
> > > > _______________________________________________
> > > > Insight-developers mailing list
> > > > Insight-developers at itk.org
> > > > http://www.itk.org/mailman/listinfo/insight-developers
> > > >
> > >
> > >
> >
> >
> >
> > --
> > Mathieu
> >
>
>



-- 
Mathieu