Summary:The authors propose the incorporation of mask images within the diffeomorphic demons framework.
Hypothesis:Using masks should greatly help working with images that have some non-informative background.
Evidence:One 3D registration example is provided as a unit test but the result is not checked against some regression image. It would be nice to have better unit tests:
- checking against a regression image
- checking that the registration with masks is better than the registration without masks (e.g. look at the SSD and harmonic energy on the entire non-masked fixed image region)
- checking that the registration on the same data but with different spacing, orientation and origin leads to the same results (in terms of pixel data for example)
Open Science:Source code and test data is provided. The images used in the paper are probably not there due to size constraints.
Reproducibility:I was able to download compile and use the code as is. The unit test passes (but again is only checks that the code runs).
Use of Open Source Software:n/a
Open source Contributions:The code is written in standard ITK form. Usage of it is a matter of minutes for an ITK user.
Code Quality :The code is basically a patch of the current diffeomorphic demons in ITK. As such it follows ITK's coding standards and seems portable.
However, there are two things that bother me in the current code:
- The API of the DiffeomorphicDemonsRegistrationWithMaskFilter let's one think that a generic SpatialObject can be used as a mask. Yet, dynamic_cast are used internally to get an ImageMaskSpatialObject from the SpatialObjects. This will lead to user frustration. Either the API should show that one has to use an ImageMaskSpatialObject or the code should only rely on generic methods from SpatialObjects. I would definitely be in favor of the second option. This can easily be done by avoiding the warping of the moving mask but using the initial moving mask with mapped points.
- The internal code shows that one has to either specify two masks or only one. This is however not documented and apparently not necessary. Why didn't the authors allow for using for example just a fixed image mask?
To be picky, the name of the unit test should use "Diffeomorphic " and not "Diffeorphic".
Quality of the data :c.f. "evidence" comments.
Interest:I believe that using a mask in the finite difference solver hierarchy is definitely a way to go. I even think that the inclusion of these masks should be done not at the final end of the hierarchy but much higher. In that way, all similar registration code could benefit from it.
Free comment :Did the authors compared the running times of the following?
- the initial diffeomorphic demons code
- the modified diffeomorphic demons without setting up any mask
- the modified diffeomorphic demons using masks
I would be interested in seeing the performance impact of this modification.
Comment by Yongqiang Zhao: A response to your suggestions

Hi, thanks for your review.
1. Regarding your comment about tests, i added the original data used in the paper, and you can compare the results by images and metrics like harmonic energy and Jacobian value of deformation field to find the performance of this filter. The unit test name changed from "Diffeorphic" to "Diffeomorphic ".
2. About "dynamic-cast" problem, thanks for your help, i modified the code that API of this filter rely on generic methods from SpatialObjects by the initial moving mask with mapped points. Meanwhile, the filter can also allow for either two masks or just one mask.
3. About running time: if the masks are not set, all pixels will be processed. Thus, it is same as the initial diffeomorphic demons code. If the masks are set, the running time is less than that of registration without mask as the number of processed pixels is less.