pipeline graphique de darktable
La plupart des applications de traitement d’image proviennent des années 90 et/ou héritent d’un flux de travail des années 90. Ces applications traitaient des images codées avec des entiers non signés de 8 bits car c’était plus efficace en termes de mémoire et de calcul. Cependant, en raison de l’utilisation d’un format entier (qui implique des erreurs d’arrondi), elles ont dû appliquer un “gamma” (essentiellement une fonction de transfert appliquant une puissance 1/2,2 ou 1/2,4 pour encoder les valeurs RVB). Elles ont aussi dû augmenter la profondeur de bit afin de réduire les erreurs d’arrondi dans les basses lumières (les humains sont très sensibles aux détails de faible luminosité). Les formats d’entiers 8 bits sont également techniquement limités à la plage 0-255. Toute valeur qui ne se trouve pas dans cette plage est tronquée.
Ces flux de travail, utilisant des représentations RVB bornées et éventuellement des transformations non linéaires pour coder des signaux RVB, sont appelés relatifs à l’affichage. Ils reposent sur l’hypothèse que l’image a été préparée pour l’affichage à un stade précoce du pipeline graphique et intègrent des hypothèses codées en dur sur les valeurs RVB du noir, du gris moyen et du blanc. La plupart des algorithmes de traitement d’image utilisés dans ces flux de travail ont été ajustés autour de ces hypothèses. Par exemple, le mode de fusion superposition attend un gris moyen encodé à 50 % (ou à 128 en codage entier).
Malheureusement, la mise à l’échelle non linéaire, qui est obligatoire pour faire fonctionner le codage entier, rompt les relations naturelles entre les valeurs de pixel. La teinte et la saturation changent de manière imprévisible, et les relations de valeur entre les pixels voisins sont dilatées ou compressées de sorte que les dégradés sont également modifiés de manière imprévisible.
Les pipelines graphiques relatifs à l’affichage cassent donc l’effet des filtres optiques (flou ou correction du flou d’un objectif), la simulation de transparence (qui repose sur des définitions optiques et géométriques de l’occultation), les couleurs et les dégradés (relations locales entre chromaticité et luminance des pixels). Ils ne s’adaptent pas bien non plus aux images HDR, ce qui a conduit au développement de nombreuses méthodes discutables de mappage local et global des tonalités et au fameux «look HDR» des années 2010.
Les ordinateurs modernes ne sont pas assujettis aux mêmes limitations de calcul que ceux des années 1990 et peuvent travailler sur des pixels aux valeurs illimitées (de 0 à + infini) et encodées en nombres réels (en utilisant des formats à virgule flottante). Ces possibilités permettent ce que nous appelons un flux de travail “relatif à la scène”, dans lequel les pixels peuvent conserver leurs relations radiométriques d’origine presque tout le long du pipeline graphique. Dans le flux de travail relatif à la scène, les pixels sont préparés pour l’affichage uniquement à la dernière étape du pipeline, dans la transformation d’affichage. Cela signifie que les valeurs RVB des pixels sont maintenues proportionnelles à l’intensité de l’émission de lumière enregistrée par la caméra dans la scène, permettant une simulation de transparence précise et des émulations de filtre optique, tout en s’adaptant à n’importe quelle plage dynamique via le même algorithme (SDR aussi bien que HDR).
Cependant, les pipelines graphiques relatifs à la scène perdent les valeurs fixes pratiques du blanc, du gris moyen et du noir qui caractérisaient les pipelines relatifs à l’affichage. Le réglage de ces valeurs, en fonction de la scène et des conditions de prise de vue, incombe désormais à l’utilisateur. Cela nécessite une interface utilisateur plus complexe.
De plus, comme les valeurs relatives à la scène sont supposées avoir une signification physique, les pixels ne peuvent pas avoir une intensité nulle. Cela signifierait qu’ils n’ont pas de lumière du tout et que l’existence d’une lumière nulle casse de nombreux algorithmes physiquement précis. En fait, le blanc et le noir ne signifient rien par rapport à la scène originale, qui n’est qu’un ensemble de luminances à des intensités variables. Le flux de travail relatif à la scène vise simplement à mapper certaines luminances arbitraires de la scène sur ce qui apparaîtra en blanc ou en noir sur le support de sortie.
Les versions de darktable antérieures à 2.6 avaient un pipeline relatif à l’affichage non linéaire, supposant qu’une transformation non linéaire avait lieu au début du pipeline et que le gris moyen était par la suite codé à 50%. Cependant, tous les modules et filtres ne tronquaient pas les valeurs de pixels supérieures à 100%, laissant ouverte la possibilité de récupérer ces valeurs plus tard dans le pipeline.
La transformation de vue du module filmique, introduit dans darktable 2.6, était la première étape vers un pipeline relatif à la scène. Elle a reporté la préparation, obligatoire, non linéaire, de l’affichage à la fin du pipeline. Elle a aussi donné la possibilité de définir des valeurs personnalisées de noir, de gris et de blanc. Le module balance couleur a ensuite introduit un moyen de traiter une définition variable du gris moyen.
À partir de darktable 3.2, les utilisateurs pouvaient choisir entre deux flux de travail qui définissaient des paramètres par défaut cohérents, un choix de modules et leur ordre dans le pipeline graphique, à la fois, pour le traitement relatif à l’affichage et pour le traitement relatif à la scène.
Dans darktable 3.4, une option complète de masquage et de fusion relative à la scène a été introduite, permettant de définir des masques pour des valeurs de pixel supérieures à 100% et utilisant uniquement des opérateurs de fusion non bornés.
Le passage à relatif à la scène est un saut cognitif pour les utilisateurs les plus expérimentés, qui sont habitués à penser relatif à l’affichage. Dans un flux de travail relatif à l’affichage, il est habituel d’ancrer la valeur du blanc et de laisser les réglages de ton tourner autour de ce point, en essayant de maximiser la luminosité tout en évitant l’écrêtage. Dans un flux de travail relatif à la scène, les valeurs du blanc et du noir sont libres et adaptées au support de sortie. Il est conseillé aux utilisateurs d’ancrer le gris moyen (qui sera conservé tel quel pour tout support de sortie) et de laisser la transformation de vue (filmique) dilater ou contracter la plage dynamique autour de ce point. Étant donné que le blanc HDR 10 bits est 4 fois plus brillant que le blanc SDR 8 bits, toute définition rigide du «blanc» devient non pertinente. Mais l’ancrage du gris moyen est en fait plus pratique, car il maintient la luminosité moyenne de l’image inchangée pendant la transformation de la vue.
Certains modules (niveaux, niveaux rvb, courbe des tonalités, courbe rvb) sont intrinsèquement incompatibles avec un flux de travail relatif à la scène, car leur interface graphique suggère implicitement des valeurs RVB limitées dans la plage de 0 à 100%. Les opérations sur les pixels qu’ils exécutent sont non bornées en interne et peuvent être utilisées dans des flux de travail relatif à la scène ou relatif à l’affichage. Mais leur interface de contrôle ne permet pas que des pixels soient sélectionnés en dehors de la plage de 0 à 100%.
De même, les modes de fusion tels que superposer, lumière linéaire, lumière douce, lumière dure, assombrir, éclaircir, etc. ont tous des seuils codés en dur qui attendent en interne un codage non linéaire relatif à l’affichage.
Dans darktable 3.4 et les versions ultérieures, le passage du curseur sur un en-tête de module affiche une info-bulle détaillant les espaces colorimétriques, les plages et les encodages que le module attend, utilise et produit. Voici les définitions des termes utilisés :
- linéaire
- Les valeurs de pixel sont proportionnelles à l’émission radiométrique de la scène, de manière à permettre une émulation précise des filtres physiques.
- non linéaire
- Les valeurs de pixel sont redimensionnées de telle sorte que les basses lumières reçoivent une plage de codage plus large, généralement pour que le gris moyen de référence de 18,45% ait alors une valeur comprise entre 46 et 50%.
- relatif à l’affichage
- Les valeurs de pixel sont censées se situer entre 0 et 100% de la plage d’affichage, où 100% est considéré comme la luminance d’une surface blanche réfléchissante à 20% (la pastille blanche d’un Color Checker) et 0% est compris comme densité maximale du support de sortie (encre noire saturée ou rétroéclairage minimum du panneau LED).
- relatif à la scène
- Les valeurs de pixel doivent être strictement supérieures à zéro et aller jusqu’à + infini. La signification des valeurs spécifiques des pixels doit être définie par l’utilisateur lors de l’exécution. Les valeurs relatives à la scène n’impliquent pas automatiquement un codage linéaire, mis à l’échelle dans le cadre de la radiométrie.