[Insight-users] [ITK Community] Image Intensities Changed During DICOM Read-Write-Read in ITK 3.20 vs. ITK 4.4.1

Fri Dec 6 13:37:04 EST 2013

FABULOUS!!  That is an exciting development, and long overdue.

Hans

From: Brian Helba <brian.helba at kitware.com<mailto:brian.helba at kitware.com>>
Date: Friday, December 6, 2013 12:29 PM
To: Hans Johnson <hans-johnson at uiowa.edu<mailto:hans-johnson at uiowa.edu>>, ITK <insight-developers at itk.org<mailto:insight-developers at itk.org>>
Cc: Bill Lorensen <bill.lorensen at gmail.com<mailto:bill.lorensen at gmail.com>>, ITK Users <insight-users at public.kitware.com<mailto:insight-users at public.kitware.com>>, Constantine Zakkaroff <mnkz at leeds.ac.uk<mailto:mnkz at leeds.ac.uk>>
Subject: Re: [Insight-users] [ITK Community] Image Intensities Changed During DICOM Read-Write-Read in ITK 3.20 vs. ITK 4.4.1

As for upgrading GDCM, I'm currently in the process of updating both OpenJPEG and GDCM, and in the process, I'm transitioning those libraries to the new Git workflow for ThirdParty modules, where we can clearly identify how ITK's versions has forked from upstream (and indeed it has forked by a significant number of commits). As part of this process, both libraries will also be upgraded.

However, upgrading GDCM will not solve the physical coordinate issues that users having been reporting with physical coordinates. I'm preparing a bug report with more detail, but as a quick preview: GDCM 2.x is now much strict about conforming to the DICOM standard, and is not writing out tags for physical coordinate properties for images of unknown (a.k.a. Seconary Capture) imaging modalities. I think the solution is for ITK to go back to the behavior that is technically less conformant with the standard but more conformant to expectations, as it was in GDCM 1.x and ITK 3, where physical coordinate tags are always respected, regardless of modality. This requires changes to GDCM itself, and since we don't want GDCMImageIO's behavior to differ depending on whether a system-installed copy of GDCM is being used, we need to coordinate with upstream. I'm in the process of this right now, and I'll have some news shortly.

On Fri, Dec 6, 2013 at 1:12 PM, Johnson, Hans J <hans-johnson at uiowa.edu<mailto:hans-johnson at uiowa.edu>> wrote:
Brian,

Have you investigated updating GDCM?  The version we are using is very old with respect to the number of bug and performance improvements over the last 2 years.  Matthieu has become very active in updating GDCM for multiple platforms over the past 2 years.

Hans

From: Brian Helba <brian.helba at kitware.com<mailto:brian.helba at kitware.com>>
Date: Friday, December 6, 2013 11:41 AM
To: Bill Lorensen <bill.lorensen at gmail.com<mailto:bill.lorensen at gmail.com>>

Cc: ITK Users <insight-users at public.kitware.com<mailto:insight-users at public.kitware.com>>, Constantine Zakkaroff <mnkz at leeds.ac.uk<mailto:mnkz at leeds.ac.uk>>
Subject: Re: [Insight-users] [ITK Community] Image Intensities Changed During DICOM Read-Write-Read in ITK 3.20 vs. ITK 4.4.1

I've been looking into this whole category of GDCM issues. I'm preparing some more thorough bug reports for Jira, mostly related to the physical coordinate properties.

I've also looked at the rescale issue, and it seems like the simple hack may actually be the best solution without some complicated new functionality in GDCM: if the slope-intercept tags are set for an image, just apply the inverse of the rescaling function to the image values right before sending them to GDCM. I'll try to get a patch with a good test together in the next few days, before the next RC.

On Wed, Dec 4, 2013 at 1:52 PM, Bill Lorensen <bill.lorensen at gmail.com<mailto:bill.lorensen at gmail.com>> wrote:
I probably will not get to this before the release.

