Please, restore text indentation on lines 54-3957: it was 4 spaces, but you've changed it to 8 spaces.

Is it possible to change TBB to cv::parallel_for_? It has different backends (including TBB) and will work on more platforms.

Hi @mshabunin,

"Please, restore text indentation on lines 54-3957: it was 4 spaces, but you've changed it to 8 spaces."
Sure!!

"Is it possible to change TBB to cv::parallel_for_? It has different backends (including TBB) and will work on more platforms."
We are trying to do that and we are making some other performance tests to see the differences.

Hi @mshabunin. You were right: we reverted the parallel code to cv::parallel_for_ and now it is obviously more flexible (tests revealed that also parallel frameworks different from TBB improve performances pretty well). We fixed the indentation issue and wrote down some notes in the documentation.

'_P' => 'P_'

To avoid conflicts with reserved variable names (started with underscore).

I tested your last commit a bit. I noticed, that when I use CV_16U label type, connectedComponents returns only the labels from first thread and the label image is broken. This seems to occure for both, GRANA and WU as well as for 4 and 8 connected.
With CV_32S it seems to be OK.
When I set number of threads to 1 the CV_16U output also returns correct number of found labels and label image looks correct.
I use OpenMP as parallel framework and Visual Studio 2013. The correct number of labels is about 10000.

Hello @mschoeneck,
you are right. We try to explain the problem in the easiest possible way.

The CV_16U label type can be used only when the number of labels in the image can be fit a 16bit data type (i.e 65536). The problem with the parallel version of the algorithms (which divide the image to label in stripes and compute labeling on each stripe in parallel) is that each thread must start labeling from the maximum possible value reachable by the previous thread. This is necessary in order to avoid collision accesses to equivalence label array.

For example (considering an image with 8 rows and 2 thread): the first thread works with rows from 0 to 3 [0;3] and starts from label 1 (background is 0). The second one works with rows from 4 to 7 [4;7] and starts from maximum label reachable (at least in theory) by thread one incremented by one. So if the maximum label reachable from thread one is 5 thread two starts labeling from label 6.

Then, if you run connectedComponents function with CV_16U label type on an image that actually have only two labels, but the maximum number of different labels that image could contain is greater than 65536, parallel labeling will fail because of its nature.

For this reason we decided to call the parallel connectedComponents only with CV_32S label type.

@mshabunin @alalek The latest push failed under linux with strange errors (error closing /tmp/ccXGh37G.s: No space left on device), it's my fault or was there a problem with the buildbot?

there a problem with the buildbot

These builds are restarted.

hello, do you have any updates? 😄

The last commit includes the following changes/improvements:

1. Improvement of array of equivalences’ upper bound. The current upper bound in release 3.2.0 is undersized (wrong in some cases) but in the current pull request (as in the pull request REF) we have proposed a new upper bound that is correct but oversized in some cases (i.e. on images with even number of rows and/or cols). With the last commit, we definitely solve the problem (see following figure);
2. Specialized the first assigned label of each thread for parallel algorithms in 8-way-connectivity;
3. Fix some wrong comments (authors’ name) in other modules;
   

trying to fix doc builder complains, see #8789