CompareBitmaps issue

Ideas for new features & functions

Moderators: Dorian (MJT support), JRL

Post Reply
observer
Junior Coder
Posts: 44
Joined: Tue Aug 18, 2009 7:55 pm

CompareBitmaps issue

Post by observer » Tue Aug 18, 2009 8:31 pm

Hi!
So, I don't understand what method MacroScheduler use to calculate the percentage match.
It is quite reasonable to add pixel-by-pixel comparing option (whith color tolerance). This is useful for small images.
Best regards.
P.S. The percentage match of these two images is 100%!
Image Image

observer
Junior Coder
Posts: 44
Joined: Tue Aug 18, 2009 7:55 pm

Post by observer » Wed Aug 19, 2009 9:29 am

Hello again! :)
Some more suggestions.
1. It would be great to enhance CompareBitmaps command with Multicomparing option. Something like this:

Code: Select all

Let>Fast_Compare=1 (Fast_Compare=0 means a high accuracy)
Let>Multi_Compare=0 (by default (to backword compatibility ;)))
Let>Color_Tolerance=0
CompareBitmaps>File_1,File_2[FileList][Path\filemask.bmp],nPercent
nPercent turn to a number of variables if Multi_Compare=1(nPercent_1,nPercent_2...)
Also, it must be useful to return another two vars:
BEST_MATCHING_FILENAME and its BEST_PERCENTAGE

2. GetFileList command executes too slow if a number of files in directory exceeds a few thousands. I have to use

Code: Select all

RunProgram>cmd.exe /C dir /b /o:n Path\*.* > Path\tmp_filelist.txt
ReadFile>Path\tmp_filelist.txt,strFileList

observer
Junior Coder
Posts: 44
Joined: Tue Aug 18, 2009 7:55 pm

Post by observer » Wed Aug 19, 2009 9:52 pm

Hi!
I had examined the CompareBitmaps command issue and I have got the answer to my own question (about comparing method used in Macro Scheduler). This is precise graphical comparison of 1/3 of image's area. Firstly I thought that the reason is speed. I had tested this command on 3000x3000 image and it had taken just a second. Now it seems to me it's a bug.

gdyvig
Automation Wizard
Posts: 447
Joined: Fri Jun 27, 2008 7:57 pm
Location: Seattle, WA

Post by gdyvig » Thu Aug 20, 2009 4:31 pm

Hi Observer,

Here is a link to another forum post on CompareBitmaps and some alternatives:

http://www.mjtnet.com/usergroup/viewtop ... arebitmaps

Marcus suggests that CompareBitmaps compares the number of pixels of each color but not their locations, so it may conclude that XY=YX. I have not checked this out yet.
It is possible that both your bitmaps contain exactly the same number of colors and pixels (though not exactly in the same place).

Marcus also offers another alternative hash method he says is much faster.

He also offers another alternative - GetRectCheckSum.

=======================
A few questions about your results.

In your first post you show 2 images. Are you saying a bug in CompareBitmaps says the match 100% when they are obviously different? If CompareBitmaps observed color_tolerance, it would need to be set to 255 for that to be a correct result.

In your last post you said CompareBitmaps appears to compare 1/3 of the image. Which 1/3?


Gale

observer
Junior Coder
Posts: 44
Joined: Tue Aug 18, 2009 7:55 pm

Post by observer » Thu Aug 20, 2009 9:47 pm

Hi gdyvig!
That are my answers:
In your last post you said CompareBitmaps appears to compare 1/3 of the image. Which 1/3?
I confirm that CompareBitmaps(CB) command compares the left 1/3 (look at the Pic_1).
Pic_1
Image
You can find out 6 (100x100 pixels) images below.
____Pic_21_________Pic_22__________Pic_23_________Pic_24_________Pic_25_________Pic_26
Image Image Image Image Image Image
Try to run CB command to the next combinations:
Pic_21 & Pic_22 (Pic_22 has 10x10 black square at top left corner. Percentage_Match will 97%, because of MarcusScheduler :) interpolates the difference of 1/3 of the image's area to whole image. In other words difference=3%=(3*100)/(100*100))
Pic_22 & Pic_23 (At Pic_23 black square is on the same position.Difference=0%)
Pic_22 & Pic_24 (At Pic_24 black square shifted down to 6 pixels.The black squares have 40 shared pixels and 120 not shared. Difference=4(3.6)%=(3*120/10000))
Pic_22 & Pic_25 (At Pic_25 black square shifted down to 10 pixels.The black squares have no shared pixels. Difference=6%=(3*200/10000))
Pic_22 & Pic_26 (Pic_26 has the same black square as Pic_22, but ... :))
I suppose that the situation is clear.
Are you saying a bug in CompareBitmaps says the match 100% when they are obviously different?
This is not a bug... I think. This is cheat :)
If CompareBitmaps observed color_tolerance, it would need to be set to 255 for that to be a correct result.
FindImagePos command uses color tolerance in reverse oder :).
"If color_tolerance is zero the pixel colors must match exactly" (from help file)
Actually, color_tolerance variable is for special purposes. It can help to find similar (not the same) images.
Last edited by observer on Fri Aug 21, 2009 10:36 pm, edited 1 time in total.

gdyvig
Automation Wizard
Posts: 447
Joined: Fri Jun 27, 2008 7:57 pm
Location: Seattle, WA

CompareBitmaps not randomizing

Post by gdyvig » Thu Aug 20, 2009 10:26 pm

Hi very observant observer,

I would have expected CompareBitmaps to work more like FindImagePos which randomly compares a subset (FIP_SCANPIXELS) of all pixels instead of the left-most ones. Looks like a bug to me.

