[Insight-developers] New ITK data objects
Miller, James V (Research)
millerjv@crd.ge.com
Thu, 16 Jan 2003 09:27:04 -0500
I would suggest the parametric function NOT be limited to evaluating
from between [0, 1]. Clearly the "basic" parametric functions tend to
be used from [0,1] but in using parametric functions you tend to jump
pretty quickly to [0, s], i.e. splines.
Now the particular (periodic) parametric functions you want to
implement can be limited to [0,1] but I would not make that a constraint
on parametric functions. I am guessing at this point, we are just tripping
over terminology vs intention. The difference between parametric and spatial
functions is obscure.
On a side note, if we have a parametric circle, the next step would be
a parametric ellipse. Following this train of thought, it would be very
nice to have a "conic" spatial function. You should be able to specify
the conic with an implicit function, evaluate the implicit function, deduce
whether the conic is an ellipse, parabola, hyperbola, and extract the
parameters of the ellipse (or parabola, hyperbola, etc.) in the form of
a (x0, y0), theta, r1, r2, etc. Conversely, it should be able to take
the parameterized representation and construct the implicit function.
VXL has this type of capability in vxl/contrib/gel/vsol/vsol_conic_2d.h
and it would be great if ITK had this type of function.
> -----Original Message-----
> From: John M. Galeotti [mailto:jgaleotti@cmu.edu]
> Sent: Wednesday, January 15, 2003 12:37 PM
> To: insight-developers@public.kitware.com
> Subject: Re: [Insight-developers] New ITK data objects
>
>
> 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
>
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>