[Insight-developers] performance of image iterators and pixel buffer storage

Dan Mueller dan.muel at gmail.com
Tue Nov 4 12:18:56 EST 2008


Hi David,

> A little confused.
> B/C of the memory storage setup, wouldn't you expect a significant cache
> performance difference if you iterate over row's vs iterating over columns?
> Are you saying that ITK iterators have some special abstraction to avoid
> this?

No, I am saying that SetDirection(..) is used for computations in
physical space. An iterator operates on pixel space. The direction
cosines are not used in this situation.

I think you are getting confused as to what the direction cosines
actually are. They specify an image's orientation in _physical_ space,
they do not specify the pixel space.

Iterating rows over columns may exhibit a difference in performance --
you would have do some tests...

Hope this answers your question.

Regards, Dan

2008/11/4 David Fuentes <fuentesdt at gmail.com>:
> Dan, Thank you very much for the reply.
>
>> See the documentation in itkImage.h:
>>
>> * The data in an image is arranged in a 1D array as
>> [][][][slice][row][col]
>> * with the column index varying most rapidly.  The Index type reverses
>> * the order so that with Index[0] = col, Index[1] = row, Index[2] = slice,
>> * ...
>>
>>> which value for
>>>
>>>  SetDirection()
>>>
>>> should be used to give the best performance?
>>
>> From my understanding, SetDirection(..) has no impact on iterator
>> performance. SetDirection(..) changes the direction cosines, which are
>> used by TransformPhysicalPointToIndex(..),
>> TransformContinuousIndexToPhysicalPoint(..), and others in
>> itk::OrientatedImage (although in ITK 3.10, which is about to be
>> released, the direction cosines can be used in itk::Image, deprecating
>> itk::OrientatedImage).
>>
>
>
> A little confused.
> B/C of the memory storage setup, wouldn't you expect a significant cache
> performance difference if you iterate over row's vs iterating over columns?
> Are you saying that ITK iterators have some special abstraction to avoid
> this?
>
>
>
> df
>


More information about the Insight-developers mailing list