Discussion :

[Jipété]

Encore qu'en y regardant de plus près ...
on trouve aux 3 coins pourpres:

Aux 3 coins pourpres ? Mais de quoi tu parles, là ?????????????????? Je n'en vois qu'un seul, en bas à droite.
En plus, je me demande si tu ne te rajoutes pas des problèmes en utilisant une image rectangulaire... Regarde ce que donne l'espace situé entre les deux premiers ronds situés en bas à droite, en zoomant beaucoup :

Le point noir indique que c'est le pixel à sa droite et en descendant qui va être analysé.
Vus, les artefacts ? Qui n'existent pas quand je regarde l'espace entre le rond tout en bas et celui qui est au-dessus de lui !

# Tapis de douche: _ _ _ _ _ _ _ _ 247 _ 8 _ 247
# Fond continus/ carrés (1) et (2): 232 _ 9 _ 120 ( je réagis comme toi !)
et c'est pareil pour le vert:
# Tapis de douche: _ _ _ _ _ _ _ _ 08 _ 248 _ 008
# Fond continus/ carrés (1) et (2): 25 _ 248 _ 138
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _08 _ 246 _ 126

Simplifie-toi la vie avec tes textes, si tu les veux alignés : utilise la baslie "code" ("#')

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
# Tapis de douche:                  247     8   247
# Fond continus/ carrés (1) et (2): 232     9   120 (:mrgreen: je réagis comme toi !)
et c'est pareil pour le vert:
# Tapis de douche:                   08   248   008
# Fond continus/ carrés (1) et (2):  25   248   138
                                     08   246   126

Faut juste bien compter les espaces,

La différence de teinte est visible, et la variation de l'une des composantes représente ~ 50 % du maximum (255): que s'est-il passé ? Tes logiciels te laissent-ils la totale maîtrise des couleurs ? As-tu correctement paramétré la composante bleue ?

Trois questions se suivent que j'ai du mal à capter... La première fait-elle référence à ce qui la précède ou à ce qui la suit ?
La deuxième (maîtrise des couleurs), ben oui, si c'est moi qui les écris, ça serait malheureux qu'ils ne fassent pas ce que je demande,
Et pour la dernière (composante bleue), je pense que en rapport avec dessous, non ? :

L'inversion des couleurs provient d'un simple changement de convention pour l'origine; il suffit d'insérer dans l'un des deux programmes: x' = 255 - x ; y' = 255 - y .

Encore plus simple : suffisait d'inverser x et y dans la codification des couleurs :

Code pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
//      Canvas.Pixels[h, w] := RGBtoColor(byte(h), byte(w), byte(((h)+(w)) div 2));
        Canvas.Pixels[h, w] := RGBtoColor(byte(w), byte(h), byte(((h)+(w)) div 2));

Quant aux couleurs contrastées, j'aimerais bien que tu jettes un œil aux jolis cercles chromatiques qui sont là : peut-être qu'en changeant de bases on y arriverait mieux ?

[wiwaxia]

#

... Aux 3 coins pourpres ? Mais de quoi tu parles, là ?????????????????? Je n'en vois qu'un seul, en bas à droite ...

L'extrémité du coin pourpre de chaque image, la mienne (le rectangle) et tes deux carrés:
1 + 2 = 3 , le compte y est.
Je me suis mal exprimé.
J'ai refait systématiquement plusieurs prélèvements, qui fournissent des résultats identiques à 1 ou 2 unités près.

# Je crois comprendre pourquoi ton bleu arrive à 127 (au lieu de 0 ou 255):
au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        Canvas.Pixels[h, w] := RGBtoColor(byte(w), byte(h), byte(((h)+(w)) div 2));

ne devrait-on pas avoir plus tôt

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        Canvas.Pixels[h, w] := RGBtoColor(byte(w), byte(h), byte(w)     );

puisque le plan considéré vérifie l'équation (r = b) ?

... En plus, je me demande si tu ne te rajoutes pas des problèmes en utilisant une image rectangulaire ...

Il s'agit d'un plan bissecteur du cube, et le contour de l'intersection est un rectangle (détail ici secondaire, en ce qui concerne les couleurs).

[anapurna]

bonsoir

pour faire avancer le shmilblick
j'ai découvert "La théorie des couleurs opposées" de Hering
c'est fort intéressant car il ne parle pas de trois couleur primaire mais de quatre

tu as une préférence pour l'arbre oû mettre la corde

[Jipété]

# Je crois comprendre pourquoi ton bleu arrive à 127 (au lieu de 0 ou 255):
au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        Canvas.Pixels[h, w] := RGBtoColor(byte(w), byte(h), byte(((h)+(w)) div 2));

ne devrait-on pas avoir plus tôt

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        Canvas.Pixels[h, w] := RGBtoColor(byte(w), byte(h), byte(w)     );

Avec ta proposition à droite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
                | img gauche  | img droite
coin bas gauche | 245  35 124 | 253   0 251
coin haut droit |   0 255 124 |   8 255   8

(aux artefacts jpg près.)

Mais de toute façon, ceci n'a aucune importance : c'est juste pour des tests de timing et de compréhension des mécanismes de scanline, alors halte au feu !

Allez, je retourne à mes cercles chromatiques...

bonsoir

pour faire avancer le shmilblick
j'ai découvert "La théorie des couleurs opposées" de Hering
c'est fort intéressant car il ne parle pas de trois couleur primaire mais de quatre

tu as une préférence pour l'arbre oû mettre la corde

Non mais lol quoi ! Je suis en train de lire la même chose ! Et si on parle du même site, évidemment je relève des trucs incompréhensibles... :


Cette chose me plaisait bien jusqu'à ce que je regarde en même temps (et armé d'un ColorPicker) cette page (en bas sur mon montage) et l'animation associée (dernier slide, en haut du montage).
Alors pour savoir quel cercle s'applique aux métiers d'art, on repassera...

