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

Brian Helba brian.helba at kitware.com
Fri Dec 6 13:29:18 EST 2013


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>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>
> Date: Friday, December 6, 2013 11:41 AM
> To: Bill Lorensen <bill.lorensen at gmail.com>
>
> Cc: ITK Users <insight-users at public.kitware.com>, Constantine Zakkaroff <
> 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>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> 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>
>> > 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
>> >>
>> >>
>> >> 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
>>
>> 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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20131206/56e45f72/attachment.htm>


More information about the Insight-developers mailing list