Salut.
 
J'ai un programme qui (entre autres) convertit un flux vidéo du format RGB en format YUV 411 planar. Or j'ai un problème, en sortie la vidéo est en noir et blanc...
J'ai cherché un peu partout sur le net et les équations que j'utilise sont les suivantes :
 
Y = 0.257*R + 0.504*G + 0.098*B + 16
U = 0.439*R - 0.368*G - 0.071*B + 128
V = -0.148*R - 0.291*G + 0.439*B + 128
 
sachant que j'en ai essayé d'autres qui me donnent le même résultat. J'ai l'impression que j'ai seulement la luminance (composante Y)... Quelqu'un a-t'il déjà eu ce problème ? Si oui pourrait-il m'aider ? Merci d'avance.
 
NB : j'ai posté dans C++ car le programme est fait dans ce langage...

bah déjà vérifies que tout est flottant, car si tu stoques dans des entiers, la partie fractionnaire peut sauter...

sinon ta matrice a l'air bonne, hormis les +16/+128.
 
en fait la question est (sont):
 
qu'est-ce que tu as en entrée, un truc entre 0 et 1 flottant, ou 0 et 255 entier ?
 
qu'est-ce que tu veux en sortie ? (flottant entre 0 et 1 ou entier entre 0 et 255)

En fait c'est prog qui a été fait avant que je commence mon stage (par un autre stagiaire, justement) et il est fonctionnel à part ce problème de noir et blanc que j'ai pour tâche de corriger...
Il faut que je continue à regarder ce qui s'y fait, mais au niveau des équations j'en ai trouvées pas mal, et toutes reviennent au même ; comme mon prédécesseur avait fait pas mal de recherches sur le sujet, je pense qu'il a trouvé les meilleures...
Sinon concernant la partie entière, j'ai des warning à la compilation qui m'avertissent à propos d'une conversion de "double" à "unsigned char" : ça peut venir de là mon problème ?
Enfin en sortie il me semble que c'est compris entre 0 et 255, et un e fonction se charge de corriger les dépassements...idem pour l'entrée.

c'est là le problème...
 
concernant la "matrice" de passage du RVB au YUV, elle est normalisée, donc tu devrais toujours trouver les même coefficients sur le net, le problème est donc:
 

 
a) format de l'entrée
b) format de sortie
c) les constantes sont elles bonne et sont peut être là à cause du a) & b)

donc maintenant, autre astuce (Taz devrait passer par là)
 
si tes Y,U,V sont des unsigned char, j'ai peur qu'il fasse des vielles troncations dans le calcul...
 
alors attends je me fais à truc à la con pour tester la routine.

bon si t'y mets un (255,255,255) , tu as en sortie (235.045,128,128)
 
http://www.globalmediapro.com/av/messages/82880.html
 

 
à priori au niveau encodage en YUV, il faut clamper le 0-15 et le 236-255.
 
vu le comportement de la routine, ça semble attendre le R,V,B entre 0 et 255, donc l'octet de chaque canal...
 
avec le rouge à fond uniquement (255,0,0), on a ~(81,240,90) et pour le bleu à fond on obtiens ~(41,110,240).
 
ce qui semble cohérent.... (enfin chui pas sûr)
 
-------
 
