Reviews

Gareth Price

Thursday 13 December 2007

Summary:

The author has developed an extension of WrapITK that enables the generation of .NET wrappers for ITK classes via CMake. The wrapped classes can then be directly called from CLR languages. C# examples are included in the source code and discussed in the paper.

Hypothesis:

Non applicable.

Evidence:

The author supplies all source code for the build of the wrappers as well as source code for the C# examples that are quoted in the paper.

Open Science:

As stated above, all source code is provided, including examples. The images used in the examples are also included in the code bundle.

Reproducibility:

Rather than use the binaries provided, I built the wrappers using CMake (v2.4 patch 7) and Visual Studio 2005 (v2.0.50727 SP1), following the instructions in Section 3.2 of the paper. I managed to build the managed libraries but in my case I needed to include two extra (small) steps in the process before successful compilation. Following step 7 (opening the ManagedITK.sln solution) and before step 8 (building) I also needed to:

7a. Resolve #using Dependencies: The #using compiler directive needs to be told where the ManagedITK.Common.dll is. Point this to the correct directory by way of the property pages Project->Properties then Configuration Properties->C/C++->General and fill in the Resolve #using References field.

7b. Set the include directory: The location of the include directories are set relatively. These need to be set explicitly (e.g. C:\\ITK\\Utilities\\vxl\\core\\vnl instead of \\Utilities..). This can be set in the property pages (see 7a above) Configuration Properties->C/C++->General->Additional Include Directories.

With regard to the examples, without any alteration they all built OK, however, when run they failed to load the ManagedITK libraries and failed. I do not write in C# and I think that this is a problem that could be easily solved given a little more experience of the language. Writing in C++/CLI, the examples, which are clearly explained in the paper, are easily converted and I have had no problems in using ManagedITK from this environment.

Use of Open Source Software:

The author produces .NET wrappers for ITK using CMake.

Open Source Contributions:

All source code is provided, as are binaries. The build process is well documented in the paper and required only minor modifications in my case (see Reproducibility section above).

Code Quality:

The examples provided are well documented both in the paper and throughout the source and concisely summarize the use of the wrapped classes.

I am not experienced in the use of WrapITK, or particularly so with CMake, and so don’t feel qualified to comment on the coding relating to these aspects of the project. However, it is important to note that as a non-expert, I was able to create the wrappers from the instructions provided with little hassle (see Reproducibility above).

Applicability to other problems:

I feel that a well developed and validated .NET version of ITK would be very welcome. Although there will inevitably be, as acknowledged by the author in the paper, performance loss when developing applications that require managed to native transitions, the ability to rapidly develop GUI applications is very appealing. The author also includes, in Section 2, a list of the pros and cons of using managed over native code in order to enable informed choice of programming language.

Suggestions for future work:

In order to get the most from managed ITK, I feel that it is important to be able to interface smoothly and efficiently to managed VTK. Indeed the author points out that this may be used in Section 5 - FAQ. To this end it would be useful for the interface classes ImageToVTKImageFilter and vtkImageToImageFilter to be included in the wrapping.

It would be nice if all of the ITK functionality were to be available in the managed environment (in Section 2 under the list of disadvantages the author lists those object not supported). Other issues are also highlighted in the paper by the author for future attention (e.g. location of the managed/native interface to allow for optimised iterative performance).

Requests for additional information from authors:

I think that a very useful addition to the project would be an expanded explanation of the wrapping procedure (at the moment in the FAQs under “How do I wrap an external project”). It would be nice if the structure of the CMake files and the effect of the various parameters therein were explicitly stated.

Obviously the greater the knowledge of WrapITK and CMake the reader posses, the more sense this section will make. However, a detailed walk through of the wrapping of a class would, I feel, make the process much more accessible to the non-expert reader.

Additional Comments:

N/A