Finding the bounding box of the difference between 2 images?

Question

I have 2 bitmap images, where 1 is a slight variation of the other. Now I'd like to calculate the bounding box of the area-of-change, as fast as possible. Is there a smart algorithm to do that or is it just a case of brute-force processing ?

Edit: the images will be screencaptures. I want to find the minimum bounding box for the changed area, as in "outside of this box nothing has changed".

What you mean by area-of-change ? – Ian Medeiros Mar 10 '12 at 20:16 — Ian Medeiros, Mar 10 '12 at 20:16
they are rectangle or random images? – Saeed Amiri Mar 10 '12 at 20:25 — Saeed Amiri, Mar 10 '12 at 20:25
What kind of image (photograph, line art, etc.)? – Seth Mar 10 '12 at 20:29 — Seth, Mar 10 '12 at 20:29

schnaader · Answer 1 · 2012-03-11T00:13:38.097

If you want only one bounding box, you can definitely do better than "brute force" (always checking all pixels, 2*w*h operations), at least if there are any differences between the images. Just look for the 4 first different row/column pixels starting from the 4 different borders. Pseudocode:

bounding_box_y1 = -1;
loop y = 1..h {
 loop x = 1..w {
   if image1(x,y) != image2(x,y) {
     bounding_box_y1 = y
     exit loops
   }
 }
}

The pseudocode above goes through the image rows, starting from the top row until it finds a different pixel, returning bounding_box_y1. Just add 3 more loops (rows starting bottom => bounding_box_y2, columns starting left => bounding_box_x1, columns starting right => bounding_box_x2) and you'll have the coordinates of your bounding box.

This algorithm still does 2*w*h operations for identical images (note that in this case, bounding_box_y1 will stay -1 and you can skip the additional 3 loops), but will be much faster if there are differences in the images (checking only the 4 corner pixels in the best case).

EDIT: After I saw your question edit, I had an idea for another approach: If you're comparing an image several times against other images, you can store additional checksum information, e.g. storing checksums of 16x16 pixel regions would take some additional storage space, but comparing the checksums instead of pixels is much faster and gives a bouding box "estimate" - you can either use that directly if you can live with it or refine it afterwards. In either case, this will be much faster than the approach above, especially for worst case scenarios. However, it depends on your setup and is a "size for speed" tradeoff.

@JohanLundberg, I think sublinear solution is not possible. If all pixels are the same, you need to check all of them. — svick, Mar 10 '12 at 21:47
Edited the answer. It's still O(n), yes, but it can often manage to compare much less than all image pixels. — schnaader, Mar 11 '12 at 00:01
@schnaader: thanks for this simple but powerful algorithm! I got a working python implementation in Blender and it works quite fast on my small test image. I wonder if it's worth to improve speed, and how to do so. Your 16x16 pixel checksum idea sounds interesting, but is it really a good option? What if input image width or height % 16 != 0? Maybe do per-line checksums, plus checksums of e.g. 16 line checksums (and one for the entire image)? — CodeManX, Oct 19 '13 at 01:10
Size of the checksum/hash regions doesn't matter because you're comparing two images of the same size and blocks of the same size. Just make sure your checksum/hash algorithm works with arbitrary pixel counts. The main downside with the checksum/hash approach could be false positives (different blocks detected as identical) because of collisions. — schnaader, Oct 21 '13 at 20:47

Finding the bounding box of the difference between 2 images?

1 Answers1