285 replies to this topic

[FastFrench]

As I was too limited by what was feasible with PixelSearch in Autoit, I wrote an optimized DLL in C++ for searching pixels on the screen.

The most basic function allows you to find the pixel in a given color - as PixelSearch - but instead of returning the first found, it returns the closest to a given point.

It can go much further:
- Search for 'spot' the closest (NxN square containing P pixels that meet the criteria of color mentioned)
- Maintains a list containing up to 1024 colors (search pixels with one color in this list)
- Manages up to 1024 exclusion rectangles. We can define precisely the search pattern that you want (with a rectangle from which you "substract" several "exclusion rectangles"). You can have up to 1024 exclusion rectangles.
- You can also set a 'shade variation' (same idea as with PixelSearch).
- Can work on several 'snapshots' (screen captures) in memory. It is possible to retain up to 1024 snapshots simultaneously (of course, each capture consumes memory, so only use the "slots" you really need).
- Works on full screen or specific window (HWND optionnal parameter) or part of it.
- Also includes functions to identify the changes between two SnapShots (minimum rectangle containing all changes + number of pixels that have changed). Useful to detect movement on the screen, object state changes...
- Fairly sophisticated tools provided for debugging are also included in the UDF. You can choose the type of logs you want, including the ability to view on screen the detected areas (most useful during development phasis) and record the transaction details in a log file.
- For even more performance, you can capture the content of a screen memory (SnapShot, takes about the same time as or PixelSearch PixelGetColor) then do all the research you want in this snapshots (very fast functions : nearly 1000 times as fast as the native PixelGetColor).
- [v1.4] : find the "best spot" - meaning the spot that has the best number of "right" colors.
- [v1.4] : now provided with a tool, FFShowPixels.exe, to find colors, manage color lists, show all occurences of them on the Captured Window, and... automatically generates AutoIt or C++ code.
- [v1.6] : Saves SnapShots on BitMaps (BMP and JPG supported)
- [v1.6] : Modifies SnapShots with "filters" (Keep only some colors or only pixels that have changes. All other pixels can be turned to black).
- [v1.7] : Can change pixels colors on SnapShots (SetPixel)
- [v1.7] : Can access the Raw pixel data of SnapShots (GetRawData)
- [v1.7] : Can draw back SnapShots on Screen.
- [v1.8] : Bug fixes. Deleted
- [v1.8.1] : Bug fixes (FastFind.au3).
- [v1.8.2] : Bug fixes (FastFind.au3).
- [v1.8.3] : Bug fixes (FastFind.au3). Deleted
- [v1.8.4] : Should now run on early XP and Windows 2000 OS.
- [v2.0] : Documentation file in english (FastFind.chm), several new functions and new feature on some old functions.
- [v2.1] : Bug fixes (removed those nasty errors in message boxes)
- [v2.2] : Bug fix

Included in the archive: both the 32 bits and 64 bits dll (written in Visual C++ 2010), the AutoIt Wrapper, a demonstration script and a tiny Benchmark script.

Here it is, your comments and suggestions are welcome.

[Updates/Changelog]

Last Version : 2.2
 FastFind 2_2.zip   186.78KB   546 downloads

Version 2.2
Bug fixes
 FastFind 2_2.zip   186.78KB   546 downloads

Version 2.1
Bug fixes
 FastFind 2_1.zip   186.33KB   885 downloads

Version 2.0
A new documentation file, in chm format (thanks to CeramicWeasel)
New functions :
DrawSnapShotXY (same as DrawSnapShot, with specific top-left position for drawing).
ComputeMeanValues (Gives mean Red, Green and Blue values of a SnapShot)
ApplyFilterOnSnapShot (apply a AND filter on each pixels in the SnapShot)
FFGetRawData (provide access to all pixel data)
ShadeVariation parameter added in the following functions :
KeepChanges
LocalizeChanges
HasChanged
 FastFind 2_0.zip   184.05KB   1827 downloads


jan 5 2012: ShowPixel Link should work now FFShowPixels 1.7

Version 1.8
-> bug fixes
Updates :


 FastFind 1_8_4.zip   145.49KB   1388 downloads

