[Insight-users] Dicom Series Read Series Write: change in intensity values

[Mathieu Malaterre]

Hi Bill,

  That's correct MR also often -illegally- has a slope/intersept. So
does CT and I guess Secondary Capture. But we handle all of them
nicely when *reading* a DICOM file. The issue is that right now, we
are not able to store that image -just read- back to file.

 To go into further details, PET for instance has a dynamic
slope/intersept. This make not only very efficient for this type of
data, but also completely necesseray since the scalar range is so wide
and would prevent people from storing such images on 16bits as per
DICOM definition. Which means that ITK should have a mechanism
(callback?) which would allow GDCM to pass the new slope/intercept for
each new 2D image when iterating over a 3D volume. So far I have not
look into it too much.

But in summary: reading 'floating' point is handled, writing it back
is not unfortunately :(

-Mathieu

On Nov 26, 2007 11:15 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Matthieu,
>
> I'm not sure if this is relevant to the current discussion.
>
> I think that PET data often rescales each pixel with a different rescale
> value. The results should be a floating point value.
>
> Bill
>
>
>
> On Nov 26, 2007 4:44 PM, Mathieu Malaterre <mathieu.malaterre at gmail.com>
> wrote:
>
> >
> >
> >
> > Hi Matthias,
> >
> >
> > On Nov 26, 2007 8:37 PM, Matthias Schabel <mschabel at ucair.med.utah.edu>
> wrote:
> > > I may not fully understand this issue, so apologies in advance if I'm
> > > missing something, but if the support for rescaleSlope/
> > > rescaleIntercept was removed from the ITK GDCM in ITK 3.4, this change
> > > breaks my code in a way that makes it very difficult to fix...
> >
> > Here is what happen in between ITK 3.2 and 3.4, ITK-GDCM was simply
> > passing all DICOM element from the reader to the writer. This is a bad
> > idea since ITK is also at the same time decompressing (applying the
> > rescale+slope) to the Stored Pixel. Therefore whenever you would
> > read-write-read-write the linear transform would be applied multiple
> > time... yup this is a bug indeed !
> >
> > Now, to answer your question: I did not break any kind of backward
> > compatibility since -and it's been on my TODO list for a while- there
> > is no support for floating point image in ITK-GDCM.
> > So if you are using some kind of low-level script (at gdcm level), you
> > should still be able to use it. Simply completely by-pass any check
> > done at ITK-GDCM level (ie. do not pass the meta data dictionary from
> > reader to writer).
> >
> >
> > > In
> > > particular, I have code that performs pharmacokinetic modeling on
> > > dynamically acquired MRI data to generate quantitative maps of
> > > parameters (such as Ktrans, kep, Vp...) that take on floating point
> > > values in the approximate range of 0.0-2.0.
> >
> > 2.0 ? That's pretty high for Ktrans/kep/ve, isn't it :)
> >
> >
> > > These maps are then
> > > exported as DICOM, with appropriate rescale factors and offsets to
> > > minimize truncation error in conversion from float to short. Since the
> > > latest release of the ITK libraries appears to strip rescaleSlope and
> > > rescaleIntercept on DICOM write, I can no longer specify correct
> > > scaling to the visualization program I'm using (OsiriX). I don't
> > > understand the rationale behind this change - it makes it essentially
> > > impossible to deal with small floating point numbers in DICOM if you
> > > can't specify these scaling values...
> >
> > Please send your custom script, and I'll help you get it to work again.
> Thanks.
> >
> >
> > >
> > > PS The crashing problem in OSX 10.5 appears to only occur with
> > > dynamically linked versions of the ITK libraries - static linkage
> > > works fine.
> >
> > Great, thanks for the notice !
> >
> > --
> > Mathieu
> >
> >
> >
> >
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users at itk.org
> > http://www.itk.org/mailman/listinfo/insight-users
> >
>
>



-- 
Mathieu