[IGSTK-Developers] Image file format

Julien Jomier julien.jomier at kitware.com
Tue Mar 7 09:50:58 EST 2006 

Hi Luis,

Thanks for the explanation. So I already created a USImageReader that 
returns a USImageSpatialObject.

The DICOM reading for only one slice is *not* specific to the Ultrasound 
modality. For instance, if I convert my MR MetaImage file using GDCM, 
I'll get only one file that stores the 3D MRI. I've fixed the 
DICOMImageReader so that it also reads a directory with only one file 
(without setting any flags). Do you see any issues in doing this?

Regarding the real-time capture, I like the idea of deriving from the 
ImageReader, I'll see what I can do.

Julien

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
>>
>>
> 
>

More information about the IGSTK-Developers mailing list