GLREADPIXELS(3G)

📦
version 1.1 · 7 versions
, in centos-stream 9

🎀 GLREADPIXELS(3G) 🎀

okay so bestie, welcome to the GLREADPIXELS(3G) manual page — we're reading pixels out of the frame buffer and honestly it's giving main character energy ✨

💖 NAME 💖

glReadPixels, glReadnPixels — read a block of pixels from the frame buffer 🫶

💅 C SPECIFICATION 💅

okay so here's the exact function drip, no cap:

void glReadPixels(GLint x, GLint y, GLsizei width, GLsizei height,
                  GLenum format, GLenum type, GLvoid * data);

void glReadnPixels(GLint x, GLint y, GLsizei width, GLsizei height,
                   GLenum format, GLenum type, GLsizei bufSize,
                   void *data);

🌸 PARAMETERS 🌸

  • x, y — these specify the window coordinates of the first pixel that is read from the frame buffer. This location is the lower left corner of a rectangular block of pixels. 🦋
  • width, height — these specify the dimensions of the pixel rectangle. width and height of one correspond to a single pixel. literally one pixel, bestie 💅
  • format — specifies the format of the pixel data. The following symbolic values are accepted: GL_STENCIL_INDEX, GL_DEPTH_COMPONENT, GL_DEPTH_STENCIL, GL_RED, GL_GREEN, GL_BLUE, GL_RGB, GL_BGR, GL_RGBA, and GL_BGRA. 🌈
  • type — specifies the data type of the pixel data. Must be one of GL_UNSIGNED_BYTE, GL_BYTE, GL_UNSIGNED_SHORT, GL_SHORT, GL_UNSIGNED_INT, GL_INT, GL_HALF_FLOAT, GL_FLOAT, GL_UNSIGNED_BYTE_3_3_2, GL_UNSIGNED_BYTE_2_3_3_REV, GL_UNSIGNED_SHORT_5_6_5, GL_UNSIGNED_SHORT_5_6_5_REV, GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_4_4_4_4_REV, GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_1_5_5_5_REV, GL_UNSIGNED_INT_8_8_8_8, GL_UNSIGNED_INT_8_8_8_8_REV, GL_UNSIGNED_INT_10_10_10_2, GL_UNSIGNED_INT_2_10_10_10_REV, GL_UNSIGNED_INT_24_8, GL_UNSIGNED_INT_10F_11F_11F_REV, GL_UNSIGNED_INT_5_9_9_9_REV, or GL_FLOAT_32_UNSIGNED_INT_24_8_REV. 🔥
  • bufSize — specifies the size of the buffer data for glReadnPixels function. 👑
  • data — returns the pixel data. periodt 💖

✨ DESCRIPTION ✨

glReadPixels and glReadnPixels return pixel data from the frame buffer, starting with the pixel whose lower left corner is at location (x, y), into client memory starting at location data. 🫶

Several parameters control the processing of the pixel data before it is placed into client memory. These parameters are set with glPixelStore(). This reference page describes the effects on glReadPixels and glReadnPixels of most, but not all of the parameters specified by these three commands. 👀

If a non-zero named buffer object is bound to the GL_PIXEL_PACK_BUFFER target (see glBindBuffer()) while a block of pixels is requested, data is treated as a byte offset into the buffer object's data store rather than a pointer to client memory. no cap, that's the vibe 💅

glReadPixels and glReadnPixels return values from each pixel with lower left corner at x + i, y + j for 0 <= i < width and 0 <= j < height. This pixel is said to be the ith pixel in the jth row. Pixels are returned in row order from the lowest to the highest row, left to right in each row. 🌸

format specifies the format for the returned pixel values; accepted values are:

🌟 GL_STENCIL_INDEX 🌟

Stencil values are read from the stencil buffer.

🌟 GL_DEPTH_COMPONENT 🌟

Depth values are read from the depth buffer. Each component is converted to floating point such that the minimum depth value maps to 0 and the maximum value maps to 1. Each component is clamped to the range 0 to 1.

