Tif & Raw, même combat ?

[frmfrm]

mais la comparaison porte sur RAW vs TIFF.

Mais j'en parle aussi par la suite

Un raw c'est une image, c'est pas un truc innommable parce que c'est pas issu d'un foveon.
Cette image est à une étape.

Si tu la passes par lightroom et que tu génères un tif en srgb, elle sera à une autre étape.

Maintenant, si tu passes ton tif srgb en quadri, et que tu génères nouveau tif, elle sera encore dans une étape différente.

Sur color.org il y a un profile pour générer un tif dès la 1ere étape avec une réponse des tons linéaire. Est-ce que ce tif sera très différent d'un raw ?

[Verso92]

Mais j'en parle aussi par la suite

Un raw c'est une image, c'est pas un truc innommable parce que c'est pas issu d'un foveon.
Cette image est à une étape.

Si tu la passes par lightroom et que tu génères un tif en srgb, elle sera à une autre étape.

Maintenant, si tu passes ton tif srgb en quadri, et que tu génères nouveau tif, elle sera encore dans une étape différente.

Sur color.org il y a un profile pour générer un tif dès la 1ere étape avec une réponse des tons linéaire. Est-ce que ce tif sera très différent d'un raw ?

Je ne comprends pas trop où tu veux emmener la discussion... si tu développes ton RAW avec un profil linéaire et que tu l'exportes tel quel en TIFF, tu obtiendras un TIFF linéaire (avec un gamma = 1).
Rien à voir avec la discussion...

[LeFujiste]

Ce sont des affirmations sans fondement à mon avis. J'aimerais vraiment qu'on m'explique en quoi appliquer un réglage sur le tiff diffère de celui du RAW.
Parce que pour moi, traiter avant ou après dématriçage ne fait guère de différence si on n'apporte pas de 'bruit' de calcul. Et qu'on ne m'avance pas des termes comme BdB "incrustée" dans le tiff vs le raw, car ça n'a aucun fondement techniquement parlant !

Au contraire la différence est fondamentale.

Pour illustrer les différences entre les deux imaginez que vous souhaitez colorer du lait : vous mettez du bleu dans le lait mais ça ne vous plait pas alors vous le jetez et recommencez avec du lait pur et cette fois vous mettez du rouge. Le lait sera teinté en rouge sans résidus de bleu. C'est ce que permet de faire le RAW car après chaque opération l'image est intégralement recalculée à partir de sa base complètement neutre (le lait pur).

Le TIFF lui est obligatoirement enregistré (une première fois) à partir d'une version calculée du RAW, il ne peut jamais être une base neutre. Il serait comme le lait teinté de bleu dans lequel on ira verser du rouge ensuite. Quoi qu'on fasse, il contiendra toujours des résidus de bleu, et bien qu'à force de rajouter du rouge on finisse par s'approcher de la même teinte, elle ne sera jamais aussi précise que celle du RAW.

[Verso92]

Au contraire la différence est fondamentale.

Pour illustrer les différences entre les deux imaginez que vous souhaitez colorer du lait : vous mettez du bleu dans le lait mais ça ne vous plait pas alors vous le jetez et recommencez avec du lait pur et cette fois vous mettez du rouge. Le lait sera teinté en rouge sans résidus de bleu. C'est ce que permet de faire le RAW car après chaque opération l'image est intégralement recalculée à partir de sa base complètement neutre (le lait pur).

Le TIFF lui est obligatoirement enregistré (une première fois) à partir d'une version calculée du RAW, il ne peut jamais être une base neutre. Il serait comme le lait teinté de bleu dans lequel on ira verser du rouge ensuite. Quoi qu'on fasse, il contiendra toujours des résidus de bleu, et bien qu'à force de rajouter du rouge on finisse par s'approcher de la même teinte, elle ne sera jamais aussi précise que celle du RAW.

C'est tellement évident que ça m'étonne un peu (sans animosité aucune envers jaric, hein !) qu'on puisse remettre en cause ce genre de fondamentaux...
Le RAW est en quelque sorte une image latente, pour évoquer l'argentique. Le TIFF (Jpeg, etc) est une image développée.

[fred134]

Sur color.org il y a un profile pour générer un tif dès la 1ere étape avec une réponse des tons linéaire. Est-ce que ce tif sera très différent d'un raw ?

Si le profil est réellement entièrement linéaire (tons et profil des couleurs ?) et a le même point noir que le raw, il reste différent d'un raw pour les opérations de "correction" comme le débruitage, qui peuvent bénéficier de la connaissance des données brutes avec un bon algorithme.

