Discussion :

[wiwaxia]

Bonjour,

@ sevyc64
La dernières indication du texte auquel renvoyait ton lien ( www.w3.org/TR/WCAG20-TECHS/G17.html )

Calculate the contrast ratio using the following formula: (L1 + 0.05) / (L2 + 0.05), where

# L1 is the relative luminance of the lighter of the foreground or background colors, and

# L2 is the relative luminance of the darker of the foreground or background colors.

Check that the contrast ratio is equal to or greater than 7:1

conduit en fait aux résultats suivants:
a) Une couleur quelconque présentera un contraste suffisant avec le noir (L_noir = 0) si sa luminance relative dépasse un certain seuil et vérifie la condition:
(L + 0.05)/(0 + 0.05) > 7 , soit: L > 7*0.05 - 0.05 et pour la luminance un minimum: L_min = 0.30 ;
b) La même couleur contrastera suffisamment avec le blanc (L_blanc = 1 , valeur maximale) si elle apparaît nettement plus sombre et vérifie la condition symétrique: (1 + 0.05)/(L + 0.05) > 7 , d'où: L < 1.05/7 - 0.05 ; la luminance ne doit pas alors dépasser la limite L_max = 0.10 .

Les valeurs trouvées pour les 2 bornes sont malheureusement incompatibles (L_max < L_min), il n'y a pas de domaine de luminance sur lequel les critères seraient simultanément vérifiés.

Un compromis est cependant envisageable, par la recherche d'un rapport commun:
k = (L + 0.05)/(0 + 0.05) = (1 + 0.05)/(L + 0.05)
qui conduit à: (L + 0.05)² = 1.05 * 0.05 = 0.0525 et au seuil de luminance: L_lim = Sqrt(0.0525) - 0.05 = 0.18
correspondant au rapport: k = 4.58 , inférieur au précédent: le critère apparaît moins exigeant, mais fournit une limite entre couleurs sombres et claires.

PS: Je viens de retrouver un lien que je cherchais depuis quelques jours, sur la luminosité et la clarté, ou leucie.

[anapurna]

salut

peut être un liens qui pourrais t'intéresser grayscale

[Jipété]

PS: Je viens de retrouver un lien que je cherchais depuis quelques jours, sur la luminosité et la clarté, ou leucie.

Ça plus les autres liens donnés précédemment, j'ai de la lecture ce week-end !

Plus l'ami anapurna qui me casse le moral avec sa page très bien faite (sans compter que tout le reste du site a l'air très intéressant...)

peut-être un lien qui pourrait t'intéresser grayscale

car hélas, on y trouve

Note that while this formula produces arguably the best possible results from an objective technical perspective, that doesn’t mean its results always look the best subjectively. Other formulas have been devised that may give better-looking results for specific images.

Comment s'en sortir ?
À priori quelque chose de 100 % automatique n'est pas envisageable, on dirait, car subjectivement il y aura des couleurs avec lesquelles ça ne le fera pas, et il faudra mettre les mains dans le cambouis... En première approche, je verrais bien un curseur qui déplacerait le seuil de basculement noir-blanc, comme j'avais bricolé il y a quelques jours.
"100 fois sur le métier" vous connaissez la suite

PS : à propos du site cité par ana, vous noterez que ses couleurs ne sont pas pures, par exemple son rouge est à 255 25 0, son jaune à 255 240 0 son vert à 0 216 0 ! Pourquoi ? Il ne le dit pas...

[wiwaxia]

Bonsoir,

La recherche du niveau de gris équivaut à celle de la luminance, parce que celle-ci ne dépend plus alors que d'un seul indice de couleur (g); et c'est au départ une bonne idée, dans la mesure où il s'agit d'une moyenne pondérée, ce que tout lecteur comprend intuitivement.
L'affaire se corse dès que l'on entreprend d'y regarder d'un peu plus près; l'égalité des luminances de la couleur considérée (r, v, b) et du gris équivalent (g, g, g): L(r, v, b) = L(g, g, g)
devient, si l'on reprend la relation standard proposée par la CIE et pour des indices de couleur tous supérieurs à 10⁽¹⁾
(g + h)^2.4 = 0.2126 * (r + h)^2.4 + 0.7152 * (v + h)^2.4 + 0.0722 * (b + h)^2.4 , en posant h = 255 * 0.055 = 14.025 ;
d'où le niveau de gris équivalent:
g = [0.2126 * (r + h)^2.4 + 0.7152 * (v + h)^2.4 + 0.0722 * (b + h)^2.4]^(1/2.4) - h
résultat de nature à faire fuir la majorité des internautes ...
(1) Déjà une restriction !
C'est donc, en théorie, reculer pour mieux sauter ...

