[Insight-users] Insight-users Digest, Vol 61, Issue 43

Tue May 12 20:28:39 EDT 2009

----------------------------------------
> From: insight-users-request at itk.org
> Subject: Insight-users Digest, Vol 61, Issue 43
> To: insight-users at itk.org
> Date: Tue, 12 May 2009 12:41:48 -0400
>
> Send Insight-users mailing list submissions to
> insight-users at itk.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.itk.org/mailman/listinfo/insight-users
> or, via email, send a message with subject or body 'help' to
> insight-users-request at itk.org
>
> You can reach the person managing the list at
> insight-users-owner at itk.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Insight-users digest..."
>
>
> Today's Topics:
>
> 1. Re: 3d Deformable Registration problem based on
> DeformableRegistration8 (Luis Ibanez)
> 2. Re: 3d Deformable Registration problem based on
> DeformableRegistration8 (Luis Ibanez)
> 3. How to Set Output Origin and Output Region in
> ResampleImageFilter When Resampling For a Different Direction? (Kon Z)
> 4. Re: DTI data for testing (Luis Ibanez)
> 5. Re: Behavior of FastMarchingImageFilter (Dan Mueller)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 12 May 2009 12:02:13 -0400
> From: Luis Ibanez 
> Subject: Re: [Insight-users] 3d Deformable Registration problem based
> on DeformableRegistration8
> To: Albert Gubern 
> Cc: insight-users at itk.org
> Message-ID:
> 
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Albert,
>
> It turned out in practice that the LBFGSBOptimizer is not as superior
> as it may have been assumed.
>
> Lately we have simply used the RegularStepGradientDescentOptimizer
> with reasonable results.
>
> See for example:
>
> Insight/Examples/Registration/DeformableRegistration15.cxx
>
> In general,
> any claims saying than some component is
>
> "The Best"
>
> should be taken with a lot of suspicion.
>
>
> Such claims are good only for publishing papers in traditional
> Journals and Conferences that do not exercise reproducibility.
> You can not rely on such sources when you are working on
> serious applications.
>
>
> Don't hesitate to experiment with other components of the
> registration framework.
>
> In many cases, the challenge is not so much about what components
> to use, but about how to fine-tune their parameters for the problem
> at hand.
>
>
> Please let us know what you find,
>
>
> Thanks
>
>
> Luis
>
>
> -------------------------
> On Tue, May 12, 2009 at 11:21 AM, Albert Gubern  wrote:
>> Hi,
>>
>> I've modified the example DeformableRegistration8.cxx in order to do a 3D
>> DeformableRegistration. This example uses MattesMutualInformationMetric,
>> BSplineDeformableTransform and LBFGSBOptimizer.
>>
>> I tested the code with a brain phantom generated with Matlab. The original
>> volume is deformed using Matlab b-spline deformation based on this routine
>> http://www.mathworks.com/matlabcentral/fileexchange/20057, and I want to use
>> the deformable registration of ITK to recover the deformation. The next link
>> shows two checkerboard of one slice, before and after the succesful
>> registration:
>> http://img140.imageshack.us/img140/1831/phantomdeformableregist.png. The
>> original volume is set as the fixed image and the deformed phantom as the
>> moving.
>> - Mostra el text citat -
>>
>> The output of the execution is:
>>
>> Starting Registration
>> 0 ? -0.579387 ? 0 0
>> 0 ? -0.581355 ? 0 0
>> 0 ? -0.584345 ? 0 0
>> 0 ? -0.584345 ? 6.33911e-05 0
>> 1 ? -0.603649 ? 6.33911e-05 0
>> 1 ? -0.603649 ? 6.41689e-05 0
>> 2 ? -0.624884 ? 6.41689e-05 0
>> 2 ? -0.624884 ? 7.76054e-05 0
>> 3 ? -0.638071 ? 7.76054e-05 0
>> 3 ? -0.638071 ? 6.32524e-05 0
>> 4 ? -0.655438 ? 6.32524e-05 0
>> 4 ? -0.655438 ? 7.51525e-05 0
>> 5 ? -0.677776 ? 7.51525e-05 0
>> 5 ? -0.677776 ? 6.37494e-05 0
>> 6 ? -0.696669 ? 6.37494e-05 0
>> 6 ? -0.696669 ? 5.09743e-05 0
>> 7 ? -0.713613 ? 5.09743e-05 0
>> 7 ? -0.713613 ? 5.48518e-05 0
>> ... (60 iterations more)
>> 67 ? -0.854863 ? 4.01611e-05 0
>> 67 ? -0.854863 ? 4.01611e-05 0
>> 67 ? -0.854863 ? 4.01611e-05 0
>> 67 ? -0.854863 ? 4.01611e-05 0
>> ? ? ? ? ?Probe Tag ? ?Starts ? ?Stops ? ? ? ? ? ? Time (s)
>> ? ? ? ?Registration ? ? ? ? ? 1 ? ? ? ? ? ?1 ? ? ? ? ? 3289.35
>>
>> Next step was to test the same code with prostate MRI images but the
>> registration doesn't work. The original volume is a central region of MRI to
>> focus the registration on the prostate
>> (http://img145.imageshack.us/img145/200/mrireal.png), and the same
>> deformation, that was applied to the phantom test, is used to deform the
>> original prostate. The goal of the registration is the same: recovering the
>> deformation. The next link is a checkerboard of one slice of the volume to
>> show that fixed and moving images look different enough
>> (http://img26.imageshack.us/img26/8905/im011.png).
>>
>> In this test the program the registration stops too early doing only few
>> iterations and the InfinityNormOfProjectedGradient is always zero:
>>
>> Starting Registration
>> 0 ? -0.742878 ? 0 0
>> 0 ? -0.722791 ? 0 0
>> 0 ? -0.721167 ? 0 0
>> 0 ? -0.721134 ? 0 0
>> 0 ? -0.733701 ? 0 0
>> 0 ? -0.733701 ? 0 0
>> 0 ? -0.742878 ? 0 0
>> 0 ? -0.742878 ? 0.000122748 0
>> ? ? ? ? ?Probe Tag ? ?Starts ? ?Stops ? ? ? ? ? ? Time (s)
>> ? ? ? ?Registration ? ? ? ? ? 1 ? ? ? ? ? ?1 ? ? ? ? ? 97.3459
>>
>> I have tested the registration using different values of bins
>> (32,64,100,etc), % samples (100, 50, ...), using the original
>> (0.46875,0.46875,0.46875) and the unitary spacing, different number of grids
>> (from 5 to 50) and the parameters of the LBFGSBOptimizer are the following:
>>
>> ?double costFunctionconvergenceFactor = 1.e7;
>> ?double projectedGradientTolerance = 1e-6;
>> ?int maxNumberOfIterations = 500;
>> ?int maxNumberOfEvaluations = 500 ;
>> ?int maxNumberOfCorrections = 5;
>>
>> Among other tests, I've also changed the metric to MeanSquareMetric to know
>> if mattes mutual information metric is the problem or, separately, the fixed
>> and moving image have been binarized to reduce the information of each
>> image. The output has been the same.
>>
>> All the tests seem to show that the problem is the optimizer, but I don't
>> know how I can solve it because in some posts in the mailing list I've read
>> that it is the best optimizer for deformable registration. Should I change
>> it for another one (Regular or LBFGS)? Any other idea?
>>
>> Thanks in advance.
>>
>> Albert
>> _____________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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
>>
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 12 May 2009 12:02:24 -0400
> From: Luis Ibanez 
> Subject: Re: [Insight-users] 3d Deformable Registration problem based
> on DeformableRegistration8
> To: Albert Gubern 
> Cc: insight-users at itk.org
> Message-ID:
> 
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Albert,
>
> It turned out in practice that the LBFGSBOptimizer is not as superior
> as it may have been assumed.
>
> Lately we have simply used the RegularStepGradientDescentOptimizer
> with reasonable results.
>
> See for example:
>
> Insight/Examples/Registration/DeformableRegistration15.cxx
>
> In general,
> any claims saying than some component is
>
> "The Best"
>
> should be taken with a lot of suspicion.
>
>
> Such claims are good only for publishing papers in traditional
> Journals and Conferences that do not exercise reproducibility.
> You can not rely on such sources when you are working on
> serious applications.
>
>
> Don't hesitate to experiment with other components of the
> registration framework.
>
> In many cases, the challenge is not so much about what components
> to use, but about how to fine-tune their parameters for the problem
> at hand.
>
>
> Please let us know what you find,
>
>
> Thanks
>
>
> Luis
>
>
> -------------------------
> On Tue, May 12, 2009 at 11:21 AM, Albert Gubern  wrote:
>> Hi,
>>
>> I've modified the example DeformableRegistration8.cxx in order to do a 3D
>> DeformableRegistration. This example uses MattesMutualInformationMetric,
>> BSplineDeformableTransform and LBFGSBOptimizer.
>>
>> I tested the code with a brain phantom generated with Matlab. The original
>> volume is deformed using Matlab b-spline deformation based on this routine
>> http://www.mathworks.com/matlabcentral/fileexchange/20057, and I want to use
>> the deformable registration of ITK to recover the deformation. The next link
>> shows two checkerboard of one slice, before and after the succesful
>> registration:
>> http://img140.imageshack.us/img140/1831/phantomdeformableregist.png. The
>> original volume is set as the fixed image and the deformed phantom as the
>> moving.
>> - Mostra el text citat -
>>
>> The output of the execution is:
>>
>> Starting Registration
>> 0 ? -0.579387 ? 0 0
>> 0 ? -0.581355 ? 0 0
>> 0 ? -0.584345 ? 0 0
>> 0 ? -0.584345 ? 6.33911e-05 0
>> 1 ? -0.603649 ? 6.33911e-05 0
>> 1 ? -0.603649 ? 6.41689e-05 0
>> 2 ? -0.624884 ? 6.41689e-05 0
>> 2 ? -0.624884 ? 7.76054e-05 0
>> 3 ? -0.638071 ? 7.76054e-05 0
>> 3 ? -0.638071 ? 6.32524e-05 0
>> 4 ? -0.655438 ? 6.32524e-05 0
>> 4 ? -0.655438 ? 7.51525e-05 0
>> 5 ? -0.677776 ? 7.51525e-05 0
>> 5 ? -0.677776 ? 6.37494e-05 0
>> 6 ? -0.696669 ? 6.37494e-05 0
>> 6 ? -0.696669 ? 5.09743e-05 0
>> 7 ? -0.713613 ? 5.09743e-05 0
>> 7 ? -0.713613 ? 5.48518e-05 0
>> ... (60 iterations more)
>> 67 ? -0.854863 ? 4.01611e-05 0
>> 67 ? -0.854863 ? 4.01611e-05 0
>> 67 ? -0.854863 ? 4.01611e-05 0
>> 67 ? -0.854863 ? 4.01611e-05 0
>> ? ? ? ? ?Probe Tag ? ?Starts ? ?Stops ? ? ? ? ? ? Time (s)
>> ? ? ? ?Registration ? ? ? ? ? 1 ? ? ? ? ? ?1 ? ? ? ? ? 3289.35
>>
>> Next step was to test the same code with prostate MRI images but the
>> registration doesn't work. The original volume is a central region of MRI to
>> focus the registration on the prostate
>> (http://img145.imageshack.us/img145/200/mrireal.png), and the same
>> deformation, that was applied to the phantom test, is used to deform the
>> original prostate. The goal of the registration is the same: recovering the
>> deformation. The next link is a checkerboard of one slice of the volume to
>> show that fixed and moving images look different enough
>> (http://img26.imageshack.us/img26/8905/im011.png).
>>
>> In this test the program the registration stops too early doing only few
>> iterations and the InfinityNormOfProjectedGradient is always zero:
>>
>> Starting Registration
>> 0 ? -0.742878 ? 0 0
>> 0 ? -0.722791 ? 0 0
>> 0 ? -0.721167 ? 0 0
>> 0 ? -0.721134 ? 0 0
>> 0 ? -0.733701 ? 0 0
>> 0 ? -0.733701 ? 0 0
>> 0 ? -0.742878 ? 0 0
>> 0 ? -0.742878 ? 0.000122748 0
>> ? ? ? ? ?Probe Tag ? ?Starts ? ?Stops ? ? ? ? ? ? Time (s)
>> ? ? ? ?Registration ? ? ? ? ? 1 ? ? ? ? ? ?1 ? ? ? ? ? 97.3459
>>
>> I have tested the registration using different values of bins
>> (32,64,100,etc), % samples (100, 50, ...), using the original
>> (0.46875,0.46875,0.46875) and the unitary spacing, different number of grids
>> (from 5 to 50) and the parameters of the LBFGSBOptimizer are the following:
>>
>> ?double costFunctionconvergenceFactor = 1.e7;
>> ?double projectedGradientTolerance = 1e-6;
>> ?int maxNumberOfIterations = 500;
>> ?int maxNumberOfEvaluations = 500 ;
>> ?int maxNumberOfCorrections = 5;
>>
>> Among other tests, I've also changed the metric to MeanSquareMetric to know
>> if mattes mutual information metric is the problem or, separately, the fixed
>> and moving image have been binarized to reduce the information of each
>> image. The output has been the same.
>>
>> All the tests seem to show that the problem is the optimizer, but I don't
>> know how I can solve it because in some posts in the mailing list I've read
>> that it is the best optimizer for deformable registration. Should I change
>> it for another one (Regular or LBFGS)? Any other idea?
>>
>> Thanks in advance.
>>
>> Albert
>> _____________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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
>>
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 12 May 2009 17:04:46 +0100
> From: Kon Z 
> Subject: [Insight-users] How to Set Output Origin and Output Region in
> ResampleImageFilter When Resampling For a Different Direction?
> To: insight-users at itk.org
> Message-ID: 
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello ALL.
>
> I realise that the output image region is likely to become larger then
> the input region when using ResampleImageFilter to resample an image
> with a new direction and I would like to have all original image data to
> be included in the output region.
>
> Also while in the input image the (0,0,0) index is at the position of
> the image origin, in the output image the origin needs to be set with
> the new direction in mind.
>
> What is the correct way of calculating the output region (for calling
> SetSize()) and output origin (for calling SetOutputOrigin()) when using
> ResampleImageFilter to resample an image with a new direction?
>
> Regards,
> Kon
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 12 May 2009 12:08:55 -0400
> From: Luis Ibanez 
> Subject: Re: [Insight-users] DTI data for testing
> To: Antoine DUCHAMPS 
> Cc: insight-users at itk.org
> Message-ID:
> 
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Antoine,
>
> You may want to look at this data sets from the NAMIC DTI Workshop
> http://www.na-mic.org/Wiki/index.php/Training:DTI_Workshop#Preparation_for_Workshop_--_Important_Information_for_all_attendees
>
> http://www.na-mic.org/Wiki/images/7/72/Tensor_data.zip
>
>
> Regards,
>
>
> Luis
>
>
> ---------------------------------
> On Tue, May 12, 2009 at 11:42 AM, Antoine DUCHAMPS
>  wrote:
>> Hi All,
>>
>> I'm working with DTI images of the brain and I'm looking for image data
>> for testing. Does anybody know any database (like Bullit's), synthetic
>> sequence, or phantom acquisition I could use?
>>
>> Thanks!
>>
>> Antoine
>>
>> _____________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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
>>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 12 May 2009 18:41:40 +0200
> From: Dan Mueller 
> Subject: Re: [Insight-users] Behavior of FastMarchingImageFilter
> To: Amardeep Singh 
> Cc: insight-users at itk.org
> Message-ID:
> 
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Amardeep,
>
> The initial patch I proposed missed a use case, so: no, the results
> you experienced are not normal. The solution Luca proposed (adding an
> InitialTrial type) should correctly solve your issue.
>
> I'm snowed under at work at the moment, so I won't get around to
> submitting the fix until the weekend...
>
> Regards, Dan
>
> 2009/5/12 Amardeep Singh :
>> Hello
>>
>> I would just like to let you know what I have experienced with the bugfix as
>> it is
>> now.
>> The "jaggednes" of the result has definitely disappeared. However, I am
>> confused
>> by the fact that the isolines of the fast marching output a little further
>> away from the object look like edges of a square
>> rotated by 45 degrees (see the snapshot at the isoline 12 and the attached
>> output image; I have applied the filter to the
>> binary circle again).
>> Is this normal? I understand that the current bugfix is a preliminary one.
>>
>> I am looking forward to the final bugfix and thanks a lot for correcting
>> this bug.
>>
>> Best regards
>> Amar
>>
>>
>> Dan Mueller wrote:
>>>
>>> Hi Luca,
>>>
>>> Sure -- adding the target stuff to the base class at the same time sounds
>>> great.
>>>
>>> Do you want me to do it? I probably won't make the Friday 15th May
>>> deadline for 3.14 though...
>>>
>>> Cheers, Dan
>>>
>>> 2009/5/11 Luca Antiga :
>>>
>>>>
>>>> Hi Dan,
>>>> ?yep, that would work.
>>>> The user-supplied Trial points should be tagged as InitialTrial in the
>>>> LabelImage,
>>>> put in the TrialHeap but not be updated as neighbors. And taking care of
>>>> condition
>>>> ? ?if ( m_LabelImage->GetPixel( node.GetIndex() ) != TrialPoint )
>>>> at line 292 in itkFastMarchingImageFilter.txx.
>>>> Actually, since we are at it, it may also be good to move the Target
>>>> business from
>>>> FastMarchingUpwindGradientImageFilter to the base class (see your Apr 14
>>>> message "Trying to monitor progression of fast march operation").
>>>> Actually, we may also improve it by not looping around the target point
>>>> list
>>>> in
>>>> the UpdateNeighbors method, but defining an extra label in the enum
>>>> (Target)
>>>> and storing the Target label in the LabelImage.
>>>> I didn't do it back then because I just wanted to write an extra class
>>>> without
>>>> touching the original filter.
>>>> What do you think?
>>>>
>>>> Luca
>>>>
>>>>
>>>> On May 9, 2009, at 8:19 PM, Dan Mueller wrote:
>>>>
>>>> shouldn't you check if the update value computed for the trial point
>>>>
>>>> is smaller than the already existing value for that trial point and if
>>>>
>>>> so update it regardless?
>>>>
>>>> Ah yes, I see the issue with the fix I proposed -- once a trial point
>>>> is given a solution value, it will never be improved upon.
>>>>
>>>> But what if the trial point is user specified? Shouldn't the value
>>>> given by the user be used, even it is larger than the calculated one?
>>>> Otherwise, why does the user even specify the node value?
>>>>
>>>> So I guess we need some way to distinguish between user specified and
>>>> computed trial points... If the neighbour is a user specified trial
>>>> point or alive, then don't update it...?
>>>>
>>>> Regards, Dan
>>>>
>>>> 2009/5/9 Luca Antiga :
>>>>
>>>> Hi Dan,
>>>>
>>>> ?shouldn't you check if the update value computed for the trial point
>>>>
>>>> is smaller than the already existing value for that trial point and if
>>>>
>>>> so update it regardless?
>>>>
>>>> Luca
>>>>
>>>> 2009/5/9, Dan Mueller :
>>>>
>>>> Hi Amar,
>>>>
>>>> Congratulations! It seems you managed to find a bug in the
>>>>
>>>> FastMarchingImageFilter :P
>>>>
>>>> In itkFastMarchingImageFilter.txx the UpdateNeighbors method checks if
>>>>
>>>> the candidate neighbour is an alive point. If so, then it is skipped
>>>>
>>>> from further processing. If not, then it is processed (ie. output
>>>>
>>>> value updated). This method should also test if the candidate
>>>>
>>>> neighbour is a *trial* point. If it is a trial point, then the output
>>>>
>>>> value has already been set, and does not need to be updated. Doing so
>>>>
>>>> will actually produce incorrect values, as you have encountered with
>>>>
>>>> your "jagged" edges.
>>>>
>>>> I have submitted a bug for this issue:
>>>>
>>>> ? ?http://public.kitware.com/Bug/view.php?id=8990
>>>>
>>>> The bug report includes a patch, which I have also attached to this mail.
>>>>
>>>> Surprisingly this issue has been around since version 1.16 of the file
>>>>
>>>> (nearly 8 years)...
>>>>
>>>> Please let us know if this solves your issue.
>>>>
>>>> Regards, Dan
>>>>
>>>>
>>>> 2009/5/8 Dan Mueller :
>>>>
>>>> Hi Amar,
>>>>
>>>> I can reproduce your results. It is very strange; I can't see what is
>>>>
>>>> wrong with the code. I will look into it further on the weekend.
>>>>
>>>> Cheers, Dan
>>>>
>>>> 2009/5/8 Amardeep Singh :
>>>>
>>>> Hello everybody:
>>>>
>>>> Dear Dan:
>>>>
>>>> Thank you very much for your help!
>>>>
>>>> I have attached some sample code and a binary image of a circle for
>>>>
>>>> testing.
>>>>
>>>> The program can be called like the following:
>>>>
>>>> fast_marching_itk_mailing_list ./circle.nii.gz
>>>>
>>>> ./fast_marching_output.nii.gz
>>>>
>>>> 200
>>>>
>>>> The last number is the stopping value which I usually set to large
>>>>
>>>> values. I
>>>>
>>>> use
>>>>
>>>> the fast marching filter in this example with a constant speed of 1 so
>>>>
>>>> that
>>>>
>>>> the result should be some kind of a distance map.
>>>>
>>>> Certainly, one important point is my calculation of the alive and trial
>>>>
>>>> points. All the points of the circle that have a background voxel within
>>>>
>>>> their
>>>>
>>>> 6-neighborhood are considered trial points (so the last layer around the
>>>>
>>>> circle becomes a layer of trial points). All other points of the circle
>>>>
>>>> are
>>>>
>>>> alive points.
>>>>
>>>> I have attached a screenshot of the 0 isoline of the result (the complete
>>>>
>>>> output image was too large for the mailing list, unfortunately). When you
>>>>
>>>> look at it, you can see the jagged edge again. But still: Shouldn't it
>>>>
>>>> propagate evenly from the trial points?
>>>>
>>>> The intialization (0 isoline of the result) looks jagged already.
>>>>
>>>> Concerning my previous snapshot:
>>>>
>>>> The output image was of type float. Just for the snapshopt, I mapped all
>>>>
>>>> values> 0 to 1 in order to visualize the jagged edge.
>>>>
>>>> Best regards
>>>>
>>>> Amar
>>>>
>>>>
>>>> Dan Mueller wrote:
>>>>
>>>> Hi Amar,
>>>>
>>>> Perhaps you can post a minimal example (code, input image, output
>>>>
>>>> image) demonstrating the issue.
>>>>
>>>> I have not experienced this issue myself, but the
>>>>
>>>> FastMarchingImageFilter does propagate the front using
>>>>
>>>> 4-/6-connectivity, so after a small timestep it may be possible to
>>>>
>>>> experience the "jagged" edge you are seeing (though not the checked
>>>>
>>>> pattern inside the hole). How many iterations are you letting the
>>>>
>>>> filter run for? (ie. what is the stopping value?)
>>>>
>>>> Also, the FastMarchingImageFilter requires a real (float, double)
>>>>
>>>> output image. What is the pixel type of your output image?
>>>>
>>>> Cheers, Dan
>>>>
>>>> 2009/5/7 Amardeep Singh :
>>>>
>>>>
>>>> Hello everyone
>>>>
>>>> I am wondering about the behavior of the FastMarchingImageFilter.
>>>>
>>>> I want to let the algorithm march from a certain surface which is
>>>>
>>>> represented by a binary image. I
>>>>
>>>> pass the points of the object as alive points to the marcher. The layer
>>>>
>>>> outside of the object (in my case: a brain)
>>>>
>>>> is passed as trial points. When I look at the output of the fast
>>>>
>>>> marching filter, there is something strange -> see attached screenshot.
>>>>
>>>> The area within the yellow line is my initial object. So they are all
>>>>
>>>> alive points whose value is 0 in the output. ?But when you look at the
>>>>
>>>> layer
>>>>
>>>> outside of the inner object, you see that it is jagged, black (value 0)
>>>>
>>>> and white (value != 0) voxels take turns. Why is this the case?
>>>>
>>>> What do I need to do, so that the marcher marches equally away from the
>>>>
>>>> alive points. The speed image values on the layer around the alive
>>>>
>>>> points do have the same value, so this is not the reason.
>>>>
>>>> Thanks a lot in advance!
>>>>
>>>> Best Regards
>>>>
>>>> Amar
>>>>
>>>
>>>
>>
>
>
> ------------------------------
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
>
> End of Insight-users Digest, Vol 61, Issue 43
> *********************************************

_________________________________________________________________
Create a cool, new character for your Windows Live™ Messenger. 
http://go.microsoft.com/?linkid=9656621