[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-