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

[yawie]

Je ne comprends pas physiquement comment on peut corriger la convergence. On ne peut pas afficher moins d'un pixel. Tout ce qu'on peut faire c'est changer sa couleur non ?
Donc tu fais quoi là, tu prends un peu de la couleur des voisins ? Tu modifies les coordonnées réelles des pixels et tu comptes sur le moteur de resize pour se débrouiller avec ?

[Seb.26]

Je ne comprends pas physiquement comment on peut corriger la convergence. On ne peut pas afficher moins d'un pixel. Tout ce qu'on peut faire c'est changer sa couleur non ?
Donc tu fais quoi là, tu prends un peu de la couleur des voisins ? Tu modifies les coordonnées réelles des pixels et tu comptes sur le moteur de resize pour se débrouiller avec ?

Prends le problème à l'envers : que se passe t'il quand y'a un problème de convergence ?

[leeperry]

ouaip comment c'est possible de bouger l'image de moins d'un pixel ?

genre 1/4 de pixel je vois une difference avec une mire....WTF ?

et ±0.1 qui change qqchose, spossible ou c'est dans ma tete ?



I'm not crazy

[chambolle]

ouaip comment c'est possible de bouger l'image de moins d'un pixel ?

genre 1/4 de pixel je vois une difference avec une mire....WTF ?

et ±0.1 qui change qqchose, spossible ou c'est dans ma tete ?



I'm not crazy

ta valeur pour le sharpen fait bien une moyenne avec les pixels situes a + ou - 0.65 pixels d'un pixel.
Or ca fait bien quelque chose de different des arrondis au pixel pres (voir un de mes messages precedents). D'apres mes tests ca fait quelque chose comme
rouge calcule = rouge origine * 0.35 + rouge du pixel suivant * 0.65

A mon avis, c'est bien le meme principe.
Mais je suis peut-etre completement a cote de la plaque. Surtout n'hesitez pas a corriger si je dis une connerie.

[leeperry]

a voir comment celui de Haali's Renderer fonctionne.

car +0.25 de rouge horizontalement et la grille devient verte

[jim.ro]

Hello ! Je vois que l'on s'amuse bien avec les shaders !!
Pour la petite histoire, quand les versions de sharpen ont été écrites, Casimir et moi n'avions que des cartes vidéo qui acceptaient les PS2.0

Le problème c'est que les shader 2.0 sont limité à 64 opérations de calcul...

donc j'avais laissé tombé les essais beaucoup plus "puissant".
Puis Casimir s'est lancé sur le MPC-HC, moi j'ai un new bébé à la maison ( ) et on a un boulot "monstre" au taf...
Mais je vais essayer d'y rejeter un coup d'eye

Autrement, effectivement une image vidéo est traitée comme une texture avec des coordonnées allant de 0,0:0,0 à 1,0:1,0. Les "registres" p1[0], p1[1] sont préchargé par MPC avec (1/width) et (1/height) ce qui donne donc la dimension d'un pixel en x et en y !
X et Y étant en flottant, c'est bien sur une approcximation faite par les shader et il est tout à fait possible de demander autre chose que l'équivalent d'un pixel réel. Par contre, je ne sais pas vraiment quel est le "calcul" fait par le tex2D().
Les algo théorique (Prewitt, sobel et autre) sont fait pour des pixels c'est pourquoi le dx est presque toujours un "multiple" de pixel. Après, avec des "," çà peut marcher mais on ne sait pas trop ce que çà fait !!!

Le sharpen Complex est le mélange de deux techniques : soustraction d'une image floue (pour accentuation des détails) puis détection des contours (par Sobel car les PS 2.0 ne permettait pas d'utiliser d'autre algo (style Prewitt) qui sont beaucoup plus efficaces) et sharpen par le "sharpen simple".

Maintenant, y'a plus qu'a tester le mélange de plusieures techniques

[chambolle]

@jim.ro:
merci ce qu tu dis me rassures. Je pense aussi qu'il faut rester autant que faire ce peut dans l'unite des pixel (et pas des demi pixels ou trucs comme ca).
merci aussi pour tes PS. Cela m'a bien aide a comprendre.

[chambolle]

Est-ce que quelqu'un ayant un bon ecran calibre peut tester le PS suivant et me dire honnetement ce qu'il en pense.

L'idee est d'avoir un faible sharpen qui ne fait pas de EE et d'eviter les probblemes du type banding. Je reste sur mon idee: je floute les trucs tres tres proche, j'ameliore les contours mais legerement et pas tous.

Il y a deux parametre:
seuilFlou: exprime en unite de couleur (normalise en 0 et 1). Tous les pixels proches les uns des autres selon leur trois couleurs vont etre floutes. (8/255 par defaut)
seuilLumaSharpen: entre 0 et 1. 0.4 par defaut. Plus on augmente plus on durcit l'image, mais on augmente aussi le EE. C'est a vous de voir.

@tobal: les PS permettent essentiellement de faire de la convulation: i.e. on calcule la nouvelle couleur d'un pixel a partir de ses voisins.


------- BlurrAndSharp

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 dx (p1[0])
#define dy (p1[1])

#define seuilFlou (8./255.)
#define seuilLumaSharpen 0.4

#define PI acos(-1)

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 ori = tex2D(s0, tex);
float4 c1 = tex2D(s0, tex + float2(-dx,-dy));
float4 c2 = tex2D(s0, tex + float2(0,-dy));
float4 c3 = tex2D(s0, tex + float2(dx,-dy));
float4 c4 = tex2D(s0, tex + float2(-dx,0));
float4 c5 = tex2D(s0, tex + float2(dx,0));
float4 c6 = tex2D(s0, tex + float2(-dx,dy));
float4 c7 = tex2D(s0, tex + float2(0,dy));
float4 c8 = tex2D(s0, tex + float2(dx,dy));