On Wed, Dec 4, 2013 at 12:12 PM, Yi-Yu Chou <yiyu.chou at gmail.com<mailto:yiyu.chou at gmail.com>> wrote:
> Hi Bill,
>
> It appears the bug "Acquisition Matrix" is still not corrected when running
> with itk4.5_rc02.
> Are you going to fix it in the new released itk ?
>
> Many thanks !!
>
> Yi-Yu
>
>
> On Fri, Oct 18, 2013 at 8:24 PM, Constantine Zakkaroff <mnkz at leeds.ac.uk<mailto:mnkz at leeds.ac.uk>>
> wrote:
>>
>> Hi Bill,
>>
>> It appears the bug with slope and intercept being processed incorrectly
>> still shows up in ITK 4.4.2.
>>
>> Is there an explanation why in the original DICOM file rescale slope is
>> 7.1, but in order to see the same image stats (min, max, etc.) it needs to
>> be saved with the rescale slope value of 1.0?
>>
>> Also, I believe I mentioned it a while ago, but there wasn't much feedback
>> on this: some tag values get unexpected values. For example, compare the
>> following tag values in the original DICOM file:
>>
>> (0010,21C0) Pregnancy Status VR: US Length: 2 Value: 4
>> (0018,0088) Spacing Between Slices VR: DS Length: 4 Value: 17.0
>> (0018,1310) Acquisition Matrix VR: US Length: 8 Value: 0 144 144 0
>>
>> and saved file:
>>
>> (0010,21C0) Pregnancy Status VR: US Length: 2 Value: 52
>> (0018,0088) Spacing Between Slices VR: DS Length: 2 Value: 1
>> (0018,1310) Acquisition Matrix VR: US Length: 12 Value: 23600 13361 23604
>> 13361 23604 48
>>
>> As suggested earlier, I use the same GDCMImageIO object for reading and
>> writing.
>>
>> Many thanks,
>> Constantine
>>
>>
>> On 16/08/2013 19:13, Bill Lorensen wrote:
>>>
>>> Constantine,
>>>
>>> You found a bug in itk's dicom IO. I'll report it and prepare a patch to
>>> fix it for future users.
>>>
>>> As a workaround, which should work for ITK 3 and ITK4 and hopefully
>>> after I fix the bug:
>>>
>>> 1) If you want to retain the input dicom entries, you should create a
>>> GDCMImageIO and use it for both the input and output.
>>> 2) To work around the itk dicom bug, add these lines AFTER the stats
>>> filter:
>>>    // Set rescale slope and intercept to 1 and 0
>>>    imageReader0->Update();
>>>    typedef itk::MetaDataDictionary   DictionaryType;
>>>    DictionaryType & dict =
>>> imageReader0->GetOutput()->GetMetaDataDictionary();
>>>    itk::EncapsulateMetaData<std::string>( dict, "0028|1052", "0.0");
>>>    itk::EncapsulateMetaData<std::string>( dict, "0028|1053", "1.0");
>>>
>>> NOTE: You need to #include "itkMetaDataObject.h"
>>>
>>> I've attached the your program with all of these changes. Thanks for
>>> your patience,
>>>
>>> Bill
>>>
>> _____________________________________
>> Powered by www.kitware.com<http://www.kitware.com>
>>
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://www.kitware.com/products/protraining.php
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-users
>
>

--
Unpaid intern in BillsBasement at noware dot com
_____________________________________
Powered by www.kitware.com<http://www.kitware.com>

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.itk.org/mailman/listinfo/insight-users
_______________________________________________
Community mailing list
Community at itk.org<mailto:Community at itk.org>
http://public.kitware.com/cgi-bin/mailman/listinfo/community

--
Brian Helba
Medical Imaging
Kitware, Inc.

________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________

--
Brian Helba
Medical Imaging
Kitware, Inc.

________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20131206/d7d7590c/attachment.htm>