[Insight-developers] ImageSpatialObject Bug0006340

[Rupert Brooks]

Hi Bill,

Thats just the thing - the ImageSpatialObject does NOT use
TransformXtoY calls, because it has its own internal transformation
system.  It copies the information out of the image that it is given
and uses that as the spatial object IndexToWorld transform.  The bug
was caused because previously it did not copy the direction - this is
easily fixed.

The tricky issue is that itk::Image always behaves as though its
direction is identity - but this is not enforced.  Its entirely
possible to put a non-identity direction in itk::Image.  This is not
used in the TransformXtoY calls of the image - but it is returned by
the GetDirection method.  So when i copy the direction information, if
there is some in the itk::Image, it breaks the test.

As you can probably guess, i discovered that by accident.

I agree that itk::Image should not behave differently inside and
outside a Spatial object.   As I see it, theres 4 options - I think
its a design decision which is why im bringing it up here.

1. Explicitly test for the itk::Image case inside itk::SpatialObject,
and ignore its directions
    This will run into problems with subclasses of itk::Image - and
not all subclasses can be treated the same way.  Which leads to #2

2. Explicitly test for the itk::OrientedImage case inside
itk::SpatialObject and only use the direction in that case
    This runs into the reverse problem, that if another subclass of
itk::Image with direction information is used, it will break when used
in the itk::ImageSpatialObject.    Perhaps I am biased against this
because i actually have such a class in my code.   No such class
currently exists in ITK, that i know of.

3. Consider this a conceptual bug in itk::Image, and force the
itk::Image GetDirection method to always return identity.
    I think this is the most correct answer, but i fear backward
compatibility consequences.

4. Ignore the issue, and assume/hope that users wont put direction
cosines in an itk::Image anyway.
    This is by far the easiest approach, but i don't like knowing a
potential bug exists and not fixing it.  These type of sins always
seem to come back to haunt me :-)

Rupert

On Tue, Aug 5, 2008 at 2:08 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Rupert,
>
> In general, itkImage directions are ignored (assumed identity).
> itkOrientedImage directions are used. I have not looked at the
> ImageSpatialObject yet. If it uses Transform{X}To{Y} type calls, then
> Image and OrientedImage should behave properly. I don't think itkImage
> should behave differently inside and outside of itkImageSpatialObject.
>
> Bill
>
> On Tue, Aug 5, 2008 at 1:58 PM, Rupert Brooks <rupe.brooks at gmail.com> wrote:
>> Hi Everyone,
>>
>> As Luis wisely suggested i waited until after the 3.8 release to work
>> on this  :-)  I still need some big picture advice thoug
>>> Please note that the first action to take, even before experimenting
>>> with a fix, is to add a tests that illustrates the failure. E.g. to
>>> add a test that exercise the condition you have identified as
>>> problematic.
>>
>> I've added the test (itkImageMaskSpatialObjectTest2), and you all
>> should notice it failing in your dashboards shortly :-)
>>
>> Theres more than one way to patch the problem - i'll refer back to my
>> previous email.  I think theres a conceptual bug, or at least
>> confusion in the itk::Image. I cant decide how i should make
>> ImageSpatialObject behave when handed an ITK image that has
>> non-identity directions.
>>
>>>> Briefly, the image spatial object takes the coordinate transform from
>>>> the image that it is given, and uses that as its IndexToWorld
>>>> transformation.  Previously, it was ignoring the direction.  The fix
>>>> was a matter of adding the necessary lines to copy the direction
>>>> information also.
>>>>
>>>> However, this fix raises a further issue, and I'd like advice:
>>>>
>>>> The itk::Image class may have a non-identity direction component, but
>>>> it always ignores it.  However, a naive implementation of my fix would
>>>> use that direction information, giving a different behavior than the
>>>> itk::Image.  I could write code to check if its an ITK image, and then
>>>> behave differently, but this seems inelegant at best.   Is this
>>>> actually another bug - should an itk::Image always have an identity
>>>> direction, to conform with its behavior?  Can i ignore the issue,
>>>> assuming the user will be bright enough to only put direction
>>>> information in an itk::Image for a very good reason.
>>
>> Does anyone have some insights into how the itkImageSpatialObject
>> should behave when handed an itk::Image which has non-identity
>> direction cosines?
>>
>> (the bug in question is this one
>> http://public.kitware.com/Bug/view.php?id=0006340)
>>
>> Cheers
>> Rupert B.
>>
>>
>> --
>> --------------------------------------------------------------
>> Rupert Brooks
>> McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
>> Ph.D Student, Electrical and Computer Engineering
>> http://www.cyberus.ca/~rbrooks
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>



-- 
--------------------------------------------------------------
Rupert Brooks
McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
Ph.D Student, Electrical and Computer Engineering
http://www.cyberus.ca/~rbrooks