float4 sumabs2=((ori-c1)*(ori-c1) + (ori-c2)*(ori-c2) + (ori-c3)*(ori-c3) +(ori-c4)*(ori-c4) + (ori-c5)*(ori-c5) + (ori-c6)*(ori-c6) + (ori-c7)*(ori-c7) + (ori-c8 )*(ori-c8 ))/8.;

float4 gauss=(c1+2*c2+c3+2*c4+2*c5+c6+2*c7+c8+4*ori)/16.;
float4 res=2*ori-gauss;
float limit2=seuilFlou*seuilFlou;
float luma=dot(ori, float4(0.299, 0.587, 0.114,0));
if (luma > seuilLumaSharpen){
res=ori;
//res=float4(1,0,0,0);
}// else res=float4(0,1,0,0);
if (sumabs2.r <= limit2 && sumabs2.g <= limit2 && sumabs2.b <= limit2){
res=gauss;
//res=float4(0,0,0,0);
}

return res;
}

[chambolle]

Un PS qui affiche en rouge la peau.
Ca marche pas trop mal et ca peut etre utile a ceux qui veuelnt eviter de toucher les visages.

---- skin

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
{
float4 ori = tex2D(s0, tex);
float4 res= ori;
float maxrgb=max(ori.b,ori.g);
maxrgb=max(ori.r,maxrgb);
float minrgb=min(ori.b,ori.g);
minrgb=min(ori.r,minrgb);

if (ori.r > (95./255.) && ori.r > 40./255. && ori.b > 20./255.
&& (maxrgb - minrgb) > 15./255 && abs(ori.r -ori.g) > 15/255. && ori.r > ori.g && ori.r > ori.b){
res=float4(1,0,0,0);
}
return res;
}

[Seb.26]

Par contre, je ne sais pas vraiment quel est le "calcul" fait par le tex2D().

Tout dépend de la façon dont est déclarée ta texture dans D3D, mais à priori dans MPC, c'est de l'interpolation bilinéaire.

[Seb.26]

Je pense aussi qu'il faut rester autant que faire ce peut dans l'unite des pixel (et pas des demi pixels ou trucs comme ca).

Tout dépend du filtre ... Mais dans une convolution, le fait de prendre une valeur non entière permet de pondérer l'écart entre ce pixel et son voisin ... par exemple, la puissance du sharpen est au max quand effect_width tend vers 1.0 ( donc les pixels voisins ont toute leur puissance ) ... et avec 0.0, l'effet est nul puisque que l'on va utiliser comme voisin le pixel d'origine lui même ...

[tobal]

Est-ce que quelqu'un ayant un bon ecran calibre peut tester le PS suivant et me dire honnetement ce qu'il en pense.

Hello,

je teste ce soir en sortant du taf et je te dis ce qu'il en ressort .

@tobal: les PS permettent essentiellement de faire de la convulation: i.e. on calcule la nouvelle couleur d'un pixel a partir de ses voisins.

Hemmm... Tu veux parler de convolution, p-ê ?

Micose la convulation, ça fait comment dire... euh...plus féminin (?).

@+,
Xavier.

[oli2]

Je pense aussi qu'il faut rester autant que faire ce peut dans l'unite des pixel (et pas des demi pixels ou trucs comme ca).

Tout dépend du filtre ... Mais dans une convolution, le fait de prendre une valeur non entière permet de pondérer l'écart entre ce pixel et son voisin ... par exemple, la puissance du sharpen est au max quand effect_width tend vers 1.0 ( donc les pixels voisins ont toute leur puissance ) ... et avec 0.0, l'effet est nul puisque que l'on va utiliser comme voisin le pixel d'origine lui même ...

On avait bien compris, Seb !
Le problème est que, lorsque des valeurs non entières sont utilisées, on ne peut maitriser les algos propres à Texd2D utilisés pour calculer les couleurs ...

Avec le Sharpen simple à 0.65, on fait de la pondération sur une valeur calculée on ne sait pas comment.

J'ai téléchargé le code de MPC : dans quel fichier puis-je trouver le PS utilisé dans le resize ?

Du reste, je travaille sur une autre question : "tex2d" est-elle bien la fonction la plus pertinente pour notre besoin ? En effet, cette fonction appartient à une famille de fonctions "tex2Dgrad" par exemple.

[oli2]

Autrement, effectivement une image vidéo est traitée comme une texture avec des coordonnées allant de 0,0:0,0 à 1,0:1,0. Les "registres" p1[0], p1[1] sont préchargé par MPC avec (1/width) et (1/height) ce qui donne donc la dimension d'un pixel en x et en y !
X et Y étant en flottant, c'est bien sur une approcximation faite par les shader et il est tout à fait possible de demander autre chose que l'équivalent d'un pixel réel. Par contre, je ne sais pas vraiment quel est le "calcul" fait par le tex2D().

Super ! : je ne m'étais pas trompé ! (cf mes posts d'il y a quelques pages ...)

Avant que j'oublie : @Chambolle : super-boulot !

[Seb.26]

Le problème est que, lorsque des valeurs non entières sont utilisées, on ne peut maitriser les algos propres à Texd2D utilisés pour calculer les couleurs ...

Avec le Sharpen simple à 0.65, on fait de la pondération sur une valeur calculée on ne sait pas comment.

Si tu le sais, je viens de te le dire : c'est une interpolation linéaire 2D ...