Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Module order
#5
> 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.
Aurélien, photographe portraitiste, spécialiste calcul.
Développeur de filmique, égaliseur de tons, balance couleur, etc.
darktable est mon métier, pensez à m'aider :
[Image: 2FAd4rc]
Répondre


Messages dans ce sujet
Module order - par JacoTux - 05-02-20, 23:10
RE: Module order - par aurelienpierre - 06-02-20, 00:44
RE: Module order - par jpg54 - 06-02-20, 07:06
RE: Module order - par JacoTux - 07-02-20, 00:02
RE: Module order - par aurelienpierre - 07-02-20, 01:33
RE: Module order - par JacoTux - 07-02-20, 10:38

Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)