The authors propose the incorporation of mask images within the diffeomorphic demons framework.

Using masks should greatly help working with images that have some non-informative background.

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)

Source code and test data is provided. The images used in the paper are probably not there due to size constraints.

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).

n/a

The code is written in standard ITK form. Usage of it is a matter of minutes for an ITK user.

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".

c.f. "evidence" comments.

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.

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.