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

Tue Jun 24 23:58:18 EDT 2014

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