solved Topic is solved

[Yaosr]

solved

[Gio]

Hello Yaosr.

"#9d0000" is probably being interpreted as text (with no mathemathical value), since this is not a valid notation for a number within AutoHotkey. Have you tried using the color notation specified in the docs for PixelSearch?

ColorID
The decimal or hexadecimal color ID to search for, in Blue-Green-Red (BGR) format, which can be an expression. Color IDs can be determined using Window Spy (accessible from the tray menu) or via PixelGetColor. For example: 0x9d6346.

Thus, this is how you would correctly set the colorID parameter of PixelSearch:

Code: Select all

PixelSearch, Px, Py, 177, 177, 780, 450, 0xd90000, 3, Fast
if ErrorLevel
    MsgBox, That color was not found in the specified region.
else
    MsgBox, A color within 3 shades of variation was found at X%Px% Y%Py%.

Best wishes.

[Yaosr]

solved

[Gio]

Hmm.. I just noticed you mentioned D90000 as Red?

PixelSearch ColorIDs follow a BGR color pattern (Not an RGB). (See the quote above).

Thus, try this:

Code: Select all

PixelSearch, Px, Py, 177, 177, 780, 450, 0x0000d9, 3, Fast
if ErrorLevel
    MsgBox, That color was not found in the specified region.
else
    MsgBox, A color within 3 shades of variation was found at X%Px% Y%Py%.

[Yaosr]

solved

[Gio]

Its easy. Each two HEX characters are the values of a single color channel. RGB and BGR are different in that:
RGB is just red first, than green, than blue.
BGR is just Blue first, than Green, than Red.

Thus, RGB Color 0xA1B3C4 Means:

Red: A1
Green: B3
Blue: C4

Thus, when RGB 0xA1B3C4 is converted to BGR, it is just changed to this:
0xC4B3A1

You can thus create two small functions to translate between the two color codes. Check the example below.

Code: Select all

msgbox % "RGB 0xD90000 is BGR " . RGBtoBGR(0xD90000)
msgbox % "BGR 0xA1FBC3 is RGB  " . BGRtoRGB(0xA1FBC3)
Return

RGBtoBGR(InputRGB)
{
BGR := "0x" . SubStr(InputRGB, 7, 2) . SubStr(InputRGB, 5, 2) . SubStr(InputRGB, 3, 2)
Return BGR
}

BGRtoRGB(InputBGR)
{
RGB:= "0x" . SubStr(InputBGR, 7, 2) . SubStr(InputBGR, 5, 2) . SubStr(InputBGR, 3, 2)
Return RGB
}

Since the translation routine is actually the very same, you can even squish the two functions above into a single function if you would like to.

[Nextron]

The above will misbehave it the 0x is not included.

Alternatively, you can tell pixelsearch to interpret the value as RGB: PixelSearch, Px, Py, 177, 177, 780, 450, 0xd90000, 3, Fast RGB

Also: sleep, 16000 ; Keep it down for 2 seconds... 2 seconds?

[Yaosr]

solved

[Yaosr]

solved

[Gio]

I think the relevant info from the docs in this case would be this one:

Slow mode only: By default, the search starts at the upper-left pixel of the region and checks all pixels vertically beneath it for a match. If no match is found there, the search continues to the right, column by column, until it finds a matching pixel. The default left-to-right search order can be inverted by swapping X1 and X2 in the parameter list. In other words, if X1 is greater than X2, the search will be conducted from right to left, starting at column X1. Similarly, if Y1 is greater than Y2, each column of pixels to be searched starting at the bottom rather than the top. Finally, if the region to be searched is large and the search is repeated with high frequency, it may consume a lot of CPU time. To alleviate this, keep the size of the area to a minimum.

So basically, you can set how you want the search to be conducted (the directions), but only in SLOW mode.

Furthermore, in my tests, this is the standard behaviour for FAST mode: search from right to left, line by line, going down one pixel a time when a line of pixels is finished with no matches. Stop at first match.

Either way, don't forget you have these two other options:
1 - You can do math with the results. In example: If you know the match reveals the position of a subimage that is AT LEAST 50 pixels wide and 50 pixels height, add a number smaller than that to the results of your PixelSearch and you will most likely end up in a matching pixel further into the picture.
2 - Given your thoughts about other positions of pixels, it looks like you are using PixelSearch to look for a picture (not a pixel) composed of all-red pixels (or something like that). If that is the case, don't forget you can use ImageSearch with an all-red (or any other color) image if you know your sample to be smaller (in width and height) than the actual image to be searched for. This could probably be used to yield some other position of X and Y inside the picture and you can control the relative position by controling the sample to be searched for.