Version 1.7
-> bug fix with client coordinates
-> Can change pixels colors on SnapShots (SetPixel)
-> Can access the Raw pixel data of SnapShots (GetRawData). Not that this feature is not allready wrapped into autoit: you have to do it with dllcall.
-> Can draw back SnapShots on Screen (DrawSnapShot).
-> New function to duplicate a SnapShot (DuplicateSnapShot)
 FastFind 1_7.zip   149.28KB   906 downloads
FFShowPixels + FastFind complete 1.7 package : FFShowPixels 1.7

Version 1.6
-> bug fix (restriction rectangles + FFColorCount)
-> New functions to export captures into BMP or JPEG Files
-> New functions to create SnapShots with changes or selected colors from a previous SnapShot(FFKeepChanges & FFKeepColors).
 FFShowPixels1_6 wo FFShowPixels.zip   142.68KB   484 downloads

Version 1.5
-> FFGetPixel bug fix.
 FastFind1_5.zip   132.45KB   402 downloads


(Update) Version 1.4
-> A new optional parameter in SetHWnd : You can now choose to take either the full Window or only the Client area of the window.
-> Several bug fixes (more reliable and consistent)
-> A new search fonction : FFBestSpot. It will find the spot that contains the most "good" pixels.
-> A new tool - ShowPixels.exe - will allow you to easily manage list of colors (find them on the screen, make stats...) and automatically generate AutoIt or C++ code from them.

Unfortunately, the zip is too big to include ShowPixel.exe in it. So if you want this tool, just ask with pm or mail.

(Update) Version 1.3
-> comments in demo scripts now in english
-> Some minor bug fixed
-> now both 32 bits and 64 bits dll are provided
-> Several function calls are now more simple to use : the x1,y1,x2,y2 limits of the area for search functions are now optional. Default values means full window (or screen))
** Warning ** I've changed the order of the parameters in some fonctions, to make them easier to use. So if you use any of the 3 following function, you will need to reorder the parameters if you want to update to the version 1.3 of FastFind.
Func FFNearestPixel($PosX, $PosY, $Color, $Left=0, $Top=0, $Right=0, $Bottom=0, $ForceNewSnap=true, $NoSnapShot=$FFLastSnap, $WindowHandle=-1)
Func FFNearestSpot($SizeSearch, $NbPixel, $PosX, $PosY, $Color, $ShadeVariation=0, $Left=0, $Top=0, $Right=0, $Bottom=0, $ForceNewSnap=true, $NoSnapShot=$FFLastSnap, $WindowHandle=-1)
Func FFColorCount($ColorToCount, $ShadeVariation=0, $Left=0, $Top=0, $Right=0, $Bottom=0, $ForceNewSnap=true, $NoSnapShot=$FFLastSnap, $WindowHandle=-1)


(Update) Version 1.2




I hope these library will prove useful. Please tell me how you use it and how you like it.


FF

Edited by FastFrench, 23 April 2013 - 10:56 AM.

[Ascend4nt]

This looks very cool. I will give it a shot once I have time (and once I decipher what the french comments & messages mean)

[FastFrench]

This looks very cool. I will give it a shot once I have time (and once I decipher what the french comments & messages mean)

Well, for the french comments in fastFind.au3, you have the english equivalent in the first message here. And I guess all traces / error messages should be in english. If there're still some french inside, just ask

[FastFrench]

(Update) New version 1.3
-> no French left : all comments are now in english (error messages and traces in the dll were allready in english)
-> Several function calls are now more simple : Now the x1,y1,x2,y2 limits of the area for search functions are optional. Default values means full window (or screen))
** Warning ** I've changed the order of the parameters in some fonctions, to make them easier to use. So if you use any of the 3 following function, you will need
to reorder the parameters if you want to update to the version 1.3 of FastFind.

Func FFNearestPixel($PosX, $PosY, $Color, $Left=0, $Top=0, $Right=0, $Bottom=0, $ForceNewSnap=true, $NoSnapShot=$FFLastSnap, $WindowHandle=-1)
Func FFNearestSpot($SizeSearch, $NbPixel, $PosX, $PosY, $Color, $ShadeVariation=0, $Left=0, $Top=0, $Right=0, $Bottom=0, $ForceNewSnap=true, $NoSnapShot=$FFLastSnap, $WindowHandle=-1)
Func FFColorCount($ColorToCount, $ShadeVariation=0, $Left=0, $Top=0, $Right=0, $Bottom=0, $ForceNewSnap=true, $NoSnapShot=$FFLastSnap, $WindowHandle=-1)

