[MPC] Filtre(s) Pixels shaders ...

[pitch28]

"dans MPC HC l' espace des couleurs depend de ton renderer. VMR9 et EVR font la conversion en RGB [16,235], Haali converti en RGB [0,255]"

Si le VRM9 s'occupe de la conversion en RGB pourquoi oblige t'on FFdshow a faire cette conversion (CPU......)?

[chambolle]

"dans MPC HC l' espace des couleurs depend de ton renderer. VMR9 et EVR font la conversion en RGB [16,235], Haali converti en RGB [0,255]"

Si le VRM9 s'occupe de la conversion en RGB pourquoi oblige t'on FFdshow a faire cette conversion (CPU......)?

parce vmr9 ne l'a fait pas bien. Il l'a fait dans [16,235]

[nykoh06]

La confusion m'envahit un peu

Avec MPC-HC, j'utilise ffdshow pour le decodage (xvid, h264) sans aucun parametre additionnel (pas de conversion d'espace, de mapping, etc...).
Dans MPC j'utilise uniquement un filtre de sharpenning en pixel shaders (sharpen complex)

En VMR9, effectivement les couleurs sont delavees (et encore c'est surtout sur des videos de def standard, pas tellement sur de la hd)
En EVR Custom (3D surfaces, resizer bicubic 0.75 PS2), je ne constate pas de couleurs delavees, le noir est bien noir.

Donc quand je suis en EVR, il y a bien quelquechose qui fait la conversion vers RGB[0-255], mais je ne vois pas quoi puisque je n'ai rien réglé explicitement pour... Comment ca se fait? (Je suis sous Vista32, 8600GT)

[chambolle]

La confusion m'envahit un peu

Avec MPC-HC, j'utilise ffdshow pour le decodage (xvid, h264) sans aucun parametre additionnel (pas de conversion d'espace, de mapping, etc...).
Dans MPC j'utilise uniquement un filtre de sharpenning en pixel shaders (sharpen complex)

En VMR9, effectivement les couleurs sont delavees (et encore c'est surtout sur des videos de def standard, pas tellement sur de la hd)
En EVR Custom (3D surfaces, resizer bicubic 0.75 PS2), je ne constate pas de couleurs delavees, le noir est bien noir.

Donc quand je suis en EVR, il y a bien quelquechose qui fait la conversion vers RGB[0-255], mais je ne vois pas quoi puisque je n'ai rien réglé explicitement pour... Comment ca se fait? (Je suis sous Vista32, 8600GT)

Salut,

Va sur cette page:
http://forum.doom9.org/showthread.php?t=120718&page=3

download vmr9 test.zip et essaie en vmr9 puis en evr
La tu verras bien si tu as une difference.

Le fait que tu sois sous vista explique peut-etre la difference.
Et hoooo il y a quelqu'un pour tester aussi ? (j'ai pas de vista)

[chambolle]

Bon l'histoire des changements d'espaces avec consequences terrible m'a quand meme titille un peu.

En faisant un petit calcul de conversion RGB [16,235] vers YUV [16,235] en 601 avec application des formules, puis conversion YUV [16,235] vers RGB [16,235] en 601 avec application des formules, je me suis rendu compte de la chose suivante:
le R' (R calcule) est egal a (0.299 + 1.371*0.511)R= 0.999581 * R
R etant entre 0 et 1. L'echelle comporte 256 niveaux et 1/255=0.0039216 ce qui multiplie par
0.999581 ne fait pas une erreur d'un niveau. En consequence les conversions devraient etre identiques.

Un petit shader montre que j'ai raison:
Il effectue les deux transformations et affiche un point rouge a la place de tout point ayant change.


RGB identity
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0=tex2D(s0,tex);
// r=c0[0], g=c0[1], b=c0[2]
// RGB [16,235] to YUV: 601 mode (128 is not added to Cb and Cr)
float y=0.299*c0[0] + 0.587*c0[1] + 0.114*c0[2];
float Cb=-0.172*c0[0] -0.339*c0[1] +0.511*c0[2];
float Cr=0.511*c0[0] -0.428*c0[1] -0.083*c0[2];

