Advanced Pixel Search Library

[SirbuCtin]

functions declared as this :

        [DllImport("FastFind.dll")]
        public static extern int FFGetPixel(int X, int Y, int NoSnapShot);

        [DllImport("FastFind.dll")]
        public static extern int SnapShot(int aLeft, int aTop, int aRight, int aBottom, int NoSnapShot);

and also remove :

LogWrite("PixelSearch : Found at (" + Math.Abs(j) + ":" + Math.Abs(k) + ")");

 

[viper8844]

What About FFNearestPixel Shade variation?

[PhilHibbs]

Any thoughts on the  "Failed to load FastFind.dll, application probably won't work" problem?

[argnist]

Hi, guys!

Sorry for my English.

I have totally different snapshots in 1st and 2nd Snapshot "slots". (FFSaveBMP saves totally different pics)

FFIsDifferent(0, 1) always returns false.

What I'm can do wrong?

Thanks in advice.

Edited June 17, 2016 by argnist

[DiesIrae]

arginist, try to download version 2015 here - https://github.com/FastFrench/FastFind

[Trashfrog]

Thank you for that awesome collection. I'm using it quite alot.

There're some features I miss.

Something like ImagesearchUDF, as far as I get it. (I more or less just startet with Autoit) it should be possible with FFBestSpot too, or am I wrong? But its quite complicated.

Docs on the Shade Variation: What is it and how to use it?

I would also like some functions using Pixel checksum

[Dru4]

Hi guys!

I have problem with snapshot work under VMware. Without VM it works perfectly.

I making screenshot by handle

FFSnapShot(0, 0,0, 0, 1,$hWnd)

With VM it brings my same screenshot every time, without- work like it should.

If i make FFSnapShot by coords, not by handle- it crashes, because i use 2 monitors and make screenshots on second monitor.

Any ideas?

[Marshian]

Great tool, this is helping me a lot with a timing tool to measure HMI update speeds.
I do have a problem that has been mentioned before: Using the coordinates to define an area to snapshot is not working on multi-monitor setups. The DLL can't handle the coordinates outside the first monitor.

Any chance you might fix this?

[Mysticdrew]

Please review this, post I made regarding getting Pixel colors and windows 10, 

Your library helps a bit, but still does not provide the speed in Windows 10 that the basic autoit PixelGetColor has in Windows 7.
This library does help quite a bit in Windows 10 compared to PixelGetColor, with that example code in the linked post. It brings the execution down to 3 seconds including script startup time. Keep in mind, PixelGetColor on a 39x47 rectangle 8 times is .3 seconds in wondows 7. I have not fully tested with the library in Windows 7 yet. I will update this post when I finish the tests.

Here is an old discussion on the root cause of the issue. https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/4db649d2-4747-4773-8f9a-9b74dacc5a7d/getpixel-calls-slow-under-aero?forum=windowsuidevelopment

Here is one possible solution. http://www.codeproject.com/Articles/617613/Fast-pixel-operations-in-NET-with-and-without-unsa

Edited October 11, 2016 by Mysticdrew

[sas]

FFColorCount doesn't seem to work with exclusion areas, I'm getting the same result for different exclusion area combinations, is it a bug or a feature?

FFSetWnd($wHandle)
FFSnapShot()

For $col = 1 To $Height Step 1
   For $row = 1 To $Width Step 1
      $currentTileLeft = Round($leftTilePos + ($row-1) *$tilePixelSize,0) + $margin
      $currentTileTop  = Round($upTilePos + ($col-1) *$tilePixelSize,0) + $margin
      $currentTileRight = Round($leftTilePos + $row *$tilePixelSize,0) - $margin
      $currentTileBottom = Round($upTilePos + $col*$tilePixelSize,0) - $margin
      FFResetExcludedAreas( )
      FFAddExcludedArea( 0, 0, @DesktopWidth, $currentTileTop )
      FFAddExcludedArea( 0, $currentTileTop, $currentTileLeft, $currentTileBottom )
      FFAddExcludedArea( $currentTileRight, $currentTileTop, @DesktopWidth, $currentTileBottom )
      FFAddExcludedArea( 0, $currentTileBottom, @DesktopWidth, @DesktopHeight )
      $tileValues[$col][$row] = FFColorCount($color,$variation,False)
   Next