-> Some minor bug fixed


Also it's important to say that the search functions always work on the full SnapShot : if you want to restrict the search to only some part of a Window, then either do a SnapShot
of the proper size, or use Restriction Rectangles.

I've also added a small Benchmarking script. Here are the result I have :
Native GetPixelColor: 19ms
Native PixelSearch (FullScreen 1920x1080 and ShadeVariation): 88ms
FFGetPixel: 0.027 ms (27 µs)
SnapShot small area (10x10): 18ms
SnapShot FullScreen (1920x1080): 65ms
Simple pixel search in medium size (200x200) area: 0.17 ms (170µs)
Pixel search in FullScreen (1920x1080) and ShadeVariation: 68ms 5.6ms (FF function do not return the first Pixel, but the closest to a given point)
Complexe FullScreen Search (1920x1080 area, searching for a 20x20 spot having 50 pixels within a list à 5 colors with a ShadeVariation of 10, and 3 excluding rectangles): 78 ms 56 ms

BTW, if someone is willing to help to write some decent documentation in English for this small library, that would be great.

Edited by FastFrench, 18 February 2013 - 03:28 PM.

[FastFrench]

A small error in the benchmark script : FF fullScreen Pixel Search was surprisely long (68ms). It is because a FullScreen snapShot was done each time.

The right time is :
5.6 ms for the FullScreen Pixel Search using ShadeVariation.

And the right BenchMark Script :

AutoIt        expandcollapse  popup

 #cs ----------------------------------------------------------------------------
 FastFind Version: 1.3
 AutoIt Version: 3.3.6.1
 Author:         FastFrench

 Script Function:
    FastFind simple Benchmark.

#ce ----------------------------------------------------------------------------

#include "FastFind.au3"


; Use Native Pixelgetcolor() on 100 different points 
$begin = TimerInit()
for $x = 1 to 100
  $a = PixelGetcolor($x, 500);
 Next

$dif = TimerDiff($begin)

; Use Native PixelSearch() on FullScreen (1920x1080) x 100 with ShadeVariation
$begin1 = TimerInit()
for $x = 1 to 100
  $a = PixelSearch(0,0,1919,1079, 0x00FF5511, 2);
Next
$dif1 = TimerDiff($begin1)

; Processing time comparaison with FastFind equivalent : FFGetPixel, that works on a SnapShot. 
FFSnapShot() ; To keep it simple, a FullScreen capture here
$begin2 = TimerInit()
for $x = 1 to 1000
  $a = FFGetPixel($x, 500);
 Next
$dif2 = TimerDiff($begin2)

; SnapShot BenchMark : 100 SnapShots of 10x10 areas
$begin3 = TimerInit()
for $x = 1 to 100
  $a = FFSnapShot(0,0,9,9) ; 10x10 pixels area
Next
$dif3 = TimerDiff($begin3)

; SnapShot BenchMark : 100 FullScreen SnapShots
$begin4 = TimerInit()
for $x = 1 to 100
  $a = FFSnapShot() ; FullScreen Capture
Next
$dif4 = TimerDiff($begin4)


; FFNearestPixel BenchMark : 500 simple pixel search in 200x200 area
$a = FFSnapShot(0,0,199,199) ; 200x200 pixels
$begin5 = TimerInit()
for $x = 1 to 500
  $a = FFNearestPixel($x,$x,0x002545FA,false) ; Pixel search in 200x200 area, don't force SnapShots each time
Next
$dif5 = TimerDiff($begin5)

; FFNearestPixel BenchMark : 200 pixel search in FullScreen and ShadeVariation
; As NearestPixel do not expose ShadeVariation, we use FFNearestSpot($SizeSearch, $NbPixel, $PosX, $PosY, $Color, $ShadeVariation=0, $ForceNewSnap=true, $Left=0, $Top=0, $Right=0, $Bottom=0, $NoSnapShot=$FFLastSnap, $WindowHandle=-1)
$a = FFSnapShot() ; FullScreen
$begin52 = TimerInit()
for $x = 1 to 200
  $a = FFNearestSpot(1, 1, $x, $x, 0x00FF5511, 2, false)
Next
$dif52 = TimerDiff($begin52)


