CompareBitmaps issue

[observer]

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%!

[observer]

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]

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]

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]

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

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.

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.

[gdyvig]

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]

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]

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

[observer]

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

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]

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]

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

[Marcus Tettmar]

This issue has now been fixed in dev.

[jpuziano]

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.