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

[Daniel Faken]

Dan,

  Thanks very much for your response, and for sharing your code.

  After further rumination on the FastMarchingImageFilter, I think the 
applicability of a Sparse-Image implementation would
be seriously limited.  Specifically, while it is true that the 
_algorithm_ only needs data near the moving-front, the output in
regions not near the active-front-terminator (i.e. the StoppingValue) is 
not necessarily as trivial as I had said.  The regions not
near the front may be completely filled (the trivial case), but they may 
also be partially filled in two cases:
1) there are zero-speed values in that region of the speed-map.  The 
output is still fairly trivial in this case (in combination with the 
speed-map)
2) there are zero-speed values which partition the region into multiple 
subregions, not all of which are filled.

  The second case will cause trouble, since it basically means that a 
region of the output image can be visited multiple times.
  So although a sparse implementation is certainly possible, only 
completely-filled regions could wind up being 'freed' before termination,
which puts limitations on the usefulness.

  I did notice that FastMarchingImageFilter() only uses the trivial 
GetPixel() when accessing the speed-map, so I was considering
the approach you suggest for that (that is, subclassing ImageBase, not 
the sparseImage stuff).
  I am now thinking a better approach, when streaming is possible, is to 
make an image source that decompresses a _region_ of the image,
that is, generates an NxNxN block of the data at a time instead of a 
single pixel.  This is potentially more efficient for the decompression 
(well, mine at least!),
and utilizes ITK's flat-array-based design better.
  But both this and a more direct 'Functional Image Source' (your 
suggestion) would be useful, since streaming isn't always possible.

  Now as far as my actual implementation goes, I'm leaning toward just 
invading the FastMarchingImageFilter's implementation, because I suspect 
the overhead of streaming would actually be too high for small regions, 
and I need to use small regions to minimize memory overhead...  But I 
haven't actually decided yet.

  [WRT the Insight-Developers mailing list, I did actually look through 
several months for things there, but obviously I missed your posting.
I would guess it isn't googleable since it is members-only, and the 
members used to be limited to 'Consortium only' (according to the 
InsightDeveloperStart.pdf document that comes with ITK).  But I was 
allowed on the list, so this is presumably no longer the case.]

  Thanks again for sharing your code, though.  I have seen several 
requests for similar things on the list (e.g. Carlos Sánchez Mendoza's).

regards,
Daniel Faken
Coventor, Inc.

Dan Mueller wrote:
> 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
>>
>>     
>
>
> ------------------------------
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
>
> End of Insight-users Digest, Vol 54, Issue 73
> *********************************************
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20081031/da7057a8/attachment-0001.htm>