[Insight-developers] File suffixes ... and questions about utility of octree representation

[Mark Foskey]

 From last Friday's tcon I was unsure about how thoroughly templated 
your octree class was going to be.  I really do think it makes sense 
for each cell to store an arbitrary data type.  Then you can have 
something like

   itk::Octree< std::vector<MeshSimplex::Pointer> >

Such an octree wouldn't be subdivided down to the voxel level, but 
could be useful for a number of purposes.  Would that be easy to do, Kent?

Also, I don't know if anybody mentioned that there's a kd-tree class in 
ITK:

   http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1KdTree.html

It's specialized for storing n-dimensional samples, and Jisung (its 
author) didn't think it made sense to do any work right now to give it 
a common base class with the Octree class.  But it still might be good 
to know that it's there.

kent williams wrote:
> Well I guess the answer is no, there is no definitive list ;-)  But I have
> an idea  now of the range of suffixes, and I'll work with Hans as we go
> forward on the octree file implementation.  We have existing files it would
> be good to be able to bring in, but perhaps we can deal with those at the
> application level.
> 
> Another issue with adding the new file format for which I'm interested in
> feedback: ITK file I/O has a paradigm of files as images -- you read a file,
> you get an image you can push into a pipeline.  In brains2, the Octree is
> retained in-memory, for, among other things, rendering.  An octree image
> representation lends itself to rendering since you can walk the tree and
> render rectangle.  I can certainly think of cases where the octree would be
> a more useful representation for algorithms than a uniform array of pixels.
> 
> So the question is this: would it be useful to retain and expose the octree?
> And more important, what would be the best way to expose the octree?
> 
> This might be a case for another pending Iowa ITK project of enhancing
> itk::Image by adding a general data dictionary -- a place to retain things
> like the orientation of scan that Analyze scan, but could conceivably
> encompass secondary data representations, like Octrees.  Hans Johnson and I
> have been discussing the dictionary idea, but more on that when Hans has a
> preliminary specification for it to disseminate for review.
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers


-- 
Mark Foskey    (919) 843-5436  Computer-Aided Diagnosis and Display Lab
mark_foskey@unc.edu            Department of Radiology, CB 7515, UNC
http://www.cs.unc.edu/~foskey  Chapel Hill, NC  27599-7515