The author proposed three alternative memory models for ITK images, while only one contiguous is now used in the toolkit.

The author provided set of tests for each memory model.

Source code is provided, and there is enough information to be able to replicate the work.

Code compiles, and tests run ok.

The internal representation of the data in SigleBitBinaryImage is an array of unsigned ints. And there is no mechanism to prevent writing to the same int from different threads in the same time.

In general case, SingleBitBinaryImage is not thread safe for using it with ITK's standard  filters. Some pixels (bits) may belong to different regions and filter may try to set them in paralel. But these bits also may belong to the same int, and changing them in paralel may lead to incorrect output.

The author propose some alternative memory models for ITK images. Currently only a contiguous memory model is used in the toolkit. The author proposes three alternative models: slice contiguous, for blocks of memory representing slices, sparse, for sparse images with only a set of pixels different from background value and single-bit binary images.

The author hypothesis is that the described memory models can be implemented by creating subclasses of image with corresponding pixel containers. All the filters and processing classes that access the images through PixelAccesors should continue to work.

A set of tests, one for each image memory model is provided. A performance benchmark is also provided.

Source code is provided, input images are generated as well as output images.

Code compiles cleanly. Tests run ok.

However there are problems running the performance benchmark. The program runs out of memory during the first iteration loop for sparse images. An std::bad_alloc is thrown after reaching a memory usage of 2.078.188 Kb. and m_PixelMap with 24061408 elements.

N/A

Usage of code is clearly described in the tests.

Code seems to conform to the ITK quality standards. Code was tested on an Intel Core 2 Quad 6600 2,4Ghz CPU, with 3 Gb. RAM, WinXP, VS2008.

N/A

In the future it would be particularly interesting to extend the slice memory model to be an on-demand cache memory model that loads the images as they are needed for processing, visualization etc. This would be very interesting for processing very large images with the current filters. Maybe this could be coupled with the streaming capabilities of the readers. We have already worked on this but with custom code and standard 2D images and readers.

Page 4, paragraph 1 seems to be incomplete.

Would be nice to have an example with an iterator in the article itself.

I do not totally agree with proposing the SliceContiguousImage class as not having a Dimension argument. 4D images are stored as slices too!