[IGSTK-Developers] igstkImageReader & ImageSpatialObject

Luis Ibanez luis.ibanez at kitware.com
Thu Sep 8 18:26:36 EDT 2005


Hi Patrick,

You are right,
the itkImageToVTKImageFilter does the equivalent
of putting the vtkImporter and itkExporter together.

The issue here is that the itkImageToVTKImageFilter
is not available in IGSTK. It doesn't make part of
the toolkit. This filter is distributed as part of
InsightApplications, and has been copied in some
occasions from application to application.

For this reason, the reader is taking over its
functionality by calling directly the importer and
exporter. Notice that application developers are not
exposed to these details.

We could consider adding the itkImageToVTKImageFilter
to IGSTK, if we find that ITK-VTK image conversions
will happen in many places. But the expectation of the
design was rather that we will have an IGSTK Image class
with the capability of exposing an ITK image side and
a VTK image side.

As Andinet pointed out, this requires a bit of templates
since the ITK image type will be different depending of
the image modality (CT, MRI, Fluoroscopy).

The code for the conversion should not go into the reader
it should go into the igstkImage. The reader should produce
a specific igstk image modality as output.

E.g.

    igstkCTImageReader->GetOutput() ==>>  igstkCTImage
    igstkMRIImageReader->GetOutput() ==>>  igstkMRIImage
    igstkFluoroscopyImageReader->GetOutput() ==>>
                                           igstkFluoroscopyImage


The definition of image modality is fundamental for the
safety of the surgical procedure, so we must enforce its
consistency in any way we can. E.g. we must make impossible
for an application that expects a CT, to load a MRI by
accident.



   Regards,


       Luis



----------------------
Patrick Cheng wrote:
> Hi Andinet,
> 
> Thank you for your reply.
> 
> For Q2 I mean: The code in the igstkImageReader class, is actually 
> connecting the itkExporter and vtkImporter. like the 
> itkImageToVTKImageFilter does. Which I think it's confusing
> 
> Patrick
> 
> Andinet Enquobahrie wrote:
> 
>> Hello Patrick,
>>
>> You have brought up important points.  Before I comment on  each  
>> item, I want to mention as a general remark that some of these 
>> inconsistencies/confusions are partly due to the new image reader 
>> classes design. As we go further along the development, these flaws 
>> will be flushed out.
>>
>> For example, in the ImageSpatialObject classs, igstkImageReader should 
>> be used instead of igstkCTImageReader class.
>>
>>> I have some question about the design of these two classes.
>>> It seems that the igstkImageReader is essentially a 
>>> itkImageToVTKFilter, and the inheritance relation is:
>>> igstkImageReader <-- igstkDICOMImageReader <-- igstkCTImageReader
>>> and in the igstkImageSpatialObject it uses the CTImageReader and the 
>>> GetVTKImage() method to pass the data to 
>>> ImageSpatialObjectRepresentation. the internal itkImageSpatialObject 
>>> actually is not used at all.
>>> Here is my question:
>>> 1. If we encapsulate the Reader Class into the ImageSpatialObject, it 
>>> will be very hard to extend. (if people wants to read in other kind 
>>> of data). So I think we should separate them and use the 
>>> internalitkImageSpatialObject->SetImage() method to pass the image 
>>> data from reader to igstkImageSpatialObject
>>
>>
>>
>> I don't think this would be a problem once we replace the 
>> CTImageReader with ImageReader class. The new ImageReader class is 
>> templated over input image data type. It was designed this way so that 
>> we can handle different types of data.
>>
>>>
>>> 2. itkImageToVTKFilter is actually a filter, need input image, it 
>>> behaves differently from ImageReader. I think we should not make this 
>>> class to be the base class of igstkImageReader. instead, put it into 
>>> the igstkImageSpatialObjectRepresentation. then we can use this 
>>> filter and the igstkImageSpatialObject->GetImage() method to filter 
>>> the data to VTKImageData and create actor for it.
>>>
>> I am not sure if I understood this question. igstk::ImageReader is 
>> derived from itk:Object. itkImageToVTKfilter is not the base class of 
>> ImageReader...
>>
>>> 3. Also the igstkImageSpatialObjectRepresentation class may be need 
>>> to branch into two class: igstkImageSpatialObject2DRepresentation and 
>>> igstkImageSpatialObject3DRepresentation. b/z we need implement 
>>> different rendering method for 2D (slice) and for 3D (volume or 
>>> surface).
>>
>>
>>
>> Good point....
>>
>>> 4. Also some small requirements: logger need to be added to 
>>> igstkImageSpatialObject; testing program need to be added for 
>>> igstkImageSpatialObjectRepresentation
>>
>>
>>
>> These are missing  components...especially test programs are critical. 
>> We shouldn't add new classes/filters without an accompanying test 
>> program....
>>
>> cheers,
>> -Andinet
>>
>>
>>
> 




More information about the IGSTK-Developers mailing list