<br>I read a few more papers and thought about the question number 2 again. I think there is misinterpretation on my part. The 4 neighbors of [49.7,49.8] along their exact distance value should be set as Alive Points instead of Trial Points. Then the neighbors of the 4 neighbors (another layer around the 4 neighbors) are set as trial points, their initial tentative values are calculated using upwind difference method. When I check the result distance map, a few things to notice:<br>
1. The distance value of the 4 neighbors of [49.7, 49.8] are correct. This is obvious since I set them as Known instead of Trial.<br>2. The distance value of the neighbors of the 4 neighbors (the input trial points) still changed. I think this is due to the inherent FMM accuracy and update method.<br>
<br>You can try this with the following code.<br><a href="http://www.rpi.edu/~chens/download/main3.cpp">http://www.rpi.edu/~chens/download/main3.cpp</a><br><br>Thanks<br>Siqi<br><br><div class="gmail_quote">On Mon, Jan 4, 2010 at 6:03 PM, siqi chen <span dir="ltr"><<a href="mailto:siqichensc@gmail.com">siqichensc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>To better illustrate my questions regarding fast marching, I put 2 example code in the attachment.<br>
<br>In main1.cpp, I simply compute a distance map to point [50,50]. As you can see from the output, the distances from the 4 neighbors of [50,50] to [50,50] are correct, obviously the result is 1. However, the distance from [51,51] to [50,50] is 1.707 instead of 1.414, which is obviously wrong. I think this is due to the fast marching accuracy itself. If we switch to higher order FMM, the result should be improved.<br>
<br>In main2.cpp, I perturb the target point a little bit. Instead, I want to compute the distance map to point [49.7,49.8]. From my point of understanding, I need to initialize the 4 neighbors of [49.7, 49.8] and put them into the TrialPoints. As you can see, I compute the exact distance from these 4 neighbors to [49.7,49.8] and put them into TrialPoints. However, when I go back and check the result distance map, some thing is different. The distances from these 4 neighbors to [49.7,49.8] are changed. As you can see, the distance from [50,50] to [49.7,49.8] remains correct. This is because this value is the smallest in the TrialPoints, therefore it is pushed in to the AlivePoints heap first and the value is frozen since then. I think there is something wrong here about whether to update trial points value or not. If this trial point is user specified, then the value should not be updated. I noticed a related discussion a couple of months ago in the mailing list, <a href="http://www.itk.org/pipermail/insight-users/2009-May/030282.html" target="_blank">http://www.itk.org/pipermail/insight-users/2009-May/030282.html</a><br>
<br><a href="http://www.rpi.edu/%7Echens/download/main1.cpp" target="_blank">http://www.rpi.edu/~chens/download/main1.cpp</a><br>
<a href="http://www.rpi.edu/%7Echens/download/main2.cpp" target="_blank">http://www.rpi.edu/~chens/download/main2.cpp</a><br><br>Any input is appreciated.<br><font color="#888888">Siqi</font><div><div></div><div class="h5">
<br><br><br><div class="gmail_quote">On Mon, Jan 4, 2010 at 3:32 PM, Dan Mueller <span dir="ltr"><<a href="mailto:dan.muel@gmail.com" target="_blank">dan.muel@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Siqi,<br>
<br>
Indeed I am familiar with Fast Marching. I saw your question to the<br>
mailing list, but did not respond because I have not experienced what<br>
you describe: when I set the trial point value, that is the value in<br>
the arrival function.<br>
<br>
Perhaps you could post to the mailing list a minimal example<br>
(code+cmake+data) demonstrating your issue. That would make it really<br>
easy for me to help you!<br>
<br>
Cheers, Dan<br>
<br>
2010/1/4 siqi chen <<a href="mailto:siqichensc@gmail.com" target="_blank">siqichensc@gmail.com</a>>:<br>
<div><div></div><div>> Hi, Dan,<br>
><br>
> Sorry to bother you. From the ITK mailing list, I noticed you reported a bug<br>
> about FastMarchingImageFilter couple of months ago. So I guess you are a<br>
> fast marching expert : )<br>
><br>
> I am trying to use FastMarchingImageFilter to calculate a distance map to a<br>
> set of points which have non-integer coordinates and I want the result to be<br>
> as accurate as possible. Here is what I did, but the result is not very<br>
> accurate.<br>
><br>
> First I find the integer points which are the neighbors of the target points<br>
> and set these integer points as trial points. Then I use some interpolation<br>
> method to initialize the distance from these trial points to the target<br>
> points, which are assumed to be "exactly correct". The TrialPoints in the<br>
> FastMarchingImageFilter is defined as this set of trial points and their<br>
> corresponding distances to the target points. The AlivePoints is empty. When<br>
> I check the result distance map, I find that the distance value of these<br>
> trial points are changed, they are no longer what their initial states are.<br>
> Therefore, the iso curve deviate the original input a little bit. I am quite<br>
> confusing about this result.<br>
><br>
> I noticed you mentioned on the mailing list about neighbor update, that is<br>
> to distinguish between user-specified trial points and algorithm-generated<br>
> trial points. here is the discussion,<br>
> <a href="http://www.itk.org/pipermail/insight-users/2009-May/030282.html" target="_blank">http://www.itk.org/pipermail/insight-users/2009-May/030282.html</a> . I wonder<br>
> if you have any suggestions about my problem.<br>
><br>
> Any input is appreciated.<br>
><br>
> Thanks<br>
> Siqi Chen<br>
><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>