[Insight-developers] spatial function iterators

Damion Shelton dmshelto@andrew.cmu.edu
Wed, 22 May 2002 17:32:54 -0400


Hi,

Based on a few problems I've run into recently, I'm considering modifying 
the behavior of FloodFilledSpatialFunctionConditionalIterator. Currently, 
the test of "insideness" occurs by converting the pixel index to a physical 
position (see question at the end) and testing whether or not that physical 
position is inside an InteriorExteriorSpatial function.

While this works well in some cases, I've run into limitations where the 
function covers quite a bit of physical space but does not "contain" any 
pixels under the existing definition of insideness.

I propose the following additional definitions:

2) Center: if the center of a pixel, in physical space, is inside the 
function, then the pixel is inside the function

3) Complete: if all of the corners of the pixel in physical space are 
inside the function, then the pixel is inside the function

4) Intersect: if any of the corners of the pixel in physical space are 
inside the function, then the pixel is inside the function

The existing strategy is:

1) Origin: if the origin of the pixel in physical space is inside the 
function, then the pixel is inside the function

FloodFilledSpatialFunctionConditionalIterator would contain an ivar 
"ContainmentStrategy", and do the appropriate test during execution of the 
flood fill. I suggest a default strategy of "Center".

I know this has been discussed before, but to verify, the data/physical 
scheme results in a mapping of:

Physical 0-----1-----2-----3
Data     0000001111112222223

and the physical location of pixel 1 in data space (with a spacing of 1 and 
origin of 0) is 1.0 and not 1.5, right?

Comments/suggestions on the iterator changes?

-Damion-