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

[Mathieu Malaterre]

Hi Matthias,

 I am getting kindda confused...but I'll try to answer your questions.
Please let me know if I misunderstood you.

On Nov 27, 2007 2:09 AM, Matthias Schabel <mschabel at ucair.med.utah.edu> wrote:
>   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?

You cannot do that easily from ITK-GDCM, instead you have to directly
access the lower level: GDCM. From ITK-GDCM you can only store
char/uchar/short/ushort images. This is not an issue with the
modality, but simply that it is not implemented at ITK-GDCM level.

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

Really ? That seemed like the obvious approach. User would be very
suprised when loading a volume that absolute value does not mean the
same thing from one slice to the other.

>  What I would expect is that either (in
> order of my preference)
>
> 1) rescaling would only happen if explicitly invoked

Per slice ? Per volume ? How would you know when to apply it in a
batch environment ? the value loaded would not even have the correct
unit for modality such as CT...

> 2) rescaling would happen invertibly when DICOM images are converted to
> float and vice versa...

I do not understand that sentence...

> 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

Again I do not understand that sentence. Your Stored Pixel are 16bits,
you apply an affine transform with floating point parameters (32bits)
and load your real world value into 64bits double types... There is no
way you can have any kind of loss of precision in this case, right ?
Your input data has to be coming from some kind of acquisition device
where it is dealing with descretized values, so the only loss I can
think of is when this device is storing the discretized value as an
approximation of an affine transform and a 16bits value.

> far as I understand it, since DICOM only supports 16 bit integer precision,

If we except RT Dose and SC...

> anyone using DICOM files to encode/decode float data will need to know about
> rescaleSlope/rescaleIntercept...

correct

> Those entries in the metadata seem to me to
> be providing the additional information necessary to do integer->float and
> float->integer conversions.

We simply give up when the itk::Image is of type float...so there is
no easy way to shoot yourself in the foot ...
Removing the Rescale slope/Intercept is to work aroung the issue I
described in a previous email, where input data is passed back to
output.


HTH
-- 
Mathieu