<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dan,<br>
<br>
&nbsp; Thanks very much for your response, and for sharing your code.<br>
<br>
&nbsp; After further rumination on the FastMarchingImageFilter, I think the
applicability of a Sparse-Image implementation would<br>
be seriously limited.&nbsp; Specifically, while it is true that the
_algorithm_ only needs data near the moving-front, the output in<br>
regions not near the active-front-terminator (i.e. the StoppingValue)
is not necessarily as trivial as I had said.&nbsp; The regions not<br>
near the front may be completely filled (the trivial case), but they
may also be partially filled in two cases:<br>
1) there are zero-speed values in that region of the speed-map.&nbsp; The
output is still fairly trivial in this case (in combination with the
speed-map)<br>
2) there are zero-speed values which partition the region into multiple
subregions, not all of which are filled.<br>
<br>
&nbsp; The second case will cause trouble, since it basically means that a
region of the output image can be visited multiple times.<br>
&nbsp; So although a sparse implementation is certainly possible, only
completely-filled regions could wind up being 'freed' before
termination,<br>
which puts limitations on the usefulness.<br>
<br>
&nbsp; I did notice that FastMarchingImageFilter() only uses the trivial
GetPixel() when accessing the speed-map, so I was considering<br>
the approach you suggest for that (that is, subclassing ImageBase, not
the sparseImage stuff).<br>
&nbsp; I am now thinking a better approach, when streaming is possible, is
to make an image source that decompresses a _region_ of the image,<br>
that is, generates an NxNxN block of the data at a time instead of a
single pixel.&nbsp; This is potentially more efficient for the decompression
(well, mine at least!),<br>
and utilizes ITK's flat-array-based design better.<br>
&nbsp; But both this and a more direct 'Functional Image Source' (your
suggestion) would be useful, since streaming isn't always possible.<br>
<br>
&nbsp; 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...&nbsp; But I haven't actually decided yet.<br>
<br>
&nbsp; [WRT the Insight-Developers mailing list, I did actually look through
several months for things there, but obviously I missed your posting.<br>
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).&nbsp; But I was
allowed on the list, so this is presumably no longer the case.]<br>
<br>
&nbsp; Thanks again for sharing your code, though.&nbsp; I have seen several
requests for similar things on the list (e.g. Carlos S&aacute;nchez Mendoza's).<br>
<br>
regards,<br>
Daniel Faken<br>
Coventor, Inc.<br>
<br>
Dan Mueller wrote:
<blockquote cite="mid:mailman.5.1225468805.13242.insight-users@itk.org"
 type="cite">
  <pre wrap="">
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:
    <a class="moz-txt-link-freetext" href="http://www.na-mic.org/svn/NAMICSandBox/trunk/SliceBasedImageMemoryLayout/">http://www.na-mic.org/svn/NAMICSandBox/trunk/SliceBasedImageMemoryLayout/</a>

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:
    <a class="moz-txt-link-freetext" href="http://www.itk.org/Wiki/Proposals:VectorImage">http://www.itk.org/Wiki/Proposals:VectorImage</a>

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 <a class="moz-txt-link-rfc2396E" href="mailto:dfaken@coventor.com">&lt;dfaken@coventor.com&gt;</a>:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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] <a class="moz-txt-link-freetext" href="http://www.itk.org/pipermail/insight-users/2005-April/012593.html">http://www.itk.org/pipermail/insight-users/2005-April/012593.html</a>
[2] <a class="moz-txt-link-freetext" href="http://www.itk.org/pipermail/insight-users/2005-April/012622.html">http://www.itk.org/pipermail/insight-users/2005-April/012622.html</a>

 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
<a class="moz-txt-link-abbreviated" href="mailto:Insight-users@itk.org">Insight-users@itk.org</a>
<a class="moz-txt-link-freetext" href="http://www.itk.org/mailman/listinfo/insight-users">http://www.itk.org/mailman/listinfo/insight-users</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->

------------------------------

_______________________________________________
Insight-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Insight-users@itk.org">Insight-users@itk.org</a>
<a class="moz-txt-link-freetext" href="http://www.itk.org/mailman/listinfo/insight-users">http://www.itk.org/mailman/listinfo/insight-users</a>


End of Insight-users Digest, Vol 54, Issue 73
*********************************************


  </pre>
</blockquote>
<br>
</body>
</html>