Changement de sujet : j’ai la tête dans les pixels plutôt que dans les bases de données. L’image numérique me fait tripper, surtout depuis que j’ai compris qu’un beau résultat à l’écran peut cacher un fichier trop lourd, trop petit ou déjà abîmé par la compression.

Le bouton Enregistrer sous a l’air simple. Avant de cliquer, il faut savoir à quoi le fichier va servir. La dimension réelle d’une image est son nombre de pixels, par exemple 2 048 × 1 536. Le nombre de points par pouce inscrit dans le fichier ne crée pas de détails supplémentaires; il indique surtout une taille d’impression souhaitée. À 300 points par pouce, 2 048 pixels donnent environ 6,8 pouces. À l’écran, le navigateur s’intéresse surtout aux pixels affichés.

Une image RVB non compressée de cette taille exige environ :

2 048 × 1 536 × 3 octets = 9 437 184 octets, environ 9 Mo

Un document Photoshop ajoute les calques, masques et autres informations de travail. Une copie Web doit être beaucoup plus petite. Le JPEG obtient cette réduction en profitant du fait que l’œil remarque davantage certaines variations de luminosité que de couleur.

Le compresseur convertit grossièrement les couleurs, divise l’image en blocs de 8 × 8 pixels, représente chaque bloc comme un ensemble de fréquences, puis quantifie ces coefficients. Quantifier veut dire arrondir avec une précision choisie : les petits détails à haute fréquence peuvent devenir zéro. Un codage sans perte compresse ensuite les nombres restants. Le décodeur reconstruit une approximation, pas les pixels originaux.

Cette mécanique explique deux défauts visibles : des blocs dans les zones très compressées et des halos autour des contours nets. Une photo tolère souvent bien le compromis. Du petit texte ou une capture d’écran avec de grands aplats le tolère moins; GIF ou PNG convient mieux. Et chaque nouvel enregistrement JPEG repart de l’approximation précédente, la découpe de nouveau en blocs et jette encore de l’information.

Un original, plusieurs sorties

Le workflow qui me semble le plus logique ressemble donc à ceci :

• garder un document de travail riche, avec les calques;
• conserver une copie maître sans perte et à pleine dimension;
• redimensionner une copie selon sa destination;
• accentuer légèrement après la réduction si nécessaire;
• compresser cette copie juste assez pour l’usage prévu;
• revenir à l’original quand une nouvelle version est nécessaire.

Le redimensionnement est lui-même un calcul. Pour réduire, le logiciel doit combiner plusieurs pixels sources en un pixel de sortie. Le plus proche voisin est rapide mais produit des marches; une interpolation bilinéaire ou bicubique mélange les voisins et donne souvent un résultat plus doux. Agrandir une petite image ne retrouve jamais les détails absents : le programme invente seulement des valeurs entre les pixels connus.

Pour le Web, je ferais un test concret avec une copie de 600 pixels de large à trois niveaux de qualité JPEG. Je note le poids, j’affiche chaque version à 100 % et je regarde les visages, le ciel et les contours. Le plus petit fichier sans défaut gênant gagne; une valeur de qualité universelle n’existe pas. Une miniature séparée évite aussi de télécharger l’image complète pour l’afficher en petit.

Le fichier peut échouer autrement que visuellement. Une copie interrompue laisse un fichier tronqué, un profil de couleur inconnu peut changer les teintes sur une autre machine, et des métadonnées EXIF peuvent révéler une date ou d’autres informations qu’on ne voulait pas publier. Je garde l’original sur un support distinct, je vérifie l’image exportée avec un autre lecteur et je retire les métadonnées inutiles de la copie publique.

Oui, le maître prend plus de place. Sacrifier le seul fichier modifiable pour économiser quelques mégaoctets serait un drôle de calcul. Je vais traiter le JPEG comme un livrable reproductible : on le jette et on le régénère depuis la source, jamais l’inverse.