[Insight-developers] New ITK data objects
John M. Galeotti
jgaleotti@cmu.edu
Wed, 15 Jan 2003 12:33:35 -0500
I am not opposed to the idea of a general "path" class, although I would
like to solicit suggestions as to what belongs in the general API. Are
Add/GetOrigin, Add/GetStep, and GetNumSteps sufficient? I would leave it
to someone else to implement the minimum cost path calculation, etc.
My ultimate vision for the parametric function hierarchy would be to
have generic ND versions implemented and a special, efficient 2D
sub-hierarcy implemented as well. However, since I only need the 2D
sub-hierarchy for my work, I currently do not intend to implement the ND
versions (at least not yet; anyone else interested?).
Stephen R. Aylward wrote:
> 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
>
>
>