[IGSTK-Developers] Image file format

Julien Jomier julien.jomier at kitware.com
Mon Mar 6 21:55:44 EST 2006 

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

More information about the IGSTK-Developers mailing list