Multiple PC issue with WaitScreenImage

[TXPoloPolo]

I've been a user of Macro Scheduler Standard since version 4.3.6
and upgraded to "Pro" this year in order to compile a script that used to take 12 hours to run on one computer and using the resulting .EXE to run it in parallel on six different machines in our training room in order to save time.

Even though the software, screen resolution, color depth, are the same on all of these PC's (using a corporate WinXP image) I had to use the capture tool on each machine to customize the bitmap files used for the WaitScreenImage command to work properly.

That would be OK if I only had to do it one time, but what I'm discovering is that each month when I go back to these same computers to run it again, the script will pause indefinitely (WSI_TIMEOUT intentionally set to 0) waiting for an image to appear even though the active window is completely repainted and the icon is present on the desktop application.

I'm wondering if anyone else has experienced this symptom. I've cut down the size of the bitmap image files to 26x17 and 14x14 pixels (just enough to make them unique) and I still have the issue.

Once I "re-customize" the bitmap files the script works perfectly.

Thanks in advance for any suggestions,

Marco Fehlbaum
Dallas, Texas

(MS Pro v10.1.20)

[JRL]

You don't mention (or I missed it) whether you have tried setting the color tolerance value in WaitScreenImage>

From help:

WaitScreenImage>BitmapFile[,Color_Tolerance]

Waits until the image in BitmapFile is found on the screen.

Returns the number of occurrences found on the screen in the WSI_RESULT variable.

Optionally, a Color tolerance value can be specified. The default is 0 (no tolerance). If color_tolerance is zero the pixel colors must match exactly. color_tolerance can be set to a value between 0 and 255. If larger than zero the red, green and blue values of the pixels in bitmap_to_scan are checked to see if they are within the tolerance specified (color value + or - color_tolerance). Smaller values match less and larger values match more.

[TXPoloPolo]

JRL,

I tried varying the values initially up to 10 before giving up when my bitmap files were a little larger than they are now, however the help file guidance is is a little vague about suggesting among the 256 values (0-255) and what degree the value will have on the match. Besides, it didn't seem to be helping anyway.

The screen resolution is 1280x1024 (single monitor) and I also tried changing from a 32bit color palette to a 16bit color palette with the same results.

-Marco

[TXPoloPolo]

The processor utilization while the WaitScreenImage command is running never exceeds the 60% threshold in case anyone is thinking that the application is CPU bound.

2.8Ghz Dual-core Intel processors

[JRL]

I'm not very experienced with WaitScreenImage, but I think that before I decided the tolerance setting wasn't doing anything, I'd be inclined to keep bumping the number up until I either got the results I wanted or until I was plagued with false positives. If changing the tolerance doesn't help, I really have no other suggestions.

Try something like this to test for the tolerance threshhold:

Code: Select all

Let>WSI_TIMEOUT=2
Let>kk=0
Label>Start
Add>kk,1
//Sub your image name
WaitScreenImage>d:\today_button.bmp,%kk%
If>kk=200,IGiveUp
If>WSI_TIMEDOUT=TRUE,Start
Goto>Success
Label>IGiveUp
Label>Success
MDL>%kk%

[gdyvig]

I have been experimenting with this issue and reading up on RBG color schemes on wiki and other places.

32bit and 24bit images both use the same 2**8=256 colors for the 3 channels. The 32bit image also contains an unused 4th channel sometimes used for other purposes. The 16bit images use 2**5=32 colors for the RB channels and 2**6=64 colors for the G channel. The worst case is for the RB channels. The same color range is used, but only every 256/32= 8 color codes. So a color tolerance of 8 would cover 24/32 bit images played back on a 16bit machine. Actually, I think 8-1=7 will work equally well.

You have standardized on screen size, so differences in background shading due to dark-to-light gradients should not matter. Also make sure ALL your Display effects are identical on all machines.

A longer WSI_TIMEOUT may give WaitScreenImage time to find the image.

Marcus often recommends comparing bitmap images from different machines and comparing them pixel by pixel with Paint. You can also use GetPixelColor to compare the color code values for each pixel. Another post in the forums describes how to convert the color code to the RBG values.

Gale

[pgriffin]

All good suggestions so far, but let me also state the you need to be sure the fonts are the same, the font smoothing setting, etc...Also, if you could use FindImgPos, then you could check the setting for number of pixels to check. Something like let>FIP_SCANPIXELS=1000 or whatever number you feel will force a thorough enough search.

As gdyvig mentioned, opening one of your images in paint and zooming to about 400% might show you what is going on...

I have some experience with image recognition as it is my role to manage our AppNavigator product.

I have tried to convince myself TOO many times that image recognition is somehow broken....it isn't ...I have always found that something is changing on the users desktop.

[Marcus Tettmar]

Something must be changing. If you have to recapture it something must be different each time. Perhaps the background is not smooth - causing a small change in position to create a very different image pixel for pixel. Transparency? Has the font been changed? Is focus different? Something has changed.

Let me try and explain the colour tolerance. A colour is made up of a Red, Green and Blue value. Each one is represented by a number from 0 to 255. So lets say a pixel has a color of 120,50,90. If we set a color tolerance of 30 we would match any pixel with RGB values in the range 90-150,20-80,60-120. A tlerance of 0 would therefore require an exact match and a tolerance of 255 would obviously match everything. So you'd never want to use that. You'd rarely want to set the tolerance value too high.

Whenever anyone says to "It says it's not on the screen but I can see it" I make the script take a screenshot of the screen and then open that AND the bitmap they are looking for in paint. I zoom in and spot the difference. The command doesn't lie.

- Make the desktop background a single colour
- Set and leave the theme
- Set and leave fonts, font sizes, font colours
- Remove any transparency
- Think about what happens if a window size changes. If looking for a window you probably don't want to capture the entire window unless you can be sure it doesn't change size/appearance.
- Does the window have a background image or graduated colour - can you change that?
- If the window is resized do things move and resize within it? Is the thing you are looking for changing size?
- Titles and objects change appearance when they are focused. So consider what state it is in at the point in the process you will be seeking it. Capture it in that state. Can the user change it's state while the process is running? If so perhaps you need to use BlockInput, or capture it in BOTH states and check for either.

If you can't figure out what is changing, replace your WaitScreenImage call with a loop containing FindImagePos. Inside the loop capture the screen with ScreenCapture using the time in the filename. Keep looping until you've found the image you're waiting for. If it fails to find it you have a trace of what it was seeing. Now you can open up this file and your needle file in Paint, zoom them in and find out what is different. This should give you some clues as to what you need to do, if possible, to make it reliable. Feel free to send me the bmps and I'll compare them.

---

Of course one other possibility is that you are barking up the wrong tree. It might be that it's failing because you are calling WaitScreenImage at the wrong time and it never sees the image. The image may appear and disappear before you call it. You could just have a simple timing issue. Again, using ScreenCapture and FindImagePos in a loop instead of WaitScreenImage will test this theory and give you some clues.