[Insight-developers] New ITK data objects

[John M. Galeotti]

I'm sorry for the confusion.  My proposed ChainCode class will be of
the form

       n ---> n^N
         where n=natural numbers
         and   N=dimensionality of the image the chain code traverses

       t ---> { d1(t),d2(2),...,dN(t) }
         where dN(t) = axis-aligned component of the next pixel offset in
                       the connected sequence of the chain code

Because the sequence is required to be connected, dN(t) has only 3
possible values:  -1, 0, and 1.  Also, since the chain code is
offset-valued, the index of the starting point (a ND vector) would also
need to be stored as part of the class.


On the other hand, my proposed parametric function class is of the form
described by Luis below, but with the very important constraint that t
is only defined over the range from 0 to 1.  In particular, for periodic
functions this means that f(0) = f(1).


  >     R ----->  R^N
  >
  >     t ------> { X1(t),X2(t),.... XN(t) }
  >
  > Where "t" is the parameters and {X1,X2...XN} are the coordinates
  > of a point in N-D space associated with this parameter.

I intend to derive both itk::ParametricFunction and itk::ChainCode (or 
perhaps a new parent class for itk::ChainCode, itk::Path) from 
itk::FunctionBase; my prior concern was that I did not want to derive 
from either of itk::ImageFunction or itk::SpatialFunction (Jim raised a 
question concerning this at the start of the thread). I suppose my 
phrasing "separate, new parent classes" was a bit strong; I meant parent 
classes at the same level of the ITK hierarchy as the other parent 
classes being discussed.

  > ====================================================================
  >
  > 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
  >>
  >
  >
  >
  > _______________________________________________
  > Insight-developers mailing list
  > Insight-developers@public.kitware.com
  > http://public.kitware.com/mailman/listinfo/insight-developers


-- 
John M. Galeotti   (jgaleotti@cmu.edu)  412-268-9576
Robotics Institute, EDSH, Carnegie Mellon University
5000 Forbes Avenue, Pittsburgh, PA 15213