; FFNearestPixel BenchMark : 500 simple pixel search in 200x200 area
; SnapShot BenchMark : 100 FullScreen SnapShots
$a = FFSnapShot() ; FullScreen Capture
FFAddColor(0x453456)
FFAddColor(0xFF0034)
FFAddColor(0x76FF98)
FFAddColor(0x8723FF)
FFAddColor(0x771122)
FFAddExcludedArea(5,10,10,15)
FFAddExcludedArea(52,52,80,80)
FFAddExcludedArea(120,130,100,180)
$begin6 = TimerInit()
for $x = 1 to 100
  $a = FFNearestSpot(20, 50, 100, 100, -1, 10, false) ; With ShadeVariation, don't force SnapShots each time 
Next
$dif6 = TimerDiff($begin5)

MsgBox(0, "PixelGetColor vs FFGetPixel", "Elpased time for :"&@lf&"100 PixelGetColor = " & ($dif/1000) & " S"&@lf&"100 FullScreen PixelSearch with ShadeVariation = " & ($dif1/1000) & " S"&@lf&@lf&"1000 FFGetPixel = " & ($dif2/1000) & " S"&@lf&@lf&"100 SnapShot 10x10 area = "&($dif3/1000) & @lf&"100 FullSreen SnapShot = "&($dif4/1000) & @lf&"500 Simple Pixel Searches in 200x200 area = "&($dif5/1000) & @lf&"200 Pixel Searches with ShadeVariation in FullScreen = "&($dif52/1000) & @lf&"100 Complexe FullScreen searches (20x20 Spot, List of 5 colors with ShadeVariation and 3 excluded rectangles) = "&($dif6/1000) & @lf)


; Results : PixelGetColor x 500 = 9.61 Seconds 
;           FFGetPixel x 500    = 0.0893 Seconds

[Ascend4nt]

