[Insight-users] GDCM version upgrade plans for ITK4?

Sun Oct 28 14:43:02 EDT 2012

Hans,

One specific feature I am interested in is the support of DICOM
Segmentation storage and bit-encoded PixelData, which was added in
2.2.0 (see more details in the attached exchange with Mathieu).

Looking at the release notes, 2.2.0 also includes support for
SurfaceSegmentation. All these improvements should allow better
support of various types of DICOM in 3D Slicer. Currently, we are
working on implementing support for Segmentation storage in Slicer,
and we would essentially need to duplicate the functionality available
in GDCM.

Having said that, I have not yet tested the segmentation storage
functionality in GDCM.

I cc Steve in case he has any comments as to how updated GDCM could be
relevant for the other Slicer-related projects.

Here's my earlier communication with Mathieu:

---------- Forwarded message ----------
From: Mathieu Malaterre <mathieu.malaterre at gmail.com>
Date: Sun, Oct 28, 2012 at 1:28 PM
Subject: Re: GDCM support of DICOM SEG PixelData read/write
To: Andriy Fedorov <fedorov at bwh.harvard.edu>
Cc: gdcm-developers <gdcm-developers at lists.sourceforge.net>, Johan
Moreau <johan.moreau at gmail.com>, Steve Pieper
<pieper at bwh.harvard.edu>, David Clunie <dclunie at dclunie.com>

Andriy,

  I have not been following ITK dev in a while, so I cant say much about it.

regards

On Sun, Oct 28, 2012 at 5:52 PM, Andriy Fedorov <fedorov at bwh.harvard.edu> wrote:
> Mathieu,
>
> This sounds very promising!
>
> But it looks to me ITK4 is still using gdcm 2.0.17.
>
> I think the only way Slicer can benefit from the new functionality is
> if it becomes available in ITK4.
>
> Do you know what is the plan (if there is one) of upgrading the gdcm
> version in ITK4?
>
> --
> Andriy Fedorov, Ph.D.
>
> Brigham and Women's Hospital
> Harvard Medical School
> 75 Francis Street
> Boston, MA 02115 USA
> fedorov at bwh.harvard.edu
> (617) 525-6258 (office)
>
>
> On Sun, Oct 28, 2012 at 4:32 AM, Mathieu Malaterre
> <mathieu.malaterre at gmail.com> wrote:
>> Andriy,
>>
>> On Fri, Oct 26, 2012 at 9:51 PM, Andriy Fedorov <fedorov at bwh.harvard.edu> wrote:
>>> Mathieu,
>>>
>>> As you probably know, currently Slicer relies on ITK3/GDCM for loading
>>> DICOM images.
>>>
>>> Recently, we've been working on adding support for handling DICOM
>>> segmentation objects, which essentially are multiframe images that can
>>> have multiple segments encoded in one DICOM object, typically using
>>> bitset encoding for pixel data.
>>>
>>> Currently, we load DICOM SEGs by first identifying the source image
>>> series, loading it using our conventional ITK3/GDCM pipeline,
>>> resetting the content and then uncompressing the bitset pixel buffer
>>> into the image raster. This non-GDCM part of this pipeline is
>>> implemented in a Slicer plugin that handles DICOM SEG objects.
>>>
>>> This current approach is suboptimal for various reasons: we may not
>>> have the source image series reference in the DICOM object and ideally
>>> should use shared and per-frame functional groups sequences to
>>> reconstruct the geometry, and also a module in Slicer is probably not
>>> the right place to do low-level DICOM operations like encoding of the
>>> bitset and handling of DICOM frames.
>>>
>>> So, my question to you is whether there are any plans to support
>>> reading and writing of the pixel data frames stored in DICOM SEG
>>> objects?
>>
>> It is included in GDCM 2.2.0:
>> http://gdcm.sourceforge.net/html/classgdcm_1_1SegmentReader.html
>>
>> See:
>> http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=GDCM_Release_2.2.0
>>
>> A very big thanks to the IRCAD team for sponsoring this development !
>>
>>> When I try to read such an object with ITK4/GDCM, I have the following error:
>>>
>>>    ITKv4/Modules/IO/GDCM/src/itkGDCMImageIO.cxx:391:
>>> itk::ERROR: GDCMImageIO(0x1048f4fc0): Unhandled PixelFormat: 11
>>>
>>> 11 == gdcm::PixelFormat::BITSET. Looking into itkGDCMImageIO.cxx, this
>>> pixel format is not included in the pixel types supported for
>>> read/write.
>>>
>>> Is there a plan to support this pixel type and reading/writing DICOM
>>> SEG pixel data in GDCM?
>>
>> I would guess you are using something before GDCM 2.2.0. Is this correct ?
>>
>> If you can reproduce this with 2.2.1 and or git/master, feel free to
>> ping me again.
>>
>> Thanks.
>> --
>> Mathieu

On Sun, Oct 28, 2012 at 2:24 PM, Johnson, Hans J <hans-johnson at uiowa.edu> wrote:
> Andriy,
>
> 1) Matt McCormick and I recently discussed the need to do this.  I've done
> recent work on GDCM to prepare it for the update in ITKv4.
>
> Is there a there a specific bug fix/ feature that could help motivate the
> effort needed to accomplish updating GDCM?
>
> Hans
>
>
>
> On 10/28/12 12:45 PM, "Andriy Fedorov" <fedorov at bwh.harvard.edu> wrote:
>
>>Hi,
>>
>>If I am not mistaken, ITK4 is currently using GDCM version 2.0.17. The
>>current stable release of GDCM is 2.2.1.
>>
>>Is there any plan for upgrading the version of GDCM used by ITK?
>>
>>--
>>Andriy Fedorov, Ph.D.
>>
>>Brigham and Women's Hospital
>>Harvard Medical School
>>75 Francis Street
>>Boston, MA 02115 USA
>>fedorov at bwh.harvard.edu
>>(617) 525-6258 (office)
>>_____________________________________
>>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
>
>
>
> ________________________________
> 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.
> ________________________________