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

[Matthias Schabel]

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

Matthias

PS The crashing problem in OSX 10.5 appears to only occur with  
dynamically linked versions of the ITK libraries - static linkage  
works fine.

> Hello,
> I upgraded ITK and the problem is now solved.  The problem was  
> related to the rescale slope and intersect tags in the DICOM files.
>
> Thank you Mathieu for your help! ,
> Eliana
>
>
> Mathieu Malaterre wrote:
>> That's correct the patch was added ~August 2007, so only ITK 3.4 and
>> ITK 3.6 will have it.
>>
>> Sorry for the troubles,
>> -Mathieu
>>
>> On Nov 22, 2007 3:42 PM, "Eliana M. Vásquez Osorio"
>> <e.vasquezosorio at erasmusmc.nl> wrote:
>>
>>> Hello Mathieu,
>>> no.  I don't have it. -- I checked the whole file.  :\
>>> Just checking the version of ITK I got installed... it's ITK 3.2...
>>> :]  ups.
>>> I think I'll upgrade the ITK version before I continue working...
>>>
>>>
>>> Thank you,
>>> Eliana
>>>
>>>
>>> Mathieu Malaterre wrote:
>>>
>>>> Hi Eliana,
>>>>
>>>>  Could you please check that you have something like this in your
>>>> itkGDCMImageIO.cxx: (~line 835)
>>>>
>>>>          && !(dictEntry->GetGroup() == 0x0028 &&
>>>> dictEntry->GetElement() == 0x1052)
>>>>          && !(dictEntry->GetGroup() == 0x0028 &&
>>>> dictEntry->GetElement() == 0x1053)
>>>>
>>>>  This means that itk-gdcm will *never* write a rescale slope/ 
>>>> rescale
>>>> intercept because of the issue you just mentionned.
>>>>
>>>> Thanks again for your feedback,
>>>> -Mathieu
>>>>
>>>>
>>>> On Nov 22, 2007 3:19 PM, "Eliana M. Vásquez Osorio"
>>>> <e.vasquezosorio at erasmusmc.nl> wrote:
>>>>
>>>>
>>>>> [off list]
>>>>>
>>>>> Hello Mathieu,
>>>>>
>>>>> I made the change in the pixel type with no difference.  :(
>>>>> But -- here comes the nice part --, while reading the last FAQ  
>>>>> entry you
>>>>> send, I became aware of the rescale slope and intercept.  And I  
>>>>> know
>>>>> what is happening now.
>>>>>
>>>>> I'm using the metadata of the read files into the written files  
>>>>> (line
>>>>> 92).  The rescale interpect is -1000 in both, the read and the  
>>>>> written
>>>>> image.  And that -1000 is exactly the difference I found between  
>>>>> the
>>>>> intensity values of the images (write - read).  So what happens  
>>>>> is this:
>>>>> - when reading the pixel value is calculated with [RWV = slope *  
>>>>> SP +
>>>>> intercept]  from FAQ
>>>>> - when writing, the pixel value is not changed, and the rescale
>>>>> intercept is set to -1000.
>>>>> * when the written image is read, the pixel values are again  
>>>>> calculated
>>>>> and you get the intercept (-1000) added again.
>>>>>
>>>>> I read and write the same image 3 times, and the difference was  
>>>>> accumulating
>>>>> [original image] -> readNwrite -> [written1] -> readNwrite ->  
>>>>> [written2]
>>>>> -> readNwrite -> [written3]
>>>>> and
>>>>> written1 was -1000 offset from the original (pixel intensity  
>>>>> values);
>>>>> written2 was -2000 offset from the original (pixel intensity  
>>>>> values);
>>>>> written3 was -3000 offset from the original (pixel intensity  
>>>>> values);
>>>>>
>>>>> I just include this in the code, and the problems seems to be  
>>>>> fixed:
>>>>>    WriterType::DictionaryArrayRawPointer dicts =
>>>>> dcmreader->GetMetaDataDictionaryArray();
>>>>>    WriterType::DictionaryArrayType::const_iterator itdict;
>>>>>    for( itdict = dicts->begin(); itdict != dicts->end(); itdict+ 
>>>>> + )
>>>>>    {
>>>>>        WriterType::DictionaryRawPointer dicti = *itdict;
>>>>>        //change 0028,1052,Rescale Intercept from -1000 to 0
>>>>>        itk::EncapsulateMetaData<std::string>( *dicti, "0028| 
>>>>> 1052", "0" );
>>>>>    }
>>>>>
>>>>> But the question that remains is, should this rescale intercept be
>>>>> updated automatically when writing?  Are they other values that  
>>>>> should
>>>>> also be "corrected" when writing? Is this a bug? or is just a  
>>>>> "special
>>>>> case"?
>>>>>
>>>>> Thank you very much.  I'll write something to the list, just to  
>>>>> round
>>>>> off the 'topic'.
>>>>> (sorry for so much ping pong)
>>>>>
>>>>> Eliana