Mais en effet pour la BdB & Cie ce n'est probablement pas moins bon, ces opérations sont de toute façon probablement réalisées après le dématriçage à proprement parler.

D'un autre côté, le raw est fait pour ça, et les logiciels sont assez confortables, ce qui n'est pas le cas de l'utilisation d'un Tiff linéaire :-)

Ce profil est compatible avec quels logiciels de développement des raw ?

[Verso92]

Mais en effet pour la BdB & Cie ce n'est probablement pas moins bon, ces opérations sont de toute façon probablement réalisées après le dématriçage à proprement parler.

Tu es sûr de ce que tu avances ?

[fred134]

Tu es sûr de ce que tu avances ?

Non, j'ai écrit "probablement", c'est juste une hypothèse logique : les algos de dématriçage sur le RGGB sont une chose (je ne vois pas ce que la BdB apporte à ce stade, mais on peut toujours imaginer une astuce à implémenter - mais ce n'est pas probable :-), et ce qui survient derrière est probablement basé sur le RGB "pleine déf" (suis-je clair ?) issu du dématriçage.

A l'appui de cette "logique", les temps de recalcul des aperçus LR selon ce que l'on change... mais ce ne sont que des indices. Perso, c'est comme ça que je ferais a priori, mais je ne suis sûr de rien, soyons clair :-)

[Verso92]

Non, j'ai écrit "probablement", c'est juste une hypothèse logique : les algos de dématriçage sur le RGGB sont une chose (je ne vois pas ce que la BdB apporte à ce stade, mais on peut toujours imaginer une astuce à implémenter), et ce qui survient derrière est probablement basé sur le RGB "pleine déf" (suis-je clair ?) issu du dématriçage.

Je dirais ton que ta "logique" m'échappe... dans des discussussions récentes sur Capture One, il semblerait bien que ce soit justement l'inverse.

A l'appui de cette "logique", les temps de recalcul des aperçus LR selon ce que l'on change... mais ce ne sont que des indices. Perso, c'est comme ça que je ferais a priori, mais je ne suis sûr de rien, soyons clair :-)

Je ne pratique pas LR.
Le rafraichissement de l'image affichée par Capture One quand tu changes un réglage de BdB, de courbe, etc, n'est pas quantifiable à l'échelle humaine : c'est instantané (et heureusement : sinon, ce serait quasi inutilisable)...

[fred134]

Le rafraichissement de l'image affichée par Capture One quand tu changes un réglage de BdB, de courbe, etc, n'est pas quantifiable à l'échelle humaine : c'est instantané (et heureusement : sinon, ce serait quasi inutilisable)...

Dans LR aussi, cela semble plutôt confirmer que ces opérations sont basées sur une représentation intermédiaire (genre RGB linéaire), et non sur la reprise des opérations de dématriçage.

Ton exemple va tout à fait dans le sens de mon hypothèse :-) Je suis surpris que tu penses l'inverse...?

[Verso92]

Dans LR aussi, cela semble plutôt confirmer que ces opérations sont basées sur une représentation intermédiaire (genre RGB linéaire), et non sur la reprise des opérations de dématriçage.

Ton exemple va tout à fait dans le sens de mon hypothèse :-) Je suis surpris que tu penses l'inverse...?

Oui, mon exemple n'est pas bon : il est tout à fait possible que l'image affichée ne soit qu'une représentation intermédiaire.
Ce que je voulais dire, c'est que les changements sur un certain nombre d'outils des logiciels de développement RAW sont de type paramétrique*. L'image sera vraisemblablement complètement recalculée lors de l'export (comprendre que le dématriçage sera refait avec les nouvelles valeurs de ces outils).
*Apparemment, ce ne serait pas le cas, par contre, avec les outils qui induisent des déformations géométriques (redimensionnement, correction de la distorsion, des perspectives, etc).

[fred134]

Ce que je voulais dire, c'est que les changements sur un certain nombre d'outils des logiciels de développement RAW sont de type paramétrique*. L'image sera vraisemblablement complètement recalculée lors de l'export (comprendre que le dématriçage sera refait avec les nouvelles valeurs de ces outils).

*Apparemment, ce ne serait pas le cas, par contre, avec les outils qui induisent des déformations géométriques (redimensionnement, correction de la distorsion, des perspectives, etc).

Oui, c'est aussi comme ça dans LR. (Même si un aperçu 100% est disponible, l'export refait tout le calcul. Probablement entre autres parce qu'un certain nombre d'opérations sont directement appliquées à la représentation RGB, qui n'est donc plus le RGB "primaire" issu du dématriçage - celui-ci n'étant d'ailleurs probablement pas conservé en mémoire.)

