[Insight-developers] Blox Images

[Brad King]

Damion,

> That's correct. These are not "normal images", nor are they intended
> to be.  The problem is that a linked list at each pixel is a
> fundamentally different sort of thing than most other primitive data
> types. This would result in compile errors any time you attempted to
> combine blox images with "normal" filters or blox filters with
> "normal" images.
I agree that normal filters cannot work with the Blox images, however,
there is no reason someone shouldn't be able to write new filters that can
work with a BloxImage.  The set of operations defined for blox images
shouldn't be limited by the methods implemented by the BloxImage classes.  
This is the idea of the pipeline: new filters can be added to perform new
operations on the existing class representations of their input/output
data.  The documentation could simply state that only filters with the
suffix "BloxImageFilter" can be used with a BloxImage (see below).

> Most of the other filter-type functions found in the blox classes are 
> similar. You would end up with a bunch of filters with names like:
> 
> BloxBoundaryPointImageToBloxCoreAtomImageImageToImageFilter
> BloxCoreAtomImageToBloxCoreAtomEigenanalyzedImageToImageFilter
Since BloxImage inherits from Image, and the filters only apply to
BloxImage types, the names could be:

  BoundaryPointToCoreAtomBloxImageFilter
  CoreAtomToCoreAtomEigenanalyzedBloxImageFilter

Note the "BloxImageFilter" suffix.

> The input and output data types are also "locked". The "output" of the 
> routine:
> 
> >   /** Walk the source image, find core atoms, store them.  */
> >   void FindCoreAtoms();
> 
> produces a very specific type of type of output (a BloxCoreAtomItem), for 
> which there is no possible cast to other data types (ints, floats, etc.) 
[...]
> Names aside, the "bad" things about these filters is that they could _only_ 
> take a very specific kind of input image and would only produce a very 
> specific kind of output image.
Some filters are meant to work only with vector data, others with only
scalar.  I see no difference here.  It will still be okay to produce
BloxImage outputs, which could potentially become inputs to new filters
written in the future.  The template argument of the BloxImage could be
reduced to specify only the representation used inside the blox pixel,
and/or the dimension of the image (to help lock down the type of
input/output image).

> > I think these classes should be changed to filters.  A normal itk::Image
> > should be sufficient to store the Blox image pixels, given the proper
> > pixel type as its first template argument.
> Subclassing BloxImage's from Image allows the addition of additional
> image parameters, relevant to blox images but not to normal images.
> For example, without adding an m_NumItems parameter to BloxImage
> (which may or may not be implemented yet - don't remember offhand)
> it's impossible to tell how many items are stored in the BloxImage
> without explicitly counting every time you want that information.
Good point.  I hadn't read the class carefully enough to see that.  A
"BloxImage" is a specific version of an "Image", so a subclass is
appropriate.  This would also help to restrict the type of input/output
images a filter could take.

> I agree that it would work, but I don't know that implementing it that
> way would increase clarity or efficiency in the code. We do gain quite
> a bit by subclassing from image - ability to use iterators, in
> particular, but I don't know that adhering to the pipeline
> architecture (in this instance)  really gains anyone anything, and
> creates a large number of very specific filters that don't allow us to
> do anything we can't already do.
Changing the implementation to a pipeline filter may not increase the
clarity of the code for this specific case, but it will greatly help in
consistency with the rest of ITK.  This consistency will automatically
increase clarity overall.

-Brad