Jump to content

Advanced Pixel Search Library


FastFrench
 Share

What do you think of this library ?  

35 members have voted

  1. 1. What do you think about FastFind ?

    • It's really great, I can't imagine doing a script without it
    • It's of some use for me in my current scripts
    • I could use it some day
    • Looks nice, but of no use for me
    • I've tried it, but it doesnt fit my needs
    • Sounds good on the paper, but can't make it work (bug or too difficult to use it)
  2. 2. Have you tried it ?

    • Yes, I'm using it right now
    • Somewhat, I've done some testing, will surely use it later
    • I've downloaded it and just played a little with packaged demo scripts
    • I've downloaded it, but not tried it so far
    • Not downloaded it so far, but I probably will some day
    • It's of no interested for me.
  3. 3. What is missing or should be improved ?

    • It has all the features I may need about Pixels Handling
    • OK it's pretty fast, but couldn't it be faster ?
    • Too hard to use it, could you simplify usage ?
    • Some additional features would be nice to have (please explain in a message)
    • It really lacks some decent documentation (I still hope to find someone to help on that)
    • Some critical features are missing, can't use it (please explain in a message)
    • I found some minor bugs (please explain in a message)
    • I've found some serious bugs (please explain in a message)
    • I've never tried it so far, can't tell
    • It would be nice if you could provide easy access to the associated tool - FFShowPixel
    • I would like to use it other languages. Could you provide wrappers ? (please explain in a message)


Recommended Posts

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

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

(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
Link to comment
Share on other sites

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 :

#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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

  • 3 weeks later...

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...