[IGSTK-Developers] Image file format
Mathieu Malaterre
mathieu.malaterre at kitware.com
Tue Mar 7 09:42:24 EST 2006
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
>
More information about the IGSTK-Developers
mailing list