Le site indiqué par anapurna donne quelques relations, sans aucune indication de provenance; il les présente cependant clairement comme des recettes imparfaites, ne donnant pas partout de bon résultats; et il les donne par ordre de complexité croissante:

Gray = (Red + Green + Blue)/3
Gray = 0.299×Red + 0.587×Green + 0.114×Blue (?)
Gray = 0.2126×Red + 0.7152×Green + 0.0722×Blue
Gray = (0.2126×Red^2.2 + 0.7152×Green^2.2 + 0.0722×Blue^2.2)^(1/2.2)

On devine le rapprochement progressif avec la formule standard - si l'on a eu l'occasion de la lire ...
Un seul reproche: quitte à prendre le parti de la simplicité - et là l'auteur ne s'en prive pas - pourquoi s'encombrer de données à 4 décimales ? Observant que 2126/722 = 2.94 ~ 3 et que 7152/722 = 9.91 ~ 10 , j'aurais écrit:
g = ((3 * rⁿ + 10 * vⁿ + bⁿ)/14)^(1/n) en posant n = 2.2 - Au fait, pourquoi pas 2.4 ? Ça, c'est une autre histoire ... sans doute pour compenser la disparition du terme constant (h) ?

... PS : à propos du site cité par ana, vous noterez que ses couleurs ne sont pas pures, par exemple son rouge est à 255 25 0, son jaune à 255 240 0 son vert à 0 216 0 ! Pourquoi ? Il ne le dit pas ...

Là, tu te montres encore plus mesquin que moi ...

[wiwaxia]

... À priori quelque chose de 100 % automatique n'est pas envisageable, on dirait, car subjectivement il y aura des couleurs avec lesquelles ça ne le fera pas, et il faudra mettre les mains dans le cambouis... En première approche, je verrais bien un curseur qui déplacerait le seuil de basculement noir-blanc, comme j'avais bricolé il y a quelques jours.
"100 fois sur le métier" vous connaissez la suite ...

La seule manière de vérifier la pertinence des tests proposés, c'est d'explorer le domaine des couleurs et d'établir quelques palettes bidimensionnelles de contraste.
J'ai pris les 3 plans de symétrie du cube admettant pour intersection l'axe chromatique, et contenant par conséquent l'origine du repère (0,0,0) et le point blanc (255,255, 255), diamétralement opposé.
Le contour de l'intérieur du domaine est un rectangle de dimensions (l, L = l*Rac(2)), construit sur deux arêtes et deux diagonales des faces opposées.
Les dimensions de l'image sont prises dans le rapport (17/12), valeur rationnelle la plus proche de Rac(2) dans le cas de petits entiers ne dépassant pas (40) .

Code :

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

1
2
3
4
5
6
7
8
 
 q:        p:        |p - q*Rac(2)|
 
  2         3        0.172
  5         7        0.0711
 12        17        0.0294
 29        41        0.0122
 70        99        0.00505

Vous repérerez les sommets colorés du cube, qui présentent des teintes complémentaires (Rouge/Cyan, Vert/Pourpre, Bleu/Jaune). Le texte est un peu fruste, mais le temps m'a manqué pour faire mieux.
On y voit les régions d'estompement du noir et du blanc, avec l'inévitable zone de transition.



