[IGSTK-Developers] Image file format

[Julien Jomier]

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
>