[ITK] DICOM read-write intensity rescaling problems still present in ITK 4.5.2

[Matt McCormick]

Hi Mikael,

Here are some tips:

- Install Git
git clone http://itk.org/ITK.git
cd ITK
git fetch http://review.source.kitware.com/p/ITK
refs/changes/19/15919/1 && git checkout FETCH_HEAD -b
RescaleSlopeIntercept

Note that the last line is pasted from the "checkout" line in the
Gerrit Change [1].  More detailed instructions are found on the ITK
Git wiki pages [2], ITK Bar Camp [3], and the Pro Git book [4].

Thanks,
Matt

[1] http://review.source.kitware.com/#/c/15919/

[2] http://www.itk.org/Wiki/ITK/Git

[3] http://insightsoftwareconsortium.github.io/ITKBarCamp-doc/CommunitySoftwareProcess/PerformAGerritReview/index.html

[4] http://git-scm.com/book


On Wed, Jun 25, 2014 at 1:40 AM, Eriksson, Mikael
<mikael.k.eriksson at philips.com> wrote:
> Hi,
>
> Glad that my tests were useful! I'll test your patch, but I would like to know if you have any suggestions for how to go about doing it, since I don't use git to get the latest ITK-version, but rather have a static version of ITK, and add to that that I'm by no means a programmer or anything so if you have any suggestions for how to do the testing as efficiently as possible given these premises it would be appreciated!
>
> Mikael
>
> ………………………………………………………………………………………….
> Mikael Eriksson
> R&D Physicist Trainee
> Philips Medical Systems MR Finland, Feasibility studies
>
> +358 40 631 8500
> mikael.k.eriksson at philips.com
> ………………………………………………………………………………………….
>
>
> -----Original Message-----
> From: Matt McCormick [mailto:matt.mccormick at kitware.com]
> Sent: 25. kesäkuuta 2014 6:58
> To: Eriksson, Mikael
> Cc: community at itk.org
> Subject: Re: [ITK] DICOM read-write intensity rescaling problems still present in ITK 4.5.2
>
> Hi Mikael,
>
> Thanks for the feed back and tests -- it was very helpful.
>
> I dug quite deep into this.  If rescale-slope on write had been fixed, it was broken during the GDCMv1 to GDCMv2 transition [1]. It is an opportunity to improve to our tests :-).
>
> I started a patch to improve the situation [2].  Please test it out.
> On your writer, call
>
>   writer->UseInputMetaDataDictionaryOff();
>   writer->SetImageIO( theReadersGDCMImageIO );
>
> To transfer to the writer both the pixel InternalComponentType, i.e.
> the pixel type on disk before rescaling is applied, and the rescale slope and rescale intercept tags used in the original image.
>
> Thanks,
> Matt
>
> [1] http://itk.org/gitweb?p=ITK.git;a=blobdiff;f=Code/IO/itkGDCMImageIO.cxx;h=fbd0c7826822775a9e624ba3fd67df35e6872bc7;hp=6b80f7d7928f570d729bac02fc5304f03c16e128;hb=99893f1b;hpb=f08de4d800f8b7dd91b5f43d4803b9db4227812e
>
> [2] http://review.source.kitware.com/#/c/15919/
>
> On Mon, Jun 23, 2014 at 6:45 AM, Eriksson, Mikael <mikael.k.eriksson at philips.com> wrote:
>> Hi Matt,
>>
>> I tested with a couple of different sets of data: one set had bits allocated = 16, bits stored = 16, pixel representation = 1, intercept = -1024 and slope = 1, and was rewritten as expected with intercept = 0, and otherwise the same types. The other set had bits allocated = 16, bits stored = 12, pixel representation = 0, intercept = -1000 and slope = 1, and was rewritten with bits allocated = 16, bits stored = 16, pixel representation = 0, intercept = -1000 and slope = 1, so in this case the problem appeared. Another difference, although I don't think it should be the reason for this problem, is that the first data set was just a plain folder with .dcm-files, and the other data-set was a folder with extensionless files, with a DICOMDIR file in the parent directory.
>>
>> In neither case did the if-block you linked to execute, since the outpixeltype had not been changed from its initialized type gdcm::PixelFormat::UNKNOWN,  but rather, the else-block on line 989 with image.SetPixelFormat(pixeltype) had been executed.
>>
>> I defined both my inputPixelType as unsigned short and outputPixelType as signed short in both cases.
>>
>> Can you make any sense of all this?
>>
>> Best regards,
>> Mikael
>>
>>
>> -----Original Message-----
>> From: Matt McCormick [mailto:matt.mccormick at kitware.com]
>> Sent: 19. kesäkuuta 2014 19:44
>> To: Eriksson, Mikael
>> Cc: community at itk.org
>> Subject: Re: [ITK] DICOM read-write intensity rescaling problems still
>> present in ITK 4.5.2
>>
>> Hi Mikael,
>>
>> The rescaling should occur here [1].  If you run your code in a debugger, does it execute as expected?
>>
>> Thanks,
>> Matt
>>
>> [1]
>> http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/IO/GDCM/src/itkGDCMIm
>> ageIO.cxx;h=e1b194934bbc6ffb7dd492448bcf9f9a70153d5a;hb=HEAD#l997
>>
>> On Thu, Jun 19, 2014 at 6:00 AM, Eriksson, Mikael <mikael.k.eriksson at philips.com> wrote:
>>> Hi all,
>>>
>>>
>>>
>>> I’m using ITK 4.5.2, and recently noticed that in my work with
>>> DICOM-images, the intensities are rescaled even without any
>>> processing taking place between the read/write operations. I found
>>> this old thread from November 2007,
>>> http://www.itk.org/pipermail/insight-users/2007-November/024327.html,
>>> which does a good job explaining the cause and a workaround. The
>>> cause is that when reading the image volume, rescale slope and
>>> intercept is used to convert the stored unsigned integers (assuming
>>> the “Pixel representation”-tag is 0) to real-world values, but then
>>> these real-world values are written into the new DICOM-series, while
>>> the rescale-parameters are copied, so on the next read the real-world values will be different.
>>>
>>>
>>>
>>> In the thread I posted, it says that a patch was added ahead of ITK
>>> 3.4 to correct the problem, but I’m using ITK 4.5.2 and still have the same issues.
>>> By using the workaround suggested by Eliana M. Vasquez Osorio,
>>>
>>>      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" );
>>>
>>>      }
>>>
>>> I get the end result I want, so the intensities stay the same by
>>> manually setting rescale intercept to 0 in the new written series. I
>>> added a line to set the slope to 1 as well just to be sure, but so
>>> far in the data I’ve been working with the rescale slope has been 1 as for Eliana.
>>>
>>>
>>>
>>> However, my question is: is this a good way to go about correcting
>>> this problem, and if it was corrected already in ITK 3.4, why then do
>>> I see the same behaviour with ITK 4.5?
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Mikael
>>>
>>>
>>>
>>>
>>>
>>> ………………………………………………………………………………………….
>>>
>>> Mikael Eriksson
>>>
>>> R&D Physicist Trainee
>>>
>>> Philips Medical Systems MR Finland, Feasibility studies
>>>
>>> mikael.k.eriksson at philips.com
>>>
>>> ………………………………………………………………………………………….
>>>
>>>
>>>
>>>
>>> ________________________________
>>> The information contained in this message may be confidential and
>>> legally protected under applicable law. The message is intended
>>> solely for the addressee(s). If you are not the intended recipient,
>>> you are hereby notified that any use, forwarding, dissemination, or
>>> reproduction of this message is strictly prohibited and may be
>>> unlawful. If you are not the intended recipient, please contact the
>>> sender by return e-mail and destroy all copies of the original message.
>>>
>>> _______________________________________________
>>> Community mailing list
>>> Community at itk.org
>>> http://public.kitware.com/mailman/listinfo/community
>>>
>>
>> ________________________________
>> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.