🌟 GL_DEPTH_STENCIL 🌟

Values are taken from both the depth and stencil buffers. The type parameter must be GL_UNSIGNED_INT_24_8 or GL_FLOAT_32_UNSIGNED_INT_24_8_REV.

🌟 GL_RED, GL_GREEN, GL_BLUE, GL_RGB, GL_BGR, GL_RGBA, GL_BGRA 🌟

Color values are taken from the color buffer.

Finally, the indices or components are converted to the proper format, as specified by type. If format is GL_STENCIL_INDEX and type is not GL_FLOAT, each index is masked with the mask value given in the following table. If type is GL_FLOAT, then each integer index is converted to single-precision floating-point format. 🧚

If format is GL_RED, GL_GREEN, GL_BLUE, GL_RGB, GL_BGR, GL_RGBA, or GL_BGRA and type is not GL_FLOAT, each component is multiplied by the multiplier shown in the following table. If type is GL_FLOAT, then each component is passed as is (or converted to the client's single-precision floating-point format if it is different from the one used by the GL). 💜

Okay so this next bit is literally just a glow-up chart, bestie — it tells you, for every type you're allowed to hand over, what the index mask is and how the component values get converted. Read it like a little lookbook: left column is the type, middle is the mask, right is the conversion. 💅

  • GL_UNSIGNED_BYTE — index mask 2^8 - 1, component conversion (2^8 - 1)c
  • GL_BYTE — index mask 2^7 - 1, component conversion [(2^8 - 1)c - 1] / 2
  • GL_UNSIGNED_SHORT — index mask 2^16 - 1, component conversion (2^16 - 1)c
  • GL_SHORT — index mask 2^15 - 1, component conversion [(2^16 - 1)c - 1] / 2
  • GL_UNSIGNED_INT — index mask 2^32 - 1, component conversion (2^32 - 1)c
  • GL_INT — index mask 2^31 - 1, component conversion [(2^32 - 1)c - 1] / 2

And yes, that lil c in every conversion is just the component value doing its main character thing — it's not a mystery variable, it's the value, no cap. 🫶

So like, signed types get that - 1 ÷ 2 treatment so they land in the right spot, and unsigned types get the clean straight-up multiply. Notice how the mask for the signed version is one bit smaller (2^7 - 1 vs 2^8 - 1, 2^15 - 1 vs 2^16 - 1, 2^31 - 1 vs 2^32 - 1) but the conversion still uses the unsigned-style 2^8, 2^16, 2^32 scale. That's not a typo, that's just the vibe of the table — literally copy it exactly. ✨

Read the rows, don't vibe-guess the numbers. Half of y'all are gonna squint at 2^31 - 1 and quietly type 2^32 - 1 and then wonder why your pixels are cursed. 😭 Not on my watch.

those stray little c, -, 1 bits at the very top are just the tail end of the cell that got chopped in half by the page break — they're the last crumbs of a 2^N - 1 and a c, nothing new, okurrr 🫶

and then the table picks right back up. the terminal squished it into vertical confetti (classic), so here's how to read each line: type first, then the middle column, then the right-hand column, left to right, exactly as printed. middle column is either none or 2^N - 1. right-hand column is either just c, or 2^N - 1 with a c chillin' underneath it ✨

  • GL_HALF_FLOAT — none · c
  • GL_FLOAT — none · c
  • GL_UNSIGNED_BYTE_3_3_2 — 2^N - 1 · 2^N - 1 and c
  • GL_UNSIGNED_BYTE_2_3_3_REV — 2^N - 1 · 2^N - 1 and c
  • GL_UNSIGNED_SHORT_5_6_5 — 2^N - 1 · 2^N - 1 and c
  • GL_UNSIGNED_SHORT_5_6_5_REV — 2^N - 1 · 2^N - 1 and c
  • GL_UNSIGNED_SHORT_4_4_4_4 — 2^N - 1 · 2^N - 1 and c
  • GL_UNSIGNED_SHORT_4_4_4_4_REV — 2^N - 1 · 2^N - 1 and c

so the two float-y icon types are out here living their truth with none in the middle column, and every packed type is giving 2^N - 1 realness in both columns, with that little c tagging along on the right 💅 the list keeps going btw, we're not done, stay with me 🔥

…okay so the table is like not done yet, bestie 😭 it just keeps going, same vibe every row. Here's the rest of it, and every one of these types comes with size 2, and the two right-hand cells both stack up as 2 / N / - / 1 (the N floating up above the -1), with that last cell wearing a little c tag 💅

  • GL_UNSIGNED_SHORT_5_5_5_1 — size 2; the two component cells both read 2/N/-/1, and the last one is tagged c 🎀
  • GL_UNSIGNED_SHORT_1_5_5_5_REV — size 2; same deal, both component cells read 2/N/-/1, last cell tagged c ✨
  • GL_UNSIGNED_INT_8_8_8_8 — size 2; again 2/N/-/1 in both cells, c on the end 🌸
  • GL_UNSIGNED_INT_8_8_8_8_REV — size 2; 2/N/-/1 twice over, and yep, c 🦋
  • GL_UNSIGNED_INT_10_10_10_2 — size 2; 2/N/-/1, 2/N/-/1, plus that little c 🍓
  • GL_UNSIGNED_INT_2_10_10_10_REV — size 2; both cells 2/N/-/1, c tagging along 💜
  • GL_UNSIGNED_INT_24_8 — size 2; same pattern one more time — 2/N/-/1 in both component cells, c on the right 💖

So if you clocked the pattern: every single one of these rows is rocking the exact same structure, no cap 👑

Rather than making you eyeball that ASCII soup, here's the same seven rows written out the chill way — type, size, and the two stacked cells, with the c marker noted:

GL_UNSIGNED_SHORT_5_5_5_1          2   2 N - 1   2 N - 1   c
GL_UNSIGNED_SHORT_1_5_5_5_REV      2   2 N - 1   2 N - 1   c
GL_UNSIGNED_INT_8_8_8_8            2   2 N - 1   2 N - 1   c
GL_UNSIGNED_INT_8_8_8_8_REV        2   2 N - 1   2 N - 1   c
GL_UNSIGNED_INT_10_10_10_2         2   2 N - 1   2 N - 1   c
GL_UNSIGNED_INT_2_10_10_10_REV     2   2 N - 1   2 N - 1   c
GL_UNSIGNED_INT_24_8               2   2 N - 1   2 N - 1   c
Heads up bestie: those 2 / N / - / 1 bits are stacked vertically in the original because it's a typeset table — the N rides up high and the -1 sits low, so read them together when you're matching your type against the spec 📖 The letters and numbers themselves are exactly as printed, zero edits, iykyk.

And like — that's the run of the table for this chunk. There's still more page to get through, so don't run off yet, we're not even at the good part 🌈

okay so the table has just these last three rows left, bestie — no cap, we’re almost through the pixel-layout tea:

  • GL_UNSIGNED_INT_10F_11F_11F_REV / -- / Special
  • GL_UNSIGNED_INT_5_9_9_9_REV / -- / Special
  • GL_FLOAT_32_UNSIGNED_INT_24_8_REV / none / c (Depth Only)

Return values get placed in memory like this. If format is GL_STENCIL_INDEX, GL_DEPTH_COMPONENT, GL_RED, GL_GREEN, or GL_BLUE, a single value is returned and the data for the ith pixel in the jth row is placed in location j ⁢ width + i. GL_RGB and GL_BGR return three values, GL_RGBA and GL_BGRA return four values for each pixel, with all values corresponding to a single pixel occupying contiguous space in data. Storage parameters set by glPixelStore(), such as GL_PACK_LSB_FIRST and GL_PACK_SWAP_BYTES, affect the way that data is written into memory. See glPixelStore() for a description.

glReadnPixels function will only handle the call if bufSize is at least of the size required to store the requested data. Otherwise, it will generate a GL_INVALID_OPERATION error.

🫧 NOTES

  • Values for pixels that lie outside the window connected to the current GL context are undefined.
  • If an error is generated, no change is made to the contents of data.

💀 ERRORS

  • GL_INVALID_ENUM — generated if format or type is not an accepted value.
  • GL_INVALID_VALUE — generated if either width or height is negative.
  • GL_INVALID_OPERATION — generated if format is GL_STENCIL_INDEX and there is no stencil buffer.
  • GL_INVALID_OPERATION — generated if format is GL_DEPTH_COMPONENT and there is no depth buffer.
  • GL_INVALID_OPERATION — generated if format is GL_DEPTH_STENCIL and there is no depth buffer or if there is no stencil buffer.
  • GL_INVALID_ENUM — generated if format is GL_DEPTH_STENCIL and type is not GL_UNSIGNED_INT_24_8 or GL_FLOAT_32_UNSIGNED_INT_24_8_REV.
  • GL_INVALID_OPERATION — generated if type is one of GL_UNSIGNED_BYTE_3_3_2, GL_UNSIGNED_BYTE_2_3_3_REV, GL_UNSIGNED_SHORT_5_6_5, or GL_UNSIGNED_SHORT_5_6_5_REV and format is not GL_RGB.
  • GL_INVALID_OPERATION — generated if type is one of GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_4_4_4_4_REV, GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_1_5_5_5_REV, GL_UNSIGNED_INT_8_8_8_8, GL_UNSIGNED_INT_8_8_8_8_REV, GL_UNSIGNED_INT_10_10_10_2, or GL_UNSIGNED_INT_2_10_10_10_REV and format is neither GL_RGBA nor GL_BGRA.
  • GL_INVALID_OPERATION — generated if a non-zero buffer object name is bound to the GL_PIXEL_PACK_BUFFER target and the buffer object’s data store is currently mapped.
  • GL_INVALID_OPERATION — generated if a non-zero buffer object name is bound to the GL_PIXEL_PACK_BUFFER target and the data would be packed to the buffer object such that the memory writes required would exceed the data store size.
  • GL_INVALID_OPERATION — generated if a non-zero buffer object name is bound to the GL_PIXEL_PACK_BUFFER target and data is not evenly divisible into the number of bytes needed to store in memory a datum indicated by type.
  • GL_INVALID_OPERATION — generated if GL_READ_FRAMEBUFFER_BINDING is non-zero, the read framebuffer is complete, and the value of GL_SAMPLE_BUFFERS for the read framebuffer is greater than zero.
  • GL_INVALID_OPERATION — generated by glReadnPixels if the buffer size required to store the requested data is greater than bufSize.

🔎 ASSOCIATED GETS

glGet() with argument GL_PIXEL_PACK_BUFFER_BINDING.

🌈 VERSION SUPPORT

The table headers are Function / Feature Name and OpenGL Version, with version columns 2.0, 2.1, 3.0, 3.1, 3.2, 3.3, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5.

  • glReadPixels — 2.0: ✔; 2.1: ✔; 3.0: ✔; 3.1: ✔; 3.2: ✔; 3.3: ✔; 4.0: ✔; 4.1: ✔; 4.2: ✔; 4.3: ✔; 4.4: ✔; 4.5: ✔.
  • glReadnPixels — 2.0: -; 2.1: -; 3.0: -; 3.1: -; 3.2: -; 3.3: -; 4.0: -; 4.1: -; 4.2: -; 4.3: -; 4.4: -; 4.5: ✔.

🎀 SEE ALSO

glPixelStore(), glReadBuffer().

Copyright © 1991-2006 Silicon Graphics, Inc. Copyright © 2010-2014 Khronos Group. This document is licensed under the SGI Free Software B License. For details, see http://oss.sgi.com/projects/FreeB/.

Copyright © 1991-2006 Silicon Graphics, Inc. Copyright © 2010-2014 Khronos Group

And that’s the footer, bestie: source/version tag [FIXME: source], date 08/09/2021, page GLREADPIXELS(3G) — iconic. 🎀✨

📦 where this page comes from