[IGSTK-Developers] Multi-frame single-file DICOMs

[Hui Zhang]

Hi,

I checked the draft standard, and seems the data is not following the draft 
standard to my knowledge.

James

----- Original Message ----- 
From: "David Gobbi" <dgobbi at atamai.com>
To: "Hui Zhang" <zhang at isis.imac.georgetown.edu>
Cc: "Andinet Enquobahrie" <andinet.enqu at kitware.com>; "'IGSTK-developers'" 
<igstk-developers at public.kitware.com>; "Mathieu Malaterre" 
<mathieu.malaterre at kitware.com>
Sent: Wednesday, March 15, 2006 12:23 PM
Subject: Re: [IGSTK-Developers] Multi-frame single-file DICOMs


>I found the draft DICOM standard for 3D/4D ultrasound.  The latest draft is 
>dated October 2003.
> I don't know if the Philips 4D machine follows this draft standard, or how 
> close this draft standard
> is to being finalized.
> ftp://medical.nema.org/medical/dicom/supps/sup43_07.pdf
>
> Here is quote from the draft document:
>
>  The existing ultrasound standard is a 2D image standard, and cannot 
> represent the 3D and 4D
>  image data that ultrasound imaging devices now create. These new 
> modalities need the ND
>  (multi-dimensional) framework of Supplement 63. This Supplement 
> introduces a new SOP
>  Classes to store 3D/4D ultrasound instances.
>
> The DICOM "Supplement 63: Multi-Dimensional Interchange" document is 
> collection of suggestions
> on how DICOM could be extended to support multi-dimensional data:
> ftp://medical.nema.org/medical/dicom/supps/sup63_pc.pdf
>
> Here is a quote from Supplement 63:
>
>  This Supplement introduces a new IE for to represent multi-dimensional 
> data of any clinical specialty,
>  modality, or post-processing application. This IE supports the following 
> features:
>   -  Supports and extends the multi-frame encoding approach for viewable 
> image data.
>   -  Encoding medical imaging data with spatial, temporal, acquisition and 
> channel (property) dimensions,
>      in a modality independent way.
>   -  Generic exchange of ND data (any modality)
>   -  Volumetric representation of tissue classified segmentations (binary 
> or probabilistic) -- i.e. as bit maps
>       rather than boundary representations
>   -  Non-uniform sampling rates such as those used in triggered 
> acquisition or other acquisition protocols
>
>
> How is this relevant to IGSTK?  Well, it shows that 3D ultrasound DICOM 
> files are part of a
> proposed "next generation" multi-frame DICOM file standard.  If we want 
> IGSTK to support
> 3D ultrasound, it looks like we would need to add a new DICOM reader with 
> a new state
> machine that supports 3D multi-frame DICOM files.
>
> - David
>
>
> Hui Zhang wrote:
>> Hi,
>>
>> I worked on the ultrasound images, and recently I got a multi-frame 
>> ultrasound DICOM image. At first I thought it was a 3D data, but finally 
>> realized it is a 4D ultrasound data, in a single DICOM file.
>>
>> This file is got from a Philips 3D ultrasound machine. Cause the 3D 
>> ultrasound is becoming more and more popular, IGSTK may need take into 
>> consideration whether to support this kind of image format. As David 
>> pointed out, I am also not sure whether the 3D ultrasound standard is in 
>> draft or not, for I found the value of one dimension's size is in a 
>> private tag, just for Philips.
>>
>> Thanks,
>> James
>>
>> ----- Original Message ----- From: "David Gobbi" <dgobbi at atamai.com>
>> To: "Andinet Enquobahrie" <andinet.enqu at kitware.com>
>> Cc: "'IGSTK-developers'" <igstk-developers at public.kitware.com>
>> Sent: Tuesday, March 14, 2006 6:04 PM
>> Subject: Re: [IGSTK-Developers] Multi-frame single-file DICOMs
>>
>>
>>> Hi Andinet,
>>>
>>> Some ultrasound machines produce multi-frame 3D DICOM files, and I think 
>>> that all 3D nuclear medicine images are multi-frame.
>>>
>>> I'm pretty sure that CT, MR and PET images are never multi-frame, unless 
>>> the frames are used for cine.  If conversion utilities create 
>>> multi-frame 3D MR or CT images, then those utilities are probably 
>>> stretching the DICOM standard, if not breaking it outright.
>>>
>>> So the images that we have to worry about for IGSTK are 3D ultrasound 
>>> scans.  I've used a 3D ultrasound machine, and it produces multi-frame 
>>> 3D image files.  I don't know if all 3D ultrasound machines produce 
>>> multi-frame 3D DICOM files, but some of them certainly do.
>>>
>>> All the answers about what is standard and what isn't are in Chapter 3 
>>> of the DICOM standard.  My 2003 copy of the standard only mentions 3D 
>>> multi-frame images for nuclear medicine.  I suspect that the standards 
>>> for 3D ultrasound were still in draft then, since 3D ultrasound is a 
>>> very recent modality.
>>>
>>> - David
>>>
>>>
>>> Andinet Enquobahrie wrote:
>>>> Folks,
>>>>
>>>> On the tcon last week, we discussed about the need to modify the dicom 
>>>> reader to allow multi-frame single-file DICOMs.  Luis and I looked at 
>>>> the changes that need to be made in the  DICOMImageReader class state 
>>>> machine design to support this type of dicom files. Supporting this 
>>>> type of dicom files necessitates adding a new state and several changes 
>>>> in the transition matrix. .
>>>>
>>>> This significant change in the design made us think about the 
>>>> motivation behind this feature add-on. We learnt from Julien that he 
>>>> made this request due to the MRI dicom file he generated from an MRI 
>>>> image he has in Meta data format. Julien used ITK Image IO filter for 
>>>> this conversion. In close inspection of the image file writer, we 
>>>> realized that the filter was doing the conversion incorrectly. The 
>>>> image file writer will be fixed soon. Hence,  Julien wont have a 
>>>> problem with his MRI dicom after the fix. But, the bigger question is 
>>>> how common are multi-frame single dicom files to justify the changes in 
>>>> igstk DICOM image reader class?
>>>>
>>>> Any thoughts?
>>>>
>>>> -Andinet
>>>>
>>>> _______________________________________________
>>>> IGSTK-Developers mailing list
>>>> IGSTK-Developers at public.kitware.com
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>>
>>>
>>> _______________________________________________
>>> IGSTK-Developers mailing list
>>> IGSTK-Developers at public.kitware.com
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>
>>
>>
>>
>
>
>