[IGSTK-Developers] Image file format
Hui Zhang
zhang at isis.imac.georgetown.edu
Tue Mar 7 11:32:01 EST 2006
Hi, Mathieu,
I recently touched a single DICOM file with 4D information. It is maybe an
extension to existed DICOM format.
2 cents.
James
----- Original Message -----
From: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
To: "Luis Ibanez" <luis.ibanez at kitware.com>
Cc: "'IGSTK-developers'" <igstk-developers at public.kitware.com>
Sent: Tuesday, March 07, 2006 9:42 AM
Subject: Re: [IGSTK-Developers] Image file format
> 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