[ITK-users] FastMarching and FastMarchingBase

[Dan Mueller]

Hi Wei,

The article describes a number of optimizers that use gradient information
*from the arrival function*. My mathematical ability is not very good, but
suspicion tells me the gradient computed retrospectively from the arrival
function, or on-the-fly as part of the Eikonal equation, are not going to
be significantly different.

In any case, it would not be difficult to create a custom optimizer that
takes the computed gradient image and uses those gradients to perform the
back propagation.

Good luck.

HTH

Cheers, Dan
Dan,

I read your code and the document and found although the document mentioned
the FastMarchingUpwindGradientImageFilter, and the code does use it, but
the filter does not use the gradient image output of
the FastMarchingUpwindGradientImageFilter. Instead, it computes the path
directly from the cost map by optimizing within a neighborhood.

I'm curious how you see it. Naturally, I would prefer using the gradient
information for fast tracking back to the starting point, but there might
be reason that the filter is implemented without using the gradient.

Thanks,
Wei


On Thu, Apr 3, 2014 at 10:13 AM, Wei Liu <weiliu620 at gmail.com> wrote:

> Hi Dan,
>
> Thanks for point it out. I will read it. A first look of this Insight
> article seems very different from the current implementation of the fast
> marching filter. But I need to read it and come back for any further
> question.
>
> Wei
>
>
> On Wed, Apr 2, 2014 at 8:51 PM, Dan Mueller <dan.muel at gmail.com> wrote:
>
>> Hi Wei,
>>
>> There is an Insight Journal article which shows how to extract a
>> continuous directed path using Fast Marching:
>> http://www.insight-journal.org/browse/publication/213
>>
>> HTH
>>
>> Cheers, Dan
>> On 3 Apr 2014 09:00, "Wei Liu" <weiliu620 at gmail.com> wrote:
>>
>>>  Arnaud,
>>>
>>> Thanks for the information. Is there a minimal example of extracting the
>>> shortest path given the ending point and the gradient image? One thing not
>>> clear to me is the gradient at each pixel points to the direction away from
>>> starting point. If I have ending point, how could I use the gradient to
>>> trace back to the starting point?
>>>
>>> Thanks very much,
>>> Wei
>>>
>>> p.s. that question may also due to my lack of good understanding of the
>>> fast marching method itself.
>>>
>>>
>>> On Sat, Mar 29, 2014 at 1:40 AM, Arnaud Gelas <arnaudgelas at gmail.com>wrote:
>>>
>>>> Hi Wei,
>>>>
>>>> FastMarchingBase and its derivatives offer the possibility:
>>>>
>>>> * to provide your own stopping criterion, as you mentioned, i.e. not
>>>> only the time of arrival for the front. See
>>>> FastMarchingStoppingCriterionBase and its derivatives [1]
>>>> * to provide some forbidden points [2], or a binary mask on which the
>>>> front would evolve [3]
>>>> * to impose for images some topological constraints by the means of
>>>> SetTopologyCheck [4], see [5] for details
>>>> * to work with images or meshes, e.g. [6]
>>>>
>>>> HTH,
>>>> Arnaud
>>>>
>>>> [1]
>>>> http://www.itk.org/Doxygen/html/classitk_1_1FastMarchingStoppingCriterionBase.html
>>>> [2]
>>>> http://www.itk.org/Doxygen/html/classitk_1_1FastMarchingBase.html#a4f20d07dd57b0e5a0016bcf98d1aeffc
>>>> [3]
>>>> https://github.com/Kitware/ITK/blob/master/Modules/Filtering/FastMarching/test/itkFastMarchingImageFilterRealTest2.cxx
>>>> [4]
>>>> http://www.itk.org/Doxygen/html/classitk_1_1FastMarchingBase.html#afcd4d899f100ec28d309026e9dc98f00
>>>> [5] http://www.insight-journal.org/browse/publication/778
>>>> [6]
>>>> http://itk.org/ITKExamples/src/Filtering/FastMarching/ComputeGeodesicDistanceOnMesh/Documentation.html
>>>>  On Friday, March 28, 2014, Wei Liu <weiliu620 at gmail.com> wrote:
>>>>
>>>>> Dear ITK users,
>>>>>
>>>>> When I look at the ITK FastMarching module I found two version of same
>>>>> filter. For example, I found FastMarchingImageFilter
>>>>> and FastMarchingImageFilterBase have similar functions, also I
>>>>> found FastMarchingUpwindGradientImageFilter
>>>>> and FastMarchingUpwindGradientImageFilterBase. I can see some functions are
>>>>> different (such as set stop criterion), but is there anything I need to
>>>>> know about when I should use which of these filters?
>>>>>
>>>>> This Git commit [1] seems to say that two implementations co-exists: "
>>>>> With this change both frameworks (ITKv3 and refactored one) co-exist,
>>>>> classes have different name to avoid conflicts." Not sure if it's
>>>>> related to my questions.
>>>>>
>>>>> Anyone has any thoughts about it? I appreciate your input.
>>>>>
>>>>> Wei
>>>>>
>>>>> [1]
>>>>> http://itk.org/gitweb?p=ITK.git;a=commit;h=6271a744582c413c7db57456c8ee0149930e5fd9
>>>>>
>>>>
>>>
>>> _____________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.php
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20140404/793af644/attachment.html>