[Insight-developers] New ITK data objects
Stephen R. Aylward
aylward@unc.edu
Mon, 13 Jan 2003 19:39:50 -0500
Hi,
Should there be a more general "path" class that provides an API for
storing a sequence of movements through a space? Chaincodes are but
one instance of them. The base class would provide a general API, the
chaincode sub-class would have specific member functions for the faster
access and reduced memory requirements that they provide. This base
path class should be extensible to minimum cost path calculation as well
as chaincodes...
SpatialFunctions are parametric functions that should derive from
FunctionBase. However, it sounds like you are proposing a special set
1D to ND parametric functions.
About your class names, ITK convention is to go from specific to
general. So, for example, a good class name would be
itkCircle1DTo2DParametricFunction. I think Luis holds the record of a
class name that was 30+ characters long :)
I am sure others have suggestions as well. These are great extensions
to / integrations with ITK's current design!
Thanks!
Stephen
galeotti wrote:
> I believe that both of these data structures are sufficiently general
> and unique to justify making them seperate, new parent classes. I think
> that they should not descend from existing data structures for the
> reasons given below. Please let me know if my reasons are sufficient
> and valid. Thanks.
>
> A chaincode is by nature represented as a starting index followed by a
> sequence of local movements into neighboring pixels. I believe (please
> correct me if I'm wrong) that this is conceptually very different than
> the indented purpose of the PolygonCell and PolygonBoundary classs.
> Also, for efficiency reasons I store and frequently manipulate the 2D
> steps of the chaincode as a single encoded byte.
>
> Although ParametricFunction could syntatically descend from
> SpatialFunction, I believe that it would be very counter-intuitive.
> Parametric funcitons have a single independent variable that is defined
> only over the domain from time = 0 to 1, but the have a multidimensional
> spatial return value (the opposite of "typical" spatial functions).
>
> My current ideal hierarchy of parametric function would be as shown
> below. What do you all think about making a special class for 2D
> parametric functions? Efficiently coding parametricfunction for ND
> would be a nightmare, I think (especially for the Fourier smoothed
> chaincode class descendent).
>
> class ParametricFunction<outputtype> // do-nothing parent class
>
> class ParametricFunction2D<CoordinateType>
> : public ParametricFunction< vnl_vector_fixed<CoordinateType,2> >
>
> class ParametricFunction2DCircle<CoordinateType>
> : public ParametricFunction2D<CoordinateType>
> class ParametricFunction2DPolygon<CoordinateType>
> : public ParametricFunction2D<CoordinateType>
> class ParametricFunction2DFourierSmoothedChainCode<CoordinateType>
> : public ParametricFunction2D
>
>
> I think it makes more sense for chaincode and parametricfunction to
> have their own class hierarchies, but I'd like to hear other developers
> opinions, especially with regard to the reasons I have given.
>
> Thank you,
> John
>
> Miller, James V (Research) wrote:
>
>> I guess the first question is how general are these data structures?
>>
>> Could some of them use (be? or be if we added something to) the existing
>> mesh/cell classes? Is a chain code much different than a polyline of
>> polygon?
>> (do you want to represent it as a collection of indexes or as a starting
>> index and a neighbor indicator?)
>>
>> Could the parametric path classes use or be part of the existing
>> function hierarchy? We already have ImageFunction and SpatialFunction.
>> Should we have a ParametricFunction?
>> Jim
>>
>>> -----Original Message-----
>>> From: John M. Galeotti [mailto:jgaleotti@cmu.edu]
>>> Sent: Friday, January 10, 2003 1:31 PM
>>> To: insight-developers@public.kitware.com
>>> Subject: [Insight-developers] New ITK data objects
>>>
>>>
>>> Hello, I'm working with Dr. Stetten at CMU to implement his swath-based
>>> "active contour" as part of ITK. Now that I've isolated the
>>> algorithm from Dr. Stetten's Visualization and Image Analysis (VIA)
>>> toolkit, I'm ready to add it to ITK. In order to do that, I need to
>>> add a couple of data types to ITK, if no one objects. Comments
>>> welcome (and requested).
>>> Pseudo-code for the proposed classes follows:
>>>
>>> class chaincode
>>> get/set origin
>>> add/get step
>>> get number of steps
>>> make 4-connected (convert every diagonal step into 2 orthogonal steps)
>>> get step rotated +/- 45 degrees (optional, but very helpful for the
>>> swath)
>>>
>>> class parametric path funciton (virtual parent class)
>>> get point at time t (virtual, t lies on the interval [0,1])
>>>
>>> class parametric circle
>>> class parametric polygon
>>> class parametric Fourier smoothed chaincode
>>> contstruct from chaincode
>>> get derivative of point at time t
>>> add/set optimum error offset points
>>> get error-corrected point at time t
>>
>
> ---
> John M. Galeotti (jgaleotti@cmu.edu) 412-268-9576
> Robotics Institute, EDSH, Carnegie Mellon University
> 5000 Forbes Avenue, Pittsburgh, PA 15213
>
> _______________________________________________
> 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