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

[David Gobbi]

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
>>
>
>
>