Jump to content

Why PixelGetColor is reported to NOT work


Recommended Posts

I have been wondering pixels measured from a full screen application cannot be measured reliabily with PixelGetColor. I wrote the following test program and collected values for a single pixel that seemed static on my screen.

HotKeySet("^{F1}", "GetPixelColor")             
HotKeySet("^{F9}", "Idle")      

Global $pixelColor

Idle()

;.....................................................................
Func Idle()
    While 1
    Wend
EndFunc

Func GetPixelColor()
    While 1
        $pixelColor = PixelGetColor(760,1120)
        ConsoleWrite($pixelColor & @CRLF)       
    Wend
EndFunc

Next, I copied the data reported on the console into Excel and created the following graphic of pixel values versus time.

Posted Image

displaycyclespo3.gif

I suspect that the dip in the pixel color is due to the application refreshing the display buffer (perhaps using a display trick like double buffering). So now my question is, how can I measure a pixel value and ignore the refresh?

Now there's a stumper for all you AutoIT Gurus! ;)

Edited by mvriesen2004
Link to comment
Share on other sites

I just had to say this. Ive seen people saying it lately, Just seems. Odd.

The word "Gurus" and/or "Guru". I just really seems odd to me, Like, Cant explain it xD.

# MY LOVE FOR YOU... IS LIKE A TRUCK- #
Link to comment
Share on other sites

strange...never seen that before...:evil:

Any Gurus want to grab this one?

I just had to say this. Ive seen people saying it lately, Just seems. Odd.

The word "Gurus" and/or "Guru". I just really seems odd to me, Like, Cant explain it xD.

Seems like the only thing you guies realy know is how to pad your post count ;)

The pixelColor did not chage at all while I was posting this:

HotKeySet("^{F1}", "GetPixelColor")    
HotKeySet("^{F9}", "Idle")    

Global $pixelColor

Idle()

;.....................................................................
Func Idle()
    While 1
      sleep(100)
    Wend
EndFunc

Func GetPixelColor()
   Local $lastpc, $pixelColor
    While 1
        $pixelColor = PixelGetColor(2,2)
    if $pixelColor <> $lastpc Then 
             ConsoleWrite($pixelColor & @CRLF)      
     endif 
     $lastpc = $pixelColor
    Wend
EndFunc

But I know I have read about it before and there was an explanation in the forum. :lmao:

What kind of graphic card do you use?

Link to comment
Share on other sites

I have a Radion 9800 card in my Dell 8300 and GeForce 6800 in my handmade AMD 4600+. But I don't think that is the problem. I think the issue is that the application I am scanning appears to manage it's own display and probably does a block memory copy to the video memory (of what ever windows uses as a graphics context.) Thus, I think the pulsing that I am seeing is due to the block move of pixels and perhaps pixel buffer blanking (to improve rendering smoothness). In effect, it is like a raster scan effect.

I am wondering if there is a way to catch the pixel at the high value (I have tried several versions of an algorith to do this). Or is there is a smart mod to the AutoIt toolbox that can be made.

In any event, I now see why many posts are reporting that the PixelGetValue does not work reliably. It seems to be application dependent.

BTW - your program and my program both work fine in non-graphically intense application windows. Thanks for your help with this tricky problem!!!

Yes - the post count padding is bad.

Edited by mvriesen2004
Link to comment
Share on other sites

You have tried your script on both machines and got the same result?

Any particular reason for the choise of coordinates?

Say, do you get the same result if you chose a pixel in the grey area of the start button? Or in the midle of the flag?

Link to comment
Share on other sites

You have tried your script on both machines and got the same result?

Any particular reason for the choise of coordinates?

Say, do you get the same result if you chose a pixel in the grey area of the start button? Or in the midle of the flag?

I get the same results for both computers - same application. The point I am checking is a control bound point where I want to be able to create additional alerts and responses. The behavior is the save regardless of what pixel I choose in the application.

Link to comment
Share on other sites

HotKeySet("^{F1}", "GetPixelColor")    
HotKeySet("^{F9}", "Idle")    

Global $pixelColor

Idle()

;.....................................................................
Func Idle()
    While 1
sleep(10)
    Wend
EndFunc

Func GetPixelColor()
    While 1
        $pixelColor = PixelGetColor(760,1120)
        ConsoleWrite($pixelColor & @CRLF) 
 
sleep(10)  

    Wend
EndFunc

this should keep the cpu load lower... adding the delay stops 96% cpu activity while running in a continous loop.

Edited by beerman
Link to comment
Share on other sites

Would font "smoothing" (properties - appearance - effects) cause pixel values to change?

Am having a problem with obtaining a pixel value using the AutoIt window tools and finding, when using that value in a script, that it sometimes has a different value. Is it dependant on your Videocard or am i just out in deep left field or what?

