[Insight-developers] ImageSpatialObject Bug0006340

Tue Aug 5 16:22:41 EDT 2008

I think it would be possible, but the problem will still arise, just
in a different place.  The base SpatialObject class has the ability to
return Affine transforms representing each of the transformations in
the SpatialObject.   If one of these methods is called, the issue has
to be dealt with in order to create such a transform.

Its a little fuzzy to me how the SpatialObject transform hierarchy
works, but it seems from my reading of the code that it needs to get
these transforms in particular to manage the transforms of the
children of the ImageSpatialObject.

Another potential way out is to not use the image indices as the
SpatialObject indices.  The SpatialObject classes seem to have all the
structure of an image inside - indexes AND world coordinates.  The
current implementation makes the indices of the image in the
ImageSpatialObject consistent with the index structure inside the
SpatialObject.  One could imagine sacrificing that.  The image could
just hang inside the spatial object space in some arbitrary way.
Then, to get the value of a point in the image spatial object, first
the WorldToObject transform of the spatial object would be applied,
then the TransformPhysicalPointToIndex of the image, etc.   I dont
actually think thats the best idea.  But its a possibility.

Rupert

On Tue, Aug 5, 2008 at 3:31 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> More questions:
>
> Can ImageSpatialObject be rewritten to use the Transform methods of
> Image and OrientedImage?
>
> Bill
>
> On Tue, Aug 5, 2008 at 3:26 PM, Stephen Aylward
> <Stephen.Aylward at kitware.com> wrote:
>> So,
>>
>> Should an itkImage always return the identity matrix for its directions?
>>
>> or
>>
>> Should we allow inconsistency between recorded information and actual
>> operation (record, but do not use direction in itkImage)?
>>
>> or
>>
>> Should we do-away with the itkImage without orientation, and should
>> all images be itkOrientedImages?
>>
>>
>> Stephen
>>
>>
>>
>> On Tue, Aug 5, 2008 at 3:19 PM, Rupert Brooks <rupe.brooks at gmail.com> wrote:
>>> 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
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>
>>
>>
>> --
>> Stephen R. Aylward, Ph.D.
>> Chief Medical Scientist
>> Kitware, Inc. - Chapel Hill Office
>> http://www.kitware.com
>> (518) 371-3971 x300
>>
> _______________________________________________
> 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