// YUV to RGB [16,235]: 601 mode (Cb and Cr are 128 less)
float r=y+1.371*Cr;
float g=y-0.698*Cr-0.336*Cb;
float b=y+1.732*Cb;

if (round(r*255) != round(c0[0]*255) ||
round(g*255) != round(c0[1]*255) ||
round(b*255) != round(c0[2]*255)){
r=255;
b=0;
g=0;
}

float4 ret=float4(r,g,b,0);

return ret;
}

[nykoh06]

Salut,

Va sur cette page:
http://forum.doom9.org/showthread.php?t=120718&page=3

download vmr9 test.zip et essaie en vmr9 puis en evr
La tu verras bien si tu as une difference.

Le fait que tu sois sous vista explique peut-etre la difference.
Et hoooo il y a quelqu'un pour tester aussi ? (j'ai pas de vista)

J'essairai ca chez moi des que possible, mais la au boutot j'ai telecharge le vmr9-test.zip, et la video en question est une mire de couleur qui ne ressemble vraiment pas a l'image donnee dans le forum de doom9...

[chambolle]

J'essairai ca chez moi des que possible, mais la au boutot j'ai telecharge le vmr9-test.zip, et la video en question est une mire de couleur qui ne ressemble vraiment pas a l'image donnee dans le forum de doom9...

Sur le forum de doom9 il montre la partie en bas a droite de la video qui est zoomee.
Tu dois voir une barre verticale dans la partie en bas a droite sous les couleurs.

[pitch28]

Bon l'histoire des changements d'espaces avec consequences terrible m'a quand meme titille un peu.

En faisant un petit calcul de conversion RGB [16,235] vers YUV [16,235] en 601 avec application des formules, puis conversion YUV [16,235] vers RGB [16,235] en 601 avec application des formules, je me suis rendu compte de la chose suivante:
le R' (R calcule) est egal a (0.299 + 1.371*0.511)R= 0.999581 * R
R etant entre 0 et 1. L'echelle comporte 256 niveaux et 1/255=0.0039216 ce qui multiplie par
0.999581 ne fait pas une erreur d'un niveau. En consequence les conversions devraient etre identiques.

Un petit shader montre que j'ai raison:
Il effectue les deux transformations et affiche un point rouge a la place de tout point ayant change.


RGB identity
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0=tex2D(s0,tex);
// r=c0[0], g=c0[1], b=c0[2]
// RGB [16,235] to YUV: 601 mode (128 is not added to Cb and Cr)
float y=0.299*c0[0] + 0.587*c0[1] + 0.114*c0[2];
float Cb=-0.172*c0[0] -0.339*c0[1] +0.511*c0[2];
float Cr=0.511*c0[0] -0.428*c0[1] -0.083*c0[2];

// YUV to RGB [16,235]: 601 mode (Cb and Cr are 128 less)
float r=y+1.371*Cr;
float g=y-0.698*Cr-0.336*Cb;
float b=y+1.732*Cb;

if (round(r*255) != round(c0[0]*255) ||
round(g*255) != round(c0[1]*255) ||
round(b*255) != round(c0[2]*255)){
r=255;
b=0;
g=0;
}

float4 ret=float4(r,g,b,0);

return ret;
}

J ai essayé ton PS Chambolle et pour moi il n'y a aucun changement

1) le PS ne marche pas ??
2) il ny a pas de perte lorsqu'on change d espace couleur et que l on reconvertie dans l 'espace premier

Réponse 2 non ???

[nykoh06]

Sur le forum de doom9 il montre la partie en bas a droite de la video qui est zoomee.
Tu dois voir une barre verticale dans la partie en bas a droite sous les couleurs.

Bon je confirme: quand je suis en VMR9 ou en EVR j'ai effectivement le probleme de mapping, mais par contre en EVR *custom* c'est niquel.
Donc que dois t'on conclure? que l'evr custom sous vista prend correctement en charge la conversion en rgb[0-255]? Si quelqu'un d'autre pouvais tester...

[chambolle]

J ai essayé ton PS Chambolle et pour moi il n'y a aucun changement

1) le PS ne marche pas ??
2) il ny a pas de perte lorsqu'on change d espace couleur et que l on reconvertie dans l 'espace premier