L'idéal eût été d'y superposer quelques courbes de luminance (ou de niveau de gris⁽¹⁾) constants, mais la programmation des fonctions réciproques (par ex. r = F(L, v, b) s'est révélée franchement hyperch pénible.
(1): C'est peut-être une bonne piste, sous réserve de vérification.

[Jipété]

Bonjour,

Autant j'ai apprécié ton post de la nuit, autant celui de ce matin avec ses tapis de douche, tu m'as complètement perdu, largué à des profondeurs insoupçonnées. Pour faire court et simple, je n'ai absolument rien compris -- bon, ok, je ne suis pas un critère de qualité, je suis juste le béotien lambda qui s'intéresse à mettre un texte sur une image en visant la meilleure lisibilité possible.


Avec tous ces liens, un truc s'est quand même télescopé, tout à l'heure ; dans le lien de sevyc64, on peut lire, en bas, rubrique "procedure", ça :

Measure the relative luminance of each letter (unless they are all uniform) using the formula:
L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:
if R sRGB <= 0.03928 then R = R sRGB /12.92 else R = ((R sRGB +0.055)/1.055) ^ 2.4

(Je ne mets que la ligne "R" pour ne pas alourdir)

Et en fouillant sur le site donné par ana, dans l'article A close look at the sRGB formula rubrique "0.03928?" en bas, je lis

In any case, there’s certainly no reason to use 0.03928 together with 12.92.

Que faire, alors, avec la formule précédente ?...
Bon sang, où est mon aspirine ??????????????????????

[wiwaxia]

... Autant j'ai apprécié ton post de la nuit, autant celui de ce matin avec ses tapis de douche, tu m'as complètement perdu, largué à des profondeurs insoupçonnées. Pour faire court et simple, je n'ai absolument rien compris ...

Chaque couronne circulaire a été partagée en deux zones (noire et blanche) afin de ne pas envoyer deux fois plus d'images, l'une ne comportant que des "O" blancs, et l'autre que des noirs. Je jugeais l'ensemble assez encombrant comme cela, d'autant que j'aurais pu y ajouter les 3 faces du cube adjacentes à l'origine (pour ne s'en tenir qu'à celles présentant les plus sombres teintes).
Mais il est vrai que cela peut compliquer le discernement des régions de contraste net du blanc (ou du noir) sur le fond coloré.



Il y a bien deux zones de fort contraste pour les deux sortes de caractères, mais dont les frontières (ici grossièrement tracées) ne coïncident pas: c'est là qu'interviendra l'appréciation personnelle, pour le choix d'une limite intermédiaire.

Contrainte indispensable pour des résultats cohérents: les frontières choisies dans tous les plans possibles (ici bleu-jaune, d'équation r = v) doivent vérifier la même relation générale: g = F(r, v, b) = C^te .
Les exemples ne manquent pas: voir la braderie proposée sur les précédents liens.

Je tâcherai de mettre au point de nouveaux tapis de douche, dotés d'un faisceau de courbes de niveau, et toujours exemptés de TVA.

[wiwaxia]

... Avec tous ces liens, un truc s'est quand même télescopé, tout à l'heure ; dans le lien de sevyc64, on peut lire, en bas, rubrique "procedure", ça :
Measure the relative luminance of each letter (unless they are all uniform) using the formula:
L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:
if R sRGB <= 0.03928 then R = R sRGB /12.92 else R = ((R sRGB +0.055)/1.055) ^ 2.4
(Je ne mets que la ligne "R" pour ne pas alourdir)

Et en fouillant sur le site donné par ana, dans l'article A close look at the sRGB formula rubrique "0.03928?" en bas, je lis

In any case, there’s certainly no reason to use 0.03928 together with 12.92.

Que faire, alors, avec la formule précédente ?...
Bon sang, où est mon aspirine ??????????????????????

J'ai effectivement perçu un flottement sur la valeur de la limite (~0.4) lors du codage numérique de la fonction luminance; il ne m'a pas inquiété dans la mesure où:
a) il s'agit d'une borne séparant deux domaines, qui n'intervient pas dans le calcul mais découle au contraire de la confrontation de deux équations;
b) les écarts observés sont faibles (0.03928 | 0.04045), et plus encore ceux ceux qui en découlent sur (L);
c) les indices de couleur sont des variables entières, pour lesquelles la frontière demeure inchangée:
I₀ = Floor(255 * 0.03928) = Floor(10.01640) = 10 ;
I'₀ = Floor(255 * 0.04045) = Floor(10.31475) = 10 .

