[IGSTK-Developers] Image file format

[Julien Jomier]

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