CompareBitmaps issue
Moderators: Dorian (MJT support), JRL
CompareBitmaps issue
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%!
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%!
Hello again!
Some more suggestions.
1. It would be great to enhance CompareBitmaps command with Multicomparing option. Something like this:
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
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
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
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.
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.
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.
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
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
Hi gdyvig!
That are my answers:
Pic_1
You can find out 6 (100x100 pixels) images below.
____Pic_21_________Pic_22__________Pic_23_________Pic_24_________Pic_25_________Pic_26
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.
"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.
That are my answers:
I confirm that CompareBitmaps(CB) command compares the left 1/3 (look at the Pic_1).In your last post you said CompareBitmaps appears to compare 1/3 of the image. Which 1/3?
Pic_1
You can find out 6 (100x100 pixels) images below.
____Pic_21_________Pic_22__________Pic_23_________Pic_24_________Pic_25_________Pic_26
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.
This is not a bug... I think. This is cheatAre you saying a bug in CompareBitmaps says the match 100% when they are obviously different?
FindImagePos command uses color tolerance in reverse oder .If CompareBitmaps observed color_tolerance, it would need to be set to 255 for that to be a correct result.
"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.
CompareBitmaps not randomizing
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
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
CompareBitmap algorithm and 2, maybe 3 bugs bugs
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:
(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
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
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.
Hi gdyvig!
_____Pic_31_________Pic_32_________Pic_33_________Pic_34
But it would be much better to assign separate variable like color_tolerance. In this case user get more power to choose comparing strategy.
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.CompareBitmaps uses the bitmap dimensions when comparing the RGB matrices. That is why only the left third of the image is compared.
_____Pic_31_________Pic_32_________Pic_33_________Pic_34
Actually, I haven't found this bug. May be you are mistaken.The green-white and white-green compares should give a result of 33, not 0 to be consistant with the other compares
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 .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.
But it would be much better to assign separate variable like color_tolerance. In this case user get more power to choose comparing strategy.
I think we are in agreement.
Hi observer,
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
Yes, that is what I was saying.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.
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
- Marcus Tettmar
- Site Admin
- Posts: 7393
- Joined: Thu Sep 19, 2002 3:00 pm
- Location: Dorset, UK
- Contact:
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?
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
Double Woot! Thanks Marcus... looking forward to the maintenance release.mtettmar wrote:This issue has now been fixed in dev.
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 -
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 -