Summary:
The paper describes two connected component algorithms and analyzes their improved performance compared to the connected component filter in the InsightToolkit.
In a three-step process, every connected component in a binary image receives a different label. The pixel intensity inside every component is replaced with the value of its label.
This operation is particularly useful as a pre-processing step to extract the largest component in an image or to measure the size of anatomical structures.
Evidence:
The author describes his experiments in details and gives useful tips for researchers interested in optimizing their algorithms.
The code and data for the performance analysis are provided. However a pair of example input/output images would help to check if the executable gives the expected result.
Open Science:
Fully Open Science. Almost Open Data: the input images are provided, not the output images.
I understand that this was not intentional but the author did not see the need for providing the output images. Those images could be easily added as a revision.
I really appreciate that the author comments his experiment process and mentions other directions.
Reproducibility:
I compiled the code with MS VS8 and run it. The process is seamless.
I could not compare the output image I got with what the code is expected to return (see above comment).
Open Source:
100% ITK. Excellent code quality.
Requests for additional information from authors:
I would like to see a pair of input/output images in the paper and the archive, along with the list of arguments used.
Additional Comments:
What would be impact on the performance to collapse the labels in a way that all labels from 0 to number_of_components are used?
I tried the code on an image with 2 components on a black background, and the result image had labels 0, 1 and 18.
I would like to avoid having a second filter to re-label 0, 1 and 18 to 0, 1 and 2.
Comment by Richard Beare: New revision should address your concerns

Hi,
I've released a new revision that includes the additions you requested.
There is a new version of the filter that returns an image with consecutive
labels starting at 1. The connected components are ordered so that components
that are hit first by a raster order scan have lower labels.
There is a subdirectory containing my output images. These images can be used
for regression testing in the case of the filters returning consecutive labels.
There was no significant change in performance in making output labels consecutive.
Comment by Richard Beare: consecutive labels and output images

The production of consecutive labels is on my wish list, ideally the numeric order should match the
raster order in which objects were found. The first pass at optimization attempted to reuse as much
of the existing implementation as possible, which includes the equivalency table code which controls
the labels produced.
I'm hoping that a replacement for the equivalency table will provide this capability as well as improve
performance in the future.
The equivalency table also relates to my reasons for not including output images. I suspect, although
I haven't confirmed this, that the equivalency table will produce different labels on different hosts. The
output images will therefore be equivalent but not identical.
The way I've structured the test programs enables the user to produce a labelled image using the
current itk implementation which I take to be the "standard" output image, and the images produced
by the modified code are compared to that standard. Maybe this isn't the best policy, but it can be updated
in a revision as you suggest.