Okay, just tested this out.. for some reason, on my setup the Aero theme got disabled twice due to resources being overloaded. Is the DLL releasing GDI objects correctly? (I'm running Win 7 x64 w/4GB memory and a 512 MB Radeon HD card) - I tried the script in both x86 and x64 mode). I don't see any function that frees the memory used by snapshots, but maybe I am missing something?

As for the benchmark script itself, it took over a minute to complete.. had to fix the one line to read the right difference though. It should be:

$dif6 = TimerDiff($begin6)

The times are pretty impressive, and I have a project which might make use of this in the future, only I have a couple of questions:

In terms of 'nearest pixel,' what exactly is your the DLL doing? Is it searching simultaneously left,right, up and down? Is it searching one way before the others? One nice feature of AutoIt's PixelSearch is it allows you to specify a search direction simply by changing the order of X/Y parameters. A little more understanding of how the DLL is performing the search would help here.

Also, 3 API calls are not wrapped, which sound great (and are listed in the header of 'FastFind.au3'):
- ColorSearch
- ColorsSearch
- ColorsPixelSearch
Are they incomplete? If not, could you provide a calling convention for them? I sometimes find myself searching for the 1st occurrence of a range of colors, so a multi-search function will be useful. I suppose I could do a snapshot and then search that a few times - but assembled code will always be faster.

One last thing - the function prototypes listed in the UDF has 'COLORREF' indicated for Add/Remove Color. This is different from the way AutoIt uses colors (COLORREF: BGR, AutoIt RGB: RRGGBB). Will we need to adjust code to shift around color bits before calling these functions? Also - do any of the other Pixel search functions use the COLORREF format?

Thanks for the UDF and the help.

*edit: From a UDF I wrote a while ago, the way I grabbed pieces of the screen was using the following calls (sorta pseudo-code here):
GetDC ($hWnd) -> $hSourceDC
CreateCompatibleBitmap ($hSourceDC,$iWidth,$iHeight) -> $hCompatBitmap
CreateCompatibleDC ($hSourceDC) -> $hCompatDC
SelectObject ($hCompatDC, $hCompatBitmap)
BitBlt ($hCompatDC,$iWidth,$iHeight,$hSourceDC,$iX1,$iY1)
- some form of memory allocation to hold bitmap+extra info -> $pAllocatedMem
GetDIBits ($hCompatDC,$hCompatBitmap,0,$iHeight,$pAllocatedMem)
SelectObject ($hCompatDC,$hPrevSelectedObj) -> not sure if this is really necessary
DeleteObject ($hCompatBitmap)
DeleteDC ($hCompatDC)
ReleaseDC ($hWnd,$hSourceDC)

Edited by Ascend4nt, 14 March 2011 - 12:55 AM.

[FastFrench]

Okay, just tested this out.. for some reason, on my setup the Aero theme got disabled twice due to resources being overloaded. Is the DLL releasing GDI objects correctly? (I'm running Win 7 x64 w/4GB memory and a 512 MB Radeon HD card) - I tried the script in both x86 and x64 mode). I don't see any function that frees the memory used by snapshots, but maybe I am missing something?

Odd. I've never meet this problem. Done lot of testing both on Vista 32 2GB and Seven 64 8GB. What kind of script were you using ? Could you try with active traces and check for the errors ? What settings do you use for debugging ? (try to remove graphical debug, to see if the problem remains).


The memory of SnapShots is only released when :
- a new SnapShot is done with the same SnapShot Number (memory is reallocated)
- the dll is unloaded

So if you always play with a couple of snapshots, you don't really to release the memory (A couple of 1024x768 captures will take 6MB. So on nowdays computers, you can keep that allocated as long as your script is running).

As for the benchmark script itself, it took over a minute to complete.. had to fix the one line to read the right difference though. It should be:

$dif6 = TimerDiff($begin6)

Ah yes, thank you for pointing this. Finally the complex search is a bit faster than I thought (I've update Benchmark stats in first spost : : 56ms instead of 78ms for the last part - the complexe search).

The times are pretty impressive, and I have a project which might make use of this in the future, only I have a couple of questions:

In terms of 'nearest pixel,' what exactly is your the DLL doing? Is it searching simultaneously left,right, up and down? Is it searching one way before the others? One nice feature of AutoIt's PixelSearch is it allows you to specify a search direction simply by changing the order of X/Y parameters. A little more understanding of how the DLL is performing the search would help here.

Compared to PixelSearch, you have two additionnal parameters to give a Position. All search routines will return the pixel or spot that is as close as possible from this position (= the pixel or spot with the minimum distance). This way you have much more control over what is done vs PixelSearch.

Also, 3 API calls are not wrapped, which sound great (and are listed in the header of 'FastFind.au3'):http://www.autoitscript.com/forum/index.php?app=forums&module=post&section=post&do=reply_post&f=9&t=126430&qpid=877992
- ColorSearch
- ColorsSearch
- ColorsPixelSearch
Are they incomplete? If not, could you provide a calling convention for them? I sometimes find myself searching for the 1st occurrence of a range of colors, so a multi-search function will be useful. I suppose I could do a snapshot and then search that a few times - but assembled code will always be faster.

That was for historical reasons. In fact, in order to reduce redundancy and acheive better reliability, I've only one very generic C++ method left for all searchings (except differences detection and ColorCount), that has optimized section for all possible situations (16 different algorithms depending on what has to be done).
This function (in the dll) is exported as :

int WINAPI GenericColorSearch(int SizeSearch, int &NbMatchMin, int &XRef, int &YRef, int ColorToFind/*-1 if several colors*/, int ShadeVariation, int NoSnapShot);

So in fact, now all functions like ColorSearch, ColorsSearch and ColorsPixelSearch will make one and only one call to GenericColorSearch. So it's just a question of parameters. For instance, ColorsPixelSearch and ColorsSearch still exist in the dll, but it just for a question of compatibility with my own scripts using them : in C++, they just call GenericColorSearch (once).

FFNearestPixel (in AutoIt Wrapper) for instance is a wrapper that calls ColorPixelSearch, a simplified version of GenericColorSearch (less parameters).
But in the Benchmark, I wanted to used a function that is as close as possible of PixelSearch, with ShadeVariation. So, as ShadeVariation is not a parameter of FFNearestPixel, I used FFNearestSpot insteaded.

FFNearestSpot keeps all the parameters (and so all the genericity) of the C++ GenericColorSearch function.

Please check the last example in BenchMark to see how to make a multi-color search.

One last thing - the function prototypes listed in the UDF has 'COLORREF' indicated for Add/Remove Color. This is different from the way AutoIt uses colors (COLORREF: BGR, AutoIt RGB: RRGGBB). Will we need to adjust code to shift around color bits before calling these functions? Also - do any of the other Pixel search functions use the COLORREF format?

Well, basically a COLORREF is just another name of the DWORD (32 bits unsigned int). I prefered to use "COLORREF" instead of "DWORD" just to explicit the fact that it holds color information. But I don't use all COLORREF-related macros (RGB and the like), prefering to explicitely play with bits.
So, to make it short : despite the confusing name, Color coding is the same as in AutoIt (in hexa, 0x00RRGGBB).

*edit: From a UDF I wrote a while ago, the way I grabbed pieces of the screen was using the following calls (sorta pseudo-code here):
GetDC ($hWnd) -> $hSourceDC
CreateCompatibleBitmap ($hSourceDC,$iWidth,$iHeight) -> $hCompatBitmap
CreateCompatibleDC ($hSourceDC) -> $hCompatDC
SelectObject ($hCompatDC, $hCompatBitmap)
BitBlt ($hCompatDC,$iWidth,$iHeight,$hSourceDC,$iX1,$iY1)
- some form of memory allocation to hold bitmap+extra info -> $pAllocatedMem
GetDIBits ($hCompatDC,$hCompatBitmap,0,$iHeight,$pAllocatedMem)
SelectObject ($hCompatDC,$hPrevSelectedObj) -> not sure if this is really necessary
DeleteObject ($hCompatBitmap)
DeleteDC ($hCompatDC)
ReleaseDC ($hWnd,$hSourceDC)

Yes, that's roughly the idea of the SnapShots.

Edited by FastFrench, 14 March 2011 - 11:06 AM.

[Ascend4nt]

FastFrench,

Thanks for clarifying things.. I think I've got a handle on how it works now.

As for the weird Aero crashes.. I've since restarted the machine and haven't seen the situation happen again. So for now I guess we'll just chalk it up to something funky going on with my computer or O/S. No error messages as of yet, and its set to the default.

I will test it further when I have time. I have the tools to create an area to search (see my 'CrossHairs (FullScreen)' & 'Rubber-band boxes' UDF's), and other tools at my disposal to make good use of this.

Thanks again for your work and explanations

[FastFrench]

Thanks for the update Ascend4nt.

The next function should be the following :
; FFBestSpot Function - This feature is similar to FFNearestSpot, but even more powerful.
; Suppose for instance that you want to find a spot with ideally 200 blue pixels in a 50x50 area, but some of those pixels may be covered,
; and also for transparency reasons, the color may be a bit different. So, if it can't find a spot with 200 pure blue pixels, you could
; accept "lower" results, like only 120 blue pixels minimum, and - if enough pure blue pixels can't be found - try to find something close
; enough with ShadeVariation.
; FFBestSpot will do that all for you.
; Here is how it works :
; Only one additionnal parameters compared to FFNearestSpot : you give the minimum acceptable number of pixels to find, and then the
; "optimal" number. All other parameters are the same, with same meaning.
; First, FFBestSpot will try to find if any spot exist with at least the optimal number of pixels and pure color (or colors). If yes,
; then it return the one that as the shorter distance with $PoxX/$PosY
; Otherwise, it will try to find the spots that has the better number of pixels in the pure Color (or colors). If it can find a spot with
; at least the minimum acceptable number of pixels, then it returns this spot.
; Otherwise, it will try again the two same searches, but now with ShadeVariation as set in the parameter (if this parameter is not 0)
; If no proper spot can be found, returns 0 in the first element of the array and set @Error=1.
;
; Proto C function: int WINAPI ProgressiveSearch(int SizeSearch, int &NbMatchMin, int NbMatchMax, int &XRef, int &YRef, int ColorToFind/*-1 if several colors*/, int ShadeVariation, int NoSnapShot)
Func FFBestSpot($SizeSearch, $MinNbPixel, $OptNbPixel, $PosX, $PosY, $Color, $ShadeVariation=0, $ForceNewSnap=true, $Left=0, $Top=0, $Right=0, $Bottom=0, $NoSnapShot=$FFLastSnap, $WindowHandle=-1)


Any use ?

Edited by FastFrench, 15 March 2011 - 06:45 AM.

[Ascend4nt]

Sounds good. Your UDF has actually saved me from a future project, although I had considered using two optional variances for each individual color:
a.) either a shade variation, or
b.) a HSL variation (hue, saturation and/or lightness/brightness)

Perhaps something to think about.. one could also override all pixels' variance states with a passed parameter (shade variation or HSL variation).

If you choose something like that, you might have to precompute the HSL info and variation data to prevent extra calls to 'ColorRGBToHLS', 'ColorHLSToRGB'. One such function that could help is 'ColorAdjustLuma'.. the others would need extra calculations (Microsoft has their conversion routine posted here: http://support.microsoft.com/kb/29240)

This is all just theorizing on what may be useful. No pressure

On a side note - do you work with just the primary monitor, or does this use virtual screen width/height (for multiple screens combined as one)?

Edited by Ascend4nt, 15 March 2011 - 07:15 AM.

[FastFrench]

Thank you for this suggestion.

That's indeed an interesting idea. I'm a bit afraid of the impact it may have on processing time (eh, would maybe even have to rename the dll ). And, in case of preprocessing all those data, then SnapShots would take much more time and probably involve more memory (as I would probably have to keep both pixel codifications).
It's right that such filtering would probably have more sense than ShadeVariation. But I wonder if there're many topics were "ShadeVariation" is not enough.

Another idea I had, would be to have the ability to provide some mask to find a precise pattern on the screen.
For exemple, providing the following pattern would mean to take in account only the pixels corresponding to to the "1", ignoring all others. This would probably greatly reduce the "noise" when looking for some precise pattern.
000000000000000
000000111000000
000010000010000
000100000001000
001000000000100
001000000000100
010000000000010
010000000000010
001000000000100
000100000001000
000010000010000
000000111000000
000000000000000


For the double screen: it works fine for me with extended display on two screens. Works as if I had a larger one (width around 2900). Now I've not done extensive testing on different configurations. It's probably very OS-dependant.

Edited by FastFrench, 15 March 2011 - 06:05 PM.

[PhilHibbs]

Looks very useful, something I have been wanting for a long time! I've managed to crash it, though. I was running the demo and moving icons around and pressing F2, watching it find the 10x10 shortcut arrow on my desktop icons, and it suddenly stopped changing where it found it, no matter where I moved the icons it would always find it in the same place and not where the nearest icon to the top-left of the screen was, like it got stuck with a snapshot. I pressed Esc and now the demo script won't even run.

*Edit* I compiled it as an EXE, and that runs, and also the .AU3 version works now as well! Very odd. It does occasionally stop detecting the shortcut arrow as a 10x10 black-or-white area sometimes. Oh, I think it's when I have AutoIt Window Info running, it only detects within the Window Info window! *Update* No, any window with white space in it will be detected in preference to a black-and-white pattern.

Does it work with multiple monitors? I can't get it to detect above the primary desktop, which would be a negative Y position. *Edit* Just rearranged things so my secondary monitor is to the right, and it doesn't detect stuff beyond 1024 pixels (my primary monitor X resolution).

Edited by PhilHibbs, 16 March 2011 - 04:56 PM.

[PhilHibbs]

Another potential glitch: if you bind it to a window and part of that window is off-screen, it detects the offscreen portion on F2, I'm guessing it detects as all black because it is not rendered with anything. This might be a general problem with pixel scanning in AutoIt as well, haven't tested it.

[FastFrench]

Looks very useful, something I have been wanting for a long time! I've managed to crash it, though. I was running the demo and moving icons around and pressing F2, watching it find the 10x10 shortcut arrow on my desktop icons, and it suddenly stopped changing where it found it, no matter where I moved the icons it would always find it in the same place and not where the nearest icon to the top-left of the screen was, like it got stuck with a snapshot. I pressed Esc and now the demo script won't even run.

Thank you for trying FastFind.

Maybe I should clarify how the demo is supposed to work.

First, you can bind the searches to a given Window with F3 (Notepad if such a Window exist when you press F3, or the active Window otherwise) and come back to full screen searches with F4. So the behaviour will be somewhat different if you pressed F3 first or not.
When you press F2, the instruction used is :

FFNearestSpot(10, 100, 0, 0, -1, $ShadeVariation, 0, 0, 0, 0, $FirstLoop)

So, looking for a 10x10 area with 100 pixels in the list of colors (that holds pure white and pure black), as close as possible from top left corner (of the Window or the screen), using a Shade Variation if needed (up to 20).
So a 10x10 pure white area should be prefered to your black & white shortcut arrow if it's at a shorter distance from the (0,0) point.



For the dual Monitor configuration, can't test that right now (have only 1 monitor here), but can you check in the log file (TRACER.TXT) what window size/coordinates are used for the SnapShot ?

This TRACE.TXT file should usually help to clarify what happen.


Also, In my configuration when I move a Window partially out of the screen, I think that the detection still work fine on the whole window. Now it may depend on the OS you use, and also the context. Not sure that the out of the screen part of a Window is still refreshed, and so it may become black when it should have been repainted (and has not, as it's not visible).

Edited by FastFrench, 17 March 2011 - 09:08 AM.

[FastFrench]

New version 1.4 posted. As the size was too big, couldn't include the new tool ShowPixels. If you want it, you can mail or pm me.

Several fixes and improvements in this version. Most visible change is a new function, FFBestSpot, allready described in a previous post.

As I've found no volunteer to help on this task, documentation could be better.

Edited by FastFrench, 01 April 2011 - 03:50 PM.

[FastFrench]

Version 1.5 : fix the FFGetPixel function (there was sometimes a conflict with Win32 API GetPixel(hdc, int, int), so returned -1).

[MedeaIT]

Thanks for the fix

Awesome UDF script

[FastFrench]

Thank you for reporting it I suspected something was wrong with this function, but couldn't point the problem before.

[Ariff]

Awesome work you have done with this FastFrench, i used to do my pixelsearch routines with the builtin PixelSearch(), but since i discovered this, my work has been going a lot more fluent. I have a few questions about it though and wonder if you might have some time to answer them. If not i understand and know you're busy... Anyways in the 1.3 release of your scripts you are talking about the following :

ColorsSearch (Close to ColorSearch, except that instead of a single color, all colors of the current list are in use)
ColorsPixelSearch (Similar to ColorPixelSearch, except that instead of a single color, all colors of the current list are in use)

ColorSearch (it's the most versatile and powerful function here : you can, at the same time, check for as many colors as you want, with possibly a "ShadeVariation", multiple subareas to ignore... will Find the closest spot with a all specified criteria. The spot is a square area of NxN pixels with at least P pixels that are as close as allowed by ShadeVariation from any of the colors in the list).

I was looking for them in the FastFind.au3 file, but couldnt find any more reference to it. Do these functions still exist or are they removed ? Or are they the same as the FFNearestSpot function ?

Another thing i was wondering is when you do a FFNearestSpot function in combination with the ColorList by using FFAddColor, and lets say we add 10 colors in there, you have to set the parameter to -1 to enable it. Does the function searches through all the colors in the colorlist ? Or will it stop at lets say Color[2] if somethings being found.

[FastFrench]

Awesome work you have done with this FastFrench, i used to do my pixelsearch routines with the builtin PixelSearch(), but since i discovered this, my work has been going a lot more fluent.

Thanks you very much !

I have a few questions about it though and wonder if you might have some time to answer them. If not i understand and know you're busy... Anyways in the 1.3 release of your scripts you are talking about the following :

I was looking for them in the FastFind.au3 file, but couldnt find any more reference to it. Do these functions still exist or are they removed ? Or are they the same as the FFNearestSpot function ?

On the very first release of FastFind, those were different functions, one for each case. In version 1.2, I've done some refactoring with a highly optimized generic function GenericColorSearch called by most other functions. So all those "deprecated" functions still exist (for compatibility reasons with my own code), but you don't really need them as they internally all call FFNearestSpot with some restrictions on the parameters. Of course, there are some functions that are obviously different, but those are exposed in FastFind.au3 (ColorCount, Changes detection...).

Another thing i was wondering is when you do a FFNearestSpot function in combination with the ColorList by using FFAddColor, and lets say we add 10 colors in there, you have to set the parameter to -1 to enable it. Does the function searches through all the colors in the colorlist ? Or will it stop at lets say Color[2] if somethings being found.

Well, it doesn't really matter. For a given pixel, if I know there is a match on a given color in the list, then it's just a question of performance to know if I continue to check the rest of the list for that same pixel or not (so of course, I don't). Anyway the result would be the same. In no case would a single pixel counts for more than one hit, if that is the question. And the impact on performance is in most cases not noticeable (except in very specific cases, with large list of pixels and most pixels in the area having one of the first color in the list).
No matter what colors in the list have hits, if you ask a NxN spot with at least P "good" pixels, then you're assured to have the closest spot that fit those criteria if one exists.

Edited by FastFrench, 05 April 2011 - 07:44 AM.