compare subimage-search returns me different start-coordinates for the found image

[HansWurst]

I have two images. Both are black/white images and generated by “convert orig_x.png -threshold 90% x_threshold_90.png”. The results are two black images with a white line:
- A_threshold_90.png has a line from y-coordinate 644 – 645
- B_threshold_90.png has a line from y-coordinate 643 – 644

Then I generate a 3rd image with a white line of 1293x1 by:
convert -size 1293x1 xc:white whiteLine1293x1pixel.png

In last step, I try to find the image “findThisLine.png” in my threshold-generated images. My wish is to find the y-coordinate of the white line:
compare -metric rmse -subimage-search A_threshold_90.png whiteLine1293x1pixel.png diff.png
0 (0) @ 627,644
compare -metric rmse -subimage-search B_threshold_90.png whiteLine1293x1pixel.png diff.png
0 (0) @ 627,644

As you can see, I get the response for y=644 on each image. Only if I try this again with a 2-pixel wide subimage, than I get the right response:
compare -metric rmse -subimage-search A_threshold_90.png whiteLine1293x2pixel.png diff.png
0 (0) @ 627,644
compare -metric rmse -subimage-search B_threshold_90.png whiteLine1293x2pixel.png diff.png
0 (0) @ 627,643

Using the 2 pixel wide line for search is not possible in my use case. Why ever, the response by searching for 1-pixel line is the upper part of in one image and the lower part in the second image. Can anyone tell me where my mistake is?

[HansWurst]

This are the corresponding images:

A_threshold_90.png


B_threshold_90.png


compare -metric rmse A_threshold_90.png B_threshold_90.png diff.png

[snibgo]

Your posted A_threshold_90.png and A_threshold_90.png are 1040x390, but your subimage whiteLine1293x1pixel.png is 1293x1 which is wider, so a subimage search will fail.

I guess you linked to the wrong inputs, or a web hoster has downsized them.

In both your searches, IM has found a perfect match. When there is more than one perfect match, IM doesn't guarantee that it will be any particular one.

IM generally works by allocating batches of lines to different threads, and this could affect which match is found, so try "-limit thread 1".

[HansWurst]

Oh, sorry. The image was downsized by the web hoster. The image is big enogh.
With you hint it is working perfekt. Thank you for that.

Do you know a god side at imagemagick.org where I can read more about the behaivour of ?-limit thread" ?

[snibgo]

"-limit" is documented at http://www.imagemagick.org/script/comma ... .php#limit

Multithreading in IM is documented at http://www.imagemagick.org/script/archi ... hp#threads

See also policy.xml and MAGICK_THREAD_LIMIT in http://www.imagemagick.org/script/resources.php

Internally, most IM operations work by processing each row from the top, and within each row from left to right. Multithreading will allocate a batch of rows to each thread, so there is no guarantee that row (N) will be processed before row (N+1). The compare operation stops as soon as a perfect match is found.

[HansWurst]

Thank you very much for your detailed list of links