[IGSTK-Developers] Image file format
David Gobbi
dgobbi at atamai.com
Tue Mar 7 10:38:26 EST 2006
Hi Mathieu,
There actually is a standard for multi-dimensional DICOM, I had a
contract where I had to visualize 4D cardiac data a couple years ago.
For Nuclear Medicine (NM) images, the 4D image is stored in a single
file, and for US to though I've never seen a 4D US.
For nuclear medicine, the multi-dimensional module is described in
Chapter 3, C.8.4.8 "NM Multi-frame Module". Ultrasound and X-ray DICOMs
also use multi-frame images to support the time dimension, as described
in Chapter 3, C.7.6.5 "Cine Module". If an ECG was used during the
acquisition, then the ECG waveform is also stored in the DICOM image.
For CT and MR, there is a "Temporal Position Identifier" tag (0020,0100)
is supposed to give the time index for each image in the series, but I
know that not all manufacturers use this tag. I've never found a good,
standardized way of dealing with 4D CT and MR. Instead I just assume
that if any two slices are at the same position, they must be at
different times. Do you use a similar method in ITK to sort a 4D series
into a four-dimensional image?
- David
Mathieu Malaterre wrote:
> Just my two cents:
>
> First of all: there is no 4D DICOM as far as I know. The only way
> to have that is either a series of 3D images, or a multi-series of 2D.
> But anyway the Series should know as little as possible. The Series
> should not do any heuristic about finding the dimension of the output.
> The ImageIO should handle that.
>
> For instance I have a 4D images. How I am supposed to see it ?
> Maybe I would like something different than what's on disk and do for
> example: do a time serie taking a slice at a particular time t0. I
> believe this should work out of the box using the ITK class+GDCM (ie
> ImageIO<Type,2> + SeriesReader).
>
> So I'd suggest IGSTK closely follow ITK. Where the ImageIO effectively
> read the N-D images, and the SeriesImages only deals with a list of
> DICOM files.
>
> 2 cents,
> Mathieu
> Ps: BTW If you are heading toward a per Modality design, keep in mind
> that there are ~40 different modalities (PS 3.3).
>
> enum ModalityType {
> Unknow,
> AU, // Voice Audio
> AS, // Angioscopy
> BI, // Biomagnetic Imaging
> CF, // Cinefluorography
> CP, // Culposcopy
> CR, // Computed Radiography
> CS, // Cystoscopy
> CT, // Computed Tomography
> DD, // Duplex Dopler
> DF, // Digital Fluoroscopy
> DG, // Diaphanography
> DM, // Digital Microscopy
> DS, // Digital Substraction Angiography
> DX, // Digital Radiography
> ECG, // Echocardiography
> EPS, // Basic Cardiac EP
> ES, // Endoscopy
> FA, // Fluorescein Angiography
> FS, // Fundoscopy
> HC, // Hard Copy
> HD, // Hemodynamic
> LP, // Laparoscopy
> LS, // Laser Surface Scan
> MA, // Magnetic Resonance Angiography
> MR, // Magnetic Resonance
> NM, // Nuclear Medicine
> OT, // Other
> PT, // Positron Emission Tomography
> RF, // Radio Fluoroscopy
> RG, // Radiographic Imaging
> RTDOSE, // Radiotherapy Dose
> RTIMAGE, // Radiotherapy Image
> RTPLAN, // Radiotherapy Plan
> RTSTRUCT, // Radiotherapy Structure Set
> SM, // Microscopic Imaging
> ST, // Single-photon Emission Computed Tomography
> TG, // Thermography
> US, // Ultrasound
> VF, // Videofluorography
> XA, // X-Ray Angiography
> XC // Photographic Imaging
> };
>
> Luis Ibanez wrote:
>>
>>
>> Hi Julien,
>>
>>
>> Please note the the specific functionalities needed for
>> reading Ultrasound images should be placed in a class
>> deriving from igstkDICOMImageReader, in order to conform
>> to the hierarchy:
>>
>>
>>
>> ImageReader
>> |
>> |
>> +--DICOMImageReader
>> |
>> |
>> +--CTImageReader
>> |
>> |
>> +--MRIImageReader
>> |
>> |
>> +--USImageReader
>>
>>
>>
>> If the DICOMImageReader needs to be modified in order
>> to read a single DICOM slice, this should be a mode
>> controlled by its StateMachine. That mode should be
>> set only once and not be reversible, since it will be
>> requested from the derived classes, and therefore it
>> will be specific to the modality.
>>
>> The mode should control a State that goes before the
>> selection of the directory name. The "Request" methods
>> for selecting the mode must be protected, so only the
>> derived classes are allowed to call them. Those methods
>> must not be part of the public API.
>>
>>
>> RealTime capture should be modeled in an independent
>> hierarchy. Probably deriving from the "ImageReader"
>> class. We could anticipate to have real-time capture
>> from fluoroscopic images, CT fluoroscopy, microscopy
>> (for neurosurgery), color video (for laparoscopy) and
>> ultrasound.
>>
>>
>>
>>
>> Luis
>>
>>
>>
>> ------------------------
>> Julien Jomier wrote:
>>
>>> I have the DICOMImageReader working now. I'll check this in the
>>> sandbox tomorrow.
>>>
>>> Julien
>>>
>>> Hui Zhang wrote:
>>>
>>>> Hi, Julien,
>>>>
>>>> I agree. Some single DICOM file contains the 3D and even 4D
>>>> information. So should we enhance igstkDICOMImageReader to make it
>>>> accept single file input? May just have a parallel itkImageReader
>>>> variable in the class to handle the single file input, and the
>>>> output is switched between itkImageReader and itkImageSeriesReader
>>>> depending on the input?
>>>>
>>>> You are right. The test of 3D/2D image registration class
>>>> definitely need a ultrasound image file input. The ultrasound image
>>>> should not be restricted in real-time capture.
>>>>
>>>> Regards,
>>>> James
>>>>
>>>> ----- Original Message ----- From: "Julien Jomier"
>>>> <julien.jomier at kitware.com>
>>>> To: "Hui Zhang" <zhang at isis.imac.georgetown.edu>
>>>> Cc: "'IGSTK-developers'" <igstk-developers at public.kitware.com>
>>>> Sent: Monday, March 06, 2006 6:11 PM
>>>> Subject: Re: [IGSTK-Developers] Image file format
>>>>
>>>>
>>>>> Hi James,
>>>>>
>>>>> I agree with you, we need an igstkBufferedImage class. I'll work
>>>>> on that soon.
>>>>>
>>>>> The problem with the DICOM having only one slice is not only a
>>>>> problem with Ultrasound images but some 3D DICOM files can be
>>>>> stored in only one file. Also, I don't see why Ultrasound images
>>>>> should be restricted to real-time capture.
>>>>>
>>>>> Julien
>>>>>
>>>>> Hui Zhang wrote:
>>>>>
>>>>>> Hi, Julien,
>>>>>>
>>>>>> Regard the ultrasound images, I think it should be from a stream,
>>>>>> either video grabbing or acquired, not from a saved file.
>>>>>> Ultrasound image is used for real-time image display in the
>>>>>> application, while reading from a single file means it is not a
>>>>>> live or real-time image. For the research, the saved ultrasound
>>>>>> image will be useful.
>>>>>>
>>>>>> In my ultrasound application, pre-operative CT or MR images are
>>>>>> from DICOM images, and the ultrasound image is directly from
>>>>>> firewire port transfer. I used an image buffer to fill the
>>>>>> real-time ultrasound data. So perhaps we need an
>>>>>> igstkBufferedImage or igstkStreamImage for ultrasound, not from
>>>>>> igstkDICOMImageReader? igstkBufferedImage may provide a function
>>>>>> to fill the data from various input?
>>>>>>
>>>>>> 2 cents,
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> James
>>>>>>
>>>>>> ----- Original Message ----- From: "Julien Jomier"
>>>>>> <julien.jomier at kitware.com>
>>>>>> To: <cleary at georgetown.edu>
>>>>>> Cc: "'IGSTK-developers'" <igstk-developers at public.kitware.com>
>>>>>> Sent: Monday, March 06, 2006 5:13 PM
>>>>>> Subject: Re: [IGSTK-Developers] Image file format
>>>>>>
>>>>>>
>>>>>>> Ok DICOM it is... I agree it's better, but we can still read a
>>>>>>> DICOM without any patient information so I don't really see the
>>>>>>> difference (why is this not handled by the state machine BTW?)
>>>>>>>
>>>>>>> Anyways. The current implementation of the DICOMImageReader is
>>>>>>> using the itkImageSeriesReader which requires at least two
>>>>>>> filenames, this assumption is not true since a 2D Ultrasound
>>>>>>> image has only one slice. How should we deal with this? Can we
>>>>>>> just bypass the SeriesReader if there is only one slice?
>>>>>>>
>>>>>>> I'm open to suggestions, thanks,
>>>>>>>
>>>>>>> Julien
>>>>>>>
>>>>>>> Kevin Cleary wrote:
>>>>>>>
>>>>>>>> Hi guys
>>>>>>>>
>>>>>>>> I agree with Luis on this one - I like to stick with DICOM
>>>>>>>> because it is
>>>>>>>> also traceable from the header - meaning I can tell on what
>>>>>>>> scanner and
>>>>>>>> where it came from
>>>>>>>>
>>>>>>>> Kevin
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From:
>>>>>>>> igstk-developers-bounces+cleary=georgetown.edu at public.kitware.com
>>>>>>>> [mailto:igstk-developers-bounces+cleary=georgetown.edu at public.kitware.com]
>>>>>>>>
>>>>>>>> On Behalf Of Luis Ibanez
>>>>>>>> Sent: Monday, March 06, 2006 3:32 PM
>>>>>>>> To: Andinet Enquobahrie
>>>>>>>> Cc: 'IGSTK-developers'
>>>>>>>> Subject: Re: [IGSTK-Developers] Image file format
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Andinet, Julien,
>>>>>>>>
>>>>>>>> Adding fileformats different from DICOM will compromise the
>>>>>>>> safety level of IGSTK.
>>>>>>>>
>>>>>>>> Having gdcm in ITK we can save any image in DICOM format.
>>>>>>>>
>>>>>>>> You can convert your MetaImage file in to DICOM by using
>>>>>>>> the examples in Insight/Examples/IO. Then load that DICOM
>>>>>>>> file into your IGSTK application.
>>>>>>>>
>>>>>>>>
>>>>>>>> I would suggest that we stick to supporting *only DICOM*
>>>>>>>> as the only format that is safe enough for being used in
>>>>>>>> the surgery room.
>>>>>>>>
>>>>>>>>
>>>>>>>> The MetaImage format has the recent addition of anatomical
>>>>>>>> information and orientation, but those entries are optional.
>>>>>>>>
>>>>>>>> MetaImage doesn't carry information about PatientName, or patient
>>>>>>>> ID, which makes it extremely dangerous in a clinical environment.
>>>>>>>>
>>>>>>>> It would be too easy to load the image of the wrong patient,
>>>>>>>> and an IGSTK application would not have a way of raising a flag.
>>>>>>>>
>>>>>>>>
>>>>>>>> Also, in its current state it is too easy to modify a MetaImage
>>>>>>>> headers with an editor and to corrupt a file.
>>>>>>>>
>>>>>>>>
>>>>>>>> Please remember that the conveniences that you may want
>>>>>>>> to have while you are developing prototypes for research,
>>>>>>>> are the same risky operations that can harm a patient during
>>>>>>>> an actual surgical intervention. IGSTK is not supposed to
>>>>>>>> behave like Matlab.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> My 2 Cents,
>>>>>>>>
>>>>>>>>
>>>>>>>> Luis
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------
>>>>>>>> Andinet Enquobahrie wrote:
>>>>>>>>
>>>>>>>>> Julien Jomier wrote:
>>>>>>>>>
>>>>>>>>>> Andinet,
>>>>>>>>>>
>>>>>>>>>> The liver MR has been converted to isotropic voxels and saved
>>>>>>>>>> as MetaImage. Looking at the igstkMRImageReader class, this
>>>>>>>>>> one derives from DICOM image reader, so right now I don't
>>>>>>>>>> know how to read an MR volume using MetaImage.
>>>>>>>>>> Should I create an igstkMetaImageMRImageReader class?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Julien,
>>>>>>>>>
>>>>>>>>> As we chatted on IM and agreed, I think igstkMetaImageReader
>>>>>>>>> class templated by image type would be fine unless the other
>>>>>>>>> developers think of a different approach.
>>>>>>>>>
>>>>>>>>> -Andinet
>>>>>>>>>
>>>>>>>>>> The ultrasound images are in the spatialobject file format
>>>>>>>>>> right now. I can try to convert them to metaImage or just
>>>>>>>>>> read them directly since IGSTK seems to support several file
>>>>>>>>>> formats.
>>>>>>>>>>
>>>>>>>>>> Let me know,
>>>>>>>>>>
>>>>>>>>>> Julien
>>>>>>>>>>
>>>>>>>>>> Andinet Enquobahrie wrote:
>>>>>>>>>>
>>>>>>>>>>> Julien,
>>>>>>>>>>>
>>>>>>>>>>> The image reader classes are designed in such a way that we
>>>>>>>>>>> can also support non-DICOM images. The Dicom image reader
>>>>>>>>>>> class is derived from the "ImageReader" superclass which you
>>>>>>>>>>> can use to derive a MetaImageReader class. Are your
>>>>>>>>>>> Ultrasound images in MetaImage forma?
>>>>>>>>>>>
>>>>>>>>>>> -Andinet
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -Andinet
>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> Are we going to support only DICOM for image reading?
>>>>>>>>>>>> I've a MetaImage file that I want to read in (from the
>>>>>>>>>>>> original dicom but preprocessed). I can convert it to DICOM
>>>>>>>>>>>> but I'd rather read it in directly.
>>>>>>>>>>>>
>>>>>>>>>>>> thanks for the input,
>>>>>>>>>>>>
>>>>>>>>>>>> Julien
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
More information about the IGSTK-Developers
mailing list