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

[Mathieu Malaterre]

David Gobbi wrote:
> 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.

	There is no doubt about it, multi frame DICOM images are fairly common. 
Maybe not as common as single frame though.

	After discussion with Luis, my understanding was that the state machine 
would duplicate a lot of code if we were to support multi frame images.

	So instead of moving all the controls at IGSTK level, I suggested to 
have a 'wizard' in gdcm. And the wizard would be an abstract layer on 
the underlying physical (on disk) representation of the series: either a 
single multiframe file, or a series of single frames.

	IGSTK would then only send request on how many slice there is, what is 
the patient name...Hopefully this would still make the state machine 
lightweight and not redundant.

	Of course, the initial problem was created only by a deficiency in the 
current ITK-GDCM implementation, therefore the need for multiframe 
images is not very strong right now.

My 2 cents,
Mathieu