Gestion correcte du gamma sous ffdshow

[Seb.26]

Si en RGB toujours !
C'est la connexion de sortie RGB32 vers le VMR9 qui fait le mapping 16-235 > 0-255

Heu ... dans FFDshow, c'est l'onglet 'output' qui fait la conversion ... et c'est justement ce TV->PC de l'onglet output que j'ai modifié ...

En directshow, une 'outputPin' ne fait à part faire passer la frame, directshow se chargeant de la passer à l'inputPin du filtre suivant ...

[Seb.26]

Plus on avance plus s'est confus

Et pourtant, je t'assure : c'est extremement simple ...

[stloup]

Moi, j'avais compris que le rgb était en 0-255 (il me semble avoir lu dans ce post une histoire comme quoi le passage yuy-RGB "decompressait le 16-235 en 0-255. Donc si on donne du rgb 0-255 au VMR9 il ne fait pas de mapping puisque que c'est déjà en 0-255 !

Je suis comme kbill69 "confusionné"

[stloup]

Si en RGB toujours !
C'est la connexion de sortie RGB32 vers le VMR9 qui fait le mapping 16-235 > 0-255

Heu ... dans FFDshow, c'est l'onglet 'output' qui fait la conversion ... et c'est justement ce TV->PC de l'onglet output que j'ai modifié ...

En directshow, une 'outputPin' ne fait à part faire passer la frame, directshow se chargeant de la passer à l'inputPin du filtre suivant ...

Donc on sort de ffdshow en 0-255 et on attaque le VMR9 direct dans ce statut et alors pas de mapping à l'intérieur de celui-ci ?
C'est ça ?

Sgreugnieugnieu !!

[Emmanuel Piat]

>d'ailleur pour mon info perso : pourquoi sortir en RGB vers l'overlay ?

Petit rappel historique (sur les ATI) :

- Au tout début, il n'y avait que l'overlay et tout le monde l'attaquait en YUY2 (car à l'époque les player DVD sortaient tous en YUY2 en faisant un upsampling de chroma de 4:2:0 à 4:2:2, upsampling qui merdait souvent au passage (red chroma bug)). Le YV12 est arrivé très tard (sur TT en premier, puis Dscaler, puis intervideo).

Principal défaut ds cette config : l'overlay ajoutait du sharpen, bidouillait le chroma et aussi le gamma. Par défaut le mapping était [16-235] -> [0,255], d'où pas de BTB ni de WTW. Mais via ajustement de la luminosité et du contraste ds l'overlay, on pouvait faire entrer légèrement le BTB et le WTW dans l'intervalle [16-235] pour le retrouver sur l'image affichée après mapping.

- Ensuite fut VMR9. Bcp de mirent à l'utiliser en l'attaquant tjrs en YUY2, vu qu'on avait pas le choix au niveau du player.

Principal défaut : tearing + flou car les algo resize de texture utilisés par la CG pour resizer l'image n'étaient franchement pas terrible... Le mapping par défaut était [16-235] -> [16,235]. D'où affichage de la totalité du BTB et du WTW. L'espace profond de la guerre des étoiles était soudainement devenu tout gris. Il fallait donc ajuster la luminosité et le contraste en conséquence.

- Ensuite fut la sortie YV12 sur les players DVD. Principal csq AMHA si on intercallait pas ffdshow : une baisse de qualité des chromas car il n'y avait plus aucun upsampling de chroma à aucun niveau du traitement vidéo.