[anapurna]

salut

a bin non on parle pas du meme site mais presque


leblanc jean marc.- couleur
et celui-ci
https://www.atramenta.net/lire/oeuvr...hapitre-1.html

qu'est ce que tu n'a pas compris ?

[Jipété]

a bin non on parle pas du meme site mais presque

leblanc jean marc.- couleur
et celui-ci
https://www.atramenta.net/lire/oeuvr...hapitre-1.html

Arrête, ton 1^er lien c'est exactement le contenu du site que je donne ! Compare les tables des matières et les illustrations : l'un a pompé l'autre. Et regarde l'image page 38 : il y a le logo de l'autre site ! CQFD !

Quant au 2^nd lien, il a l'air sympathique (je l'ai survolé à la va-vite).

qu'est ce que tu n'a pas compris ?

Sur la petite image (en bas dans mon montage) on peut lire "à droite la roue chromatique adoptée dans les arts de la peinture."
Et dans la capture de l'animation (haut du montage) le texte stipule que "Ce cercle chromatique (gauche) est la référence des métiers d'art."

J'ai donc fait ce montage pour pouvoir comparer le cercle gauche d'en haut et le cercle droit d'en bas, et force est de constater qu'ils sont loin d'être identiques !
Avec un ColorPicker tu pleures... Alors parler de "référence" ou d'"adoption" pour ces deux cercles, euh, comment dire...

J'aurais bien aimé lui écrire mais je n'ai pas trouvé de lien...

[anapurna]

salut

a oui cela ne m'avait pas choqué

mais tout s'explique

pour la peinture quand tu parle de couleur primaire (les pigments naturel de base)ce sont
le bleu, le jaune et le rouge (BJR)
d'ou la Roue chromatique adoptée dans les arts de la peinture
actuellement avec la sérigraphie ,l'impression et tout autre moyen de reproduction les couleurs primaire sont :
Cyan Magenta et Yellow (CMY) d'ou a mon avis la petite notes qui te trouble
Ce cercle chromatique (gauche) est la référence dans les métiers d’art

[Jipété]

Salut bonsoir,

mais tout s'explique

Parle pour toi
Bon, de toute façon, la solution n'est pas là... Lecture :

Ça fait deux jours que je me bagarre avec les conversions de/vers CIE L*a*b* et de/vers HSL pour au final confirmer ce que sevyc64 (depuis le début) et dans une moindre mesure wiwaxia (suite à expérimentations poussées) disaient, à savoir qu'il n'y a pas de solution miracle et surtout pas universelle...

Voilà d'abord des essais avec CIE L*a*b*,