J'ai d'autre part repris par curiosité le calcul de la racine de l'équation: s/K = ((s + 0.055)/1.055)^2.4
en cherchant la limite de la suite u_n+1 = 1.055(u_n/K)^(5/12) - 0.055 , en prenant K = 12.92 et u₀ = 0.04044 .
La convergence est assez lente; ma calculette a cependant donné au bout de 886 itérations:
s = 0.040 448 236 277 566 et y = 0.0031 306 684 425 361 .
Arrêtons-là le délire calculatoire, pour en revenir à l'incertitude incompressible des coefficients, qui découlent d'un grand nombre de valeurs expérimentales: K = 12.92 , s = 0.04045 et y = 0.003131 - soit 4 chiffres significatifs.

# L'article de Wikipédia déjà cité donnait déjà des informations sur les conditions de raccordement (continuité de la fonction et de sa dérivée première); voir § Theory of the transformation.
# Celui de W3.org, quoique bien résumé, citait la valeur contestée (0.03928).
# La page du dernier site m'avait échappé, et sort de l'ordinaire: il n'est pas fréquent qu'un informaticien se livre à une analyse numérique aussi poussée d'un système d'équations.
Un grand , donc, à anapurna dont l'information nous a finalement permis de connaître cette mise au point.

[Jipété]

Mais il est vrai que cela peut compliquer le discernement des régions de contraste net du blanc (ou du noir) sur le fond coloré.

C'est fou comme deux bêtes traits colorés ça change la vie et la comprenette du fourbi

Je tâcherai de mettre au point de nouveaux tapis de douche, dotés d'un faisceau de courbes de niveau, et toujours exemptés de TVA.

[...]
# Celui de W3.org, quoique bien résumé, citait la valeur contestée (0.03928).
# La page du dernier site m'avait échappé, et sort de l'ordinaire: il n'est pas fréquent qu'un informaticien se livre à une analyse numérique aussi poussée d'un système d'équations.

Oui, et c'est exactement ce que je disais : un site préconise une formule et un autre site en démonte (sans "r") la moitié : qu'est-ce qu'on fait ?

