[Insight-users] "Image Adaptor" for compressed/non-itk::Image object

[Dan Mueller]

Hi Daniel,

Are you still interested in an itk::SparseImage? (I see your most
recent email is asking about streaming fast marching now, rather than
using a sparse image...) If you are still interested in the sparse
approach, then perhaps I can give you a few ideas.

In my spare time (which is very small at the moment) I have been
working on a "slice contiguous" image within ITK. This image has a
different underlying memory model than the "volume contiguous" format
assumed by itk::Image. I have a rough skeleton which currently works
with non-neighborhood filters:
    http://www.na-mic.org/svn/NAMICSandBox/trunk/SliceBasedImageMemoryLayout/

A discussion took place on the Insight Developers mailing list some
months back, but unfortunately this list is not Google-able (Insight
Developers: why not?). Basically Karthik Krishnan (from Kitware)
pointed me to some work he did for itk::VectorImage:
    http://www.itk.org/Wiki/Proposals:VectorImage

The idea is to subclass itk::ImageBase, provide custom implementations
for Get/SetPixel, and provide customised
PixelAccessors/NeighborhoodPixelAccessors. So far I have created the
normal PixelAccessors, but not the neighborhood or overriden
Get/SetPixel. But you should be able to see the general concept.

It should not be too hard to do the same for an itk::SparseImage. The
trouble comes when you consider IO: at the moment I have ignored that
issue (for slice contiguous images) assuming I will always import them
(as shown in the test Testing/SliceContiguousImageTest01.cxx). Are you
proposing to use a sparse image for both the input speed and output
arrival function? It may be interesting to note that
itk::FastMarchingImageFilter only uses Get/SetPixel (no iterators, no
neighborhood iterators) so you need only implement these in your
subclassed itk::SparseImage (as a quick hack)...

So, here are some steps to proceed down this path:
1. Take a look at itk::SliceContiguousImage
2. Create itk::SparseImage which subclasses itk::ImageBase
3. Override Get/SetPixel
(4. Ignore the pixel accessors for the moment)
5. Think about IO (how will you create/read/write these sparse images)
(6. Share anything you make via the Insight Journal, so others can benefit!)

Hope this helps gets the brain juices flowing on a Friday...

Regards, Dan

2008/10/29 Daniel Faken <dfaken at coventor.com>:
> Hello,
>
>  I would like to use a compressed representation of our data for the
> speed-map in the FastMarchingImageFilter, but the itk::ImageAdaptor only
> works for other itk::Image objects.
>  Is there another way to do this?
>
>  I found a discussion from 2005 suggesting basically reimplementing what
> itk::Image does beyond itk::ImageBase (see [1], [2]), but I'm wondering if
> anyone has worked further on this.
>
> [1] http://www.itk.org/pipermail/insight-users/2005-April/012593.html
> [2] http://www.itk.org/pipermail/insight-users/2005-April/012622.html
>
>  Our data tends to be very large (e.g. 10000^3), so I need to avoid creating
> a flat representation.
>  Of course, FastImageMarchingFilter creates another image, the LevelSet, of
> the same dimensions.  But for that I was going to try making a 'sparse
> image' class, to avoid storing the data not near the moving-front (which
> will almost always be most of the data!).  I was thinking of maybe having an
> image of NxNxN blocks, most of which will be marked as 'infinite' or
> 'under-threshold', and promoting/demoting to full-data blocks as necessary.
>  Any input on this is welcome too!
>
>  Thanks very much for any help.
>
> Daniel Faken
> Coventor Inc.
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>