[Insight-users] itkImageFunction

[Miller, James V (Research)]

Martin, 

As we move towards the OrientedImage, the transformation from physical to 
continuous index can include rotations and permutations.  So the check
will not be a simple axi-align box check in physical coordinates.

The good news is that we have been experimenting with using template
meta programming to perform the transformation from physical to index.
This allows the OrientedImage to tranform coordinates as fast or faster
than Image.  We still have some work to do on this and then it will 
be moved up into Image so it will benefit as well.

We'd have to look at the each of the virtual functions that you are 
concerned about.  I would guess that most of the ones you would want
to make nonvirtual cannot be made so.  But a few of them might.

Jim



-----Original Message-----
From: insight-users-bounces+millerjv=crd.ge.com at itk.org
[mailto:insight-users-bounces+millerjv=crd.ge.com at itk.org]On Behalf Of
Martin Urschler
Sent: Tuesday, June 21, 2005 1:27 PM
To: insight-users at itk.org
Subject: [Insight-users] itkImageFunction


hi,

i was looking through the implementation of the itkImageFunction

1.
---
i'd like to get some feedback on modifying the method
virtual bool IsInsideBuffer( const PointType & point ) const
{
    ContinuousIndexType index;
    m_Image->TransformPhysicalPointToContinuousIndex( point, index );
    return this->IsInsideBuffer( index );
}

Since there are two function calls in this method which is heavily used 
in registration and resampling applications, I'd suggest to cache the 
bounds of the physical domain as well:

virtual bool IsInsideBuffer( const PointType & point ) const
{
    for ( unsigned int j = 0; j < ImageDimension; ++j )
    {
       if ( point[j] < m_StartPhysicalPoint[j] ) { return false; };
       if ( point[j] > m_EndPhysicalPoint[j] ) { return false; };
    }
    return true;
}


m_StartPhysicalPoint and m_EndPhysicalPoint are calculated in the 
SetInputImage method similar to the other cached values

My concern is that it might have some problems with buffered and 
requested regions, but I'm not sure about that.

I would modify the SetInputImage method like that:

typename InputImageType::SpacingType spacing = ptr->GetSpacing();
typename InputImageType::PointType origin = ptr->GetOrigin();

for ( unsigned int j = 0; j < ImageDimension; ++j )
{
    m_EndIndex[j] = m_StartIndex[j] + static_cast<IndexValueType>(
                    size[j] ) - 1;
    m_StartContinuousIndex[j] = static_cast<CoordRepType>(
                                m_StartIndex[j] );
    m_EndContinuousIndex[j] = static_cast<CoordRepType>( m_EndIndex[j] );

    m_StartPhysicalPoint[j] = origin[j];
    m_EndPhysicalPoint[j] = origin[j] + size[j] * spacing[j];
}

What do you think about that?

After thinking about it some longer, one might even include the start 
index and the size of the buffered region into the calculations of the 
start and end physical points, to tackle the region problem.



2.
---
Another thing:
if we could get rid of the 'virtual' in front of those isInsideBuffer 
methods and some of the evaluate methods, the compilers would be able to 
inline those short code fragments, but since I'm not really familiar 
with all overall design decisions, I'm not sure if this is possible.


Martin

_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users