[Insight-developers] Re: missing ITK functions document

Joshua Cates cates@cs.utah.edu
Tue, 27 Nov 2001 11:08:32 -0700 (MST)


Hi,

Do you have some pseudocode examples of what this stuff looks like and how
it is used?  Just a few snippets of code demonstrating the API in action.  
I'm not talking about working examples or even real classes, just use-case
scenarios to go from the abstract to the concrete.  I think this is the
best way to get our minds around a new abstraction.

Thanks,

Josh.
______________________________
 Josh Cates			
 School of Computer Science	
 University of Utah
 Email: cates@cs.utah.edu
 Phone: (801) 587-7697
 URL:   www.cs.utk.edu/~cates


On Mon, 26 Nov 2001, Stephen R. Aylward wrote:

> Hi,
> 
> Vikram has asked about the PhysicalObject classes, and so I thought I'd
> give a brief summary to the group.
> 
> The goal is to devise a class hierarchy that can represent spheres,
> cubes, connected components, segmentation results, etc in a common
> framework.   In that manner, we will be able to calculate volumes,
> moments, bounding boxs, convex hulls, etc; generate masks; load and save
> scenes; and more...
> 
> We are proposing a class hierarchy of "PhysicalObjects." At the base
> class, a specific type of representation (data container) of an object
> is not specified, just the basic api.   Derived types of physical
> objects will represent different types of objects and will contain data
> containers.   So, a physicalObject could be an image mask (e.g., all
> values between 10 and 100 in the image represents object A), a list of
> points, a function, a parameterize model, or a collection of other
> physicalObjects (a CSG type object).  
> 
> Jean-Philippe Guyon is working hard on this and is following the
> composite-pattern design in the book "Design Patterns: Elements of
> Reusable Object-Oriented Software" by Erich Gamma et al - suggested by
> Luis.
> 
> A point of future discussion is what do we want at the base class level
> - what characteristics should be common to every physical object.
> 
> Our first draft includes the following concepts/functions in the base
> class:
> - Position, orientation, and scale in physical space.
> - Bounding box.
> - Test if a physical point is inside a physical object.
> - Resolution of the physical object (if it is a discrete representation,
> how should we 	query its points)
> 
> There would be the following filters:
> * PhysicalObjectToPhysicalObject filters allow objects to be combined
> (CSG).
> * PhysicalObjectToImage filters allow objects to be drawn in images.
> * PhysicalObjectToValue filters will give you moments, etc.
> 
> We've got some other ideas on where we can go with these, but we are
> going to keep it simple at first: box, sphere, tube, image-mask, and
> point-list will be the objects that we hope to provide.
> 
> Comments?
> 
> Thanks,
> Stephen and Jean-Philippe
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>