<!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>
Thanks very much for your response, and for sharing your code.<br>
<br>
After further rumination on the FastMarchingImageFilter, I think the
applicability of a Sparse-Image implementation would<br>
be seriously limited. 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. 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. 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>
The second case will cause trouble, since it basically means that a
region of the output image can be visited multiple times.<br>
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>
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>
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. This is potentially more efficient for the decompression
(well, mine at least!),<br>
and utilizes ITK's flat-array-based design better.<br>
But both this and a more direct 'Functional Image Source' (your
suggestion) would be useful, since streaming isn't always possible.<br>
<br>
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.<br>
<br>
[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). But I was
allowed on the list, so this is presumably no longer the case.]<br>
<br>
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).<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"><dfaken@coventor.com></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>