[IGSTK-Developers] Image file format

[Hui Zhang]

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
>