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

[Matthias Schabel]

Mathieu,

>   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.

Thanks for your response. I guess my question could be turned  
around : how should I format my output DICOM metadata to achieve,  
correctly, my goal. That is, what do I need to do to get ITK to  
output a DICOM file with rescale slope and rescale intercept  
specified - change modality? The post-processed data is clearly not  
PET data. Is there a special modality tag that indicates that the  
data is post-processed?

>  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 :(

This seems like strange behavior. What I would expect is that either  
(in order of my preference)

1) rescaling would only happen if explicitly invoked
2) rescaling would happen invertibly when DICOM images are converted  
to float and vice versa...

Since you can't correctly apply rescaling for integer conversions  
without loss of precision, it seems like a bad choice for the default  
behavior. As far as I understand it, since DICOM only supports 16 bit  
integer precision, anyone using DICOM files to encode/decode float  
data will need to know about rescaleSlope/rescaleIntercept... Those  
entries in the metadata seem to me to be providing the additional  
information necessary to do integer->float and float->integer  
conversions.

Matthias

> -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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20071126/b94a71dd/attachment-0001.html