[Insight-users] Reading 4D images from Dicom files, in a generic manner

[David Clunie]

Hi Joel

There are two standard efforts to improve the consistency of
extraction of 3D and 4D volumes for application programmers
who are less interested in the details of DICOM images than
in their use.

One is the new enhanced family of DICOM IODs for CT, MR, PET,
XA, tomosynthesis, OCT, etc., which introduce the concept of the
Dimension Module, which allows for dimensions to be specified
without being terribly concerned about exactly which data
elements vary for each position within a dimension. As an
example of how this might be applicable for perfusion or
diffusion imaging, see the new IHE profiles on the subject,
at:

http://wiki.ihe.net/index.php?title=Radiology_Technical_Committee#Enhanced_CT.2FMR_Supplement

There is expected to be similar work on the cardiac timing
applications done in the next 12 month IHE cycle.

You can find a bunch of presentations on the enhanced
multiframe family of IODs on my web site that include
descriptions of how the Dimensions mechanism works.

Whilst there are currently few devices on the market that use
the enhanced family of objects, you can probably see how this
abstraction might be useful to you, e.g., by building your
own dimension representation for common patterns used by
various different vendors with the "old" DICOM objects
before feeding them to the business logic of your
application that does something with them. That way it
will be easier to add support as the vendors add new
variants and implementations.

The other effort is the so-called "abstract model" of the
DICOM WG 23 API, which is intended to allow the application
host to do the hard work of figuring out the abstraction,
and let the plugin application developer forget about the
nasty details. This is largely based on work contributed
by Bernard Gibaud from Rennes. See:

ftp://medical.nema.org/medical/dicom/supps/sup118_pc.pdf

The Sup 118 work is much less mature than the enhanced family
of objects, and any feedback that you have on it would be
appreciated. It is intended to take advantage of the Dimensions
capability of the new object when available, but is not
dependent on it.

To the extent that the XIP project is tracking the WG 23
interface development, and includes ITK and VTK, you may
find that it includes a sufficiently well-defined abstraction
layer for the concept of dimensions such that you do not
need to reinvent this. If it doesn't, I am sure its
developers would appreciate your feedback:

	http://erl.wustl.edu/research/xip.html
	http://www.openxip.org/

David

Mathieu Malaterre wrote:
> What I am trying to say is: This is easy to order MR Image Storage /
> CT Image Storage in the case of a 4D cardiac acquisition.
> However you will not be able to order Secondary Capture Image Storage,
> you may not be able to order MR Image Storage that represent a DWI/DTI
> series...
> 
> DICOM does not defines "4D data" as ITK expect, but only Multiframe
> Series. So the best we can do it map those in the rare case when they
> are identical.
> 
> How are you planning to send the data ? If this is patient data,
> special care is required to redistribute it.
> 
> thanks for your offer !
> 
> On Wed, May 13, 2009 at 2:21 PM, poireau <joelthelion at laposte.net> wrote:
>> Hi Mathieu,
>>
>> I'm not sure I understand your message. Are you planning to focus only on
>> Cardiac, or are you ready to tackle 2D+t and 3D+t as a whole? Of course the
>> latter would be much more interesting and difficult. I can send you Cardiac
>> Pet, Pulmonary CT and probably Cardiac MR data, would that be enough for a
>> start? I bet some people on this list could send a lot more :)
>>
>> Thanks,
>>
>> joel
>>
>>
>>
>> Mathieu Malaterre wrote:
>>> [top post]
>>>
>>> Yup, Cardiac is an easy case. If you find some datasets (check Osirix
>>> datasets), I volonteer to write the code that will sort in the order
>>> expected by ITK (time is 4th dimension). Then fill in a bug report and
>>> assign it to me.
>>>
>>> Thanks,
>>>
>>> On Wed, May 13, 2009 at 1:44 PM, poireau <joelthelion at laposte.net> wrote:
>>>> Hi Harvey,
>>>>
>>>> thanks for your answer! As I mentioned in my previous post, the
>>>> particular
>>>> arrangement of the dicom files depends on the manufacturer and the
>>>> modality.
>>>> As such it is quite complex to write code that supports all the different
>>>> possibilities. However given the number of people who work on 3D+t or
>>>> 2D+t,
>>>> I think having such code in ITK or GDCM would be very useful and would
>>>> avoid
>>>> a lot of duplicate effort.
>>>>
>>>> joel
>>>>
>>>>
>> --
>> View this message in context: http://n2.nabble.com/Reading-4D-images-from-Dicom-files%2C-in-a-generic-manner-tp2828252p2883389.html

poireau wrote:
> Hi all,
>
> I'm trying to build an "open dicom" function into the open-source 4d image
> viewer vv. I know there is support in ITK to read 3D volumes from many Dicom
> files, but I was wondering if there is something similar for 4D? I've seen
> at least two ways to represent 4D sequences with dicom files:
>
> 1) The CT we are using creates on Dicom Series per time frame
>
> 2) I've seen some cardiac PET images where the whole 4D sequence is in only
> one sequence, with one or more dicom fields used to differentiate the
> different time frames ("Trigger Time", "Content Time")
>
> Manufacturers have probably invented even more ways to do 4D with dicom
> files :-(. So it would definitely be interesting to have an abstraction over
> these, to allow the developer to simply Read() the sequence and get the
> correct 4d image dimensions, without the hassle of dealing with different
> manufacturer schemes.
>
> Does that functionality already exist somehow in ITK or GDCM? Have some
> people on this list already tried to deal with this problem?
>
> Thanks,
>
> joel