[Insight-users] Suggestions for the best Data Structure

[Arash Jahangir]

Hi Luis,
The Image is the output of stereo image disparity analysis.  So I don't
really have a functional transformation of the (u,v) into (x,y,z) but rather
a look up table.  Nor do all the points lie on the same plane or otherwise
can be easily categorized just based on their (u,v) coordinates.  After the
image/object is loaded in, I will be deleting the unwanted parts and
intelligently reduce the number of cells/pixels (I'd say I'll be decimating
the object, except that my algorithms are rather quite different from
standard decimation).  Eventually the data will be transformed to connect
with VTK for visualization.  But before I do that, I will need methods to
query the cells based on their angles, derivatives (both spatial and
intensity values), etc so that I can reduce the point count properly.

BTW, I will be dealing only with Surface values for now so I am curious if I
should be looking at SurfaceSpatialObjects.  It just seems to me there are
too many options open to me and I can't tell which is the best one.  Can you
tell me what is the motivation behind Spatial Objects and what they are best
used for.

all help is appreciated,
Arash

----- Original Message ----- 
From: "Luis Ibanez" <luis.ibanez at kitware.com>
To: "Arash Jahangir" <arash at vije.ca>
Cc: "ITK" <insight-users at itk.org>
Sent: Wednesday, January 28, 2004 4:27 PM
Subject: Re: [Insight-users] Suggestions for the best Data Structure


>
> Hi Arash,
>
> It seems redundant to have the coordinates
> for all the pixels represented explicitly.
>
> If you have a 2D to 3D transformation allowing
> to compute (x,y,z) from (u,v) values, you could
> avoid taking all the memory for storing such
> information on a pixel by pixel basis.
>
> You probably can represent this as a type
>
>      itk::Image< itkRGBPixel<char>, 2 >
>
> and an ITK transform.
>
> ----
>
> Unless your image is composed of scattered
> pixels, or its mapping in space is given
> by a deformation fields, it is probably not
> worth to represent this data in the form
> of a Mesh.
>
>
> ----
>
> Regards,
>
>
>     Luis
>
>
> ------------------------
> Arash Jahangir wrote:
> > Hi all,
> > I have been reading this thread for a few weeks and have been impressed
> > with the quality of the people on this thread.  I am hoping that your
> > knowledge can help me decide what basic data structure I should use for
> > manipulating my input data.  I have an input file format that can best
> > be described as bitmap image plus the real world coordinates for each
> > pixel.  The format is:
> >
> > u, v, r, g, b, x, y, z
> >
> > where (u, v) pair define the row, column coordinates of the pixel and
> > the x,y,z are the real world coordinates.
> >
> > I will need to perform all the usual activities such as image to image
> > and image to object registration as well as other image and object
> > modifications/edits.
> >
> > The question in my mind is whether I should load the input into two
> > separate data structures of appropriate image and mesh types, Or should
> > I create an ImageSpatialObject (BloblSpatialObject?)  that holds all the
> > data and then extract the mesh and/or image components from it as
needed.
> >
> > your help is greatly appreciated,
> > Arash
> >
>
>
>
>