ARNO*

Geek dilettante habitant une belle et grande propriété sur la Côte d’améthyste

  • J’ai besoin, pour un site #SPIP sur lequel je travaille, d’interdire l’utilisation de couleurs trop vives dans l’interface. J’utilise beaucoup de couleurs, chaque titre de la page d’accueil est de la couleur a sa propre couleur, alors si on affiche des couleurs vives, ça devient un arbre de Noël (et ce n’est pas l’esprit du truc). Je veux que l’ensemble reste dans des tons « éteints ».

    Pour cela, il suffit de limiter la valeur S (saturation) quand on passe la couleur en mode HSL (ou TSI en français).

    Voici un bleu ni trop vif ni trop terne (valeur de S : 60% ; dans SPIP, on codera 0.6) :

    Si on pousse la saturation à 100% (dans SPIP : 1), on obtient une belle couleur qui pète :

    Et si on passe à 0%, on arrive au gris :

    On notera que, tant qu’on ne modifie pas L (ou I), je continue donc à avoir des couleurs très lumineuses ou très foncées, et il faut donc que je prenne cela en compte dans mon interface (avec les usuels |couleur_foncer_si_claire et autres outils bien pratiques pour gérer des interfaces qui changent de couleur).

    C’est juste qu’ici, je veux limiter la valeur maximale de la saturation (le côté « couleur éteinte / couleur vive »). Pour cela, une petite fonction qui va bien :

    function couleur_desaturer($couleur, $val) {
            include_spip('filtres/images_lib');

            $couleurs = _couleur_hex_to_dec($couleur);
            $r = $couleurs["red"];
            $g = $couleurs["green"];
            $b = $couleurs["blue"];

            $couleur = _couleur_rgb2hsl($r, $g, $b);
            $h = $couleur["h"];
            $s = $couleur["s"];
            $l = $couleur["l"];

            $rgb = _couleur_hsl2rgb($h, min($val,$s), $l);
            $r = $rgb["r"];
            $g = $rgb["g"];
            $b = $rgb["b"];

            $retour = _couleur_dec_to_hex($r, $g, $b);

            return $retour;
    }

    Ça ne dénature donc pas systématiquement : ça fixe un seuil maximum.

    La fonction est facile à modifier si, par exemple, on veut travailler uniquement avec des couleurs dans des tons pastel, on supprime la variable $val, et on remplace la ligne :

            $rgb = _couleur_hsl2rgb($h, min($val,$s), $l);

    par
            $rgb = _couleur_hsl2rgb($h, 0.4, 0.7);

    (on fixe arbitrairement toutes les couleurs avec une saturation de 0.4 (légèrement terne mais pas trop) et une luminosité intermédiaire.

    • 1. c’est quoi vive ? C’est saturée ? C’est un choix éditorial/artistique.
      2. Vu comme les couleurs RVB (rgb en anglais) 24/32 bits atteignent les limites des écrans actuels qui peuvent vraiment plus en terme de Gamut et de nombre de couleur. J’aime à penser que le changement de repère en TSL (hsl en anglais) (tiens, spip c’est plus francophile ?) permet un peu plus de précision là où ca se voit et un peu moins la ou ca se voit moins... Donc j’aime à penser qu’il vaut mieux exprimer ses couleurs en TSL plutôt qu’en RVB tant que le nombre de bits n’aura pas été augmenté (40 serait pas mal, mais il doit y avoir des recherches là dessus).

    • 1. Oui, « vive » c’est « saturée ». Moi je dis « couleur qui pète », mais c’est moi.

      2. Ici le passage en TSI n’est qu’un outil dans la fonction, pour effectuer une modification mathématique facilement. Mais le retour est encore une couleur codée en RVB héxadécimale. Parce que c’est ce que les filtres de manipulations des couleurs de SPIP vont utiliser ensuite.

      Après, c’est pour des éléments d’interface, qu’en plus on génère dynamiquement. Alors la précision liée au Gamut de l’écran, ici, ça me semble moins pertinent, qui concernerait plus, à mon avis, les images.

    • Tout à fait d’accord. Les interfaces, c’est souvent des aplats, alors à +/-5 sur chaque canal RVB, osef.

      Sinon, le RGB étendu, ça doit bien exister... un truc genre 10/11/11 bits par canal (sur 32 bits)... Vu que ca existant déjà du temps du 8 / 16 bits y’a pas de raison qu’on réserve de la place pour l’Alpha quand c’est le framebuffer.
      Faudrait que je révise. C’est con d’être spécialisé en imagerie numérique et ne pas en faire depuis 15 ans.

      J’ai trouvé, au délà de 24 bits (donc 32 avec alpha) (qui s’appelle True-color), cela s’appelle Deep-color, et ça inclut 30, 36 et 48 bits... (bizarre qu’on ne fasse plus de dissymétrie chromatique, ça a peut être moins de sens avec autant de précision). Et apparemment les nouveaux formats vidéo (H.265) ou les nouvelles infrastructures HDMI 1.3 supportent ça. Ca me parait cohérent... faut vraiment être bigleux pour pas voir les artefacts en 24 bits.