Next

 

Edited October 15, 2016 by sas

[snoopie]

I currently have a dual boot System with Windows 10 x64 and Windows 7 x64 (Aero Design disabled) which gives me a chance to do a comparison:

i7 6700k @ 4.00 GHz, DDR4 3200

[bluechipps]

Has anyone successfully been able to compile version 2.3 from GitHub? I really need those fixes and can't tell you how many times I've tried. So many errors with the 2 versions of VS that I have and has just been impossible to try and bypass all the incompatibilities and still produce a library that functions properly

Edit:  Grabbed old source for 2.2 and found a copy of VS2010 Professional lying around. Manually fixed the bug with FFColorCount and finally got it compiled and working! I'd post my dlls but I think you should compile yourself for safety reasons

Edited December 29, 2016 by bluechipps

[LeCarre]

I'm surprised that I've not seen this before, I use alot of pixel functions.  I've read all posts. And have been playing with the code.

The first thing I noticed was that the snapshots in the benchmark were excluded from being timed.  This is a bit like saying you have a well tuned car because it's going real fast and ignoring the fact it was tossed out of an airplane.

After including the Snaps as part of the benchmark it shows that in the time it takes to do 1 Snapshot, you can do a few hundred of AutoIt's pixelgetcolor functions.

So basically if you're not doing a TON of pixel work in a fast (video) paced application. Then I think AutoIt functions should be learned really well before tackling this harder to use tool.

I'm not saying it's bad, don't get me wrong. Just Sayin

Also the Benchmark is poorly written, and does not work properly. (version 2.2 here, and github are the same.)

First Comment is wrong as the DebugMode disabled is itself disabled.

; In order to acheive full possible speed, I disable all debug features
;FFSetDebugMode(0)    

It generates 1260 lines of errors in the TRACER.TXT due to the fact the full screen shot is 1920x1080 and then pixels up to 2000 and 3000 are sent as parameters.

for $x = 1 to 2000
  $a = FFGetPixel($x, 500);
Next

for $x = 1 to 3000
  DllCall($FFDllHandle, "int", "FFGetPixel", "int", $x, "int", 500, "int", $FFLastSnap)
Next
 

Again, not slamming the work, it's decent.

 

Spent a few hours modifying the Benchmark to improve timers, Fix Bugs, Build a GUI, Streamlined Feedback all using same measurements for easier comparison.  I know this is an old thing, but hey   Love to Code.

Benchmark.au3

Edited March 23, 2017 by LeCarre
Added Improved Code

[LeCarre]

My Interest in this Tool was pretty strong, I read every forum post, etc, finally got down to using it, Replaced my first function that uses pixelgetcolor, and pixelsearch.

Found 3 bugs. And 1 Bad Behavior. In my first few hours with it.

Bad Behavior

1) Bad Behavior

Unless i'm mistaken a DLL should report Errors to the Application using it, not to the user thru dialog boxes.

I was taking small snaps in a window at a high rate of speed, occasionally FF would popup a dialog reporting that taking the snap had failed.

This is what a return code is for!

This alone is a DLL Buster, am i going to realease a program to the public knowing I can't control it?

BUGS

1) Debug Off still creates the TRACER.TXT file, and appends to it indefinately, a forever growing file you can't avoid. I had to add code to my program to delete the file on exit.   FileDelete(@ScriptDir & "\TRACER.TXT")

2) Using FFNearestSpot to replace pixelsearch failed for me. I got a result of 0 instead of an array, and @Error was not set.

It took me awhile to figure out the reason it would not return the expected array was that it apparently could not process an area that had a height of 1 pixel, and a width of 100, had to modify my code to use a 2x100 snap and exclude 1 row of pixels for it to work.

3) I wanted to find all x,y coordinates of a pixel color with a slight ShadeVariation.

So I thought to find first pixel, then use FFSetPixel to change the found pixel to black so it would not be found again on the next loop.

After a little hair pulling, and bad results I did the following.

Take a Snap, save the JPG, Find the Pixel.

Set the pixel to RED (Easier to see results) and save the JPEG.

What I expected was to see 1 Red Pixel, but instead the RED pixel had blurred over and shaded the adjacent pixels changing them and ruining the snapshot i was working with, how can FFSetPixel alter 4 or 5 pixels?

