AutoHotkey Community

Hi,

if i dllcall getpixel it will return a value like 2154215 but if i use autohotkey's pixelgetcolor, it will return 0xB5007C example.

what is the difference the 2? and how can i make autohotkey;s pixelgetcolor to display the first result instead?

thanks

The first value is numeric (base 10) and the second value is hexadecimal (base 16)

Try:



They're just different ways of representing numbers. In general, when working with colors, hex values will make more sense since they're often in the 0xRRGGBB format.

If you really need to switch formats, look at the documentation for SetFormat

The following info was obtained from the Win32 Programmer's Reference manual:

First, you can see the GetPixel function returns the color of the pixel in something called "COLORREF" as follows:

The GetPixel function retrieves the red, green, blue (RGB) color value of the pixel at the specified coordinates.

COLORREF GetPixel(

HDC hdc, // handle of device context
int XPos, // x-coordinate of pixel
int nYPos // y-coordinate of pixel


Parameters

hdc - Identifies the device context.
nXPos - Specifies the logical x-coordinate of the pixel to be examined.
nYPos - Specifies the logical y-coordinate of the pixel to be examined.

Return Values

If the function succeeds, the return value is an RGB value. If the pixel is outside of the current clipping region, the return value is CLR_INVALID.

Remarks - The pixel must be within the boundaries of the current clipping region. Not all devices support GetPixel. An application should call GetDeviceCaps to determine whether a specified device supports this function.

See Also - GetDeviceCaps, SetPixel

---------------------------------------------------------------------

Following is the description of the 32 byte COLORREF value:

The COLORREF value is a 32-bit value used to specify an RGB color.

Remarks - When specifying an explicit RGB color, the COLORREF value has the following hexadecimal form: 0x00bbggrr

The low-order byte contains a value for the relative intensity of red; the second byte contains a value for green; and the third byte contains a value for blue. The high-order byte must be zero. The maximum value for a single byte is 0xFF.

See Also - GetBValue, GetGValue, GetRValue, RGB

Also there is some info for the RGB macro as follows:

COLORREF RGB(

BYTE bRed, // red component of color
BYTE bGreen, // green component of color
BYTE bBlue // blue component of color


Parameters -

cRed - Specifies the intensity of the red color.
cGreen - Specifies the intensity of the green color.
cBlue - Specifies the intensity of the blue color.


Return Values

The return value is the resultant RGB color.

Remarks - The intensity for each argument is in the range 0 through 255. If all three intensities are zero, the result is black. If all three intensities are 255, the result is white.

For information about using color values in a color palette, see the descriptions of the PALETTEINDEX and PALETTERGB macros.
The RGB macro is defined as follows:

#define RGB(r, g ,b)
((DWORD) (((BYTE) (r) | \
((WORD) (g) << ) | \
(((DWORD) (BYTE) (b)) << 16)))


See Also - PALETTEINDEX, PALETTERGB

The RGB macro selects a red, green, blue (RGB) color based on the arguments supplied and the color capabilities of the output device.

------------------------------------------------------------------------------

My personal experience with GetPixelColor specifically and pixels in general is that you have to be very careful to make sure the order of the values are RGB. Sometimes they are BGR.

Also, BMP files are stored in "reverse" order. Meaning the bottom row is stored before the top row and the order of the pixels is right to left - not the left to right you might expect.

So, the 32 byte RGB value contains a zero byte before the three bytes representing RGB as you can see above.

But, it's important to know the number of bits per pixel (color depth) - typical values are 1, 4, 8, 16, 24 and 32.

If you are dealing with BMP files, they are very tricky. The one thing that caused me the most difficulty was that every row of a BMP image must end on a fullword boundary.

So if you have 177 pixels per row and each pixel requires 3 bytes to store the color, you will need a minimum of 177*3 bytes to store the row. That is 531 bytes. But that is not a fullord word boundary. So you wil find a single byte containing $00 at the end of each row so that it will end on a fullword boundary. This was so difficult for me because each pixel was represented by three bytes, but the row was "padded" with a one byte value and not a three-byte value.

Dealing with pixels is not terribly difficult. But it requires a lot of attention to detail because there are some very strange anomolies involved.

.

Thank you so much this works and its simple. I don't quite understand how to setformat but by adding +0 to tthe result it is the same i guess?

Hell, that's a realy cool AHK related subject line. Let's check what Google is telling us about it: [...]