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

[Hui Zhang]

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
>