algo de conversion d image 16 bits en 24 bits - Algo - Programmation
Marsh Posté le 20-05-2003 à 09:15:57
Code :
|
sous entendant que ton 16bits c'est du R5G6B5
va falloir que tu te penches sur le format d'encodage des couleurs et la manipulations de bits
le resultat est ici 32bits mais bon, 24 ou 32, c kif kif, l'algo change pas, juste balance ton resultat dans une structure de 24 bits ou un tableau de char au lieu de mon unsigned int final
Marsh Posté le 20-05-2003 à 09:26:35
merci bien, c effectivement du 565 (le plus classique) et je stocke ca dans un tableau de char.
Marsh Posté le 20-05-2003 à 09:55:50
hum, ca fonctionne mais mon cyan apparait jaune ... je crois que l algo inverse que j ai est faux :
(r,g,b)->(byte1,byte2) "/" -> c est le OU logique car chui sur un mac et c la merde je trouve pas la barre verticale
Code :
|
me suis je trompé ou c bon?
Marsh Posté le 20-05-2003 à 10:02:30
xilebo a écrit : hum, ca fonctionne mais mon cyan apparait jaune ... je crois que l algo inverse que j ai est faux :
|
heuh c quoi cette histoire de | qui existe pas ?
tu veux convertir de 24 a 16 ?
Code :
|
Marsh Posté le 20-05-2003 à 10:49:16
c pas qu il existe pas ... c que je le trouve pas sur l imac :-/
ok remerci a nouveau pour ton algo je vais essayer de ce pas.
Marsh Posté le 20-05-2003 à 12:25:32
Algo rapide, mais qui perd pas mal d'infos : le blanc devient du gris clair .. Heureusement que le format n'est pas du 4444 parce que sinon, ca se sentirait bien, comme diff ...
L'avantage, c'est qu'il est rapide ...
Pour ce qui est de la présentation de l'algo, je préfère cette méthode :
Code :
|
Marsh Posté le 20-05-2003 à 12:38:06
theShOcKwAvE a écrit :
|
repiquer betement les entetes de fonction de ses petits camarades sans prendre le tps de les adapter, c'est mal
Marsh Posté le 22-05-2003 à 13:41:00
chrisbk a écrit : |
Code :
|
Si tu préfères ... L'avantage, c'est que ca restait transparent pour l'utilisateur de la fct ... (utilité assez réduite, je l'accorde, mais ca évite de caster à chaque appel si il n'utilise pas des images faites à base de SPixel565, ce qui ne m'étonnerait guère ... )
Edit : Je précis que dans mon post précédent, je voulais surtout mettre l'accent sur la perte de précision : pour chaque couleur, 0 devient 0, ... normal, quoi, mais 11111 deviendra 11111000(0xF8) au lieu de 11111111 (0xFF) pour le R et le B (un peu mieux pour le G, mais c'est pas encore le top) Donc si vous trouvez une solution performante pour éviter ce problème, je suis intéressé
Marsh Posté le 22-05-2003 à 13:47:03
tiens oui j'avais jamais fait gaffe a ca
aucune idee la pour le moment, je me console juste en me disant que les conversion 16->24 on en fait pas ts les jours
Marsh Posté le 22-05-2003 à 15:07:31
Et comme ca :
Code :
|
Marsh Posté le 22-05-2003 à 16:58:33
Kristoph a écrit : Et comme ca :
|
ouais, effectivement, ca me plait déjà un peu plus ... Je note !
Edit, c'est vrai qu'utiliser les bits de poids fort pour remplir les bits de poids faible, c'est carrément cohérent quand on y réfléchit un peu ....
Marsh Posté le 22-05-2003 à 17:16:03
J'ai aussi la justification du pourquoi ca marche. La voici avec le rouge :
On veut mapper avec une fonction lineaire l'intervale 0..31 vers 0.255
Il nous faut donc f(x) = x * 255 / 31
255 / 31 = 8.2258...
Moi mon calcul fait g(x) = x * 8 + x / 4 = x * (8.25)
Pour le cas du vert, on a : 0..63 vers 0..255 soit un coefficient de 4.047 Et j'utilise 4 + 1/16 soit 4.0675
CQFD
Marsh Posté le 20-05-2003 à 09:13:20
salut,
j ai une image en 16 bits de taille 2*largeur*hauteur, je voudrais la convertir en 24 bits mais je ne trouve pas la formule , quelqu un la connait ? (cherché sur google mais rien du tout)
merci