guint , unsigned long, unsigned char

Version imprimable

14/08/2007, 01h48
Valkirion

guint , unsigned long, unsigned char

Bonjour ^ ^

je me pose quelque petites questions la ;)

Ques que le type guint( y a les 8 16 et 32 ??? je trouve pas de definition précise sur le net la dessus ( ca vient juste de gtkmm ou bien c'est utiliser ailleur aussi?)

Dans mon programme, j'ai un unsigned char, qui est casté par un programme en unsigned long, que je récupere. Or pour le passer dans le traitement gtkmm, j'ai besoin de lui faire un cast (guint8) . La question est de savoir si ce que je récupere a subie une perte sur ses données ou pas ???

Car j'ai normalement une image couleur, mais suite a ce cast, ben elle est plus coloré mais toute noire et blanche.

http://www.gtkmm.org/docs/gtkmm-2.4/...c4abe9c294d341

et sur la page de gtkmm il y a ca qui me stress un coup ;)

Currently only RGB images with 8 bits per sample are supported.

Merci ^^
14/08/2007, 08h59
Laurent Gomila

Citation:

Ques que le type guint( y a les 8 16 et 32 ??? je trouve pas de definition précise sur le net la dessus ( ca vient juste de gtkmm ou bien c'est utiliser ailleur aussi?)

Vu le nom je pense que ce sont des types spécifiques à GTK.

Citation:

Dans mon programme, j'ai un unsigned char, qui est casté par un programme en unsigned long, que je récupere. Or pour le passer dans le traitement gtkmm, j'ai besoin de lui faire un cast (guint8) . La question est de savoir si ce que je récupere a subie une perte sur ses données ou pas ???

Si ton nombre tient dans l'intervalle d'un guint8, alors aucune raison que tu perdes quoique ce soit. Et comme au départ il vient d'un unsigned char, ça a toutes les chances d'être bon.

Citation:

Car j'ai normalement une image couleur, mais suite a ce cast, ben elle est plus coloré mais toute noire et blanche.

T'es sûr que ton unsigned long ne contient pas les 3 composantes RGB plutôt qu'une seule ?
16/08/2007, 14h59
Valkirion

Pour le dernier point, oui, en fait, dans le unsigned long, on a R G B X un pour chaque octet, mais je vois pas trop comment les récuperer apres pour les mixé dans un pixel

Code:

1
2
3
4
guint32 Pixel = ...;
guint8 R = (Pixel & 0xFF000000) >> 24;
guint8 G = (Pixel & 0x00FF0000) >> 16;
guint8 B = (Pixel & 0x0000FF00) >> 8;

17/08/2007, 02h18
nicroman
Attention... ça c'est du xBGR sous Intel :) j
Si l'image est en RGBx ... R est l'octet de poids faible sous Intel.
Code:

1 2 3 4 5 guint32 Pixel = ...; guint8 R = (Pixel & 0x000000FF) ; guint8 G = (Pixel & 0x0000FF00) >> 8; guint8 B = (Pixel & 0x00FF0000) >> 16;
Mais bon... ca métonnerai que gtkmm n'ai pas les fonctions pour extraire les composantes.
17/08/2007, 08h31
Laurent Gomila
J'utilise les opérateurs & et >> justement pour m'abstraire de l'endianess de la machine. Un code qui ne le ferait pas serait par exemple celui-ci :
Code:

1 2 3 4 5 6 // A NE PAS FAIRE, CODE NON PORTABLE guint32 Pixel; guint8* Components = reinterpret_cast<guint8*>(&Pixel); guint8 R = Components[0]; guint8 G = Components[1]; guint8 B = Components[2];
17/08/2007, 16h28
Valkirion

oki merci ;)
19/08/2007, 01h25
nicroman
Citation:

Envoyé par Laurent Gomila

J'utilise les opérateurs & et >> justement pour m'abstraire de l'endianess de la machine.

Heu... ben non...
Prenons notre exemple du RGBA (ce qui n'est pas souvent le cas sous windows)... RGBA ca veut dire que les octets sont en mémoire sous la forme RR GG BB AA ...

Selon qu'on soit sur une machine Little-Endian ou Big-Endian, le rouge et ou le poids fort du mot long, ou le poids faible...

Sous Intel...
Code:

1 2 3 4 5 guint32 Pixel = ...; guint8 R = (Pixel & 0xFF000000) >> 24; guint8 G = (Pixel & 0x00FF0000) >> 16; guint8 B = (Pixel & 0x0000FF00) >> 8;
Veut dire que le rouge est 'presque' le poids fort, donc "à droite":
BB GG RR AA

Soit.... BGRA (ce qui est la 'norme' sous Windows il faut bien l'avouer).
19/08/2007, 10h25
Sylvain Togni
Hé... ben si... ;)

Ici on parle d'un pixel codé par un guint32 sous la forme 0xRRGGBBAA (quel que soit l'endianess de la machine) et le code donné par Laurent est tout à fait portable.

Ça aurait été différent si la valeur du guint32 avait été obtenu par quelque chose comme ça
Code:

1 2 guint8* pixels = ...; guint32 pixel = *reinterpret_cast<guint32*>(pixels);
qui n'est pas une bonne façon de faire, le reinterpret_cast indique bien un problème potentiel de portabilité.

La meilleure façon de procéder avec l'endianess, c'est de s'en abstraire.
19/08/2007, 10h37
Laurent Gomila

Les opérations bit à bit sont consistantes quelque soit la machine et son endianess. Sinon cela signifierait par exemple qu'un >> 2 pourrrait être une multiplication par deux sur certaines machines, ou encore que 0x1000 pourrait valoir 16 ;)
C'est le code compilé qui s'adapte à l'endianess pour produire le résultat escompté ; contrairement aux bidouilles du genre reinterpret_cast pour lesquelles le compilo n'a aucune idée de ce que l'on cherche à faire.
20/08/2007, 13h52
screetch

il y a de grande chances que GTK(ou GTKmm) fournisse l'abstraction necessaire pour cela.

A noter que si ca vien d'une image, si le type n'est pas plus precis que guint8 et guint32 il faut assumer que l'endianness est inconnue. L'endianness est connue quand on a un type ColorRGBA ou ColorBGRA.

l'image doit bien venir du disque donc avant de s'abstraire de l'endianness il faut la verifier, GTK a du s'en charger mais verifie si tu ne peux pas obtenir plus precis. Verifie la doc quoi.