[IGSTK-Developers] Image file format

Hui Zhang zhang at isis.imac.georgetown.edu
Mon Mar 6 19:55:39 EST 2006 

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

More information about the IGSTK-Developers mailing list