Summary:

This submission is an implementation of an ITK Image IO object and factory for reading Analyze ObjectMaps. The code provides a helper class enabling the formation of object maps within ITK and writing them to disk.

Hypothesis:
N/A

Evidence:
N/A

Open Science:

All code and examples provided. Highly readable and written in the correct ITK style. The submission shows a deep understanding of ITK and the IO mechanisms.

Reproducibility:

While I did not compile the examples and test, after review of the code, I dropped it immediately into my application. No compilation problems and the code works nicely. The static block failed to register the factory however.

Use of Open Source Software:

Library implemented using ITK, with VTK used for visualization.

Open Source Contributions:

No problems compiling and using the code.

Code Quality:

Code compiled cleanly on Win and Linux. Static block failed to register the factory, but I manually initialized the library without issue. Fully documented and written in the ITK style. Was very impressed that the authors support all versions of Analyze's ObjectMap format.

Applicability to other problems:
N/A

Suggestions for future work:

Develop a similar, but more flexible format for ITK. Would be useful to have object labels and be able to include a voxel in more than one object, perhaps with different levels of membership or probability.

Requests for additional information from authors:
N/A

Additional Comments:
Thanks for the very valuable contribution to ITK!

Summary:
The authors describe a set of nez ITK classes made to read and write analyze map files, and to manipulate the object within them with ITK.

Some background about that review: I'm not using the analyze map files, and thus my expertise on that point is quite limited. However, the way the objects are represented in that file format seem really closed to the one I used in the contribution about label object manipulation. I'm reviewing that code with the hope to find some goo ideas, as well as a reader and a writer for the label object contribution.

Open Science:
Source code, test programs and teste data are provided - fully open science.

Reproducibility:
I didn't reproduced the work. Using that code requires to install it in the ITK tree - I haven't done it yet.

Use of Open Source Software:
ITK all the way

Open Source Contributions:
The authors are providing the source code. I read it, but didn't use it directly.

Code Quality:
Code quality is well documented and easy to read. 

Applicability to other problems:

That contribution will be useful for everyone who wants to store its label objects (a pretty common need).

Additional Comments:

While this contribution look very promising to store the label object at the first read, it may be a bit difficult in practice, because of the limitation to 255 objects per map. This limit may not be reached by everybody, but really, it can happen quite easily.

 About the way the  way the data associated with the objects: I found quite interesting to have the map stored in a standard image, and the data associated with the objects in that image stored in the metadata of the image. However, I believe that storing the object in memory with the run-length encoding, as it is done in the analyze file format, also have some advantages:

- a low memory usage  (most of the time)

- a high efficiency for some computations

- the ability to store the data associated to the object directly in the objects, which make the manipulation of the object easier, and ensure that no metadata will be still there if an object is removed for example

and some problems:

- it's more difficult to ensure the validity of the image (a pixel contain only one object for example)

- it's highly inefficient when the neighbors need to be visited

- it's a very different image representation than the itk::Image, and thus, it can't be used in the usual ITK filters (but some filters are available to convert from/to itk::Image)

There are some advantages on both sides, however, I don't think that's a good idea to introduce both representation in the toolkit.

I hope we can discuss about how to integrate those 2 contributions soon :-)