Module order

[JacoTux]

Je viens de compiler la dernière 3.1.0+558 et je découvre "module order" et ses deux propositions V3.0 et legacy
Deux clics après dans le groupe des modules actifs pour voir tous les modules que j'ai sous le coude dans mon pré-réglage de modules préférés et je constate dans l'ordre V3.0 :
Suppression de la brume assez tôt dans le pipe
Plus étonnant filtre dégradé avant le profil de couleur d'entrée !
Est-ce logique ou moi qui aurait décalé un/des modules par mégarde quand j'ai testé cette possibilité ?

[aurelienpierre]

Filtre dégradé simule un filtre optique fixé sur l'objectif, c'est normal qu'il arrive avant le profil d'entrée si on veut qu'il ait le même effet.

Refais le trajet de la lumière, du soleil au capteur :

soleil (spectre lumineux complet) -> source lumineuse secondaire (spectre lumineux réduit) -> surface (objets) -> gaz (air + humidité) -> verre (lentille) -> capteur.

Chaque milieu traversé ajoute des défauts optiques :

soleil (référence supposée parfaite) -> réduction de spectre -> réflexions, déformation de perspective -> dispersion, diffusion, brume -> diffraction, réfraction, flou, aberrations chromatiques -> matriçage, bruit, métamérisme

Ce qu'on reçoit dans le raw vient directement du capteur. Ce qu'on veut dans le pipe est la lumière d'origine de la scène corrigée pour passer pour une lumière blanche. On va donc appliquer les corrections dans l'ordre inverse d'application des effets optiques, en partant du capteur vers la lumière du soleil :

