Après Photoshop, le bouton gris paraît encore plus gris
Je vais sortir un peu du code ce mois-ci parce que je viens de jouer avec Photoshop et, pour vrai, les calques me font tripper.
On masque le texte, on déplace une image, on ramène le texte, puis tout ce qui était dessous est encore intact. Retourner ensuite dans Paint donne l’impression d’avoir perdu une dimension. La différence vient du modèle de document : Paint modifie directement une grille de pixels, tandis que Photoshop conserve plusieurs grilles, masques et paramètres que son moteur compose pour fabriquer l’image visible.
Un calque possède ses pixels, sa position, son opacité et souvent un masque. Pour chaque pixel affiché, Photoshop prend la couleur du calque supérieur et la mélange avec celle du dessous selon l’alpha. Avec une opacité de 25 %, le calcul simplifié d’un canal ressemble à ceci :
sortie = dessus × 0,25 + dessous × 0,75
Le masque agit comme une opacité différente à chaque endroit : noir cache, blanc montre, gris mélange. Le texte peut rester un objet éditable, donc Photoshop le redessine à partir de la police au lieu de figer tout de suite ses lettres en pixels. Voilà pourquoi je peux corriger un mot ou déplacer une ombre sans repeindre l’arrière-plan.
Cette souplesse explique aussi la taille du .psd. Une image de 1 600 × 1 200 pixels en couleur 24 bits prend environ 5,5 Mo sans compression (1 600 × 1 200 × 3 octets). Quatre calques pleins, des masques, une miniature et l’historique peuvent rapidement multiplier ce nombre. Ce n’est pas du gaspillage dans le fichier de travail : on paie de l’espace pour garder les décisions réversibles.
Le problème commence si j’envoie ce fichier directement vers une application Windows. Le .psd décrit un projet d’édition; le programme a besoin d’un rendu final à une dimension et dans un format qu’il sait décoder. Il faut donc distinguer trois choses :
- la source avec calques, polices et pleine résolution;
- l’export maître aplati, conservé sans perte;
- les images livrées, dimensionnées pour chaque état de l’interface.
Pour un bouton de 120 × 28 pixels, réduire une image énorme au chargement coûte de la mémoire et donne un résultat différent selon l’algorithme de rééchantillonnage. Je préfère exporter exactement 120 × 28 et regarder le rendu à 100 %. Le BMP se charge facilement sous Windows mais ne compresse presque rien. Le GIF convient aux aplats et à une palette limitée; sa transparence est tout ou rien. Le JPEG compresse bien une photo, mais ajoute des artefacts autour du texte et des contours. Le PNG garde les pixels sans perte et peut contenir un canal alpha, même si tous les contrôles Windows de l’époque ne le rendent pas correctement.
L’intégration a aussi besoin d’un petit contrat. Combien d’états : normal, enfoncé, désactivé, peut-être survolé? Quelle couleur de fond doit apparaître autour? Le texte fait-il partie de l’image ou vient-il du contrôle pour pouvoir être traduit? Si la police manque sur le poste du développeur, Photoshop peut substituer quelque chose sans que personne le remarque avant le prochain export. Je conserve donc la police autorisée ou je rasterise seulement une copie de livraison.
Un fichier corrompu, un chemin absent ou une image trop grosse ne devrait pas empêcher tout le formulaire de démarrer. L’application peut charger les ressources au lancement, vérifier leurs dimensions et revenir à un bouton standard si l’une manque. Garder les fichiers graphiques sous contrôle de version, avec une convention comme enregistrer-normal.png et enregistrer-disabled.png, évite aussi la série final_vraimentfinal2.
Photoshop m’apprend finalement une idée très proche du code : garder une représentation riche pour travailler, puis produire un artefact plus simple avec un contrat clair. Pour mon prochain écran, je vais demander les dimensions, les états et le format avant de recevoir les images, puis tester l’export sur une machine qui n’a pas Photoshop.