Link to comment
Share on other sites

Would font "smoothing" (properties - appearance - effects) cause pixel values to change?

Am having a problem with obtaining a pixel value using the AutoIt window tools and finding, when using that value in a script, that it sometimes has a different value. Is it dependant on your Videocard or am i just out in deep left field or what?

Nope - you are right. I think it depends of how many frames per second (fps) your system can render.

Here is what I think is going on. For real-time displays, the screen is updated by 1) blanking the existing screen and 2) redrawing/bit-copying the next frame in the sequence into the display memory. In the gaming community, we call this frames per second (fps) and the more you get, the smoother the animations. However, it creates the raster scan effect I show in my graph and thus creates pixel measurement irregularities.

What I am seeing in my work (although it is not a game I am working on) follows the same principles of blanking and redrawing and creates the irregularities we seen in the PixelGetColor function. We need to raise this to the AutoIT developers as fixing it it requires a new type of PixelGetColor function where the buffer update cycle can be detected..

Link to comment
Share on other sites

As I said before... am a newbie and my problem was fixed by doing the following ----

Life is good.... made the following changes

1. AutoItSetOption ("PixelCoordMode", 0);Sets Pixel Mode to 0 ....was 2

2. Removed debugging msgboxes that were taking focus AWAY from window I was working on

3 Changed font smoothing to "clear"

All of the really geeky stuff about refresh rates, video cards, etc are beyond my ken right now. Am ancient retired SW developer (50,000 vacuum tubes on my first box) trying to build an automated Poker bot!

Link to comment
Share on other sites

What I am seeing in my work (although it is not a game I am working on) follows the same principles of blanking and redrawing and creates the irregularities we seen in the PixelGetColor function. We need to raise this to the AutoIT developers as fixing it it requires a new type of PixelGetColor function where the buffer update cycle can be detected..

This has absolutely nothing to do with the way AutoIt works. AutoIt works perfectly. It does not read your screen. It get's the information from the OS.

It has a really simple solution. FIX YOUR CODE! Your using it to detect color changes. Fix your detection algorithm it's probably way to simple.

Link to comment
Share on other sites

I've been having similar problems with a full screen game. It seemed to me that the color being reported when it failed may have been the color of the scene behind the interface I was attempting to get the pixel color from. My theory as of now is that it may be grabbing the pixel color from the back frame (the frame being drawn to behind the scenes) or something of that nature. It reads just fine for the most part then suddenly a bad read. Very strange.

Link to comment
Share on other sites

This has absolutely nothing to do with the way AutoIt works. AutoIt works perfectly..... It has a really simple solution. FIX YOUR CODE! Your using it to detect color changes. Fix your detection algorithm it's probably way to simple.

Well... while I found autoit a very easy yet powerful tool and Im using it on daily basis, I have to disagree with your statement above.

There were several threads about this fluctuating getpixelcolor result, and these topics appear over and over. Just a couple example:

"GetPixelColor value fluxuating in fullscreen games"

http://www.autoitscript.com/forum/index.php?showtopic=28631

"getpixelcolor problems"

http://www.autoitscript.com/forum/index.php?showtopic=4703

"PixelGetColor Always returns 0 or 0x000000(hex)"

http://www.autoitscript.com/forum/index.php?showtopic=36638

"PixelGetColor() keep changing detected color, Mythwar"

http://www.autoitscript.com/forum/index.php?showtopic=32289

I also encountered this problem, and Im sure, I cant fix it in my macro code, because there is only a for-next cycle, a pixelgetcolor call and a print function to display the color value what the macro detected.

And what I see and everyone else see that in 5-10% of the cases, the returned value is wrong. And it is not about animated screens, shaded colors, anti aliasing - I saw this behavior on a simple solid black image in a game.

The common stuff in these error reports: they were detected in games, I also encountered this problem with a game.

Anyhow, I can live with that, and as it seems that the devs cant/wont do anything with it (I understand them anyhow) I suggest that check several pixels in the same time.

For example, if Im waiting for a text appearance in the game, I check 3-4 points simoultaneously for the expected color - usually this will be enough, even if one or two getpixel returns incorrect result.

Link to comment
Share on other sites

I suspect that the dip in the pixel color is due to the application refreshing the display buffer (perhaps using a display trick like double buffering). So now my question is, how can I measure a pixel value and ignore the refresh?

I don't know about games or refresh rates and graphics cards or the other discussions on this topic.

I looked at the graph you provided and am I understanding your question correctly?

You have repeatedly checked the color at the same cords and it always gives you one of two colors.

Over the course of less than any one tenth of a second, one of the colors reoccurs much less than the other and you want to know which of these two colors to ignore?

Edited by 1905russell
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...