Color picker on android rounding errors - glReadPixels

I use color matching in opengl es on android and I compute a color key to compare it with the values ​​I get from glReadPixels:

ByteBuffer PixelBuffer = ByteBuffer.allocateDirect(4); PixelBuffer.order(ByteOrder.nativeOrder()); gl.glReadPixels(x, y, 1, 1, GL10.GL_RGBA, GL10.GL_UNSIGNED_BYTE, PixelBuffer); byte b[] = new byte[4]; PixelBuffer.get(b); String key = "" + b[0] + b[1] + b[2]; 

This key can be calculated manually for any color using:

 public static byte floatToByteValue(float f) { return (byte) ((int) (f * 255f)); } 

First, the float value is converted to intvalue, and then castet to byte. Float values ​​describe the colors of red green blue (from 0.0f to 1.0f). Example: 0.0f is converted to 255 (now an integer), and then from 255 to -1 in bytes

This works fine, but opengl seems to make rounding errors several times. Example:

 0.895 -> -28 and opengl returns -27 0.897 -> -28 and opengl returns -27 0.898 -> -28 and opengl returns -27 0.8985 -> -27 and opengl returns -27 0.899 -> -27 and opengl returns -26 0.9 -> -27 and opengl returns -26 0.91 -> -24 and opengl returns -24 

Perhaps my calculation method is wrong? Does anyone have an idea how to avoid these deviations?

+4
source share
2 answers

for example, if you set a red float (31/255), I think the conversion will be like this.

31 (0001_1111) converts to 3 (0000_0011) if the color format is RGB565 (default)

then we use glReadPixels () to get the value

3 (0000_0011) is converted to 24 (0001_1000)

In short, if you set 31 for red, you get 24 at the end.

The key to killing the rounding error is the conversion method from RGB565 to RGB88, which you did not do.

You can try. Good luck.

+2
source

Java byte signed.

-28 = 0xe4 in the signed byte = 228 decimal numbers if you treat 0xe4 as unsigned.
228/255 = 0.894 in the float

+1
source

All Articles