[Insight-users] Flaw in ITK? : orientation of images

[Luis Ibanez]

Hi Koen,

We are evaluating how these changes could impact
the performace of registration methods.

The concern is that the ImageInterpolator classes
that derive from ImageFunction are invoked for
every pixel of an image during the computation
of the metrics in the registration process.

Delegating the computation of the point-index
transform to the image will introduce an overhead
per pixel. These overhead is paid millions of
times during the evaluation of the metric.

On the bright side, a genera transform is a nice
to have functionality and the code changes are
relatively small.

One option to keep in mind is that it is sometimes
easier to resample a volume before passing it to
the registration process.

Once we get some timimng for both approaches we
could be able to make a better decision.

So, stay tunned...


    Luis


===============================================

Koen Van Leemput wrote:
> Hi,
> 
> In ITK, itk::Image comes with an IndexToPhysicalTransform and its inverse 
> PhysicalToIndexTransform that defines how coordinates in the index space map 
> into coordinates in the "real-world" physical space and vice versa. In 
> itk::Image, these transforms are AffineTransforms that take into account the 
> spacing of the voxels (scaling) and the position of the origin (translation).
> 
> In many medical image processing applications, however, there is a need for 
> additional positioning information, defining how the patient is oriented with 
> respect to the image coordinate system. Examples include flipping and 
> swapping of image axes, gantry tilt in CT images, interfacing with other 
> image processing tools (SPM, 3D Slicer, ...), and proper handling of various 
> medical image formats (DICOM, SPM, ...). 
> 
> Because of these reasons, I decided to go for it and derive a class from 
> itk::Image that builds m_IndexToPhysicalTransform (and 
> m_PhysicalToIndexTransform by) by composing the standard scaling and 
> translation with an additional affine transform that defines orientation. 
> Apart from some convenience methods to manipulate this orientation, I 
> overloaded itk::Image::RebuildTransforms() and itk::Image::CopyInformation(), 
> and voila, it works: the orientation information travels nicely through the 
> ITK pipeline.
> 
> BUT... things are messed up by what seems to me a design flaw in 
> itk::ImageFunction. Indeed, rather than using 
> itk::Image::TransformPhysicalPointToContinuousIndex() to convert a point in 
> physical space into an index in the image grid, itk::ImageFunction for some 
> reason provides its own implementation 
> itk::ImageFunction::ConvertPointToContinuousIndex that noisily ignores 
> whatever PhysicalToIndexTransform the image at hand actually uses. This 
> messes up all the registraton metrics and itk::ResampleImageFilter, where the 
> following construction is typically used:
> 
>     m_FixedImage->TransformIndexToPhysicalPoint( inputIndex, inputPoint );
>     transformedPoint = m_Transform->TransformPoint( inputPoint );
>     if( m_Interpolator->IsInsideBuffer( transformedPoint ) )
>       {
>       movingValue  = m_Interpolator->Evaluate( transformedPoint );
>       [clip clip]     			
>       }
> 
> (Note that also itk::ImageFunction::IsInsideBuffer() doesn't handle things 
> properly here neither)
> 
> As I see it, itk::ImageFunction::IsInsideBuffer() and 
> itk::ImageFunction::ConvertPointToContinuousIndex() should use the 
> implementation provided by itk::Image. To avoid inefficiencies induced by 
> converting from physical space into index space twice, the following 
> construction should probably be considered:
> 
>     m_FixedImage->TransformIndexToPhysicalPoint( inputIndex, inputPoint );
>     transformedPoint = m_Transform->TransformPoint( inputPoint );
>     m_MovingImage->TransformPhysicalPointToContinuousIndex(
>                               transformedPoint, transformedIndex );
>     if( m_Interpolator->IsInsideBuffer( transformedIndex ) )
>       {
>       movingValue  = m_Interpolator->Evaluate( transformedIndex );
>       [clip clip]     			
>       }
> 
> 
> More in general, is support in ITK for orientation planned any time in the 
> future? After all, the fiddling around with itk::PermuteAxesImageFilters 
> itk::FlipImageFilters in the registration examples seems quite cumbersome...
> 
> Cheers,
> 
> Koen
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-users
> 
>