Réponse 2 non ???

Exactement. Il n' y a pas de pertes. C'est ce que je veux montrer.

[chambolle]

Sur le forum de doom9 il montre la partie en bas a droite de la video qui est zoomee.
Tu dois voir une barre verticale dans la partie en bas a droite sous les couleurs.

Bon je confirme: quand je suis en VMR9 ou en EVR j'ai effectivement le probleme de mapping, mais par contre en EVR *custom* c'est niquel.
Donc que dois t'on conclure? que l'evr custom sous vista prend correctement en charge la conversion en rgb[0-255]? Si quelqu'un d'autre pouvais tester...

Apparemment ca convertit bien. Marrant ca tiens C'est quand meme un sacre bordel l'informatique !!!

[pitch28]

Chambolle ! j'ai encore des questions si tu pouvais m'aider ??

Corrige moi si je me trompe :
DVD en YV12 (16/235) ==>decodeur nvidia YUY2 (16/235) ===>VRM9 sortie RGB (16/235) = image delavée car sur l'ecran on doit sortir en RGB 0/255

Les ps s'applique donc sur une trame RGB

Pourquoi devrait on changer d'espace couleur RGB(16/235) vers un YUV(16/235) faire le decalage vers un yuv (0/255) et refaire une conversion donc RGB 0/255 ?

Ce que fait apparemment ce ps
nom : full_RVB
-----------------------------------
sampler s0 : register(s0);
float4 p0 : register(c0);
float4 p1 : register(c1);

#define width (p0[0])
#define height (p0[1])
#define counter (p0[2])
#define clock (p0[3])
#define one_over_width (p1[0])
#define one_over_height (p1[1])

#define PI acos(-1)

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float r = dot(tex2D(s0, tex), float4(1.14303, 0.01788, 0.00347,0)) - 0.07306;
float g = dot(tex2D(s0, tex), float4(0.00911, 1.15180, 0.00347,0)) - 0.07306;
float b = dot(tex2D(s0, tex), float4(0.00911, 0.01788, 1.1374,0)) - 0.07306;
float4 c0 = float4(r, g, b, 0) ;

return c0;
}


Quel est donc la difference ( avantage inconvenient)avec le PS a seb ?

Remap_16_235 ( Seb.26 ) : Remap les valeur de 16->235 vers 0->255
Code:
sampler s0 : register(s0);
float4 p0 : register(c0);
float4 p1 : register(c1);

#define width (p0[0])
#define height (p0[1])
#define counter (p0[2])
#define clock (p0[3])
#define one_over_width (p1[0])
#define one_over_height (p1[1])

#define PI acos(-1)

#define Const_1 (16.0/255.0)
#define Const_2 (255.0/219.0)

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return( ( tex2D( s0, tex ) - Const_1 ) * Const_2 );
}

Ce PS remape donc le RGB16/235 en RGB 0/255 , ce qui me parait plus logique non ? pas de changement d'espace couleur

[chambolle]

@pitch28.

Je ne sais pas bien ce que fait precisement full_RVB.
Je trouve que le PS de Seb26 est tres bien.

[chambolle]

@seb26:

J'ai eu un peu de probleme avec la "bidouille" que font les gens en mettant le coef multiplcateur du sharpen a 0.65.

Le probleme en faisant cela est que dx ou dy ne sont plus exprimable en nombre de pixel.
Je m'explique: tu definis en general dx=1/width ou width est la largeur. Comme les coordonnees sont exprimees entre 0 et 1 cela signifie que dx vaut un pixel.
Avec le parametre 0.65 utilise par tout le monde pour les shaders cela signifie que
dx=0.65/width or ca ne tombe pas sur un pixel.
Qule est la couleur retournee dans ce cas ?

De facon empirique il apparait que cela doit ressembler a quelque chose comme:
0.35 * couleur de tex + 0.65 * (couleur de tex + 1/width)

As tu des infos la-dessus ?

merci

[leeperry]

"les gens" ca serait moi

faut quelles valeurs pour que ca tombe rond alors :??:

je ne le fais que sur le script "sharpen" de base..