Ce que tu écris ne va pas à l'encontre de ce que j'écrivais plus haut, au contraire amha (mais ça reste une hypothèse).

Pour ton astérisque, je n'ai pas compris ce que tu voulais dire ? Ces opérations sont forcément paramétriques, elles sont réversibles et n'altèrent pas le raw...

[Verso92]

Oui, c'est aussi comme ça dans LR. (Même si un aperçu 100% est disponible, l'export refait tout le calcul. Probablement entre autres parce qu'un certain nombre d'opérations sont directement appliquées à la représentation RGB, qui n'est donc plus le RGB "primaire" issu du dématriçage - celui-ci n'étant d'ailleurs probablement pas conservé en mémoire.)

Ce que tu écris ne va pas à l'encontre de ce que j'écrivais plus haut, au contraire amha (mais ça reste une hypothèse).

Pour ton astérisque, je n'ai pas compris ce que tu voulais dire ? Ces opérations sont forcément paramétriques, elles sont réversibles et n'altèrent pas le raw...

Ce que je veux dire, c'est que j'imagine qu'un certain nombre d'opérations sont certainement faites de façon globale, avant dématriçage (je ne vois pas l'intérêt, par exemple, de faire une BdB sur des données dégradées par le dématriçage, alors que les données "brutes" sont disponibles).
Par contre, les opérations comme le redimensionnement ou les corrections de perspective, etc, sont faites, apparemment, sur l'image bitmap (dématricée, donc).

[fred134]

Ce que je veux dire, c'est que j'imagine qu'un certain nombre d'opérations sont certainement faites de façon globale, avant dématriçage (je ne vois pas l'intérêt, par exemple, de faire une BdB sur des données dégradées par le dématriçage, alors que les données "brutes" sont disponibles).

Par contre, les opérations comme le redimensionnement ou les corrections de perspective, etc, sont faites, apparemment, sur l'image bitmap (dématricée, donc).

Avons nous la même définition de "dématriçage" ? Pour moi, c'est l'opération consistant à reconstituer une image RGB pleine définition (3 couleurs par pixel), à partir de l'image RGGB "éparse" (1 couleur par pixel) de départ.

Pour moi, la BdB, le profil colorimétrique, etc, s'appliquent forcément après cette reconstitution.

Sinon, ça reviendrait à faire des combinaisons linéaires (voire non-linéaires) entre des RGGB qui ne sont pas situés au même point de l'image...? ? ?

[Verso92]

Avons nous la même définition de "dématriçage" ? Pour moi, c'est l'opération consistant à reconstituer une image RGB pleine définition (3 couleurs par pixel), à partir de l'image RGGB "éparse" (1 couleur par pixel) de départ.

Oui.

Pour moi, la BdB, le profil colorimétrique, etc, s'appliquent forcément après cette reconstitution.

Sinon, ça reviendrait à faire des combinaisons linéaires (voire non-linéaires) entre des RGGB qui ne sont pas situés au même point de l'image...? ? ?

Je ne vois pas en quoi ce serait gênant (c'est, par principe, lié à la structure de type Bayer)...
La seule information fiable, c'est l'info de luminance et la couleur du photosite (R, V ou B). Le reste n'est que du calcul (interpolation).

[jaric]

Avons nous la même définition de "dématriçage" ? Pour moi, c'est l'opération consistant à reconstituer une image RGB pleine définition (3 couleurs par pixel), à partir de l'image RGGB "éparse" (1 couleur par pixel) de départ.

Pour moi, la BdB, le profil colorimétrique, etc, s'appliquent forcément après cette reconstitution.

Sinon, ça reviendrait à faire des combinaisons linéaires (voire non-linéaires) entre des RGGB qui ne sont pas situés au même point de l'image...? ? ?

Bonjour,
Je reviens vers vous après une journée et je vois que le débat a bien progressé !
Je cite Fred car il résume bien l'idée que j'ai également sur le "dématriçge", qui est un bien grand mot pour dire simplement 'calcul des couleurs manquantes à partir des photosites adjacents'.
Excusez-moi si j'apparais troller, mais je ne vois toujours pas pourquoi cela donnerait au raw un statut privilégié. Comme dit Fred, toutes les opérations sur l'image doivent bien s'effectuer après la transformation du raw qui en tant que tel n'est pas exploitable.

Quant au rapport 8 bits / 16 bits, je dis simplement que si on veut modifier un jpeg, on a tout intérêt avant de commencer à transformer l'image en 48 bits afin de minimiser les dégradations apportées (pour s'en convaincre, il suffit de comparer les histogrammes avant/après dans les deux situtations).

Vite, reprenez vos explications, j'aspire à accéder à la Connaissance ! 

[fred134]

Je ne vois pas en quoi ce serait gênant (c'est, par principe, lié à la structure de type Bayer)...

La seule information fiable, c'est l'info de luminance et la couleur du photosite (R, V ou B). Le reste n'est que du calcul (interpolation).

Si tu faisais des combinaisons linéaires (pour simplifier) sur tes RVVB, avant le dématriçage, pour calculer par exemple des R'V'V'B' modifiés par la BdB :
- quelle info R et B utilises-tu pour calculer le V' d'un pixel V par exemple ? C'est déjà du dématriçage.
- tu floutes ton image en faisant ces calculs, ce sont des interpolations spatiales.
- ça me parait ardu de faire ça sans perdre d'info (de manière réversible), mais il faudrait y réfléchir pour être sûr...
- il est beaucoup plus simple de dématricer les RVVB capteur (où l'on peu appliquer les algos qui distinguent luminance et chrominance, détecter des gradients, etc), puis de faire les opérations de transformation de couleur sur du RGB (3 couleurs par pixel).

Ma réponse est trop courte, désolé, je dois y aller mais complèterai plus tard. J'essayerai de décrire un peu le dématriçage et de te retrouver quelques liens sur le sujet.

[frmfrm]

Pour moi, la BdB, le profil colorimétrique, etc, s'appliquent forcément après cette reconstitution.

Je pense aussi enfin au moins pour lightroom.

Lightroom fonctionne de la facon suivante:

1- Dematricage
2- passage des valeurs RGB en valeurs XYZ,
3- conversion dans l'espace RIMM (gamma 1)
4- affichage a l'ecran et de le l'histogramme de l'espace RIMM mais avec un gamma 2.2

Toutes les autres opérations se font après.

Le profil dont je parlait plus haut est un RIMM avec gamma 1 donc si tu génères un tif qui a ce niveau, tu n'es pas loin de ce que fait lightroom.

Enfin, a mon avis, effectuer une correction de bdb avant dematricage n'a aucun sens

[fred134]

Enfin, a mon avis, effectuer une correction de bdb avant dematricage n'a aucun sens

+1 :-)

Pour compléter un peu ma réponse plus haut : disons qu'on passe de pixels rvvb (1 couleur au choix par pixel) à des pixels RVB dématricés (3 couleurs par pixel) mais sans transformation des couleurs - donc toujours les 3 couleurs "brutes capteur".
Voilà en gros le principe pour un pixel "r", tel que je l'ai compris :
- on garde la valeur "r" du pixel (R=r), et on interpole V et B à partir du voisinage rvvb ;
- en utilisant pour les interpolations l'hypothèse que la chrominance varie peu localement, tant qu'on ne change pas d'objet (plein d'algos possibles, je ne sais pas ce qui est utilisé dans le commerce).

Bien sûr les algos sont complexes et cherchent à optimiser la netteté tout en minimisant les artéfacts (je ne suis pas du tout expert et de toute façon il y a des algos propriétaires - il peut éventuellement y avoir une astuce qui utilise l'info d'une BdB très différente de "jour" pour optimiser quelque chose, mais je dis ça juste pour être complet).

Je ne vois donc pas le sens de faire des transformations de couleur sur les valeurs rvvb avant leur dématriçage en RVB (à supposer que ce soit possible, ce qui ne me parait pas évident). Mais bon, comme déjà dit je ne suis pas expert :-)

Un lien relativement simple, et pas forcément très complet : http://tx.technion.ac.il/~rc/Demosaicing_algorithms.pdf
(faites une recherche sur "demosaicing algorithm" pour trouver plus d'infos)

[Verso92]

Enfin, a mon avis, effectuer une correction de bdb avant dematricage n'a aucun sens

Là, je ne vois pas bien pourquoi, a priori... le dématriçage en lui-même (comprendre l'association à chaque pixel des deux valeurs primaires manquantes suivant un algorithme plus ou moins sophistiqué) n'apporte aucune information supplémentaire (juste construire une image humainement visible).

[Verso92]

Là, je ne vois pas bien pourquoi, a priori... le dématriçage en lui-même (comprendre l'association à chaque pixel des deux valeurs primaires manquantes suivant un algorithme plus ou moins sophistiqué) n'apporte aucune information supplémentaire (juste construire une image humainement visible).

Bon, j'ai fait quelques recherches sur Internet, mais ce n'est pas facile de trouver une publication qui détaille les étapes avant et/ou après dématriçage...

J'en ai quand même trouvé une (voir lien en fin de post), que je vous résume ici :
--> Traitements pré-dématriçage :

1 - Corrections des erreurs dues à l'objectif
    - Vignettage,
    - correction du noir,
    - Correction des défauts isolés.

2 - Réduction du bruit statique

3 - Balance des blancs

4 - Correction de l'exposition
--> Dématriçage
--> Traitements post-dématriçage

1 - Réduction du bruit colorimétrique

2 - Correction des couleurs

3 - Correction échelle de tons & Gamma

4 - Détection des contours & amélioration du contraste

http://iut-gmp.univ-lille1.fr/fichiers/LPVI/couleur.pdf

[fred134]

Bon, j'ai fait quelques recherches sur Internet, mais ce n'est pas facile de trouver une publication qui détaille les étapes avant et/ou après dématriçage...

Oui, tu as évidemment raison pour la BdB ! (et en plus j'étais au courant, mea maxima culpa ! :-)

Pour une raison quelconque, dans cette discussion j'ai toujours pensé "matrice de transformation colorimétrique" quand on parlait de BdB (probablement parce que ça revient à ça en Tiff), alors que ce n'est évidemment pas la même chose : de ce que j'ai vu (ex dcraw, ou l'explication succincte DxO), la BdB est implémentée comme un gain sur les canaux rvvb, et donc en effet avant dématriçage. Alors que le profil colorimétrique (par lequel j'étais obnubilé) est évidemment après.
Mes excuses et merci pour ta recherche...

[frmfrm]

J'en ai quand même trouvé une (voir lien en fin de post), que je vous résume ici :

Il y a quand même des choses étonnantes dans ce papier, tu l'as lu   

Sinon, je ne vois pas ce qu'appliquer la balance des blancs avant dématriçage peut apporter.

Par contre je pense que si tu effectues la bdb avant, tu risques de créer des problèmes pour obtenir un dématricage efficace.

Si tu effectues une bdb tungstène vers couleur du jour, certains pixels bleus et verts risquent de "déborder".

Tu perds des informations alors qu'il n'en a déja pas beaucoup.

[fred134]

Il y a quand même des choses étonnantes dans ce papier, tu l'as lu  
Sinon, je ne vois pas ce qu'appliquer la balance des blancs avant dématriçage peut apporter.
Par contre je pense que si tu effectues la bdb avant, tu risques de créer des problèmes pour obtenir un dématricage efficace.
Si tu effectues une bdb tungstène vers couleur du jour, certains pixels bleus et verts risquent de "déborder".

Je n'ai pas encore eu le temps de vraiment lire le papier cité par Verso, mais pour la BdB c'est le principe retenu dans les mesures DxO de la matrice des couleurs, et surtout on voit ça par exemple dans le code de dcraw (j'avais jeté un oeil rapide, par curiosité). Il y a un équilibrage des canaux raw (avec remise à l'échelle pour éviter de déborder les limites numériques je pense), avant le dématriçage. Et ça me parait tout à fait logique, afin de "corriger" dans une certaine mesure l'influence de l'illuminant, avant les transformations.

Encore une fois, désolé d'avoir écrit l'inverse hier, c'est parce que je pensais "profil colorimétrique" (la BdB comme une transformation matricielle, à la mode Tiff pour renouer avec le sujet), ce qui serait absurde avant dématriçage...

[frmfrm]

Il peut effectivement y avoir une remise à niveau des valeurs car il n'y a pas de pixel à 0 dans le raw.

Il me semble que certains pixels d'un capteur ne sont pas exposés et que la lecture de leur valeur te permet de ramener à 0, mais tu ne perds pas d'information comme dans une balance des blancs.

Sinon effectivement une balance des blancs peut s'effectuer par calcul matriciel. Dans les cas simples une matrice diagonale est utilisée, dans d'autres , c'est un peu plus compliqué.

[B_M]

Question peut-être stupide : Peut-on enregistrer un raw en raw ?
Je veux dire garder  un raw après modif. au format raw. Autrement dit faire autre chose que du traitement paramétrique.
ACR, LR c'est du paramétrique. DPP pour raw CR2 canon propose bien d'enregistrer en cr2 après modif. Mais si vous ouvrez l'image CR2 dans LR on retrouve les reglages LR du raw initial.
Enregistrer sous en tif, psd, jpeg : on passe à autre chose et on bloque les valeurs RVB.
B_M