The author proposes a class to split an input image into multiple output images, one for each component of the input image. While adaptors are available in ITK to obtain similar behavior, the proposed class allocates a new memory region to store the split images. This approach may use more memory, but could be useful for some applications.

The source code was provided. Some example images were provided in the tests.

The documentation of the contributed code is sufficient to be able to use it in other projects.

I downloaded the code, configured it with CMake, and compiled it successfully on Mac OS X 10.6.4 with gcc 4.2.1. I enabled only the USE_DOUBLE option; otherwise, compile time took too long for the purposes of this review.

I believe this code relies on post-ITK 3.20 code in the git repository, so you'll want to build it against the code in git.

The contribution is open source software.

Yes, it is very useable. After pulling changes from ITK's git repository, I was able to run the tests within minutes. The only problem I had was a testing failure in the split-components test, but this was an exception thrown by GDCM.

The code appears to satisfy the ITK coding style guidelines.

The images provided for testing were sufficient to exercise the proposed code.

This contribution can be useful for certain applications. I would like to see it modified so that I could select the specific components I want rather than the first few given by the TComponents template argument. Sure, I could simply ask for the specific images I want from the filter by calling GetOutput(i), but I wouldn't want to waste the memory used by the images I don't care about.

While I could see the SplitComponentsImageFilter being useful, I think most of the time the existing ITK adaptor mechanism is sufficient, and even desirable because it uses less memory.

That said, some problems exist with ITK's adaptors:
- They do not support NeighborhoodIterators (http://public.kitware.com/Bug/view.php?id=822)
- They cannot be used as input to ImageFileWriter (http://public.kitware.com/Bug/view.php?id=575)

As a solution to both problems above, I suggest that you could broaden the scope of this work by creating a generalized filter that produces an output image from any of the arbitrary adaptors in ITK. You could then write the SplitComponentsImageFilter using this new filter by using NthElementImageAdapter internally.

This general adaptor-to-image filter would also offer a neat way for a user to create a an efficient filter by concatenating adaptors. The output image would then store the results of the various adaptor operations.