[IGSTK-Developers] Image file format
Luis Ibanez
luis.ibanez at kitware.com
Tue Mar 7 08:04:24 EST 2006
Hi Julien,
Please note the the specific functionalities needed for
reading Ultrasound images should be placed in a class
deriving from igstkDICOMImageReader, in order to conform
to the hierarchy:
ImageReader
|
|
+--DICOMImageReader
|
|
+--CTImageReader
|
|
+--MRIImageReader
|
|
+--USImageReader
If the DICOMImageReader needs to be modified in order
to read a single DICOM slice, this should be a mode
controlled by its StateMachine. That mode should be
set only once and not be reversible, since it will be
requested from the derived classes, and therefore it
will be specific to the modality.
The mode should control a State that goes before the
selection of the directory name. The "Request" methods
for selecting the mode must be protected, so only the
derived classes are allowed to call them. Those methods
must not be part of the public API.
RealTime capture should be modeled in an independent
hierarchy. Probably deriving from the "ImageReader"
class. We could anticipate to have real-time capture
from fluoroscopic images, CT fluoroscopy, microscopy
(for neurosurgery), color video (for laparoscopy) and
ultrasound.
Luis
------------------------
Julien Jomier wrote:
> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> 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