1

I want to look at and store in an array the RGB data of each pixel in a 100 X 100 square of my screen. I got this concept working using GetPixel() in a for loop, and then converting the output to hexadecimal and storing the RGB data in an array, but this method takes much longer than I'd like. What is the fastest way of reading pixel RGB data with c++?

NO_GUI
  • 444
  • 8
  • 12
  • 1
    I'll guess `GetPixel()` is from the windows API, painfully slow. You may want to look into `boost::gil`. – lakeweb Feb 06 '20 at 00:34
  • Yes, I'm using GetPixel() from the windows API and I have heard it's slow :D – NO_GUI Feb 06 '20 at 00:39
  • I'll look at boost::gil Thanks for the tip! – NO_GUI Feb 06 '20 at 00:40
  • I'm referring to the first plain GetPixel function. – NO_GUI Feb 06 '20 at 00:52
  • 3
    You might be able to do something with `BitBlt` to copy the whole square into RAM then access it directly. – 1201ProgramAlarm Feb 06 '20 at 01:06
  • 1
    [BitBlt](https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-bitblt) and [GetDIBits](https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getdibits) are two good choices. Also look [here](https://stackoverflow.com/a/2978927/3135317) and [here](https://www.codeproject.com/Articles/5051/Various-methods-for-capturing-the-screen) – FoggyDay Feb 06 '20 at 01:47
  • Does this answer your question? [How to read the screen pixels?](https://stackoverflow.com/questions/2659932/how-to-read-the-screen-pixels) – Thomas Dickey Feb 07 '20 at 01:45
  • It kind of does, but I wanted to know if that was the fastest way or if there was a better way, like reading the frame buffer for instance. – NO_GUI Feb 07 '20 at 01:48
  • GetPixel() and SetPixel() are absolutely forbidden for more than one single pixel (or maybe two...) if you care for performance. Each pixel access has to consider so many side aspects (clipping, coordinate mapping, ...), so it cannot be fast. The fastest way (as long as you remain in the Windows API) are the mentioned GetDIBits(), SetDIBits() and BitBlt(). – Nick Feb 07 '20 at 16:00
  • Cool I'll look into those functions. – NO_GUI Feb 08 '20 at 01:32

1 Answers1

7

Yes, GetPixel and SetPixel are relatively slow API calls. Manipulating individual pixels requires copying the contents of the DC (Device Context) into a temporary bitmap, mapping and locating the pixel, retrieving (or setting) its color value, and then (if the pixel's color is being set) blitting the temporary bitmap back to the device context. Once you understand all the work that is going on behind the scenes for such an apparently simple operation, you can see why it is slow. Worse, the overhead must be paid for each call to GetPixel and/or SetPixel, so you can see why these are not commonly used for painting operations.

The replacement approach involves the use of GetDIBits, which is the fastest possible way of determining the values of multiple pixels. This function essentially copies the contents of the device context (DC) into a temporary device-independent bitmap (DIB), which you can then view or manipulate as desired. Determining the color value of an individual pixel becomes as simple as indexing into that pixel's location in memory. With this approach, you can literally process millions of pixels per second. The overhead of retrieving the pixel color values is paid only once, at the very beginning.

To simulate SetPixel, you'd manipulate the desired pixel values, then call SetDIBits to update the device context (e.g., the screen).

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574