The authors implement a shape based interpolation method from (Raya and Udupa, 1990) in the form of two ITK filters.  This shape based interpolation method interpolates between two binary images, by interpolating the signed distance maps of each image, and then finding the zero crossing of the result.

This is a useful contribution, which does not currently exist in ITK as far as I know.

The authors propose to implement the Raya and Udupa algorithm.

The authors provide binary executables (linux, 64bit) and code, as well as the data.  They show a couple example runs on a geometric structure and an anatomical structure.

The authors provide code and data to reproduce the work.

I did not extensively check that their results are as reported, but it seems so.  I performed other tests - see following.

They have used ITK as a basis for their work.

The code conforms with open source principles, it was easy to download and use.

Overall the code seems of good quality.  It was not difficult to work with it.  There are no unit tests, however.  There are a few comments criticisms, but these issues are minor.

Ideally, Insight Journal submissions can be set up to autocompile and test automatically.  This was not done in this case.

Linux 64bit binaries were included with the submission.  This is unusual, but not a problem as such.  Normally code only would be included.

Their code compiled cleanly on gcc/Linux, but did not compile under Windows/Visual Studio as written.  This was simply due to leaving typenames in their typedefs in the filters.   The filters are not templates.  Having typename outside a template is not conformant with c++03, but gcc lets it through anyway.

The authors have chosen to not template their filter over pixel type.  While it is probably true that this filter would be most useful in unsigned char form, this is a deviation from ITK style.

Header files are not listed in the CMakeLists.txt

Unfortunately, there seem to be at least three significant problems with the implementation.  I tried interpolating between a rectangle, and a version of the same rectangle shrunken by one pixel all around. I used a DelineationRatio of 5 and linear interpolation.  These data have been attached to this review, also a modification to the test program to allow changing the delineation ratio.

If there is no padding around the volume (ie, just two slices) then the result consists of one slice the size of the large rectangle, followed by 7 slices the size of the small rectangle, followed by two blank slices.  Ideally, the interpolation should yield roughly equal numbers of slices with the larger rectangle, and with the small rectangle.

When the volume is padded with a blank slice at either end, there are three blank slices, three large rectangle slices, 7 small rectangle slices, and 7 blank slices.

In both cases, the coordinate system of the resulting volume is the same as the input volume, other than the spacing.  This means that in the first case, the center of the first slice which contains an on voxel is at the same place as the center of the first slice which contains an on voxel in the input data, but the last slice is now shifted forward, to roughly the edge of the voxel in the original data.  In the second case, the on pixels start just inside the edge of the first voxel which contained data, ie, they are shifted back.  (Assuming coordinate-centred voxels, which are ITK and DICOM standard)

Finally, if the interpolation is changed from linear to Bspline, the results are different in the padded case, but not in the unpadded case.  In the padded case, BSpline interpolation gives one small rectangular slice in place of a large rectangular slice at the first.  This is difficult to understand.  If extrapolation is being done, both linear and bspline should give similar results in this case.  

The first issue is most likely due to the SignedDanielssonDistanceMap being biased - the first pixel inside the object has a zero distance, and the first pixel outside has a 1 distance.  The Raya and Udupa paper is rather unclear on this point, the following paper, especially the diagrams, may be helpful

   G. T. Herman, J. Zheng, and C. A. Bucholtz,  "Shape-based interpolation,” IEEE Computer Graphics and Applications, May 1992, pp. 69-79.

As for the second issue, the origin of the output image seems to be explicitly set to the origin of the input image.  Its not clear to me that thats really the right thing to do when upsampling.

I am uncertain why the third observation occurs.

Overall, I would recommend the inclusion of a formal unit test, or tests, on examples which can be worked out by hand such as this rectangle case.  The examples given in the paper are too complex, at least for me, to visually judge the correctness of the results.

It might have been interesting to have done the implementation as a filter which takes two 2D slices and an interpolation factor.  As written, the filters preclude the use of this interpolator to resample objects delineated on unevenly spaced slices.  This could possibly be an important use case.