buh, un lien sympa: (mais qui complique l'affaire)
 
http://www.nalanda.nitc.ac.in/indu [...] LORSPC.PDF
 
----------
 
bon ça s'éclairci:
 
pour le Y, ton équation et celle de philips "coincident":
 
la routine attends bien des valeurs entre 0 et 255.
elle cherche à produire un Y entre 16 et 235.
si tu prends l'équation de philips pour le Y:
 
Y=0.299*R + 0.587*G + 0.114*B
 
et que tu  considères que tu veux ramener ta plage non pas sur 255 niveaux mais 219 (235 max - 16 min), tu prémultiplies les coefs par 219/255, et tu ajoutes 16:  
 
0.299*(219/255)=>0.2567
0.587*(219/255)=>0.5041
0.114 => 0.0979
 
ce qui fait que Y semble cohérent.
après voir si ça colle pour l'encode en YUV 411 planar...
 
 
---------------------------------------------
 
de la doc philips:
 

 
ok.
 
donc à priori la routine converti bien un RGB 24 bits en YUV 24bits....
 
faudrait regarder si le YUV 411 colle avec ça...

http://www.microsoft.com/Developer [...] edia_Types
 

ok merci beaucoup je vais vérifier tout ça... je te tiens au courant.
 
EDIT : j'ai essayé l'équation de Philips pour le Y et ça donne la même chose... il faut donc creuser du côté des U et V, ce sont eux qui doivent foirer.

bon essayé les équations de Philips pour les U et V, mais si j'ajoute pas 128 à la fin, ça me donne n'importe quoi comme image (avec des couleurs, certes, mais crados) ; c'est trop bizarre en plus c'est pas moi qui ait codé le prog, donc c'est chaud de comprendre ce qui a été fait...
par contre j'ai aussi essayé de faire la transformation inverse sur les U et V (enlever 128 et multiplier les coeffs par 255/127) et ça marche pas mieux...

le 128 est là, car c'est l'encodage est non-signé mais avec offset. en gros U & V sont signés, MAIS dans l'octet le 0 correspond à 128. (il faut donc décaller le bourdel avec un +128).

yep, quand je remets +128 ça revient "normal" (en N&B quoi)... je sais plus où chercher ; je me demande si ça vient pas d'ailleurs  

ensuite si tu prends l'équation de phillips U & V peuvent être négatifs.
 
donc U et V prennent un delta de 224 et non 219 comme Y (d'après philips)
 
donc la normalisation de plage serait 224/255 (pour faire un truc symétrique comme pour Y)...
 
donc si prends l'équation philips:  
 
U = - 0.169 * R - 0.331 * G + 0.500 * B
 
donc:
 
U = - 0.1484*R - 0.29*G + 0.4392*B (+ 128)

ce qui semble bon !!!!
 
et (255,255,0) donne bien 16....

c la même chose pour Y ? ou le delta diffère ?
 
EDIT : dsl tu as déjà répondu à ça...

on va faire pareil pour V:
 
V=0.500 * R - 0.419 * G - 0.081 * B
 
=> 0.4392*R - 0.368 * G - 0.07115 *B (+128)

j'essaie ça de suite...
 
EDIT : ça donne la même chose, toujours en N&B ; je vais voir si ça vient pas d'ailleurs pk là les équations sont bonnes a priori.

pareil, on obtient bien un bon comportement avec (255,0,0) qui donne 240 et (0,255,255) qui donne 16.
 
donc le matrice final est donc:
 
Y = 0.257*R + 0.504*G + 0.098*B + 16;
U = - 0.1484*R - 0.29*G + 0.4392*B + 128 ;  
V = 0.4392*R - 0.368 * G - 0.07115 *B + 128;
 
après il faudrait vérifier que l'encodage YUV 411 est correct, mais si tu as bien le noir et blanc sur toute l'image, c'est que le placement des octets est correct.

en fait on est retombé sur l'équation initiale, mais avec U & V inversés....

au niveau des octets c'est impec... par contre je me demandais un truc : pour chaque U et V de calculés on a 4 composantes RGB (puisqu'on a YYYYUV) ; donc comment savoir lors du calcul de U et V quelles composantes prendre (R1G1B1, R2G2B2,...) ?

ensuite le 411 est expliqué dans la doc philips "4:1:1 YCbCr (orthogonal)
sampling"

 
ce qui ne change rien au résultat final...

 
pour chaque pixel, du fais ta conversion RGB 24 bits => YUV 24 bits (8 bits/composante).
 
en YUV 411, pour un paquet de 4 pixels, tu émets le YUV du premier pixel, et ensuite uniquement le Y de chaque pixel (pour les 3 suivants).

donc le calcul est bon, vu que c'est le premier pixel qui est pris en compte... j'avais essayé de faire la moyenne des 4 pixels, mais ça changeait pas grand chose.

par contre le truc qui me chiffonne c'est l'ordonnencement...
 
en prennant le truc de philips directement, on a:
 
Y0 U0 V0 | Y1 | Y2 | Y3 | Y4 U4 V4 | Y5 | Y6 | Y7 .....
 
(enfin c'est l'interprétation que j'en fais hein )

alors que le format 41P  (411 packed) decrit pas grosspft c'est:
 
Y0 U0 V0 | Y1  U4 | Y2  V4 | Y3 | Y4 | Y5 | Y6 | Y7 ......
 
pas blocs de 12 octets répétitifs....

moi c'est du 4.1.1 planar que je veux ; à priori c'est Y1Y2Y3Y4U1V1

enfin attention ça l'interprétation que j'en fais....
 
ça se trouve je me plantes....
 

sinon il se peut que tu ayes un buffer à Y et un buffer à U+V....

http://www.efg2.com/Lab/Graphics/Colors/YUV.htm#411
 
et eux le format YUV 411 planar
 
c'est 4 Y + un couple UV (ce qui est ptet plus correct...)

apparemment le problème doit venir d'ailleurs ; je vais en discuter avec mon tuteur de stage cet apr...
 
EDIT voilà l'image une fois encodée puis décodée :
 

bizarre
 
si l'ordre des octets était mauvais, on aurait une image shootée

ce que tu peux faire pour débugguer le bordel:
 
ajoute un bout de code ou tu émets le premier pixel de chaque image dans un fichier .txt
 
puis tu teste avec une image noire, blanche, rouge, bleu, et tu regardes les résultats....
 

je vais essayer ça... thx

si t'as besoin d'avoir de bonnes perfs pour ta routine de conversion, voici une astuce : tu ramènes tous tes coeffs sur 256.
Y = 0.299f*R + 0.587f*G + 0.114f*B;
Y = (76*R + 150*G + 30*B) >> 8;

 
OK merci par contre que signifie le >> 8 ?

décalage de 8 bits vers la droite ce qui revient a diviser par 256.

oki d'acc...

oui mais bon avant de passer en virgule fixe, fodrait déjà que ce qui soit sorti soit bon
 
pi à la limite autant passer en virgule fixe 16:16.

en fait je vais appliquer la tactique suivante :
 
- prendre deux images identiques existantes, l'un en rgb et l'autre en yuv
- encoder puis décoder la même image à partir de rgb
- comparer l'original en yuv (le bon) et celle que j'obtiens, voir les différences qu'il y a
 
l'ennui c'est que j'arrive pas à trouver une image rgb et sa transformée en yuv...