- Et au milieu de tout cela, très vite utilisé ffdshow (bien avant l'apparition du YV12 sur les players).

Au début, tout le monde utilisait ffdshow en sortie YUY2 ou YV12. La conv. YUV vers RGB (pour attaquer les ramdac) était donc tjrs pris en charge de manière hard par la CG, qu'on soit en overlay ou en VMR9. J'ai montré il y a bien longtemps qu'avec l'overlay des nvidia, la profondeur de calcul pour cette conv n'était pas suffisante, d'où une image dégradée par rapport à celle d'une ATI. En VMR9, il y avait moins (voir pas) de différence.

Puis un jour j'ai pris ma plume pour expliquer qu'on pouvait très bien faire cette conversion en soft, dès la sortie de ffdshow car la qualité de cette conv était devenue très bonne (ce n'était pas le cas des versions antérieure de ffdshow). En plus, on pouvait désormais faire un upsampling de chroma si le flux interne à ffdshow était YV12 via l'option "high quality ouput".

Avantage en overlay : on schinte toutes les étapes hard qui trafiquent notamment le sharpen car ces étapes sont fait en YUV. Fini de ce fait le leger EE dû à l'overlay. Le mapping dans ce cas est neutre : les valeurs RGB fournie par ffdshow sont directement récupérées ds l'overlay.

Avantage en VMR9 : je ne sais pas trop car je n'utilise pas le VMR9 vu que je n'ai jamais eu des CG de course. Là aussi le mapping est neutre : les valeurs RGB fournie par ffdshow sont directement récupérées ds VMR9. Fini l'espace gris par défaut lorsque ffdshow sortait en YV12 ou YUY2

Donc en conclusion, que vous utilisiez l'overlay ou VMR9, c'est à vous de choisir votre mapping dans ffdshow lorsque vous sortez en RGB32. Les valeurs RGB obtenues seront alors directement recopiées dans l'overlay ou le VMR9.

@+
Emmanuel

[kbil69]

Bon, je laisse en auto avec :
- luma only
- full range
- original
- input 16-235
- outpu 0-255

- RGB32
- PC YUV




J'ai une autre question, qui n'as rien à voir mais comme on est dans le YV ou YUY2 ... :

Lorsque je lis un divx, et oui ca m'arrive rarement mais ca m'arrive , j'ai YV12 en entrée et sortie, pourtant en DVD je suis bien en YUY->RGB32

C'est une question d'encodage du film qui fait qu'il est en YV12 en entrée/sortie ou il y a un paramètre à changer à quelque part ?

[Seb.26]

Merci Emmanuel !
... on en apprend vraiment tous les jours ...

[stloup]

Pour les réglages je laisse aussi comme kbill69 !

Par contre j'ai une petite question aussi :

L'onglet level on le place après le resize et le swscaler ou avant ?

[kbil69]

Pour les réglages je laisse aussi comme kbill69 !

Par contre j'ai une petite question aussi :

L'onglet level on le place après le resize et le swscaler ou avant ?

En 1er d'après ce que j'ai compris

[Emmanuel Piat]

Merci Seb.26. J'ai juste oublié de dire que depuis qq temps certains utilisent l'HaaliRender . Comme l'overlay me convient parfaitement (si attaqué en RGB) je n'ai jamais essayé

[Seb.26]

Donc on sort de ffdshow en 0-255 et on attaque le VMR9 direct dans ce statut et alors pas de mapping à l'intérieur de celui-ci ?
C'est ça ?

OUI !
... Moi j'avais lu/cru qu'il y avait un mapping fait par le VMR9 en RGB ... en fait non ...

[Emmanuel Piat]

>L'onglet level on le place après le resize et le swscaler ou avant ?

avant resize, sauf si tu es ultra large en CPU.

reste ensuite à savoir si on le met avant ou après swscaler. J'ai fait pas mal de test avec Monstres & Co, et je trouve que c'est mieux si on le met avant (cf. mes snapshots de ffdshow en page 1). Evidemment, mes réglages persos de filtres peuvent avoir une importance (je fais tout en YV12). Donc, le mieux est de tester ...

[stloup]

Pour les réglages je laisse aussi comme kbill69 !

Par contre j'ai une petite question aussi :

L'onglet level on le place après le resize et le swscaler ou avant ?

En 1er d'après ce que j'ai compris

Merci Kbill et emmanuel !
Je vais finir par m'en sortir ...

[Emmanuel Piat]

Annecdote : vu hier avec la petite famille Azur et Asmar => DVD truffé de BTB et de WTW (et Pal speedup préconpensé par défaut).

[Seb.26]

Merci Seb.26. J'ai juste oublié de dire que depuis qq temps certains utilisent l'HaaliRender . Comme l'overlay me convient parfaitement (si attaqué en RGB) je n'ai jamais essayé

là je peux vous aider un poil ...

C'est ultra simple :

HR accepte 2 formats : YU2 et RGB32

> YU2 :
Par defaut HR fait un TV->PC et utilise une matrice bt.601 ( il fait donc une conversion rec.601 YUV->RGB )

> RGB32 :
Aucun mapping.

NB: depuis la dernière version, HR permet de choisir entre rec et PC pour la conversion YUV->RGB, il permet aussi de choisir en BT.601 et BT.709 concernant les matrices de conversion.

Il me semble interressant d'insister sur un point :
HR est le seul render aujourd'hui qui n'est pas influencé par les reglages vidéo des drivers ... ce qui veut dire que si vous lui donnez une frame en RGB32, l'ecran sera exactement la même chose que si c'etait paint qui affichait la frame ... donc on peut calibrer son ecran avec des mirres BMP ...