glReadPixels(...) appears to output only red, white, and black

rbrauer

glReadPixels(...) appears to output only red, white, and black

in Contributed Library Questions • 1 year ago

I'm trying to get raw pixel data in a ByteBuffer with glReadPixels(...).

gl.glReadPixels(
0, 0, width, height,
GL.GL_RGBA, GL.GL_UNSIGNED_BYTE, bb);

When I later try to construct an image from the bytes,

bb.asIntBuffer().get(pi.pixels);
PGL.nativeToJavaARGB(pi.pixels, 1280, 720);

I get only red, white, and black. Greens and blues appear black. Anyone know what I'm doing wrong here?

Replies(5)

andres

Re: glReadPixels(...) appears to output only red, white, and black

1 year ago

I tried the following code in my computer:

import javax.media.opengl.GL;
import java.nio.IntBuffer;
void setup() {
size(300, 100, P2D);
noStroke();
loadPixels();
}
void draw() {
fill(255, 0, 0);
rect(0, 0, 100, 100);
fill(0, 255, 0);
rect(100, 0, 100, 100);
fill(0, 0, 255);
rect(200, 0, 100, 100);
flush(); // Need flush to actually send the geometry to the video card.
PGraphicsOpenGL pg = (PGraphicsOpenGL)g;
GL gl = pg.beginPGL().gl;
IntBuffer buffer = IntBuffer.allocate(width * height);
buffer.rewind();
gl.getGL2().glReadBuffer(GL.GL_BACK);
gl.glReadPixels(0, 0, width, height, GL.GL_RGBA, GL.GL_UNSIGNED_BYTE, buffer);
buffer.get(pixels);
pg.endPGL();
background(0);
PGL.nativeToJavaARGB(pixels, width, height);
updatePixels();
}

and it appears to work as expected by showing red, green and blue rectangles. Note the call to flush() right after drawing the geometry we want in the buffer, this is required because otherwise the data is not sent to the video card.

Let me know if this works work you. Maybe there is another error in your code.

rbrauer

Re: glReadPixels(...) appears to output only red, white, and black

1 year ago

Thanks for the quick reply Andres. I really appreciate your forum presence. I can recreate the problem using your example code by changing your IntBuffer to a ByteBuffer and using asIntBuffer().get(...) as above to load the bytes as ints into the pixel array. Also, I use allocateDirect(...) to get my buffers although I didn't change that in your example when recreating the problem. There are no errors, but maybe this is incorrect usage. I'm using bytes because I am writing to and reading from a FileChannel.

Edit: Looks like I solved this with buffer.order(ByteOrder.nativeOrder()) in the example code. Still tinkering with my code. Yeah just had to add that to both ends of my code. I might have some nice new capture code to share pretty soon.

rbrauer

Re: glReadPixels(...) appears to output only red, white, and black

1 year ago

Actually the alpha is still screwed up. Semitransparent blues and greens appear as if they are on a black background. It is easy to notice if you draw a semitransparent blue shape on a blue background. The shape will be invisible in Processing's output, but darker when read back in to an image. I see the source of nativeToJavaARGB(...) says it leaves the alpha alone. I guess I'll see if I can modify it for my purposes.

Edit: Reversing the alpha byte seems to have fixed it until I run into something else. I used this . So now I'm using the byte order thing as well as nativeToJavaARGB(...) and reversing the alpha byte like so:

for(int a=0; a<pi.pixels.length; a++) {
    int orig = pi.pixels[a];
    int aa = (orig>>24)&0xff;
    int rest = orig & 0x00ffffff;
    int rev = 0;
    while(aa!=0) {
      rev<<=1;
      rev|=(aa&1);
      aa>>=1;
    }
    pi.pixels[a] = (rev<<24) | rest;
}

Actually it still doesn't work right. I should really look more closely before I declare it working or not. Very confusing.

andres

Re: glReadPixels(...) appears to output only red, white, and black

1 year ago

Hi, first just one clarification about the nativeToJavaARGB() method because I don't think the documentation of it was very clear: it does copy the alpha component from the native input pixel values to the ARGB output, while nativeToJavaRGB() sets the alpha of the output to 255.

The nativeToJavaARGB() function has an corresponding version that operates on a single input color, and I just added the equivalent nativeToJavaRGB(int color) to the PGL class, so the following code won't run on 2.0a6 (it will in the next release):

size(100, 100, P2D);
int natColor;
if (PGL.BIG_ENDIAN) {
// Native is R G B A
natColor = 0x01020304;
} else {
// Native is A B G R
natColor = 0x04030201;
}
int argb = PGL.nativeToJavaARGB(natColor);
int rgb = PGL.nativeToJavaRGB(natColor);
println(red(argb) + " " + green(argb) + " " + blue(argb) + " " + alpha(argb));
println(red(rgb) + " " + green(rgb) + " " + blue(rgb) + " " + alpha(rgb));

but the output should be:

1.0 2.0 3.0 4.0

1.0 2.0 3.0 255.0

Going back to the background issues. I think these are the result of just how OpenGL works. Take a look at this updated version of the test sketch I posted earlier:

import javax.media.opengl.GL;
import java.nio.ByteOrder;
import java.nio.ByteBuffer;
import java.nio.IntBuffer;
int alphaValue = 100;
boolean copyAlpha = true;
int SIZEOF_INT = Integer.SIZE / 8;
IntBuffer buffer;
void setup() {
size(300, 100, P2D);
noStroke();
loadPixels();
//buffer = IntBuffer.allocate(width * height);
buffer = ByteBuffer.allocateDirect(width * height * SIZEOF_INT).order(ByteOrder.nativeOrder()).asIntBuffer();
}
void draw() {
background(255, 0);
fill(255, 0, 0, alphaValue);
rect(0, 0, 100, 100);
fill(0, 255, 0, alphaValue);
rect(100, 0, 100, 100);
fill(0, 0, 255, alphaValue);
rect(200, 0, 100, 100);
flush(); // Need flush to actually send the geometry to the video card.
PGraphicsOpenGL pg = (PGraphicsOpenGL)g;
GL gl = pg.beginPGL().gl;
buffer.rewind();
gl.getGL2().glReadBuffer(GL.GL_BACK);
gl.glReadPixels(0, 0, width, height, GL.GL_RGBA, GL.GL_UNSIGNED_BYTE, buffer);
buffer.get(pixels);
pg.endPGL();
background(100, 100, 255);
if (copyAlpha) {
PGL.nativeToJavaARGB(pixels, width, height);
} else {
PGL.nativeToJavaRGB(pixels, width, height);
}
updatePixels();
}

where now I'm using a direct ByteBuffer (note how the proper native order is set). Anyways, if you set the fill color to be semitransparent (alphaValue = 100), you can actually see the underlying color (100, 100, 255) from the last fill. But this is only because copyAlpha = true so that the pixels retain the alpha value from previous drawing on the screen. If you change copyAlpha to false, then nativeToJavaRGB is used instead and the alpha of all the pixels gets set to 255. Does this make sense?

rbrauer

Re: glReadPixels(...) appears to output only red, white, and black

1 year ago

Thanks a lot, that makes perfect sense. I feel stupid now. I overlooked the fact that there are RGB and ARGB versions of that conversion method. I'll have a couple more questions for you when I post this capture code after I finish tweaking and cleaning it up.

Top Reply