So I had to calculate the coordinates of an exclusion rectangle to avoid redetecting this pixel, which i'm sure is slower than FFSETPIXEL as i progress thru the loops. Slower defeats the entire reason for the DLL in the first place.

 

In the end I timed my app using both methods keeping an avg time used by the routines.

Analyzing a 2x100 pixel area was 25% slower using FastFind after 5 minutes of stress test.

 

My excitement for Fast Find v.2.2 is dead.

Overall I can't trust this DLL to do anything with accuracy.  Too bad it was never cleaned up, or even tested well.

 

[cal]

On 3/25/2017 at 10:58 AM, LeCarre said:

My Interest in this Tool was pretty strong, I read every forum post, etc, finally got down to using it, Replaced my first function that uses pixelgetcolor, and pixelsearch.

1) Bad Behavior

1) Debug Off still creates the TRACER.TXT file, and appends to it indefinately,

3) Take a Snap, save the JPG, Find the Pixel.

 

 

I've just started playing with it.   Its working quite well for me.

Bad Behavior. 
Have not seen that yet,  but yes.  I would agree, it should be returning a code.    However.   I think I read he did the DLL.  Someone else did the autoit wrapper file.   The msgbox is coming from the wrapper.  So thats easy to fix.  I see it in the "fastfind.au3" file.   I may have read who did what wrong.  I've just skimmed this thread while trying a few things out.   However.  I do see reference to the DLL throwing a msgbox on serious errors in the help file.   So..... Now I'm not sure.

Tracer.txt
Me too.  Found that out when my dropbox filled up.  It seems to write a lot of data when you do exclusions.   But its still writing smaller amounts to it on a regular basis.  I'm now unloading the dll so I can delete the file at the end of my script.   Good enough while I play with it.   I have not looked yet.  Is this unwanted data from the DLL or from the au3 file?   Writing to a txt file has to be slowing things down I would think.   I have not looked at when and how its being written to yet.

Save the JPG
I believe your problem is that your looking at a JPG.  Its compressed even if you set it to 100.  I don't think the JPG represents the contents of the memory map.  Save the exact same map as both a BMP and as a JPG and you see there is a difference.   In my BMP I see only 1 pixel turned red.  In the JPG I see the orig pixel plus 3 surrounding ones modified.   Also I would have changed what the defaults are on the JPG so they match the BMP defaults to be consistent.   But that is just me being nit-picky.   Overall this is very good.

I'm currently playing with the FFBestSpot func.   Searching for a 10x10 spot with optimal 50 pixels.  If the spot is not what I want I hit a key excluding 100 pix from that spot in all directions and repeat the search.   This is working fairly well and not something I could have easily done myself with pixelsearch.

 

Is this being worked on?  His last visit is Feb 2015 over 2 years ago.    Even as is.  I see good use in this.

 

 

[blue_screen]

Hi everybody, I have a problem about FFNearestPixel code. I can find only one pixel location on the screen for one color value. if there are 2 different points for one color value on the screen, the code only find one location. for example if I have grids like my uploaded image, code only finds 1 numbered yellow point location, but I need also find 2 numbered yellow point location. can anybody help me? thanks

[Jos]

3 hours ago, blue_screen said:

an anybody help me? thanks

Welcome, my guess is that line 609 has a mistake in it.
(assume you can interpret what that means, else ask.)

Jos

[blue_screen]

thanks for your reply Jos,

 

in 609. line program checks if  "result" an array or not in FFGetRawData. 

I can not use efficiently FFGetRawData function. This function gives me so many pixel values for 1920x1080 resolutions. Checking every pixel to find my base color locations is very time consumed with this function. is there a way to find more than one location for one color value by using FastFind.au3?

[Jos]

Just now, blue_screen said:

in 609. line program checks if  "result" an array or not in FFGetRawData. 

Seriously, you really think I have a crystal ball in which I can see sources that are on your computer?
The meaning of that comment was to kindly tell you you need to provide proper information like the source code before people really can help!

Jos 

[JLogan3o13]

32 minutes ago, blue_screen said:

in 609. line program checks if  "result" an array or not in FFGetRawData. 

You have my sincere appreciation for the laugh this generated