It would be good if CompareBitmaps used FIP_SCANPIXELS or allowed you to define what percentage of pixels to randomly compared depending on whether you wanted accuracy or peformance. That in combination with the color tolerance.


Gale

observer
Junior Coder
Posts: 44
Joined: Tue Aug 18, 2009 7:55 pm

Post by observer » Thu Aug 20, 2009 11:26 pm

Hi gdyvig!
The thing is color_tolerance is ... already in use.
I 've found it just now :)
If you replace black square with red square rgb(255,0,0) and then with RedGreen square rgb(255,255,0) you will see how the percentage change.

gdyvig
Automation Wizard
Posts: 447
Joined: Fri Jun 27, 2008 7:57 pm
Location: Seattle, WA

CompareBitmap algorithm and 2, maybe 3 bugs bugs

Post by gdyvig » Fri Aug 21, 2009 3:37 pm

Hi Observer,

I confirmed your observations. I also did CompareBitmaps against solid white, black, red, green, and blue images. I found that each color channel for each pixel is compared separately. So a 100x100 bitmap becomes a 300x100 RGB matrix.

Here are my results:

Code: Select all

white-white=100
white-black=0
white-blue=33
white-green=33
white-darkgreen=0
white-red=33

black-white=0
black-black=100
black-red=66
black-green=66
black-blue=66

red-white=33
red-black=66
red-red=100
red-blue=33
red-green=33

blue-white=33
blue-black=66
blue-red=33
blue-green=33

darkgreen-white=0
green-white=33
green-black=66
green-red=33
green-green=100
green-blue=33
(Editted)There are 1, maybe 2 bugs:

BUG#1:
CompareBitmaps uses the bitmap dimensions when comparing the RGB matrices. That is why only the left third of the image is compared.

BUG#2: (Editted), not a bug
My original green-white and white-green compares used dark green instead of pure green. Dark green also contains red and blue.
The darkgreen-white and white-darkgreen compares gives a result of 0, which is expected.

BUG#3?:
CompareBitmaps probably was supposed to report the percentage of pixels that different in any way, not the percentage of pixel/color channels that differed. If any one of the 3 RGB colors is different for a pixel it should be counted as a mismatch so all of my test results showing 33 or 66 percent match should show 0% match. This is really a design question and should be documented so users will know how to interpret the results.



Gale
Last edited by gdyvig on Fri Aug 21, 2009 10:47 pm, edited 1 time in total.

observer
Junior Coder
Posts: 44
Joined: Tue Aug 18, 2009 7:55 pm

Post by observer » Fri Aug 21, 2009 10:13 pm

Hi gdyvig!
CompareBitmaps uses the bitmap dimensions when comparing the RGB matrices. That is why only the left third of the image is compared.
Try to compare Pic_31, Pic_32, Pic_33 and Pic_34 in any combinations and you see this is not so. The right 2/3 is not in use any way.

_____Pic_31_________Pic_32_________Pic_33_________Pic_34
Image Image Image Image

The green-white and white-green compares should give a result of 33, not 0 to be consistant with the other compares
Actually, I haven't found this bug. May be you are mistaken.
CompareBitmaps probably was supposed to report the percentage of pixels that different in any way, not the percentage of pixel/color channels that differed. If any one of the 3 RGB colors is different for a pixel it should be counted as a mismatch so all of my test results showing 33 or 66 percent match should show 0% match. This is really a design question and should be documented so users will know how to interpret the results.
The method of comparing used in current version of Macro Scheduler has some merits and some demerits. If you need to compare two snapshots from video surveillance this way is quite suitable. In fact, you have furniture on its constant places in the shot's frame and its colors are not constant because of different illuminance. Suppose you know the mismatch of these shots can't be more than 10%. So if you get 20% of mismatch this will mean there are unauthorized objects in the frame :).
But it would be much better to assign separate variable like color_tolerance. In this case user get more power to choose comparing strategy.

gdyvig
Automation Wizard
Posts: 447
Joined: Fri Jun 27, 2008 7:57 pm
Location: Seattle, WA

I think we are in agreement.

Post by gdyvig » Fri Aug 21, 2009 11:00 pm

Hi observer,
Try to compare Pic_31, Pic_32, Pic_33 and Pic_34 in any combinations and you see this is not so. The right 2/3 is not in use any way.
Yes, that is what I was saying.

I should get the following results for your pictures:

pic_31 to pic_32 = 33 (correct)
pic_31 to pic_33 = 33 because of the 1/3 bug
pic_31 to pic_34 = 33 because of the 1/3 bug

Let's say we have a Black 5x1 image.
It will look like this: XXXXX

CompareBitmap converts that to a 15x1 image.
It will look like this: RGBRGBRGBRGBRGB

It should look at the entire stretched out image (or matrix really).
But it only looks at: RGBRG
That is the bug.


Make sense?


Gale

observer
Junior Coder
Posts: 44
Joined: Tue Aug 18, 2009 7:55 pm

Post by observer » Sat Aug 22, 2009 1:09 am

Hi gdyvig!
I was confused by your "300x100 RGB matrix". My bad. :)
Probably, it was correct explanation of the bug in your previous post.

User avatar
Marcus Tettmar
Site Admin
Posts: 7393
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Fri Sep 25, 2009 9:02 am

This issue has now been fixed in dev.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

User avatar
jpuziano
Automation Wizard
Posts: 1085
Joined: Sat Oct 30, 2004 12:00 am

Post by jpuziano » Fri Sep 25, 2009 9:15 pm

mtettmar wrote:This issue has now been fixed in dev.
Double Woot! Thanks Marcus... looking forward to the maintenance release.

Thanks observer and Gale who spend spent time describing and digging into this issue... nicely done.
jpuziano

Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post - :-)

Post Reply
Sign up to our newsletter for free automation tips, tricks & discounts