[Insight-developers] m_EndContinuousIndex[j] vs m_EndIndex[j]

[Michel Audette]

Hi Luis,

I'm wondering about the logic that we implemented below in
itkImageFunction.txx...
void
ImageFunction<TInputImage, TOutput, TCoordRep>
::SetInputImage(
  const InputImageType * ptr )
...
      m_EndIndex[j] = m_StartIndex[j] + static_cast<IndexValueType>( size[j]
) - 1;
#ifdef ITK_USE_CENTERED_PIXEL_COORDINATES_CONSISTENTLY
      m_StartContinuousIndex[j] = static_cast<CoordRepType>( m_StartIndex[j]
- 0.5 );
      m_EndContinuousIndex[j]   = static_cast<CoordRepType>( m_EndIndex[j] +
0.5 );
#else
      m_StartContinuousIndex[j] = static_cast<CoordRepType>( m_StartIndex[j]
);
      m_EndContinuousIndex[j]   = static_cast<CoordRepType>( m_EndIndex[j]
);
#endif

I'm seeing failing tests where the following function is called: in
itkImageFunction.h...
155   virtual bool IsInsideBuffer( const ContinuousIndexType & index ) const
 156     {
 157     for( unsigned int j = 0; j < ImageDimension; j++ )
 158       {
 159       if( index[j] < m_StartContinuousIndex[j] )
 160         {
 161         return false;
 162         }
 163       if( index[j] > m_EndContinuousIndex[j] )
 164         {
 165         return false;
 166         }
 167       }
 168     return true;
 169     }

with an index[j] of 63.5 when m_EndContinuousIndex[j] is exactly 63.5, given
that we round everything at half upwards. Proceding this way means that
everything at 1/2 pixel at the upper end of each dimension is seen as
inside, even if it corresponds to 1 index more.

Not surprisingly, the parts of the image that trigger failing tests are
never on the lower side of the image dimension, only on the upper side.

Would it not be better to have
      m_EndContinuousIndex[j]   = static_cast<CoordRepType>( m_EndIndex[j] +
0.5 - FLT_MIN );

or something to that effect, so that something with 1/2 pixel spacing sees
the value m_EndIndex[j] + 0.5 declared outside?

Currently, and unless we make this change, our logic is allowing in an extra
row and column as "inside", which is probably not what we had in mind in
going to pixel-centered coordinates.

Copy to ITK community: anyone can chime in!

Cheers,

Michel



-- 
Michel Audette, Ph.D.
R & D Engineer,
Kitware Inc.,
Chapel Hill, N.C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090528/1036c5a2/attachment.htm>