[Insight-users] an interesting problem

[Luis Ibanez]

Hi Gourong,

This is indeed an interesting problem.

You should probably be more careful when stating
the conclusions of your tests.

Generalization is a dangerous step in reasoning.


>From your test you conclude:

   "I found symmetric force demons-like
    algorithm gave nearly good performance as
    levelset motion based algorithm did except that
    it takes much more time than the latter one."

This is a good phrase for the end of a paper, but it is
not good for a technical audience doing real work with
real images.

You can only state this conclusion for the specific type
of images that you tested, and the combination of parameters
that you used.  As you probably noticed, the number of iterations
that each one of those algorithm run is controlled by a convergence
criterion.  Changing that criterion will change the number of iterations
and therefore the total execution time. For example, did you verified
that you run each method for the minimal amount of time required for
converging to equivalent results ?

I other words, the conclusion can only make sense in the
context of your full experiment which includes:

  - Your computer
  - Your compiler
  - Your operating system
  - Your compilation options
  - The Fixed and Moving images that you used
  - The parameters set on each algorithm

The conclusion, devoided of the context above becomes
a dangerous generalization.


Note that you use "performance" in the sense of quality of final
registration results. The word, unfortunately is more commonly
used in the sense of the computation time required for executing
the algorithm.


With the modification that you introduced in the
SymmetricForcesDemonsRegistrationFunction, you are now
comparing the fixed image against the resampling of the
moving image using the deformation field of the previous
iteration.

Given that the purpose of the algorithm is to compute a
deformation field that when used for resampling the moving
image will minimize the sum of squared differences between
the fixed image and the resampled moving image,... it is to
expect that at every iteration the sum of squared differences
should decrease.

Therefore, if you decide to compute the sum of square differences
using the deformation field of the previous iteration instead of
the deformation field of the current iteration, then, it is to
expect that this new measure (SSD) will be larger.


If you want to setup a framework for a fair comparison, you should
probably take the deformation field computed by each algorithm, and
use a single resampling program for taking the moving image, resampling
it with and computing the sum of squared differences against the fixed
image.

In that way you will make sure that you are using the same interpolator
in all cases, and you will be sure that you are using the *final* answer
(deformation field) reported by each algorithm.

You will find quite interesting to look not only to the last value of
the SSD measure but to the entire trace of values versus iteration
number. You will find, for example, that for the DemonsRegistration
filter the progression of the SSD measure looks like an exponential
decay. Meaning that the very few first iteration do most of the
registration work and the correction are less significant at every
subsequent iteration.

Comparing those curves between the methods will also present a more
complete picture of their performance since the point of crossing
of the curves will tell you at what number of iterations one method
will be equivalent to another.


If you put together a test including source code, image data and
parameters, this could make an excellent paper for the Insight Journal.



Regards,



   Luis



-------------------
Guorong Wu wrote:

> hello all:
> 	I have compared the performance of non-rigid registration algorithms provided by ITK these few days. They are DeformableRegistration2.cxx, DeformableRegistration3.cxx, and DeformableRegistration5.cxx, which are the implementation of original demons, symmetric force, and levelset motion respectively. Before I notice the problem, I found symmetric force demons-like algorithm gave nearly good performance as levelset motion based algorithm did except that it takes much more time than the latter one.  
> 	As you known, the performance is evaluated by the GetMetric function which returns the value of m_SumOfSquaredDifference. The variable is updated during each iterations. I found in DemonsRegistrationFunction and LevelSetMotionRegistrationFunction this variable is update as follows:
>     globalData->m_SumOfSquaredDifference+=vnl_math_sqr(fixedImageValue-movingImageValue);
> But in SymmtricForcesDemonsRegistrationFunction the update is in another way (at line 318):
>     globlaData->m_SumOfSquaredDifference+=vnl_math_sqr(fixedImageValue-NewmovingImageValue);
> which NewmovingImageValue the output of interpolator which is evaluated at the coordinate of deformation before iterations plus the updated value in this iteration(at line 289-322)      	
> 	So in order to make fair comparision, I modify the code of SymmetricForcesDemonsRegistrationFunction making SSD is the square of fixedImageValue minusing movingImageValue, not the NewmovingImageValue. After done this, I found the SSD of symmetricforce algorightm is much bigger than before. But I think the modification will not cause the problem because the NewMovingImageValue is just the value of movingImageValue computed at next iteration. Would you like to give me an answer? Thanks.
> 	
> 	   	
> 
> 　　　　　　　　Guorong Wu
> 　　　　　　　　grwu at sjtu.edu.cn
> 　　　　　　　　　　2004-07-28
> 
> =============================================================
> Guorong Wu	
> The Department of Computer Science and Technology
> Shanghai Jiao Tong University
> 1954 Huashan RD
> Shanghai China    
> 200030
> Tel:  +86 21 3226 1236  , 6293 2089
> =============================================================
> 
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>