Cet article est une plongee technique dans le pipeline de traitement en lumiere lineaire. Il est detaille, et explique exactement pourquoi le choix du format de texture et de l'espace colorimetrique de travail change la qualite de chaque pixel. Si vous vous etes deja demande pourquoi les outils professionnels comme Lightroom traitent en float 32 bits, ou ce que signifie « scene-referred », ou pourquoi vos details dans les ombres se desintegrent dans certains logiciels, c'est l'article qui l'explique. Je montrerai les mathematiques, le code, et les standards de l'industrie.
Le problème du gamma
Chaque image numérique que vous avez vue sur un écran grand public est stockée dans un espace colorimétrique non linéaire appelé sRGB, défini par IEC 61966-2-1. L'encodage applique une courbe gamma (approximativement une puissance de 1/2,2) qui compresse les valeurs de hautes lumières et étend les valeurs d'ombres. Cet encodage existe pour une bonne raison historique : les moniteurs CRT avaient un gamma natif d'environ 2,2, et encoder les images avec une courbe inverse signifiait que la non-linéarité du CRT et celle de l'encodage s'annulaient, produisant un affichage perceptuellement uniforme. L'encodage alloue aussi davantage des 256 valeurs disponibles en 8 bits aux ombres, où la vision humaine est la plus sensible au banding.
Le problème est que les valeurs sRGB ne sont pas proportionnelles à la lumière. Elles sont proportionnelles à un encodage perceptuel de la lumière. Quand vous faites des mathématiques sur des valeurs sRGB directement, les résultats ne correspondent pas à la réalité physique. Considérez l'opération la plus simple possible : moyenner deux valeurs de pixels.
Prenez deux pixels : l'un à sRGB 50 (une ombre sombre) et l'autre à sRGB 200 (une haute lumière claire). La moyenne naïve est 125. Mais que sont ces valeurs en lumière linéaire ? sRGB 50 se linéarise à environ 0,031, et sRGB 200 se linéarise à environ 0,527. La vraie moyenne physique (la moitié des photons de chacun) est 0,279, ce qui se ré-encode à environ sRGB ~143. La moyenne naïve en sRGB de 125 correspond à un linéaire de 0,184 — une erreur de 34% par rapport au résultat linéaire correct. Le pixel moyenné est trop sombre, car la moyenne en espace gamma sous-pondère la valeur la plus brillante. Cette erreur n'est pas un artefact d'arrondi. C'est un biais systématique ancré dans chaque opération qui traite les valeurs gamma-encodées comme si elles étaient linéaires.
La conséquence pratique pour la photographie : chaque fondu, chaque filtre, chaque ajustement de luminosité calculé en espace gamma produit des résultats subtilement faux. La synthèse de grain en espace gamma concentre le bruit dans les hautes lumières et affame les ombres. Les ajustements de contraste en espace gamma ont un effet asymétrique qui ne correspond pas à la façon dont le papier ou la pellicule répondent. Les opérations de dodge et burn déplacent les tons moyens d'une manière qui ne correspond pas aux changements d'exposition qu'elles sont censées simuler.
Le problème de précision dans les ombres est encore pire. Voici comment les 256 niveaux du sRGB 8 bits se répartissent sur la plage de lumière linéaire :
| Plage de codes sRGB | Plage de lumière linéaire | % de la plage linéaire | Valeurs de code disponibles | Précision effective |
|---|---|---|---|---|
| 0 – 63 | 0,000 – 0,046 | 4,6% | 64 | Adéquate — mais seulement 4,6% de la plage lumineuse |
| 0 – 12 | 0,000 – 0,003 | 0,3% | 13 | Ombres profondes : 13 niveaux pour le tiers inférieur d'un stop |
| 64 – 127 | 0,046 – 0,216 | 17,0% | 64 | Ombres aux tons moyens inférieurs |
| 128 – 191 | 0,216 – 0,527 | 31,1% | 64 | Tons moyens supérieurs |
| 192 – 255 | 0,527 – 1,000 | 47,3% | 64 | Hautes lumières : 64 codes couvrant près de la moitié de la lumière |
Lisez ce tableau attentivement. Les 25% inférieurs des valeurs de code sRGB (0–63) correspondent à seulement 4,6% de la plage de lumière linéaire. Les 25% supérieurs (192–255) correspondent à 47,3% de la plage linéaire. Cela signifie que lorsque vous traitez en 8 bits gamma-encodé, vous avez environ dix fois plus de précision dans les hautes lumières que dans les ombres profondes. Pour le travail en N&B, où la séparation des ombres est tout — où la différence entre la Zone II et la Zone III définit le poids émotionnel d'une image — c'est catastrophique.
Le problème des 16 niveaux : Dans les ombres les plus profondes (codes sRGB 0–12), vous avez exactement 13 niveaux discrets pour représenter toutes les luminances en dessous de 0,3% de la lumière maximale. Après toute étape de traitement qui requantifie en 8 bits — ce qui se produit à chaque étape dans un pipeline 8 bits — ces 13 niveaux se réduisent encore. Deux ou trois étapes de traitement et vous arrivez à du banding visible dans les ombres. C'est pourquoi les conversions N&B bon marché montrent de la postérisation dans les tons sombres. Ce n'est pas un bug de l'algorithme. C'est un échec fondamental de précision dans la représentation des données.
Ce que signifie la lumière linéaire
Dans un espace de lumière linéaire, les valeurs sont directement proportionnelles au nombre de photons frappant le capteur. Une valeur de 0,5 représente exactement la moitié de l'énergie lumineuse de 1,0. Une valeur de 0,25 représente exactement un quart. Doubler une valeur linéaire double la luminosité. La diviser par deux la réduit de moitié. Ce n'est pas une abstraction mathématique — c'est la réalité physique du fonctionnement de la lumière, et c'est ainsi que tout système optique dans la nature combine la lumière.
Quand votre pipeline de traitement opère en lumière linéaire, chaque opération mathématique correspond à sa signification physique. La multiplication par 0,5 est équivalente à fermer d'un stop. L'addition de deux valeurs est équivalente à la combinaison de deux sources lumineuses. La moyenne est équivalente à placer un filtre de densité neutre à 50% entre deux expositions. Les mathématiques font ce que vous pensez qu'elles font, parce que les valeurs représentent ce que vous pensez qu'elles représentent.
Voici une comparaison des opérations courantes en espace gamma versus espace linéaire :
| Opération | En espace gamma | En espace linéaire | Caractère de l'erreur |
|---|---|---|---|
| Luminosité +1 stop | Multiplier par ~1,35 (varie selon la valeur) | Multiplier par 2,0 | La version gamma décale les tons moyens plus que les ombres |
| Fondu 50/50 de deux images | Moyenne des valeurs gamma (trop sombre) | Moyenne des valeurs linéaires (physiquement correct) | Jusqu'à 34% d'erreur de luminance en gamma |
| Augmentation du contraste | Courbe en S en espace perceptuel (inégale) | Courbe en S en espace linéaire (symétrique autour du point médian) | La version gamma écrase les ombres de manière disproportionnée |
| Synthèse de grain | Bruit uniforme en gamma (trop fort dans les hautes lumières) | Bruit uniforme en linéaire (perceptuellement uniforme) | Caractère du grain complètement faux en gamma |
| Dodge (éclaircissement des ombres) | Additif en gamma (réponse non linéaire) | Additif en linéaire (correspond à une augmentation d'exposition) | La version gamma sur-éclaircit près du blanc, sous-éclaircit près du noir |
| Vignetage | Multiplication en gamma (halos à la transition) | Multiplication en linéaire (chute propre) | La multiplication gamma crée des artefacts de halo visibles |
L'industrie du cinéma a compris cela il y a des décennies. Chaque pipeline VFX depuis le début des années 2000 opère en lumière linéaire, car le compositing en espace gamma produit des artefacts visibles à chaque contour. Le monde du logiciel photographique a été plus lent à adopter les pipelines linéaires, en partie parce que le coût de calcul est plus élevé (il faut plus de bits par canal pour éviter le banding dans les ombres) et en partie parce que les outils existants étaient « suffisants » pour la plupart des utilisateurs. Mais pour le travail en N&B, où la tonalité des ombres est l'essence même de l'art, « suffisant » ne l'est pas.
Du 8 bits au half-float : la mise à niveau Rgba16Float
Un pipeline classique utilise Rgba8UnormSrgb comme format de texture GPU. C'est le format standard 8 bits par canal avec conversion automatique sRGB↔lineaire en lecture/ecriture. C'est ce que la plupart des applications temps reel utilisent. C'est rapide, efficace en memoire, et pour le rendu de jeux video, c'est parfaitement adequat.
Pour le traitement photographique, c'est un désastre.
Avec Rgba8UnormSrgb, même si le matériel GPU linéarise automatiquement les valeurs lors de l'échantillonnage de la texture, les données source ont déjà été quantifiées à 256 niveaux en espace gamma. Les valeurs linéarisées sont reconstruites à partir de ces 256 niveaux, ce qui signifie que la précision dans les ombres est définitivement limitée par la quantification gamma-encodée. On ne peut pas récupérer une précision qui a été rejetée à l'étape d'encodage.
Le nouveau pipeline linéarise l'image source sur le CPU au chargement — en utilisant une table de conversion précalculée de 256 entrées pour les sources 8 bits, ou une conversion par fonction puissance directe pour les sources 16 bits — et envoie le résultat en Rgba16Float, le format à virgule flottante demi-précision IEEE 754. Cela change tout.
Le half-float IEEE 754 (binary16) a 1 bit de signe, 5 bits d'exposant et 10 bits de mantisse (plus un bit de tête implicite, donnant 11 bits de précision effective). La représentation en virgule flottante signifie que la précision est relative, pas absolue : vous obtenez le même nombre de niveaux discrets par stop sur toute la plage dynamique. Dans les ombres, où le 8 bits gamma-encodé vous donne 13 niveaux pour le stop le plus profond, le half-float en donne 2048. C'est une amélioration de 157 fois la précision dans les ombres.
| Format | Bits par canal | Niveaux dans le stop le plus profond | Plage dynamique totale | Mémoire (4K RGBA) | Support texture GPU |
|---|---|---|---|---|---|
| Rgba8UnormSrgb | 8 | ~13 | 8 stops (linéaire) | 31,6 Mo | Universel |
| Rgba16Float | 16 (float) | ~2048 | 30+ stops | 63,3 Mo | Universel (depuis D3D10 / GL 3.0) |
| Rgba16Uint | 16 (entier) | ~8 | 16 stops (linéaire) | 63,3 Mo | Universel, pas de filtrage |
| Rgba32Float | 32 (float) | ~8,4M | 127+ stops | 126,6 Mo | Support de filtrage limité |
C'est la même approche utilisée par tous les éditeurs photo professionnels. Adobe Lightroom traite en interne en float 32 bits sur le CPU, puis affiche les aperçus en float 16 bits sur le GPU. Le module « filmic » de darktable opère entièrement en float 32 bits en lumière linéaire. Capture One utilise un entier 16 bits en interne (qui a une précision uniforme plutôt que la précision logarithmique du float, le rendant légèrement moins efficace pour le contenu photographique, mais tout de même vastement meilleur que le 8 bits). Un pipeline GPU moderne utilise le float 16 bits pour le stockage des textures et le float 32 bits pour toute l'arithmetique dans le fragment shader — la meme repartition de precision que Lightroom utilise, mais avec le traitement qui se fait sur le GPU au lieu du CPU.
L'étape de linéarisation se fait une seule fois au chargement de l'image. Voici le code qui convertit du sRGB 8 bits en float linéaire :
L'insight clé est que cette linéarisation est une porte à sens unique. Une fois les données en float linéaire, toutes les opérations suivantes sont physiquement correctes, et la précision est déterminée par le format float (mantisse de 11 bits pour le half-float, mantisse de 23 bits pour l'arithmétique float 32 bits dans le shader), pas par la quantification originale en 8 bits. Nous n'interpolons pas entre 256 niveaux. Nous calculons avec 2048+ niveaux par stop de plage dynamique.
Tone mapping ACES Filmic
Traiter en lumière linéaire crée un nouveau problème : comment mapper le résultat vers une plage affichable ? L'approche naïve est un clamp dur : clamp(value, 0.0, 1.0). Toute valeur au-dessus de 1.0 est écrasée en blanc. Toute valeur en dessous de 0.0 est écrasée en noir. C'est ce que font la plupart des applications temps réel, et cela produit des hautes lumières dures et cliniques avec une transition abrupte du texturé au blanc pur.
L'industrie du cinéma a résolu ce problème avec l'Academy Color Encoding System (ACES), développé par le Conseil Science et Technologie de l'Academy of Motion Picture Arts and Sciences. Le ACES Reference Rendering Transform (RRT) définit un mapping perceptuellement motivé de la lumière linéaire scene-referred vers une sortie display-referred. C'est le standard de facto pour la production cinématographique et télévisuelle.
L'approximation polynomiale rationnelle de Narkowicz (2015) du ACES RRT est une implementation populaire et efficace. C'est une fonction rationnelle unique qui se rapproche etroitement de la transformation de sortie complete du ACES RRT, fonctionnant en quelques instructions GPU plutot que la table de consultation multi-etapes du pipeline ACES complet. La fonction :
Le facteur de normalisation mérite une explication. La fonction ACES Narkowicz brute mappe 1.0 vers 0.8148, et non vers 1.0. Sans correction, un pixel qui devrait être blanc pur à l'écran s'afficherait à environ 81% de luminosité — un assombrissement notable de l'image entière. Nous divisons la sortie par 0.8148 (équivalemment, nous pourrions multiplier l'entrée par 1/0.8148 = 1.2273) pour s'assurer qu'une entrée de 1.0 mappe vers une sortie de 1.0. Le point blanc est préservé. Les valeurs en dessous de 1.0 sont légèrement remontées (le look filmic), et les valeurs au-dessus de 1.0 sont compressées dans la plage juste en dessous de 1.0 (le rolloff des hautes lumières).
Voici la comparaison critique — ce qui arrive à des valeurs d'entrée spécifiques sous clamp dur versus ACES Filmic :
| Entrée (linéaire) | Signification physique | Sortie clamp dur | Sortie ACES Filmic | Différence |
|---|---|---|---|---|
| 0,00 | Noir absolu | 0,000 | 0,000 | Aucune |
| 0,05 | Ombre profonde | 0,050 | 0,054 | +8% remontée des ombres — ouvre les tons sombres |
| 0,18 | Gris 18% (Zone V) | 0,180 | 0,222 | +23% boost des tons moyens — la « chaleur » filmic |
| 0,50 | Mi-haute lumière | 0,500 | 0,579 | +16% — augmentation de luminosité visible |
| 0,80 | Surface lumineuse | 0,800 | 0,860 | +7,5% — début de la compression douce des hautes lumières |
| 1,00 | Blanc maximal | 1,000 | 1,000 | Aucune (normalisé) |
| 1,20 | Légère surexposition | 1,000 (écrêté) | 1,000 (compressé) | Récupérable vs. détruit |
| 1,50 | Nuage lumineux | 1,000 (écrêté) | 1,000 (compressé) | Texture préservée dans le rolloff des hautes lumières |
| 2,00 | Reflet spéculaire | 1,000 (écrêté) | 1,000 (compressé) | Les distinctions entre 1,5 et 2,0 survivent |
Trois effets sont visibles dans ce tableau. Remontée des ombres : ACES relève doucement les ombres les plus profondes, ouvrant le détail dans les tons les plus sombres sans les rendre délavés. C'est le même effet perceptuel que la pellicule a naturellement — les cristaux d'halogénure d'argent non exposés ne produisent jamais un noir absolu, donc les ombres de la pellicule ont un pied inhérent que la capture numérique n'a pas. Boost des tons moyens : La remontée de 15–23% à travers les tons moyens donne aux images une luminosité et une présence que les photographes décrivent comme « filmic ». Ce n'est pas plus lumineux de manière plate et délavée ; c'est plus vivant. Rolloff des hautes lumières : Au lieu d'un mur dur à 1.0 où tout ce qui dépasse est écrêté en blanc identique, ACES compresse les valeurs super-blanches dans un épaulement doux. Un nuage à 1,5 et un reflet spéculaire à 2,0 s'affichent tous deux comme presque blancs, mais le nuage est légèrement moins brillant que le spéculaire — la distinction survit. C'est ainsi que la pellicule gère la surexposition, et c'est pourquoi les hautes lumières pellicule ont un aspect « crémeux » tandis que les hautes lumières numériques ont un aspect « brûlé ».
Headroom : pourquoi les valeurs au-dessus de 1.0 comptent
Dans l'ancien pipeline, chaque étape de traitement utilisait clamp(x, 0.0, 1.0) pour garder les valeurs dans la plage affichable. Cela semble raisonnable — votre moniteur ne peut pas afficher quoi que ce soit de plus lumineux que le blanc, alors pourquoi garder des valeurs au-dessus de 1.0 ? La réponse est que les valeurs intermédiaires au-dessus de 1.0 portent de l'information que les étapes de traitement ultérieures peuvent utiliser.
Considérez cette séquence : vous augmentez la luminosité de +0,5 stop (multiplier par 1,41), puis augmentez le contraste, puis réduisez la luminosité de -0,3 stop. Dans l'ancien pipeline avec clamp :
Dans l'ancien pipeline, le clamp à l'étape 1 a détruit la distinction entre un pixel à 0,85 et un pixel à 0,95 — les deux sont devenus 1.0 après l'augmentation de luminosité. Cette distinction est irrécupérable. Aucun traitement ultérieur ne peut les séparer. Dans le nouveau pipeline, les valeurs 1,199 et 1,340 restent distinctes à travers toute la chaîne. Quand la luminosité est réduite plus tard, la relation originale entre ces pixels est restaurée. Quand le tone mapping ACES est finalement appliqué, les deux valeurs sont compressées dans la plage affichable, mais leur ordre relatif et leur espacement sont préservés.
C'est ce que signifie le traitement « scene-referred ». Les valeurs dans le pipeline réfèrent à la scène physique — elles représentent des intensités lumineuses réelles, pas des valeurs de code d'affichage. Un nuage réfléchissant 150% de la lumière qu'un mur blanc réfléchit est stocké comme 1,5, pas clampé à 1.0. Un reflet spéculaire sur une surface chromée pourrait être 3.0 ou 5.0. Ces valeurs super-blanches traversent chaque étape de traitement, portant de l'information réelle, jusqu'à ce que le tone mapping final les compresse vers la plage d'affichage.
Le changement de code clé a été de remplacer clamp(x, 0.0, 1.0) par max(x, 0.0) dans chaque fonction de luminosité, contraste et traitement. Nous clampons toujours à zéro (la lumière négative n'a pas de sens physique), mais nous ne clampons jamais à 1.0. Le seul endroit où les valeurs sont compressées vers la plage d'affichage 0–1 est la fonction de tone mapping ACES, appliquée une seule fois, à la toute fin du pipeline.
L'architecture complète du pipeline
Voici la chaîne de traitement complète du fichier d'entrée au pixel affiché :
Deux détails méritent d'être notés. Premièrement, l'encodage sRGB sur la surface de sortie est effectué par le matériel à fonction fixe du GPU, pas par le code du shader. Quand vous configurez une surface wgpu avec un format sRGB, les unités d'écriture de texture du GPU appliquent automatiquement la fonction de transfert IEC 61966-2-1 en écrivant les fragments dans le framebuffer. C'est un circuit dédié sur le GPU qui fonctionne à coût de calcul nul — pas d'instructions shader, pas de pénalité de performance. Le même chemin matériel existe depuis OpenGL 2.1 / DirectX 9.
Deuxièmement, toute l'arithmétique à l'intérieur du fragment shader opère en précision float 32 bits (f32), indépendamment du format de la texture source. Quand le shader échantillonne la texture Rgba16Float, l'unité de texture du GPU promeut automatiquement les valeurs 16 bits en 32 bits pour le calcul. La mantisse de 11 bits du half-float détermine la précision d'entrée, mais chaque multiplication, addition et évaluation de fonction dans le shader utilise la mantisse complète de 23 bits du float 32 bits. C'est la même architecture de précision que celle de Lightroom : float 16 bits pour le stockage, float 32 bits pour le calcul.
Comparaison
Tout éditeur photo sérieux traite maintenant en lumière linéaire avec une haute profondeur de bits. Les différences résident dans les détails : où le calcul se fait, quelle précision est utilisée, quel tone mapping est appliqué, et si le pipeline est ouvert ou propriétaire.
Differents logiciels implementent ces principes differemment. Lightroom et Capture One utilisent des courbes en S proprietaires et un traitement CPU. darktable a introduit le module Filmic (par Aurelien Pierre, darktable 3.0), qui a amene le traitement scene-referred en lumiere lineaire au logiciel de photographie open source. Le tone mapping du module Filmic utilise une spline personnalisee qui approxime la courbe caracteristique de la pellicule photographique, avec un controle explicite du pied (ombres), de la latitude (tons moyens) et de l'epaulement (hautes lumieres). L'approche ACES est moins configurable mais plus standardisee — la courbe est definie par l'Academy. Son comportement est bien documente, reproductible et compris dans les industries du cinema et des VFX. Il n'y a pas d'ambiguite sur ce que fait le tone mapping ou pourquoi.
Impact sur les presets
Le passage au tone mapping ACES Filmic a nécessité le recalibrage de chacun de nos 62 presets. Ce n'était pas une simple remise à l'échelle. La courbe ACES ajoute environ 15–20% de luminosité dans les tons moyens par rapport à l'ancien pipeline linéaire-vers-sRGB. Un preset qui réglait précédemment le contraste à 0,65 pourrait avoir besoin de 0,52 dans le nouveau pipeline pour obtenir la même densité visuelle. Les valeurs d'exposition ont changé de manière similaire. L'intensité du grain a dû être réduite car la synthèse de grain correcte en linéaire distribue maintenant le bruit plus uniformément sur la plage tonale, le rendant visuellement plus fort à la même intensité numérique.
Le processus de recalibrage a été manuel. Chaque preset a été évalué sur un ensemble de référence de douze images couvrant toute la gamme du contenu photographique : portrait high-key, portrait low-key, scène de rue, paysage, architecture, urbain nocturne, intérieur de forêt, nature morte en studio, concert, scène enneigée, silhouette à contre-jour et matin brumeux. L'objectif pour chaque preset était de correspondre au caractère esthétique visé (par ex. « Tri-X poussé, contrasté, grain en avant ») tout en tirant parti de la séparation des ombres améliorée et du rolloff des hautes lumières du nouveau pipeline.
Le résultat est que les nouveaux presets utilisent des valeurs systématiquement plus basses. Des réglages de contraste moins agressifs. Des décalages d'exposition plus faibles. Une intensité de grain réduite. Ce n'est pas parce que les presets sont « plus faibles ». C'est parce que le moteur fait plus du travail lourd. Le tone mapping ACES fournit une réponse de base magnifique avec des tons moyens riches et des hautes lumières douces. Les presets n'ont pas besoin de lutter contre le pipeline pour la luminosité ; ils orientent l'esthétique par-dessus une fondation fondamentalement meilleure.
Pour les utilisateurs ayant des presets personnalisés sauvés sous l'ancien pipeline : ces presets s'afficheront différemment avec le nouveau moteur. L'image sera plus lumineuse et plus ouverte dans les tons moyens, avec plus de détails d'ombre visibles. Vous voudrez probablement réduire légèrement l'exposition et le contraste pour retrouver la densité que vous aviez avant. L'amélioration de la précision des ombres et de la gestion des hautes lumières devrait être immédiatement visible, surtout sur les images à grande plage dynamique.
