couleur picking sur android - glReadPixels erreurs d'arrondi

Question

J'utilise la couleur picking dans opengl es sur Android et je calcule une clé de couleur pour le comparer aux valeurs que je reçois de 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]; 

Cette clé peut être calculé manuellement pour chaque couleur:

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

d'abord la valeur en virgule flottante est converti en un intvalue puis castet à octet. Les valeurs float décrivent les colorchanels rouge vert bleu (de 0.0f à 1.0f). Exemple: 0.0f est converti en 255 (maintenant entier) puis de 255 à -1 en octet

Cela fonctionne bien mais opengl semble parfois faire des erreurs d'arrondi. Exemple:

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 

peut-être que ma méthode de calcul n'est pas correcte? Est-ce que quelqu'un a une idée comment éviter ces déviations?

Answer 1

Les octets Java sont signés.

-28 = 0xe4 en octet signé = 228 décimal si vous traitez le 0xe4 comme non signé.
228/255 = 0,894 à flotteur

Answer 2

par exemple si vous définissez flotteur rouge (31/255), je pense que la transformation est comme ça.

31 (0001_1111) transforme à 3 (0000_0011) si le format de couleur est RGB565 (par défaut)

alors nous utilisons glReadPixels() pour obtenir la valeur

3 (0000_0011) transforme à 24 (0001_1000 En un mot, si vous définissez 31 pour la couleur rouge, vous obtiendrez 24 à la fin. La clé pour tuer l'erreur d'arrondi est la méthode à transformer de RGB565 en RGB88 que vous n'avez pas faite.

Vous pouvez essayer. Bonne chance.