FIP> Performance Optimization

[armsys]

Currently FIP is unbearably SLOW.
It could be accelerated.
99% of the time we don't need to scan the entire screen, only portion of it. And 99% of the time we don't scan for a moving image.
Marcus, can you add an additional set of 4 parameters (x1, y1, x2 and y2) to define the specific area of the SCREEN to be scanned?
In essense, the feature combine FIP and SCP.
Thanks for your consideration.

[JRL]

Armstrong,

Just want to be sure you realize that the functionality you're requesting can now be accomplished in two lines of code. First use the SCP> (ScreenCapture>) to capture and create a file containing the small screen area you want to search within. The second line will be the FIP> (FindImagePosition>) that uses the SCP> file as it's "HayStack" image.

You did say "In essense, the feature combine FIP and SCP". But you didn't specifically state that you use the two commands together.

[armsys]

Just want to be sure you realize that the functionality you're requesting can now be accomplished in two lines of code. First use the SCP> (ScreenCapture>) to capture and create a file containing the small screen area you want to search within. The second line will be the FIP> (FindImagePosition>) that uses the SCP> file as it's "HayStack" image.
You did say "In essense, the feature combine FIP and SCP". But you didn't specifically state that you use the two commands together.

JRL,
Thanks for your feedback.
Your dual-command approach will significantly slow down and defeat the whole performance optimization purpose. It involves excessive CPU and disk usage worst than the FIP alone.

For all practical purpose, 99% of the time FIP scans for a target located in a specific region/portion of the screen, rarely the whole screen. For example, a buttom of interest is located more or less at the 1st quadrant of the screen.

Why not define a reduced screen portion for FIP to scan for the target inside the memory?
I hope now it makes more sense to you.
The same should apply to WSI as well.
If only 50% of the screen will be scanned by FIP or WSI, you cut the processing time into 50%, a simple math and a common sense, isn't it?

[Marcus Tettmar]

The wizard already lets you define a screen area and it creates code for you using ScreenCapture and FindImagePos.

I think you want these two commands combined into one but I'm not sure why you think that would make any difference to speed. Sure we can wrap multiple commands into one but the end result would be the same - beneath the surface the same functions would be performed.

I'm intrigued that you find FindImagePos "unbearably slow". What are your benchmarks? In all our tests Macro Scheduler beat the competition by a huge margin.

[armsys]

I think you want these two commands combined into one but I'm not sure why you think that would make any difference to speed.

Yeah, that's exactly what I tried to propose.
First of all, Image Recognition Wizard is a fantastic time-saving tool to simplify the coding. I find the wizard very useful. Thanks, Marcus.
Benefits of combining FIP and SCP:
1. Just add x1, y1, x2 and y2 into the parameter list of FIP.
2. By combining FIP and SCP together, the entire process can be done in memory, instead of hard drive.
The result can be a significant speed boost, IMHO.

I'm intrigued that you find FindImagePos "unbearably slow". What are your benchmarks? In all our tests Macro Scheduler beat the competition by a huge margin.

By "unbearably slow", I mean for the CCOEFF mode. I should have been more specific.

[armsys]

Marcus,
I just invent another idea:
Instead of, say, ScreenCapture>444,269,1007,615,%TEMP_DIR%\screenrect.bmp,
Why not add support to memory variable, instead of a disk file (eg screenrect.bmp above)?
The portion, say, 444,269,1007,615, can be scanned again and again repeatedly in the subsequent multiple FIPs. In live applications, such scenarios often occcur. For example, the portion of the screen could be a keyboard for password entry. In this case, this portion of the screen image will be used repeatedly.
Currently, FIP's haystack doesn't support memory variable.

[Phil Pendlebury]

I have been doing this since, erm let me see - 2007...

First capture is only of the left half of the screen but every capture after that only looks around a defined area of the first capture. All following captures always adjust that defined area depending on which part of the previous area the image was found.

Admittedly my code would be no use to you as it is specific to one particular script but the point is that are many, many ways you can customise your screen caps for your specific purpose using some extra code of your own.

[armsys]

First capture is only of the left half of the screen but every capture after that only looks around a defined area of the first capture. All following captures always adjust that defined area depending on which part of the previous area the image was found.

Hi Phil,
Appreciate your feedback.
A simple question: How do you like the speed?

[Phil Pendlebury]

Hi again, well that was my point really. After the initial capture which can take second or two (on a 2560x1600 screen which I test on), the following captures are only looking at a small defined area. So it is less than half a second.

I don't have a problem with the speed at all. For me an automation is not about "speed" as such. It is about removing the need for interaction. Although there are limits obviously.

But of course that is only my opinion.

Bear in mind though that I have been using this feature for a looooooooooooong time so I have seen some huge speed and other types of improvements come in and also written in my own (as mentioned above) when required.

It is all about optimisation per script I guess.

for example the first capture in the script I mentioned above could actually be limited to the left QUARTER of the screen , not HALF. I am considering changing that at some point but there may be users of that script who have their screens set up differently to how I imagine. And also they are not that worried about super fast speed.

[armsys]

Hi Phil,

After the initial capture which can take second or two (on a 2560x1600 screen which I test on), the following captures are only looking at a small defined area. So it is less than half a second.

After rereading your posts, I realize you meant the ¡§initial¡¨ capture is intended as a permanent one. That¡¦s, it¡¦ll be used for subsequent FIPs today and tomorrow. For some apps, it¡¦s impossible. For example, for password entry display, the keyboard buttons are randomly arranged each time. Such permanent frozen copy of capture is not useful.

For me an automation is not about "speed" as such. It is about removing the need for interaction.

I would balance the reliability and speed factors. Both are important to my real-time apps. Lately after rewriting some scripts with seemingly slow FIPs, now its speed improves hugely just like Marcus asserts that FIP speed is second to none in the industry. Now I agree.
Thanks for your generous sharing indeed.