dématriçage, débruitage, correction du métamérisme (non implémentée), "balance des blancs" (telle qu'implémentée) -> correction des lentilles, aberrations chromatiques, défloutage objectif (non implémenté) -> suppression de la brume -> correction de perspective -> correction du spectre lumineux (non implémenté) -> surfaces vues sous une lumière blanche.

Ensuite, on intercale les filtres physiques à leur emplacement attendu. Finalement, on applique l'adaptation chromatique de la lumière "supposée blanche" vers le tristimulus physiologique humain dans le profil d'entrée. À ce moment là, on quitte le monde physique (même si on garde un codage linéaire de la lumière) pour entrer dans un monde physiologique qui permet de travailler la couleur de manière plus intuitive. Ce monde physiologique, ce sont des espaces RGB ajustés artificiellement pour que les valeurs RGB achromatiques (R = G = B) correspondent à une nuance de gris pur une fois affichés (car le RGB capteur peut parfaitement avoir des valeur achromatiques où 1,2 R = B = 2,5 G, et dériver un espace HSL de ce bourbier est juste infaisable).

Ça explique pourquoi il est conceptuellement faux (même si le résultat est passable) d'utiliser des fusions en mode couleur sur la correction du bruit. Rigoureusement, il n'y a pas de couleur à ce niveau du pipe (donc pas de saturation, pas de teinte, pas de chroma, rien). On a seulement de la lumière, déformée par un capteur dont la sensibilité est anormalement supérieure dans le "vert" (qui n'est même pas un vrai vert au sens humain).

[jpg54]

Merci pour l'info sur cette possibilité.

[JacoTux]

@ Aurélien

Excellente, l'analogie symétrique entre le trajet de la lumière de son origine à venir frapper le capteur et le chemin inverse à parcourir dans le pipe au travers des différents modules.

Intuitivement c'est ainsi que je le ressentais, si cette analogie est effective alors il faudrait traiter le profil de couleur d'entrée avant le filtre dégradé lui même avant la réduction de la brune.

Reste mon manque de connaissance des modules travaillant linéairement dont l’ordre importe moins, par analogie un filtre dégradé peut très bien être le premier filtre devant l'objectif comme le dernier à l'arrière ce qui ne change pas grand chose à l'information avant le capteur.
Dit autrement ces modules pourraient être reclassés sans conséquence... juste pour satisfaire la logique symétrique.

Pour le coup je me questionne sur les modules présents avant le dématriçage, présents contrairement à l'énumération ordonnée ; dématriçage, débruitage, correction du métamérisme (non implémentée), "balance des blancs" ou dit ici à partir ~ 1'40"
Le dématriçage, comme tu le disais, c'est passer d'une monochromie à une trichromie par interpolation, donc au moins pour balance des blancs.

> (car le RGB capteur peut parfaitement avoir des valeur achromatiques où 1,2 R = B = 2,5 G, et dériver un espace HSL de ce bourbier est juste infaisable).
Oups, pas suivit là, pour moi on est achromatique si R = G = B avec H = 0  S = 0 et 0 ≤ L ≤ 100
Ou alors c'est que les 1,2 et 2,5 sont les valeurs de signal reçu par les photosites filtrés rouge et vert, comment dois je le comprendre.

[aurelienpierre]

> Excellente, l'analogie symétrique entre le trajet de la lumière de son origine à venir frapper le capteur et le chemin inverse à parcourir dans le pipe au travers des différents modules.

En fait, c'est pas juste une analogie pédagogique, c'est comme ça qu'on fait du traitement de signal. Une fois que tu as corrigé les défauts du capteur, tu retrouves le signal lumineux tel qu'il était à la sortie de l'objectif. Si tu corriges les défauts de l'objectif, tu retrouves le signal lumineux tel qu'il était à l'entrée de l'objectif… etc. De proche en proche, tu te ramènes à ta référence, qui est la scène éclairée par une lumière blanche (parce que ta chaîne graphique est conçue autour de cette idée, ce qui explique pourquoi on a des problèmes avec les éclairage colorés, incandescents, fluorescents, etc.).

> Intuitivement c'est ainsi que je le ressentais, si cette analogie est effective alors il faudrait traiter le profil de couleur d'entrée avant le filtre dégradé lui même avant la réduction de la brune.

Non. Le profil d'entrée arrive à la toute fin de la correction dans tous les cas, car il matérialise (idéalement) la façon dont la lumière est interprétée par la rétine, à partir de l'information spectrale. Le RGB capteur, est une approximation grossière de cette information spectrale, en tout cas c'est le truc le plus proche dont on dispose. Idéalement, on voudrait d'abord remapper le RGB capteur vers un spectre lumineux (une collection de longueurs d'onde à des intensités variables) au niveau capteur, dérouler la correction d'optique, et finalement insérer une rétine virtuelle à la toute fin (ce qu'est le profil d'entrée, en fait). Mais pour toutes sortes de raisons (je suis trop fatigué pour détailler), on ne peut pas aller du RGB capteur au spectre, donc on garde le RGB capteur jusqu'au profil d'entrée.

> Pour le coup je me questionne sur les modules présents avant le dématriçage, présents contrairement à l'énumération ordonnée ; dématriçage, débruitage, correction du métamérisme (non implémentée), "balance des blancs" ou dit ici à partir ~ 1'40"
Le dématriçage, comme tu le disais, c'est passer d'une monochromie à une trichromie par interpolation, donc au moins pour balance des blancs.

La plupart des algo de débruitage dont on dispose exploitent la corrélation entre les canaux RGB pour estimer le bruit. Même si, intuitivement, on les mettrait avant le dématriçage, technologiquement , on a besoin de les mettre après. Seule la correction du bruit raw marche avant le dématriçage, mais le floutage qu'elle génère est assez violent, et en pratique c'est trop lisse pour être exploitable.

Idem, la balance des blancs et un truc 100% lié au profil d'entrée, qui ne marche que pour un illuminant D50. Rien à voir avec la lumière en elle-même, donc idéalement on aimerait l'avoir juste avant le profil d'entrée. Mais pour toutes sortes de raisons technologiques, c'est impossible de se caler sur la théorie rigoureuse.

> Oups, pas suivit là, pour moi on est achromatique si R = G = B avec H = 0 S = 0 et 0 ≤ L ≤ 100

Non. On est achromatique tant qu'une valeur RGB produit du gris sous un illuminant donné.

Un pixel RGB, en fait c'est un vecteur dans un espace vectoriel en 3D. Ton espace vectoriel (je sais pas où tu t'es arrêté en maths à l'école), il est supposé euclidien, orthonormal etc. Ton pixel RGB, en fait, il est simplement caractérisé par ses coordonnées dans cet espace. Mais on peut très bien changer les vecteurs de base de cet espace (par exemple, pivoter, translater ou dilater l'espace), sans perdre d'information (il suffit d'adapter les coordonnées en conséquence), tant qu'on sait de combien on a translaté/pivoté/dilaté pour passer d'un espace à l'autre.

La beauté de cette propriété, c'est qu'on peut bricoler des espaces spéciaux où les valeurs de gris nous donnent R = G = B (sRGB, Adobe RGB, ProPhoto RGB, ACES, Rec 2020, etc.). Mais c'est juste par un artifice de calcul pour obtenir ce qu'on cherche, en choisissant un repère spatial qui nous arrange.

En soi, un pixel RGB ne représente rien. C'est un codage. Ce qui est important, c'est d'avoir la clé de codage (donc savoir dans quel espace RGB ses coordonnées sont exprimées), ET de connaître les relations entre les différents espaces RGB, pour pouvoir donner du sens à cette valeur.

En fait { achromatique <=> R = G = B avec S = 0 et 0 ≤ L ≤ 100 } n'est pas la conséquence mais le choix de conception de l'espace de couleur. On fabrique un espace 3D particulier dans lequel cette assertion est vraie parce que ça nous simplifie la vie. Et, dans le cas général (notamment pour les espaces RGB des capteurs), elle est fausse.

[JacoTux]

Merci pour cette réponse tradive et détaillée, tous le monde n'est pas petit dormeur comme moi.
J'avais omis dans mon raisonnement l’aspect physiologique pour comprendre le positionnement du profil d'entrée.
J'ai bien conscience du cube RGB, effectivement si on en change ses dimensions les gris resteront sur la diagonale avec des valeurs R G B inégales pour coordonnées du gris mais des vecteurs perpendiculaires différents pour exprimer des teintes de saturation équivalente d'où un cône de saturation déformé.
On ne doit pas perdre les relations RGB à HSV, tout est question de référentiel.
Mais bon si cette simplification cubique ne fonctionne pas pour les capteurs il faut en passer par là.