<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Thanks a lot Dan!</span></div><div><span>It works. I will follow your advice and modify the filter so that I can define the threshold via an input.</span></div><div><br><span></span></div><div><span>Thanks again for your time!</span></div><div><br><span></span></div><div><span>Maria</span></div><div><br></div><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><font size="2" face="Arial"><hr size="1"><b><span style="font-weight:bold;">De:</span></b> Dan Mueller <dan.muel@gmail.com><br><b><span style="font-weight: bold;">Para:</span></b> Maria Alejandra Zuluaga Valencia <mariazulv@yahoo.es><br><b><span style="font-weight: bold;">CC:</span></b> "insight-users@itk.org"
<insight-users@itk.org><br><b><span style="font-weight: bold;">Enviado:</span></b> jueves 7 de julio de 2011 15:36<br><b><span style="font-weight: bold;">Asunto:</span></b> Re: [Insight-users] Problem with Fast marching minimal path extraction<br></font><br>Opps, this time with attachment.<br><br>On 7 July 2011 15:34, Dan Mueller <<a ymailto="mailto:dan.muel@gmail.com" href="mailto:dan.muel@gmail.com">dan.muel@gmail.com</a>> wrote:<br>> Hi Maria,<br>><br>> I have located the issue. It is a problem with the Fast Marching<br>> Minimal Path source code.<br>><br>> The speed functions I used when developing Fast Marching Minimal Path<br>> where for vascular segmentation. These functions were basically white<br>> (1.0) near the vessel centerline and black (0.0) outside the vessels.<br>> Hence the arrival function were relatively smooth and continuous i.e.<br>> there were no sharp changes in intensity (low first
derivatives).<br>><br>> The speed function you are trying to use has a dark spot in which you<br>> place a seed point. However, within this dark spot the arrival<br>> function has large changes in intensity (high first derivatives)<br>> because the front is moving slowing through the dark region.<br>><br>> In the file itkSingleImageCostFunction.txx, in the function<br>> GetDerivative(), there is code at the bottom which sets the derivative<br>> to 0.0 if it is above some constant threshold (currently set at 15.0<br>> arrival time units). The derivatives in your image are much bigger<br>> than 15.0 -- in the order of 50.0. By removing this code, or<br>> significantly increasing the constant, I can get your image to work as<br>> expected.<br>><br>> In short, change the following lines in<br>> itk::SingleImageCostFunction::GetDerivative from<br>><br>> // Convert the image function output to the
cost function derivative<br>> const typename DerivativeType::ValueType DerivativeThreshold = 15.0;<br>> for (int i=0; i<ImageDimension; i++)<br>> {<br>> derivative[i] = static_cast<typename DerivativeType::ValueType>(<br>> output[i] );<br>><br>> // NOTE: The cost function may undefined / unreachable areas<br>> // (indicated by very large values) which may skew the gradient.<br>> // To avoid this skewing effect, we reset gradient values larger<br>> // than a given threshold.<br>> if ( vnl_math_abs(derivative[i]) > DerivativeThreshold )<br>> {<br>> derivative[i] = 0.0;<br>> }<br>> }<br>><br>> to<br>><br>>
// Convert the image function output to the cost function derivative<br>> for (int i=0; i<ImageDimension; i++)<br>> {<br>> derivative[i] = static_cast<typename DerivativeType::ValueType>(<br>> output[i] );<br>> }<br>><br>> The proper way of solving this is to make the DerivativeThreshold a<br>> user-specified parameter, which depends on the application.<br>><br>> HTH<br>><br>> Cheers, Dan<br>><br>> On 6 July 2011 17:35, Dan Mueller <<a ymailto="mailto:dan.muel@gmail.com" href="mailto:dan.muel@gmail.com">dan.muel@gmail.com</a>> wrote:<br>>> Hi Maria,<br>>><br>>> Can you please upload the exact speed image and start/end points you<br>>> are trying to use?<br>>><br>>> I suspect the issue is because the Fast Marching front (in ITK) does<br>>> not expand into regions which have 0.0 speed values. One
possibility<br>>> is to scale your speed image to ensure no values are 0.0 (i.e. using<br>>> RescaleIntensityImageFilter with max=1.0 and min=0.01).<br>>><br>>> To quote the Insight Journal article:<br>>> pg 4. "Choosing an appropriate speed function is the most<br>>> difficult part of the entire process"<br>>><br>>> Cheers, Dan<br>>><br>>> On 6 July 2011 17:13, Maria Alejandra Zuluaga Valencia<br>>> <<a ymailto="mailto:mariazulv@yahoo.es" href="mailto:mariazulv@yahoo.es">mariazulv@yahoo.es</a>> wrote:<br>>>> Hi Dan,<br>>>> In order to provide you more information I did a small modification to the<br>>>> SpeedFunctionToPathFilter. I have added an image writer so that I can save<br>>>> what you call the current arrival function. At the same time, I compare the<br>>>> result with a well-known toolbox in matlab that performs the
fast marching<br>>>> (btw, this is my final purpose; using itk instead of matlab). What I found<br>>>> is that the arrival functions differ significantly (might the problem be on<br>>>> the Fastmarching itself?). Moreover, I do obtain a path in matlab, no matter<br>>>> the end point.<br>>>> To illustrate you the situation I provide you screenshots of the matlab<br>>>> results (example_D_one_.jpg and example_path_one.jpg files) and the arrival<br>>>> function with itk (example_D_two.jpg), since no path is obtained. For this<br>>>> example, I have used an image of mine. I was using your Synthetic-04-Speed<br>>>> to evaluate the filter, but I can't not read zraw in matlab, so that is why<br>>>> I send you this other example. However, I will try to solve the zraw problem<br>>>> so that I can run the matlab code in Synthetic-04-Speed.<br>>>>
Regarding your saying about the path, perhaps on an image as<br>>>> Synthetic-04-Speed there should be no path when a point is badly placed (due<br>>>> to the completely dark background) but, in the image as the one I am using I<br>>>> think it should get something (as in matlab). I am not an expert but I<br>>>> believe that one of the advantage/disadvantage of minimal paths approaches<br>>>> is the fact that it will always find a path given two points. But, as I said<br>>>> before, according to the results I am sending you, I believe the problem<br>>>> seems to come from the arrival function and not from the path search. What<br>>>> do you think?<br>>>> Since my firewall does not allow me to attach files to emails, you can<br>>>> obtain the screenshots here:<br>>>> <a href="http://www.creatis.insa-lyon.fr/%7Ezuluaga/fm_issues/"
target="_blank">http://www.creatis.insa-lyon.fr/~zuluaga/fm_issues/</a><br>>>> regards,<br>>>> Maria<br>>>> ps. If you want I can also send you the image of my examples, while I solve<br>>>> the zraw problem. It is very small (184x184x23). I could place it on my<br>>>> server.<br>>>> let me know if that sounds ok.<br>>>><br>>>> ________________________________<br>>>> De: Dan Mueller <<a ymailto="mailto:dan.muel@gmail.com" href="mailto:dan.muel@gmail.com">dan.muel@gmail.com</a>><br>>>> Para: Maria Alejandra Zuluaga Valencia <<a ymailto="mailto:mariazulv@yahoo.es" href="mailto:mariazulv@yahoo.es">mariazulv@yahoo.es</a>><br>>>> CC: "<a ymailto="mailto:insight-users@itk.org" href="mailto:insight-users@itk.org">insight-users@itk.org</a>" <<a ymailto="mailto:insight-users@itk.org"
href="mailto:insight-users@itk.org">insight-users@itk.org</a>><br>>>> Enviado: miércoles 6 de julio de 2011 14:43<br>>>> Asunto: Re: [Insight-users] Problem with Fast marching minimal path<br>>>> extraction<br>>>><br>>>> Hi Maria,<br>>>><br>>>> Can you please provide some more information?<br>>>><br>>>> Which synthetic image are you using? Where are you placing the seed point?<br>>>><br>>>> I would not expect that every seed point will work -- the seed point<br>>>> needs to be in a region which is reachable by the Fast Marching<br>>>> expanding front. For example, placing the seed point in a region with<br>>>> low speed (near 0.0) will not work.<br>>>><br>>>> Attached are a few examples using different seed points.<br>>>><br>>>> Regards, Dan<br>>>><br>>>> On 5 July 2011
17:23, Maria Alejandra Zuluaga Valencia<br>>>> <<a ymailto="mailto:mariazulv@yahoo.es" href="mailto:mariazulv@yahoo.es">mariazulv@yahoo.es</a>> wrote:<br>>>>> Hi,<br>>>>> I am trying to use the minimal path extraction algorithm reported in:<br>>>>> <a href="http://hdl.handle.net/1926/1332" target="_blank">http://hdl.handle.net/1926/1332</a><br>>>>> After some minor compilation errors I managed to make it work. However, I<br>>>>> found the behavior is a bit weird. As an example:<br>>>>> if I test with one of the Synthetic images provided and the path points<br>>>>> given, everything works fine. But, as soon as I change one of the path end<br>>>>> points it stops working. By stop working I mean that the extracted path<br>>>>> contains no points. I've tried with several examples and it is always the<br>>>>>
case.<br>>>>><br>>>>> As far as I know, no matter how bad I place my end point, I should get a<br>>>>> minimal path connecting the end and start points. Has any one had the same<br>>>>> kind of problem? did you managed to fix it?<br>>>>> thanks,<br>>>>> Maria<br>><br><br><br></div></div></div></body></html>