Et pendant qu'on est dans les formules, j'en ai une qui me sort un résultat hallucinant avec les patches de couleurs découverts hier (et pour lesquels j'ai forcé les couleurs au taquet : le vert est 0 255 0 par ex, et idem pour les autres) : regardez la dernière image, en bas à droite, elle est calculée avec round(0.34 *Ri) + round(0.5 *Gi) + round(0.16 *Bi); et son rendu du blanc est complètement noir !, à comparer avec l'image à sa gauche où le blanc est blanc avec des valeurs de formule assez proches : round(0.3 *Ri) + round(0.59 *Gi) + round(0.11 *Bi); // intel...



En attendant une réponse à la question en gras un poil au-dessus, j'ai joué un peu avec une idée qui me trottait dans la tête... D'abord l'image :


et ensuite le test que j'ai fait : sur le fond rouge,

• si j'enlève la ligne de code qui écrit en blanc, les lettres "ste" en bas à droite sont illisibles ;
• si j'enlève la ligne de code qui écrit en noir, les lettres "Co" en haut à gauche sont illisibles.

Je vais un peu laisser reposer avant d'enfourner...

Ah, les patches, si d'aventure quelqu'un voulait jouer avec (fichier zip, le forum n'aime pas les tifs) : testcardtif128.zip

[wiwaxia]

... Et pendant qu'on est dans les formules, j'en ai une qui me sort un résultat hallucinant avec les patches de couleurs découverts hier (et pour lesquels j'ai forcé les couleurs au taquet : le vert est 0 255 0 par ex, et idem pour les autres) : regardez la dernière image, en bas à droite, elle est calculée avec round(0.34 *Ri) + round(0.5 *Gi) + round(0.16 *Bi); et son rendu du blanc est complètement noir !, à comparer avec l'image à sa gauche où le blanc est blanc avec des valeurs de formule assez proches : round(0.3 *Ri) + round(0.59 *Gi) + round(0.11 *Bi); // intel...
...

F₁(255, 255, 255) = Round(0.34*255) + Round(0.50*255) + Round(0.16*255) = Round(86.7) + Round(127.5) + Round(40.8) = 87 + 128 + 41 = 256 = 0 (Mod 256)

F₂(255, 255, 255) = Round(0.30*255) + Round(0.59*255) + Round(0.11*255) = Round(76.5) + Round(150.45) + Round(28.05) = 77 + 150 + 28 = 255

Élémentaire, Watson.

Je te propose un petit jeu: colorier une grille triangulaire 101x101 en couleurs selon les 3 valeurs du résultat donné par la formule:
s = F(i, j) = Round(2.55 * i) + Round(2.55 * j) + Round(2.55 * (100 - i - j))
avec (s, i, j) de type Word et (i + j)<101
et qui, lorsque les "Round(.)" s'évaporent, donne 255.

[Jipété]

Salut,

F₁(255, 255, 255) = Round(0.34*255) + Round(0.50*255) + Round(0.16*255) = Round(86.7) + Round(127.5) + Round(40.8) = 87 + 128 + 41 = 256 = 0 (Mod 256)
Élémentaire, Watson.

C'est bien quand on a affaire à un matheux et qu'il explique avec des couleurs : on comprend tout

Et donc, l'abus de "round" nuit, à consommer avec modération :
F₁(255, 255, 255) = Round(0.34*255) + Round(0.50*255) + Round(0.16*255) = Round(86.7) + Round(127.5) + Round(40.8) = round(86.7 + 127.5 + 40.8) = round(255) = 255Alors méfiance partout !
(va falloir que je repasse sur tous mes codes ! Tu parles d'un dimanche...)

En attendant, je récupère un blanc bien blanc à droite, c'est Coluche (RIP) qui serait content :

Mais la différence entre le vert (col4) et le pourpre (col5) n'est pas vraiment flagrante, hein ! Cette formule m'énerve...

Je te propose un petit jeu: colorier une grille triangulaire 101x101

C'est quoi une grille triangulaire ?

[wiwaxia]

... C'est quoi une grille triangulaire ?

Un tableau carré dont on ne s'occupe pas des termes situés en-dessous de la 2^de diagonale, d'équation (i + j) = Cons^te .
Par exemple en codant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 ...
CONST Max = 100;
TYPE Mat = ARRAY[0..Max] OF Word;
VAR i, j, s: Word;
    Grille: Mat;
...
FOR i:= 0 TO Max DO
  FOR j:= 0 TO Max DO
    BEGIN
 ...
      IF ((i + j)>Max) THEN Grille[i, j]:= 0
    END;

J'aurais dû être plus clair.

... Et donc, l'abus de "round" nuit, à consommer avec modération :
F₁(255, 255, 255) = Round(0.34*255) + Round(0.50*255) + Round(0.16*255) = Round(86.7) + Round(127.5) + Round(40.8) = round(86.7 + 127.5 + 40.8) = round(255) = 255Alors méfiance partout ! ...

Bon réflexe.

[Jipété]

Je te propose un petit jeu: colorier une grille triangulaire 101x101 en couleurs selon les 3 valeurs du résultat donné par la formule:
s = F(i, j) = Round(2.55 * i) + Round(2.55 * j) + Round(2.55 * (100 - i - j))
avec (s, i, j) de type Word et (i + j)<101
et qui, lorsque les "Round(.)" s'évaporent, donne 255.

J'arrive à ça :

C'est ce à quoi tu pensais ? J'avoue ne pas bien capter ce que tu entends par lorsque les "Round(.)" s'évaporent...

The code, avec un TImage de 101 x 101 sur la fiche :

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
procedure TForm1.Button2Click(Sender: TObject);
CONST Max = 101; //100;
//TYPE Mat = ARRAY[0..Max] OF Word;
TYPE Mat = ARRAY of ARRAY OF Word;
VAR i, j, s: Word;
    Grille: Mat;
    aBuf: TBitmap;
begin
  aBuf := TBitmap.Create;
  SetLength(Grille, Max, Max);
  with aBuf do begin
    PixelFormat := pf24bit;
    SetSize(imgWiwaxia.WIDTH, imgWiwaxia.HEIGHT);
    FOR i:= 0 TO Max-1 DO
      FOR j:= 0 TO Max-1 DO
        BEGIN
          s := 0;
          IF ((i + j)>Max) THEN Grille[i,j]:= s
            else s := Round(2.55 * i) + Round(2.55 * j) + Round(2.55 * (Max-1 - i - j));
          aBuf.Canvas.Pixels[i,j] := s;
        END;
    imgWiwaxia.Canvas.Draw(0,0,aBuf);
    Free;
  end;
end;

Tu noteras qu'il a fallu que je bidouille tes définitions car il n'est pas possible d'avoir Grille[i, j] avec TYPE Mat = ARRAY[0..Max] OF Word;...
Y a un truc qui ne tourne pas rond entre "s", Grille[i, j] et aBuf.Canvas.Pixels[i,j]...
Mais comme je ne suis pas dans ta tête...

[wiwaxia]

En gros, c'est ça ... à quelques anomalies près décelables sur l'image agrandie.

Je m'attendais à quelque chose de ce genre (en adaptant certains types de variables):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
    FOR i:= 0 TO Max-1 DO
      FOR j:= 0 TO Max-1 DO
        BEGIN              
          IF ((i + j)>=Max) THEN Grille[i,j]:= 0     // Couleur noire
                            ELSE BEGIN
                                   s := Round(2.55 * i) + Round(2.55 * j) + Round(2.55 * (Max-1 - i - j));
                                   IF (s=255) THEN Grille[i,j]:= Icouleur2
                                               ELSE IF (s<255) THEN Grille[i,j]:= Icouleur1
                                                               ELSE Grille[i,j]:= Icouleur3
                                 END
           aBuf.Canvas.Pixels[i,j] := Grille[i, j]     // Je ne connais pas cette instruction
        END;

Attention à la condition sur la diagonale !

J'avoue ne pas bien capter ce que tu entends par lorsque les "Round(.)" s'évaporent...

Le résultat est selon les cas 254, 255 ou 256 lors que l'expression purgée de toutes les fonction d'arrondi vaut toujours 255 .
Une illustration de la pagaille qui peut s'introduire avec les fonctions discontinues.

[Jipété]

En gros, c'est ça ... à quelques anomalies près décelables sur l'image agrandie.

J'ai repris ton dernier code texto, j'obtiens ça (agrandi) :

Attention à la condition sur la diagonale !

Code :

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

           aBuf.Canvas.Pixels[i,j] := Grille[i, j]     // Je ne connais pas cette instruction

Expliqué dans le code :

Code pascal :

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

1
2
3
4
5
6
7
8
          IF ((i + j)>=Max) THEN Grille[i,j]:= 0  // Couleur noire
            else begin
              s := Round(2.55 * i) + Round(2.55 * j) + Round(2.55 * (Max-1 - i - j));
              IF (s=255) THEN Grille[i,j]:= clYellow
                           ELSE IF (s<255) THEN Grille[i,j]:= clGreen
                                           ELSE Grille[i,j]:= clRed;
            end;
          aBuf.Canvas.Pixels[i,j] := Grille[i,j]; // pour mettre la couleur dans le bitmap, qui sera transféré dans le TImage pour affichage, en fin de boucle

Attention, ce aBuf.Canvas.Pixels[i,j] := couleur; est épouvantablement bouffeur de ressources et ne peut être utilisé que pour des petits tests (comme ici), à partir de 300x300 ça commence à ramer et au-delà c'est inexploitable : faut passer par les ScanLines.

[wiwaxia]

Bonsoir,

L'image donne une répartition probable des valeurs "accidentelles" (s <> 255). Quelques rectifications pourraient améliorer le code.

# D'abord une erreur que je viens de trouver dans le code initial, et que tu as contournée: le type (Mat) correspond à un tableau à 2 dimensions, j'aurais donc dû écrire quelque chose du genre:

Code :

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

TYPE Mat = ARRAY[N1..N2, N1..N2] OF Word;

et comme tu tiens à partir de zéro et à retrouver (Max) éléments dans chaque ligne et chaque colonne:

Code :

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

TYPE Mat = ARRAY[0..(Max-1), 0..(Max-1)] OF Word;

# la zone triangulaire occupée s'étend jusqu'aux 2 sommets (0, Max-1), (Max-1, 0) et inclut les cases rangées en diagonale, vérifiant (i + j) = (Max-1) , d'où la condition d'exclusion:

Code :

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

IF ((i + j)>=Max) THEN Grille[i,j]:= 0  // Couleur noire

liée au choix des bornes.

# Il me semble me rappeler que la création des images bitmap ne te posait pas de problèmes, et je te proposais une matrice pour faciliter le passage à la variable (TBitmap ?) utilisée dans ton programme.
La variable (Grille) ne ferait-elle pas double emploi ? Ne pourrais-tu pas t'en passer ?
Curieusement, la constante (Max) n'intervient pas dans la définition de ton type de tableau:

Code :

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

1
2
CONST Max = 101; //100;
TYPE Mat = ARRAY of ARRAY OF Word;

N'aurais-tu pas involontairement créé un monstre (indirectement par ma faute, le le reconnais ) ? Une entité dont la taille atteindrait par omission de paramètre les limites de capacité du logiciel ? Et cela n'autait-il pas un rapport avec les difficultés dont tu fais état ?

... Attention, ce aBuf.Canvas.Pixels[i,j] := couleur; est épouvantablement bouffeur de ressources et ne peut être utilisé que pour des petits tests (comme ici), à partir de 300x300 ça commence à ramer et au-delà c'est inexploitable : faut passer par les ScanLines.

Personnellement, je n'ai pas rencontré de difficulté particulière - hormis la lenteur - avec des images Bmp de dimensions (2000x2000).

# Le plus fort, c'est que cela a l'air de marcher: ton programme paraît viable ... Tu pourrais, après amélioration, regarder ce que cela donne pour Max = 100, 101, 102, 103 ... (102 et 255 ont pour diviseur commun 51).

[Jipété]

Bonsoir aussi,

La variable (Grille) ne ferait-elle pas double emploi ? Ne pourrais-tu pas t'en passer ?

Tutafait ! Voir le code + bas.

N'aurais-tu pas involontairement créé un monstre (indirectement par ma faute, le le reconnais ) ? Une entité dont la taille atteindrait par omission de paramètre les limites de capacité du logiciel ? Et cela n'aurait-il pas un rapport avec les difficultés dont tu fais état ?

Non, je ne pense pas. Pas beau, ça je te l'accorde volontiers, avec des machins inutiles et des trucs redondants...

Personnellement, je n'ai pas rencontré de difficulté particulière - hormis la lenteur - avec des images Bmp de dimensions (2000x2000).

Cette histoire d'accès aux pixels comme je l'ai écrite, c'est très connu sur le web pour sa lourdeur et sa lenteur ; d'ailleurs, au tout début des essais ici de la transformation d'une petite (128x128) image couleur en niveaux de gris, j'employais cette manière de faire que j'ai très vite abandonnée quand j'ai commencé à générer plusieurs images en gris : fallait compter 8 secondes environ par image !

# Le plus fort, c'est que cela a l'air de marcher: ton programme paraît viable ... Tu pourrais, après amélioration, regarder ce que cela donne pour Max = 100, 101, 102, 103 ... (102 et 255 ont pour diviseur commun 51).

Commentaires dans le code au début pour voir les résultats. Avec 101 j'ai exactement la même image que celle postée ce matin.

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
procedure TForm1.Button2Click(Sender: TObject);
CONST Max = 101; // 99, 100-> triangle vert sombre (0 128 0) -- 102, 103-> triangle rouge (255 0 0)
//TYPE Mat = ARRAY[0..(Max-1), 0..(Max-1)] OF Word; inutile
VAR i, j, s: Word; // 0..65535 --> son étendue est limitée et interdit le blanc par exemple (transformé en jaune)
  aBuf: TBitmap;
begin
  aBuf := TBitmap.Create;
  with aBuf do begin
    PixelFormat := pf24bit;
    SetSize(Max, Max);
    FOR i:= 0 TO Max-1 DO
      FOR j:= 0 TO Max-1 DO
        BEGIN
          IF ((i + j)>=Max) THEN Canvas.Pixels[i,j]:= 0  // Couleur noire
            else begin
              s := Round(2.55 * i) + Round(2.55 * j) + Round(2.55 * (Max-1 - i - j));
              IF (s=255) THEN Canvas.Pixels[i,j]:= clYellow
                           ELSE IF (s<255) THEN Canvas.Pixels[i,j]:= clGreen
                                           ELSE Canvas.Pixels[i,j]:= clRed;
            end;
        END;
    imgWiwaxia.Canvas.Draw(0,0,aBuf);
    Free;
  end;
end;

Mais on s'éloigne du sujet, là... J'ai passé une bonne partie de l'aprème à faire joujou avec CIE L*a*b*, et je suis un peu déçu : là aussi il y a des cas où le texte a du mal à se détacher du fond.

[wiwaxia]

... Pas beau, ça je te l'accorde volontiers, avec des machins inutiles et des trucs redondants ...

Je ne permettrais pas ce genre d'appréciation concernant un programme dont je ne connais pas le langage !
Je me demandais ce qui pouvait tant ralentir l'exécution ...

... Cette histoire d'accès aux pixels comme je l'ai écrite, c'est très connu sur le web pour sa lourdeur et sa lenteur ; d'ailleurs, au tout début des essais ici de la transformation d'une petite (128x128) image couleur en niveaux de gris, j'employais cette manière de faire que j'ai très vite abandonnée quand j'ai commencé à générer plusieurs images en gris : fallait compter 8 secondes environ par image ! ...

J'ai retrouvé les messages livrant des parties de tes programmes, au sujet du maniement des images bitmap, sur un autre forum où sont longuement intervenus des participants superfun que nous connaissons bien .
Les difficultés portaient sur des détails (ajustement de bornes et de variables), mais pas sur la création du fichier, qui ne te posais pas de problème.

# http://www.developpez.net/forums/d16...degrade-faire/

# 04/11/2016, 00h27 _ _ #37 (p2)
# 05/11/2016, 12h03 _ _ #41 (p3)
# 07/11/2016, 10h25 _ _ #49 (p3)

Si cela peut t'aider ...

PS: Je regarde toujours la fonction "niveau de gris", mais la maîtrise des approximations reste pénible

[Jipété]

Salut salut

Je ne permettrais pas ce genre d'appréciation concernant un programme dont je ne connais pas le langage !

T'inquiète pas, c'est moi qui l'ai écrit !

Je me demandais ce qui pouvait tant ralentir l'exécution ...

C'est comme ça, c'est par construction...
J'ai un petit prog dans un coin qui me sert à tester/optimiser mes trucs, j'arrive à générer une image 256 x 256 en 8xx µSec avec ScanLine et il faut compter 460xxx µSec pour la même chose avec aBmp.Canvas.Pixels[x, y] := aColor;, ce qui fait un rapport de 1 à 575 environ (testé à l'instant)...

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
// mode ScanLine
    BeginUpdate();
    for h := 0 to IMAGE_HEIGHT-1 do begin
      {$IFDEF WINDOWS}
      p := pRGBTriple(RawImage.GetLineStart(h));
      for w := 0 to IMAGE_WIDTH-1 do
        p[w] := RGBtoRGBTriple(h, w, (h+w) div 2);
      {$ELSE}
      p := pRGBQuad(RawImage.GetLineStart(h));
      for w := 0 to IMAGE_WIDTH-1 do
        p[w] := RGBAtoRGBAQuad(h, w, (h+w) div 2, 255);
      {$ENDIF}
    end;
    EndUpdate();
// mode Pixels :
    for h := 0 to IMAGE_HEIGHT-1 do
      for w := 0 to IMAGE_WIDTH-1 do
        Canvas.Pixels[h, w] := RGBtoColor(byte(255-h), byte(255-w), byte(((255-h)+(255-w)) div 2));

J'ai eu la flemme de chercher à savoir pourquoi noir et blanc sont inversés entre les deux rendus...

PS: Je regarde toujours la fonction "niveau de gris", mais la maîtrise des approximations reste pénible

On en est là, et ce matin je n'ai pas eu le temps de regarder, et cet aprème je n'aurais pas plus le temps...

[wiwaxia]

Ça marche, les teintes semblent se correspondre.
Encore qu'en y regardant de plus près ...
on trouve aux 3 coins pourpres:
# 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

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 ?


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 .