On Sun, Jun 7, 2009 at 9:56 PM, blp330 wrote:

Jens Weller wrote:

...

Trim the first lines and rows from both images, which only contain pixels of white/transparent color. But thats surley expensive, as you have to look at a lot of pixels.

The performance issue is critical for my application. And image might offset to left, right, down. I need a way to detect the image moving.

Thanks for your reply, do you have any suggestion for that?

How about finding the first non-white pixel in each image? In the "baseline" picture that you're comparing against you can pre-compute this one time at the beginning. Suppose you find that for the reference image the first non-white pixel is at coordinates (r, s) To detect a move, calculate it for the image you're trying to verify and you find that the first non-white pixel is at coordinates (x, y). 1) It is the original image offset by some amount. In this case, it has been offset by exactly (x-r, y-s). 2) It is a totally different image than the original. If you can tolerate less than 100% confidence that the image is the same thing but just shifted, just do a memcmp of the first few lines starting from this point. You know to offset into the image by (x-r,y-s) when doing the memcmps so that the comparisons are based at the same reference. This should give you good confidence whether or not they are the same. If the image is stored in a large 2-dimensional array as I suspect it may be with only pixel color information and no other information embedded into the cells, then once you find the first non-white pixel in each cell, just do a memcmp against the entire rest of the buffer. As long as the rectangles are not different sizes, this should still work. For example, image 1 and image 2 are both 1280x1024. They are the same except image1 is in the rectangle {(3, 7), (12, 18)} and image2 is in the rectangle {(4, 8), (13,19)}. You find that the first non-white pixel is (3,7) in image 1 and (4,8) in image 2. The memory from (3,7) to (4,7) in image 1 (1024 pixels) should be the same as the memory from (4,8) to (5,8) in image 2. It's just that the margin has moved from one side to the other. It realy depends a lot on the requirements of your app how to make it faster, there are a bunch of possibilities depending on error tolerance, needs, etc.

blp330 wrote:

Thanks for your reply. This way sounds good but I am very sorry I didn't mention that background color might not be white, it might be black, brown...etc, even a other pattern image.

This is more complicated to solve this problem.

Do you have any suggestion for that? Thank you very much.

Here is a more complicated case. http://mercurius.f-snet.com/offset3.png http://mercurius.f-snet.com/offset3.png http://mercurius.f-snet.com/offset4.png http://mercurius.f-snet.com/offset4.png These two images are different by image comparison method, but you can't find what different in human eyes. The only different part is background pattern. I need a way to ignore the background and detect the image moving. Thanks. -- View this message in context: http://www.nabble.com/Does-anyone-know-how-to-detect-image-offset--tp2391331... Sent from the Boost - Users mailing list archive at Nabble.com.

joel-75 wrote:

Image difference will give 0 where pixels doesn't change.

You may have to get some basic courses in image processing at some point. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Image difference will give 0? You mean there are no pixels different between offset3.png and offset4.png? I use boost::gil::equal_pixels, it returns false to me. I also use some comparison application, it hits me that the only different part is background pattern. I will get some basic courses, I am sorry that my project requires me to solve this problem at this time. :( Thank you. -- View this message in context: http://www.nabble.com/Does-anyone-know-how-to-detect-image-offset--tp2391331... Sent from the Boost - Users mailing list archive at Nabble.com.