[Insight-developers] Octree representation

[Mark Foskey]

I think it may make the most sense to have the octree as a relatively 
bare container type.  That affords the most opportunity for people to 
use it in ways we hadn't thought of.  There could then be a spatial 
object that used your octree to actually store the data.  We already 
wrap itkImage in that way.

Unfortunately, Insight doesn't have a standard interface for container 
types.  We include the STL hash_map directly, pretty much only changing 
the namespace.  We lightly wrap vnl_vector to produce itk::Array, so 
that you can call array->Size(), but to get a begin iterator you have 
to call a lower case array->begin().  itk::FixedArray, on the other 
hand, is a fairly full-featured container with entirely itk-style 
methods.  Given that, I'd suggest using FixedArray as a guide for the 
API, since it's the most Insight-like.  I wouldn't try inheriting from 
it.  Of course you'd need to have query methods that don't make sense 
in FixedArray, but I think it still makes sense to have Begin(), End(), 
and Size(), at least.

Incidentally, is there a reason we wrap vnl_vector for our Array type, 
but don't wrap vnl_vector_fixed for our FixedArray type?

Kent Williams wrote:
> In order to further a project Hans Johnson is working on, I implemented 
> reading and writing the BRAINS2 Octree mask files.  This amounts to about 90% 
> of a Image to Octree filter. 
> 
> The last 10% would comprise
> 
> 1. Would Octrees be SpatialObjects?  In other words is there any other itk 
> hierarchy of which Octree would be a more appropriate citizen?
> 
> 2. With respect to image representation, Octrees quantize pixel colors -- that 
> being one application of Octrees, to reduce the color depth of images.  What 
> I'm thinking would be the most generally useful would be to 1) Have the 
> number of discrete colors be a template parameter.  2) Have the color 
> quantizer be a user-defined functor.
> 
> 3. What exposed function would be most useful?  An iterator to facilitate 
> rendering would be useful, and the usual Spatialobject methods come to mind.
> 
> 4. I had a look at the KD trees and wasn't really seeing much in the way of 
> commonality with the image octree.  If there is some way to put these two 
> tree types in a common framework I'm all for it though...
> 
> I am by no means an image processing expert -- I'm just learning as I go 
> along, so any guidance on making this a useful addition to ITK is welcome.
> _______________________________________________
> 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