[Insight-developers] spatial object iterators

[Miller, James V (Research)]

I have a question on the Evaluate() method for SpatialObjects:

The SpatialFunctions Evaluate() method returns the value of the 
function where the sign of the value can be used to define inside
and outside (standard implicit functions).

The SpatialObjects support both an IsInside() and a ValueAt() method.
The difference between these is that ValueAt() could map to a range
value (i.e. across the spatial object, there could be a function 
(say temperature) and the ValueAt() method could return the value 
of the function at that position).

So if Evaluate() is added to SpatialObjects, what would the expected
question be? Should Evaluate() be an alias for IsInside() or ValueAt()?






> -----Original Message-----
> From: Stephen R. Aylward [mailto:aylward@unc.edu]
> Sent: Sunday, February 09, 2003 10:17 PM
> To: Damion Shelton
> Cc: Insight-developers@public.kitware.com
> Subject: Re: [Insight-developers] spatial object iterators
> 
> 
> Hi,
> 
> Thanks for the huge help!
> 
> Damion Shelton wrote:
> > 
> > First, the primary difference between spatial objects and spatial 
> > functions is the means by which a value is returned. 
> 
> There are other differences such as including transforms, children 
> objects, properties, bounding boxes, etc.   But I'm guessing you knew 
> that.... :)
> 
>  > The
> > InteriorExteriorSpatialFunction's (to be renamed to 
> > BooleanSpatialFunctions) return true when a point is inside the 
> > function, and false otherwise, in response to an Evaluate() 
> call. This 
> > is the "condition" in the conditional iterators. SpatialObjects are 
> > quite similar, but the corresponding call is IsInside().
> 
> Cool.
> 
> > 
> > There are a several ways I can see of solving this problem:
> > 
> > 1) Because the conditional iterators are templated, it should be 
> > possible to use any of them with SpatialObjects, provided 
> SpatialObjects 
> > have an Evaluate() function. I don't know how much sense 
> this makes in 
> > the context of spatial objects (in that they don't really 
> "Evaluate"), 
> > but it would be relatively simple to wrap IsInside() into 
> Evaluate(). 
> > Both functions expect N-d points, so there's no fundamental 
> data type 
> > problem.
> 
> I could see adding an Evaluate function to the spatial 
> objects.   If you 
> Evaluate an object given a point, it returns whether or not 
> it is in an 
> object.  That really seems acceptable.
> 
> > 
> > 2) It may be possible to do type checking at runtime, and call the 
> > appropriate function. Is this true?
> 
> We could, but this seems a bit like a hack.
> 
> > 
> > 3) SpatialObjects might be a subclass of SpatialFunctions, 
> although I 
> > haven't convinced myself of this. Are there any problems with 
> > subclassing the spatial objects from spatial functions?
> 
> We could also do this.   Right now SpatialFunction derives 
> from Object 
> while SpatialObject derives from data object - I think this 
> helps when 
> SpatialObjects wrap an image/mesh.   Julien knows the most about the 
> pluses/minuses of this.   Should be particularly irrelevant with 
> pervasive pipelining.
> 
> > 
> > 4) It would be relatively straightforward to write additional 
> > conditional iterators, where the IsPixelIncluded() function is 
> > implemented to call IsInside(). My concerns here are that this code 
> > would essentially duplicate that of the spatial function 
> iterators (with 
> > the exception of one line) and therefore would create extra code to 
> > maintain.
> 
> I agree. The plan was to write a 
> spatialObjectToSpatialFunction adaptor 
> that would handle this.   But perhaps adding the Evaluate function is 
> better - saves a step for the user.
> 
> > 
> > A final issue is the name of the resulting iterators. Right 
> now, we have 
> > FloodFilledSpatialFunctionConditionalIterator; if we create 
> a version of 
> > this which can iterate over spatial objects, would the name 
> be confusing?
> > 
> 
> Seems like Adding Evaluate or deriving are equivalent.   
> We'll think it 
> over.   Any other opinions....
> 
> 
> Thanks again for the huge help!
> 
> Stephen
> 
> 
> > -Damion-
> > 
> > _______________________________________________
> > Insight-developers mailing list
> > Insight-developers@public.kitware.com
> > http://public.kitware.com/mailman/listinfo/insight-developers
> 
> 
> -- 
> ===============================================
> Dr. Stephen R. Aylward
> Assistant Professor of Radiology
> Adjunct Assistant Professor of Computer Science
> http://caddlab.rad.unc.edu
> aylward@unc.edu
> (919) 966-9695
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>