[Insight-users] Bug in itkUnaryFunctorImageFilter

[Miller, James V (Research)]

Koen,

What is the nature of the extra information in your subclass to Image?

Is it dimension specific like spacing and origin?

The question is how to support the copying of general information in 
a way that makes sense.  If the input and output to a filter are
different dimensions, then the filter and not the data object is 
the only one that will know what subset of the information to copy.
So calling output->CopyInformation(input) will have no chance of 
doing the right thing when the dimensions of the images are different
since only the filter will know the intent. 

This is why the UnaryFunctorImageFilter made the diversion from 
calling the superclass method. 

Some options:

1) Force UnaryFunctorImageFilter to call the superclass' version
of GenerateOutputInformation (and hence CopyInformation) and place
a try catch around it.  This will also require all overrides to 
GenerateOutputInformation to also place the call to their superclass'
version in try/catch blocks. 

I am not terribly happy with this since quite a few exceptions can 
be thrown in this case.  It would be like "Try this. No. Try this. No.
Try this. No.  Try this. Okay".

2) Provide another method for copying "extra" information an image class
may be carrying around.  This would be a "blind" copy with no
interpretation of the information.  We would not expect most filters
to even look at the information.  It would just be along for the ride.

3) Extend the CopyInformation() method in Image such that it can ask
an image's Source for hints on how to copy the information.  If an 
image has no Source, then some default implementation would be used.

I on the fence here.  On one hand, the original design (CopyInformation)
allowed the DataObject to determine what and how to copy.  On the other
hand, the new design allows the filter to define what and how to copy.

There is also a question on what to do when the input to a filter is a 
standard image and the output of a filter is one of your subclass' of 
image or vice versa.

Jim





-----Original Message-----
From: Koen Van Leemput [mailto:koen.vanleemput@hus.fi]
Sent: Friday, May 16, 2003 4:53 AM
To: insight-users@public.kitware.com
Subject: [Insight-users] Bug in itkUnaryFunctorImageFilter


Hi,

itkUnaryFunctorImageFilter overrides itkProcessObject's default
implementation 
of GenerateOutputInformation(), but fails to call 
Superclass::GenerateOutputInformation() prior to changing the information 
values it needs. While the comments in itkUnaryFunctorImageFilter.txx 
indicate that this behavior is intentional, it's actually a bug since the 
information values of subclasses of itkImage don't get copied as they
should. 
Indeed, such subclasses may have their own additional information and the 
corresponding implementation of CopyInformation() to push this information 
through the ITK pipeline. However, itkUnaryFunctorImageFilter only handles 
Spacing and Origin, and never calls the CopyInformation() method of its 
output image.

It appears that the reason for not calling the superclass' implementation of

GenerateOutputInformation(), is that itkImageBase and itkImage will throw 
exceptions if the input image and output image of itkUnaryFunctorImageFilter

have different dimensions. So IMHO, itkUnaryFunctorImageFilter should either

catch this exception, or then itkImageBase and itkImage should not throw 
exceptions at all...

- Koen





_______________________________________________
Insight-users mailing list
Insight-users@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-users