[Insight-developers] spatial object iterators

[Damion Shelton]

Hi,

In order for the iterators to work correctly, Evaluate() will need to 
wrap IsInside(). Based purely on names, I would think Evaluate() would 
wrap ValueAt()... but the latter does not necessarily return a bool. If 
this is well documented it shouldn't be a problem.

-Damion-

On Monday, February 10, 2003, at 09:57 AM, Miller, James V (Research) 
wrote:

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