[Insight-developers] ImageSpatialObject Bug0006340

Tue Aug 5 16:24:58 EDT 2008

Maybe Image and OrientedImage could have methods that create the
affine transforms?

Bill

On Tue, Aug 5, 2008 at 4:22 PM, Rupert Brooks <rupe.brooks at gmail.com> wrote:
> 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
>