et si les deux "Memo3" de gauche sont sympathiques, adieu Berthe avec ceux de droite (le mémo avec les nombres présente la couleur sélectionnée dans l'a-e-c et, de haut en bas,
- les valeurs RGB de la dite couleur
- les valeurs converties avec CIE L*a*b*, donc respectivement L*, a* et b*
- un essai d'inversion de ces valeurs)
La case à cocher "L changé" force un calcul de L du genre L := 100 - L; mais selon la couleur c'est bon ou pas...

Et même topo avec HSL (image un peu réduite) :


en haut le texte est illisible dans le mémo de droite avec ce bleu de fou :
- valeurs RGB dans le mémo central, 1^re ligne ;
- 2^e ligne = conversion vers HSL
- 3^e ligne = inversion/adaptation du L.

Image du haut alors que je n'avais pas touché la formule if L < 50 then L := 100 else L := 0; et image du bas en changeant le niveau du test : if L < 75... donne alors un bon résultat avec le bleu (je n'ai pas mis l'image, aucun intérêt, le texte est blanc et basta) mais c'est mort pour le jaune...

Voilà, quoi.
C'est assez décourageant...

La solution serait d'utiliser, comme je l'ai déjà montré, du texte "ombré" mais ça fait un peu pâté baveux dans les petits corps de police.
Pas de solution universelle, on dirait.

[anapurna]

salut

petites question si la valeur que tu cherche n'est autre que la couleur complémentaire
c'est a dire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CouleurCompl = CouleurMax-CouleurChoisie

[wiwaxia]

Petite question: si la valeur que tu cherches n'est autre que la couleur complémentaire
c'est-à-dire:
CouleurCompl = CouleurMax-CouleurChoisie

Gros ennui: à un ton proche du gris moyen (r, v, b ~ 128) correspondra une couleur quasiment indiscernable (r', v', b' ~ 128), d'où le recours incontournable à des fonctions discontinues (voir #11).

# Les systèmes de couleur des imprimeurs et des peintres concernent les surfaces éclairées, qui diffusent la lumière incidente; alors que la question initiale traite du contraste perçu sur une image apparaissant à l'écran d'un moniteur, surface émettrice de lumière.
C'est un autre domaine, vaste, intéressant et conduisant à de superbes palettes; mais je crains que ce nouveau développement ne mène à une impasse.

# L'inventivité de Jipété ne faiblit pas dès qu'il s'agit de montrer de nouvelles palettes! Mais je ne partage pas le pessimisme qu'il me prète:

... Ça fait deux jours que je me bagarre avec les conversions de/vers CIE L*a*b* et de/vers HSL pour au final confirmer ce que sevyc64 (depuis le début) et dans une moindre mesure wiwaxia (suite à expérimentations poussées) disaient, à savoir qu'il n'y a pas de solution miracle et surtout pas universelle ...

Cependant je crois me rappeler que le système HSL est lié à un expression simpliste et inappropriée de la luminance, de même que son jumeau (TSV): L_TSV = Max(r, v, b) et L_TSL = (Max(r, v, b) + Min(r, v, b)) / 2 .

Il faut s'en tenir à la relation proposée par la CIE, et chercher une solution à partir de la luminance relative (ou du niveau de gris) d'une couleur - comme cela a été suggéré assez tôt an cours de cet échange:
§ tbc92 a introduit une expression approchée de (L) (#6), puis son expression rigoureuse (#10);
§ Jipété a évoqué le niveau de gris (#34)
§ anapurna a donné le lien vers la meilleure documentation sur ces sujets (#42)
C'est de l'une ou l'autre de ces notions (étroitement liées) que l'on tirera une solution.

Je n'a pas terminè le codage des fonction inverses, faute de temps ... L'esprit est prompt, mais la chair est faible

[anapurna]

salut

tu as raison si nous raisonnons uniquement sur les couleur RVB
par contre rien ne nous empêche de réfléchir autrement.

si nous pensions plus au couleur chromatique situé sur un cercle
le blanc et le noir ne faisant pas parti de l'ensemble de ce cercle ces deux couleur servant à la saturation et la luminance

prenons le format HSL qui ce sert de ce cercle pour définir la teinte (H => HUE)
il est claire que si la luminance et/ou la saturation se trouve au borne de leur étendu il faudra jouer dessus

PS : j'ai trouvé un site permettant de faire la conversion selon le format choisie
colorizer

[Jipété]

Bonjour,

Gros ennui: à un ton proche du gris moyen (r, v, b ~ 128) correspondra une couleur quasiment indiscernable (r', v', b' ~ 128), d'où le recours incontournable à des fonctions discontinues (voir #11).

+ 1 !

Il faut s'en tenir à la relation proposée par la CIE, et chercher une solution à partir de la luminance relative (ou du niveau de gris) d'une couleur - comme cela a été suggéré assez tôt an cours de cet échange:
§ tbc92 a introduit une expression approchée de (L) (#6), puis son expression rigoureuse (#10);
§ Jipété a évoqué le niveau de gris (#34)
§ anapurna a donné le lien vers la meilleure documentation sur ces sujets (#42)
C'est de l'une ou l'autre de ces notions (étroitement liées) que l'on tirera une solution.

Jipété patauge dans les conversions...

Pour essayer d'y voir un peu plus clair (et juste !) et de comprendre pourquoi j'avais parfois des résultats qui ne me convenaient pas (sans pouvoir l'expliquer), j'ai bricolé ça à toute allure :

- un panel dont la couleur suit les réglages des 3 trackbars ;
- un poil de code :

Code pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
procedure TForm1.SetupCIELab(Sender: TObject);
begin
  CIELABtoRGB(trkL.Position, trkA.Position, trkB.Position, R,G,B);
  pnlCIELab.Color := RGBtoColor(R,G,B);
end;

Les formules qui se cachent sous CIELABtoRGB (un peu + bas) viennent de http://www.easyrgb.com/index.php?X=MATH
Et l'inspiration vient de ce graphique (honteusement pompé sur le web je ne sais plus où...) :


Pas de quoi fouetter un chat, hein, et pourtant c'est l'enfer !

Si "a" = "b" = 0, en jouant avec L de 0 à 100 on obtient un joli dégradé de noir à blanc en passant par tous les gris, c'est impec

Mais en mettant L à 100 et en jouant avec "a" seulement ("b" au milieu), -100 = violet, -90 = bleu, -80 = parme, -70 = parme clair, -60 = un bleu qui ressemble à l'autre, etc. j'arrête là c'est le foutoir total !
C'est pareil en allant vers les valeurs positives, et c'est la même pagaille en jouant avec le curseur "b".

Enfin, si "a" et "b" ne sont pas au centre (à "0"), jouer avec "L" renvoie n'importe quoi.

Où me suis-je gourré ?

Code pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
const
  ref_X =  95.047;
  ref_Y = 100.000;
  ref_Z = 108.883;
 
procedure CIELABtoXYZ(const CIEL,CIEa,CIEb: float; out X,Y,Z: float); inline;
var
  var_X, var_Y, var_Z: float;
  function ComputeaVar(aVar: float): float;
  begin
    if ( power(aVar, 3) > 0.008856 )
    then Result := power(aVar, 3)
    else Result := ( aVar - 16 / 116 ) / 7.787;
  end;
 
begin
  var_Y := ( CIEL + 16 ) / 116;
  var_X := CIEa / 500 + var_Y;
  var_Z := var_Y - CIEb / 200;
 
  X := ref_X * ComputeaVar(var_X);     //ref_X =  95.047     Observer= 2°, Illuminant= D65
  Y := ref_Y * ComputeaVar(var_Y);     //ref_Y = 100.000
  Z := ref_Z * ComputeaVar(var_Z);     //ref_Z = 108.883
end;
 
procedure XYZtoRGB(const X,Y,Z: float; out R,G,B: Byte); inline;
var
  var_R, var_G, var_B: float;
  var_X, var_Y, var_Z: float;
  function ComputeaVar(aVar: float): float;
  begin
    if ( aVar > 0.0031308 )
    then Result := 1.055 * power( aVar, ( 1 / 2.4 ) ) - 0.055
    else Result := 12.92 * aVar;
  end;
begin
  var_X := X / 100;        //X from 0 to  95.047      (Observer = 2°, Illuminant = D65)
  var_Y := Y / 100;        //Y from 0 to 100.000
  var_Z := Z / 100;        //Z from 0 to 108.883
 
  var_R := var_X *  3.2406 + var_Y * -1.5372 + var_Z * -0.4986;
  var_G := var_X * -0.9689 + var_Y *  1.8758 + var_Z *  0.0415;
  var_B := var_X *  0.0557 + var_Y * -0.2040 + var_Z *  1.0570;
 
  R := byte(round(ComputeaVar(var_R) * 255));
  G := byte(round(ComputeaVar(var_G) * 255));
  B := byte(round(ComputeaVar(var_B) * 255));
  // si 'x := round(ComputeaVar(var_x)) * 255;' les couleurs sont justes mais aucun dégradé
  // pareil avec trunc
  // avec ou sans 'byte' c'est pareil.
end;
 
procedure CIELABtoRGB(const CIEL,CIEa,CIEb: float; out R,G,B: Byte); inline;
var
  Xtmp,Ytmp,Ztmp: float;
begin
  CIELABtoXYZ(CIEL,CIEa,CIEb, Xtmp,Ytmp,Ztmp);
  XYZtoRGB(Xtmp,Ytmp,Ztmp, R,G,B);
end;

salut

tu as raison si nous raisonnons uniquement sur les couleur RVB
par contre rien ne nous empêche de réfléchir autrement.

Oui mais non : on est bien obligé, tout à la fin, de convertir les valeurs (de n'importe quel modèle, de n'importe quel espace) en R G B pour pouvoir les faire afficher à l'écran...
Quand je dis Panel.Color := aColor; il faut que aColor soit codé en RGB avec les classiques 0..255 3 fois.
C'est incontournable.

Vais jeter un œil à ton site...

[wiwaxia]

Oui mais non : on est bien obligé, tout à la fin, de convertir les valeurs (de n'importe quel modèle, de n'importe quel espace) en R G B pour pouvoir les faire afficher à l'écran ...
... C'est incontournable.

... et d'employer un paramètre tenant compte de la grande disparité des luminances intrinsèques des couleurs de base, qui sont dans les rapports:
(Lr : Lv : Lb) = (3 : 10 : 1) - voir (#44 ).

Chercher ailleurs est fort instructif et divertissant, mais c'est quand même une réaction d'évitement .

Quelqu'un pourrait-l entreprendre le tracé d'un faisceau de courbes de niveaux de gris g(r, v, b) = C^te sur l'une des faces du cube par exemple, à partir de l'expression approchée

Gray = (0.2126×Red^2.2 + 0.7152×Green^2.2 + 0.0722×Blue^2.2)^(1/2.2)
que l'on a rencontrée sur entropymine.com/imageworsener/grayscale/ ?

[Jipété]

Quelqu'un pourrait-l entreprendre le tracé d'un faisceau de courbes de niveaux de gris g(r, v, b) = C^te sur l'une des faces du cube par exemple,

cube ??? De quel cube parles-tu ?

à partir de l'expression approchée Gray = (0.2126×Red^2.2 + 0.7152×Green^2.2 + 0.0722×Blue^2.2)^(1/2.2)
que l'on a rencontrée sur entropymine.com/imageworsener/grayscale/ ?

Alors, à propos de ta formule, déjà j'aimerais bien qu'on mette les pendules à la bonne heure !
J'ai bien compris, dans toutes ces formules que j'ai vues passer, que coeff_r +coeff_g +coeff_b = 1, la preuve 0.299 + 0.587 + 0.0114 = 1, ou 0.2126 + 0.7152 + 0.00722 = 1 aussi, mais j'ai trouvé quelque part que openCV utilisait [0.212671, 0.715160, 0.072169] et il existe aussi des formules avec des décimales longues comme le bras, je vous laisse les chercher, en tout état de cause un arrondi + juste de 0.212671 serait plutôt, àmha, 0.2127 et du coup 0.715160 deviendrait 0.7151, il y aurait moins d'erreur qu'avec les nombres que tu donnes, repris partout et par tous, et je trouve bizarre de n'avoir jamais rien lu à ce propos...
Un scoop sur dvlp ?
À propos des erreurs d'arrondis, je vous invite à regarder l'animation sur ce (célèbre !) site, c'est enrichissant.

Et le résultat de ta demande montre en bas à droite qu'on "perd" le blanc :

Pour en être sûr, j'ai fait sauter mon approximation des arrondis "justes" (2127 7151) pour reprendre les arrondis "faux" (2126 7152), le résultat est identique en ce qui concerne la perte du blanc,

Le gag, c'est selon où on met les parenthèses...
L'image ci-dessus a été générée avec

Code pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

Result := round( power (0.2127*power(Ri ,2.2) + 0.7151*power(Gi, 2.2) + 0.114*power(Bi, 2.2), (1 / 2.2) ));

et le petit bout ci-dessous avec

Code pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

Result := round( power (power(0.2127*Ri, 2.2) + power(0.7151*Gi, 2.2) + power(0.114*Bi, 2.2), (1 / 2.2) ));

In fine, quand je lis

0.2126×Red^2.2

est-ce que je dois comprendre 0.2126×(Red^2.2) ou (0.2126×Red)^2.2 ?

[anapurna]

salut

un autre site intéressant sur les niveaux de gris

grayscale

ok c'est du vb mais cela ne le rend pas moins intéressant

[sevyc64]

# Les systèmes de couleur des imprimeurs et des peintres concernent les surfaces éclairées, qui diffusent la lumière incidente; alors que la question initiale traite du contraste perçu sur une image apparaissant à l'écran d'un moniteur, surface émettrice de lumière.

En lumière émise (écrans, ampoules, projecteur, etc....) on utilise la gamme RVB (Rouge Vert Bleu), l'absence de couleur donne du noir, la somme des trois couleur donne du blanc

En lumière réfléchie (plus exactement en lumière absorbée, puis que st réfléchie celle qui n'est pas absorbée), soit tout ce qui est imprimé, peint, les objets et la nature elle-même, on utilise la gamme CMJ (Cyan, Magenta, Jaune). L'absence de couleur donne du blanc, la somme des couleurs donne du Noir.

Dans chacune des gammes, le mélange de ces 3 couleurs permet de reproduire toutes les couleurs possibles.

A la gamme CMJ est souvent rajouté le Noir pour donner plus de profondeur, à la gamme RVB est rajouté une notion de transparence au contraire.

[wiwaxia]

cube ??? De quel cube parles-tu ?

Du cube de couleurs, dont les coordonnées des points varient entre (0) et (255).

Alors, à propos de ta formule, déjà j'aimerais bien qu'on mette les pendules à la bonne heure !

C'est déjà fait: je prends les données du site indiqué, qui apporte les explications les plus détaillées et apparaît digne de confiance (on a déjà parlé de tout cela #48 , 28/01/2017, 18h00 ).
J'ajoute que mégoter sur la 4^me ou 5^me décimale d'un coefficient, dans une formule approchée qui de surcroît conduit à un entier au plus égal à 255 (soit au mieux 3 chiffres significatifs), cela me paraît aussi pertinent que certaines disputes médiévales, sur la question de savoir combien d'anges pouvaient poser le pied sur une tête d'épingle.

le résultat est identique en ce qui concerne la perte du blanc,

La fonction Round(.) a encore frappé !

In fine, quand je lis 0.2126×Red^2.2
est-ce que je dois comprendre 0.2126×(Red2.2) ou (0.2126×Red)2.2 ?

Il n'y a aucune ambiguïté, parce que l'exponentiation ne concerne que le terme qui précède:
0.2126×Red^2.2 = 0.2126×(Red^2.2) = 0.2126×(Red^2.2)

Le gag, c'est selon où on met les parenthèses ...

Évidemment, puisqu'on change de fonction et le déchiffrage n'a rien d'amusant.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Result := round( power (0.2127*power(Ri ,2.2) + 0.7151*power(Gi, 2.2) + 0.114*power(Bi, 2.2), (1 / 2.2) ));
 
Result := round( power (power(0.2127*Ri, 2.2) + power(0.7151*Gi, 2.2) + power(0.114*Bi, 2.2), (1 / 2.2) ));

Quand tu auras compris que les fonctions emboîtées sont inintelligibles et un repaire potentiel de bogues, tu auras accompli un pas de géant dans la rédaction de tes codes.
La séquence

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Result := round( power (0.2127*power(Ri ,2.2) + 0.7151*power(Gi, 2.2) + 0.114*power(Bi, 2.2), (1 / 2.2) ));

doit être impérativement remplacée par une série d'instructions comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
T1:= 0.2127*power(Ri ,2.2); T2:= 0.7151*power(Gi, 2.2);
T3:= 0.1140*power(Bi, 2.2); N1:= 1 / 2.2;
Result := round( power (T1 + T2 + T3, N1 ));

Et encore, je me retiens d'en rajouter ...
Je considère les 3 premières instructions comme incorrectes - mais cela nous mènerait trop loin.
Une somme de (n) produits se calcule aisément par le produit scalaire de 2 vecteurs de dimension (n), sans que surviennent les lourdeurs précédentes.

[Jipété]

HS : désolé de ne pas avoir répondu plus tôt, mais le système de messagerie de mon FAI a cafouillé : je reçois ce soir les mails m'informant des entrées de ce midi... /HS

La fonction Round(.) a encore frappé !

La fonction Round est utilisée pour toutes les images en niveaux de gris que j'ai présentées ce midi...

Quand tu auras compris que les fonctions emboîtées sont inintelligibles et un repaire potentiel de bogues, tu auras accompli un pas de géant dans la rédaction de tes codes.
La séquence

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Result := round( power (0.2127*power(Ri ,2.2) + 0.7151*power(Gi, 2.2) + 0.114*power(Bi, 2.2), (1 / 2.2) ));

doit être impérativement remplacée par une série d'instructions comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
T1:= 0.2127*power(Ri ,2.2); T2:= 0.7151*power(Gi, 2.2);
T3:= 0.1140*power(Bi, 2.2); N1:= 1 / 2.2;
Result := round( power (T1 + T2 + T3, N1 ));

Tiens, cadeau, j'ai réécrit ma ligne :

Code pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
        pR := 0.2127 * power(Ri, 2.2);
        pG := 0.7151 * power(Gi, 2.2);
        pB := 0.1140 * power(Bi, 2.2);
        pTot := pR + pG + pB;
        N1 := 1 / 2.2;
        Result := round( power(pTot, N1)); // test wiwaxia

et le résultat est le même, perte du blanc transformé en noir...

EDIT : je viens de me taper les calculs pour le blanc (255 255 255) à la calculette, j'arrive à un Result de 259,65 donc je dépasse l'étendue du Byte d'où le noir, qui d'ailleurs n'en est pas un ; si j'avais regardé au ColorPicker, j'aurais vu 4 4 4 ! Et on retrouve ce que j'ai lu par ci par là aujourd'hui, certaines formules peuvent renvoyer des valeurs en dehors de l'étendue du Byte et donc, remplacer la dernière ligne par

Code Pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
        resultat := power(pTot, N1); // test wiwaxia
        if resultat > 255 then Result := 255 else Result := round(resultat);

fait revenir le blanc en 1^re colonne, mais la bande à sa droite est bien claire quand on compare avec les autres images...


EDIT2 : Un autre essai avec ce joli dégradé sensé avoir des couleurs de même intensité lumineuse (je ne sais plus comment appeler ça, à force )

Code pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{en haut à gauche} round(0.5*(max(max(Ri,Gi),Bi)+min(min(Ri,Gi),Bi))); // Lightness Gimp
{en haut à droite} (Ri+Gi+Bi) div 3; // Average Gimp
//dessous de g à d :
round( (0.2127*Ri) + (0.7151*Gi) + (0.0722*Bi) ); // moi
round( (0.297 *Ri) + (0.589 *Gi) + (0.114 *Bi) ); // povray
round( (0.299 *Ri) + (0.587 *Gi) + (0.114 *Bi) ); // matlab, télévision analogique
//dessous :
round( (0.3   *Ri) + (0.59  *Gi) + (0.11  *Bi) ); // intel
round( (0.34  *Ri) + (0.5   *Gi) + (0.16  *Bi) ); // utilisé par http://podeplace.blogspot.fr
//et pour finir, à gauche :
round( (0.297*power((Ri + 14),2.4) + power((Gi + 14),2.4) + 0.101*power((Bi + 14),2.4) )* K);  // wiwaxia
//à droite
pR := 0.2127 * power(Ri, 2.2);
pG := 0.7151 * power(Gi, 2.2);
pB := 0.1140 * power(Bi, 2.2);
pTot := pR + pG + pB;
N1 := 1 / 2.2;
resultat := power(pTot, N1); // test wiwaxia
if resultat > 255 then Result := 255 else Result := round(resultat);

Allez, c'est tout pour ce soir.

[wiwaxia]

Bonjour,

Je vois que tu as fait un effort, alors je répond rapidement avant de boucler les bagages (et le portable).
La fin de mon précédent message était rigoureusement exacte, mais à la limite de la cuistrerie dans le contexte du forum; l'irritation (légitime) consécutive au déchiffrement de ton instruction en train de marchandise

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Result:= ... (passons)

a été bien près de me faire céder à ma grossièreté naturelle - j'avais des circonstances largement atténuantes.

1°) Un programme source est fait pour être lu et compris par son auteur (6 mois après, c'est moins évident ...) et par tous les intéressés (ayant à priori une formation appropriée); à ce titre, ce que tu as écrit était franchement irrecevable, indépendamment de l'algorithme sous-jacent, en raison de l'accumulation extravagante des parenthèses.
Un code compact, dont on ne peut repérer les étapes au premier coup d'oeuil, est à rejeter d'office.
Le bloc d'instructions proposé en remplacement constituait un minimum d'urgence, le découpage mental auquel était astreint le lecteur pour comprendre le contenu de la ligne.

2°) Il y a d'autre part l'utilisation des fonctions, qui doit se conformer à la syntaxe (aux règles de grammaire) du langage, et se présenter sous la forme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Variable:= FonctionA(x, y, z)

Des expressions du type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

s:= 0.478* Fonction1(x) + 4.52 * Fonction2(y) ...

sont malheureusement courantes, et motivées par un désir mal compris de concision et de rapidité.
Mais c'est s'en remettre à la tolérance du logiciel, prendre le risque de bogues invisibles et compliquer singulièrement la recherche des causes de plantage ou de dysfonctionnement.

Et puisqu'un produit scalaire en dimension (n) a été pompeusement évoqué, de quoi s'agit-il ? Du produit terme à terme, suivi d'une sommation, sur deux listes comportant (n) éléments, et que l'on peut considérer formellement comme des "vecteurs".
Ta nouvelle version, tout à fait claire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
        pR := 0.2127 * power(Ri, 2.2);
        pG := 0.7151 * power(Gi, 2.2);
        pB := 0.1140 * power(Bi, 2.2);
        pTot := pR + pG + pB;
        N1 := 1 / 2.2;
        Result := round( power(pTot, N1)); // test wiwaxia

s'insère facilement dans un ensemble un peu plus vaste, où l'on peut facilement modifier des données numériques:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
TYPE Lst3R = ARRAY[1..3] OF Extended;          // Liste de 3 réels  
CONST N0 = 2.2; N1 = 1 / 2.2;
      Coeff: Lst3R = (0.2127, 0.7151, 0.1140);
VAR i: Byte; Ng: LongInt; p, s, t: Extended;
    Tlin: Lst3R;          // Liste des 3 termes linéaires
BEGIN
  Tlin[1]:= power(Ri, N0);          // Initialisation de la liste des termes linéaires
  Tlin[2]:= power(Gi, N0);
  Tlin[3]:= power(Bi, N0);     
  s:= Coeff[1] * Tlin[1];           // Initialisation de la somme
  FOR i:= 2 TO 3 DO BEGIN
                        p:= Coeff[i] * Tlin[i];
                        t:= s + p; s:= t
                    END;
  p:= power(s, N1);          // Calcul du niveau de gris - réel = somme^(1/2.2)
  Ng:= Round(p)              // Le niveau de gris (Ng) déclaré par précaution LongInt - le résultat peut sortir de [0..255]
END;

Tu rectifieras les éventuelles erreurs de détail, le temps me manque pour les filtrer.

[tbc92]

Pour l'histoire du calcul qui donne 259.65... et donc un nombre supérieur à 255...
Je vois circuler plein de formules qui se ressemblent plus ou moins :

D'abord : Gray = (0.2126×Red^2.2 + 0.7152×Green^2.2 + 0.0722×Blue^2.2)^(1/2.2)
Et maintenant : Result := round( power (0.2127*power(Ri ,2.2) + 0.7151*power(Gi, 2.2) + 0.114*power(Bi, 2.2), (1 / 2.2) ));

Les 2 premiers coefficients sont quasiment les mêmes, et le 3ème passe de 0.0722 à 0.114.
Dans ces formules, Blue Red Green sont des nombres qui varient entre 0 et 255 ou bien entre 0 et 1 ... ça simplifie le calcul.
Si Blue = Red = Green = la valeur maxi, la base pour que la formule soit valide, c'est que le résultat soit 0 ( ou 255 si on a une échelle de 0 à 255).
Et donc la contrainte n°1, c'est que la somme des 3 coeffs soit 1.
0.2126 + 0.7152+0.0722 = 1 --> Ok
0.2127+0.7151+0114 > 1 --> pas Ok : Cette formule ne peut pas donner des résultats sains.