DxO est-il si mauvais que çà ?

[Benaparis]

Oui : Adobe décale systématiquement la valeur de la TC (~200K, de mémoire, sur les essais que j'avais faits à l'époque).

Dans mon exemple c'est près de 500°K...donc dejà il n'y a pas de règle d'environ 200°K c'est que l'approche couleur d'Adobe est différente (même si on parle de profile dcp vs icc ça donne une explication : https://torger.se/anders/photography/camera-profiling.html#dcp_vs_icc...DxO affiche également une valeur différente de C1.

Je constate juste que (mesure thermocolorimètre = xxxxK) --> (programmation de xxxxK dans le boitier) --> xxxxK affiché dans C1 avec les couleurs bien calées...

Oui tu constates juste que C1 reprend dans son système de balance des blancs la valeur correspondante au boitier. Très bien, mais "et alors?"

D'ailleurs puisque j'ai évoqué le site de Torger qui permet de comprendre beaucoup de choses ; dans le process du traitement dng le dématricage se fait avant la balance des blancs : https://torger.se/anders/photography/camera-profiling.html#dng_profiles

Merci Robert (là, je crois que c'est clair...  ;-) !

Justement non 

[Verso92]

Dans mon exemple c'est près de 500°K...donc dejà il n'y a pas de règle d'environ 200°K c'est que l'approche couleur d'Adobe est différente (même si on parle de profile dcp vs icc ça donne une explication : https://torger.se/anders/photography/camera-profiling.html#dcp_vs_icc...DxO affiche également une valeur différente de C1.

Je cite ça de mémoire (ça remonte à plusieurs années, époque LR5... je peux me tromper).

Je referai quelques essais, par curiosité.

Oui tu constates juste que C1 reprend dans son système de balance des blancs la valeur correspondante au boitier. Très bien, mais "et alors?"

Quand on me demande, au club photo, la TC de nos ProFoto B2 à pleine puissance, je peux donner une réponse le lendemain : il suffit que je regarde dans Capture One...  ;-)

[Ayoul]

J'ai trouvé ça dans le forum de dpreview, qui résume assez bien les choses:

A DNG can be a RAW file or a rendered RGB file. A RAW file is bayered and consists of red, blue and 2 green pixels in a Bayer array. It is the job of the raw converter to convert (de-bayer) the image into a rendered RGB file. However, a DNG file can consist of a rendered (de-bayered) file, a linear DNG.
If you send a RAW file to DXO-PL it will convert the RAW file (de-bayer) into a jpg, TIFF, or DNG. The DNG will not be a RAW file but a linear DNG. This linear DNG is treated like a RAW file because unlike a 16bit TIFF, which contains exactly as much "information" as the linear DNG, it has not had a tone curve or a white balance baked in to the file.
Thus when you open this file in another raw converter like LR, it will have to assign its default tone curve and white balance. Although the linear DNG does not contain anymore "information" than the corresponding TIFF, the information is more "flexible" for further manipulation because no tone curve or white balance has been set.

Le profil colorimétrique n'est pas non plus "baked into the file" dans un DNG linéaire, il est toujours ajustable après coup. Ça reste toujours pour moi un peu magique, le linear DNG, comprends pô tout.

[Benaparis]

Je cite ça de mémoire (ça remonte à plusieurs années, époque LR5... je peux me tromper).

Je referai quelques essais, par curiosité.

Pour les têtes en bois on redonne l'info donné par le staff DxO: https://feedback.dxo.com/t/partial-solution-to-work-with-deepprime-in-photolabs-main-viewer/15509 :

DxO PhotoLab 4 comes with significant improvements on DNG export and reading compared to PhotoLab 3:

it can export a RAW file into DNG with a new mode that fully preserves RAW color information and dynamic range

Donc rien à voir avec l'explication citée par Robert où le DNG linéaire ne contiendrait pas plus d'info que le Tiff 16bits...mais peut être autant qu'un Tiff 48bits...allez savoir 

Bon WE.

[Verso92]

Le profil colorimétrique n'est pas non plus "baked into the file" dans un DNG linéaire, il est toujours ajustable après coup. Ça reste toujours pour moi un peu magique, le linear DNG, comprends pô tout.

Ça me rassure un peu : me sens moins seul !

;-)

[Benaparis]

Allez une petite illustration :

Version linéaire :


Après développement en appliquant les mêmes paramètres :

Un DNG linéaire n'est pas équivalent à un TIFF 16bits tant en terme de valeurs que de chromie c'est exactement comme un raw original sauf que des éventuelles corrections de bruit et d'optiques ont été appliquées.

[Verso92]

Allez une petite illustration :

Version linéaire :

Un DNG linéaire n'est pas équivalent à un TIFF 16bits tant en terme de valeurs que de chromie c'est exactement comme un raw original sauf que des éventuelles corrections de bruit et d'optiques ont été appliquées.

Le TIFF a pris cher !

;-)



Sinon, dans un des liens proposés par Pieloe, on peut lire :

'The only reason to use Linear DNG is to feed the file to a DNG reader that can't understand the particular flavor of DNG that DNG Converter creates for the specific camera, or to act as an interchange format—e.g., lens correx with DxO can write out a linear DNG that ACR can read. This is typically NOT an option people want, not because of size considerations, but because it's no longer really raw—it's half-baked. All the operations that take place during demosaicing are set in stone and can't be redone.'

https://www.loc.gov/preservation/digital/formats/fdd/fdd000188.shtml#notes


Alors, bien sûr, il ne peut s'agir que de l'ancienne version du DNG linéaire exporté par DxO (pas de la version proposée dans DPL4). Mais le bout de phrase que j'ai mis en gras correspond à ce que j'ai toujours pensé.

Après, que ce soit quasiment transparent in fine, tant mieux !

[Benaparis]

Le TIFF a pris cher !

;-)
Sinon, dans un des liens proposés par Pieloe, on peut lire :

'The only reason to use Linear DNG is to feed the file to a DNG reader that can't understand the particular flavor of DNG that DNG Converter creates for the specific camera, or to act as an interchange format—e.g., lens correx with DxO can write out a linear DNG that ACR can read. This is typically NOT an option people want, not because of size considerations, but because it's no longer really raw—it's half-baked. All the operations that take place during demosaicing are set in stone and can't be redone.'

https://www.loc.gov/preservation/digital/formats/fdd/fdd000188.shtml#notes
Alors, bien sûr, il ne peut s'agir que de l'ancienne version du DNG linéaire exporté par DxO (pas de la version proposée dans DPL4). Mais le bout de phrase que j'ai mis en gras correspond à ce que j'ai toujours pensé.

Après, que ce soit quasiment transparent in fine, tant mieux !

C'est clair

Sinon bien sûr Fabrice mais il faut remettre aussi cette phrase dans le contexte de l'époque de ce commentaire (probablement plus de 10ans) et de son auteur Bruce Fraser adepte des formules un peu définives (j'en avais lu une croustillante sur son système de profile DCP); en pratique le seul risque à partir du moment où les modifications (bruit+optique) sont assumées par l'utilisateur c'est que le fichier soit mal dématricé or le process semble parfaitement  maîtrisé aujourd'hui, donc pour moi les réserves sont d'ordre psychologiques, voire idéologiques mais pas pratique or c'est cela qui doit primer ici

[Verso92]

C'est clair

Sinon bien sûr Fabrice mais il faut remettre aussi cette phrase dans le contexte de l'époque de ce commentaire (probablement plus de 10ans) et de son auteur Bruce Fraser adepte des formules un peu définives (j'en avais lu une croustillante sur son système de profile DCP); en pratique le seul risque à partir du moment où les modifications (bruit+optique) sont assumées par l'utilisateur c'est que le fichier soit mal dématricé or le process semble parfaitement  maîtrisé aujourd'hui, donc pour moi les réserves sont d'ordre psychologiques, voire idéologiques mais pas pratique or c'est cela qui doit primer ici

Tu sais, Ben, j'utilisais déjà conjointement DPL et C1 (et notamment cette possibilité d'export en DNG linéaire), et j'ai fait la MàJ (DPL2 --> DPL4) lors du Black Friday, et pas seulement parce que c'était en promo.

Je trouve que les progrès faits par DeepPRIME sont vraiment intéressants, ainsi que ce nouveau paramètre d'export du DNG (correction optique et débruitage seulement).

J'ai profité de la période d'essai pour secouer le machin dans tous les sens, et j'ai été convaincu par les résultats (notamment la transparence du passage dans DPL) :

https://www.chassimages.com/forum/index.php/topic,313814.msg7789197.html#msg7789197


Reste que j'aimerais bien savoir comment ça marche...  ;-)

[Verso92]

Reste que j'aimerais bien savoir comment ça marche...  ;-)

Bon, petits essais à l'instant...  ;-)


a - export en DNG avec l'option "corrections optiques et débruitage seulement" (mais sans correction optique, ni débruitage, hein...  ;-),

b - export en DNG avec toutes les options activées (mais avec seul le rendu boitier d'activé dans DPL, celui du boitier par défaut, soit le D850. Tous les autres traitements sont dévalidés),

c - export en DNG avec toutes les options activées (mais tous les traitements de DPL dévalidés, sauf erreur de ma part).

[Verso92]

et c !


Chose amusante : quand je passe de "a" à "b", je vois les histogrammes bouger légèrement (dans les BL, au centre et dans les HL, quasi sur trois endroits localisés).

Quand je passe de "a" à "c", les histogrammes sont rigoureusement identiques, sauf une pointe dans les HL qui bouge...


La question qui vient derrière : à l'exception de cette pointe dans les HL qui bouge légèrement, est-ce que l'option "correction optique & débruitage" est équivalente à l'option complète si les traitements de DPL sont dévalidés ?

Posée autrement, est-ce que cette option est juste une facilité ou y a-t-il une différence sur l'espace couleur des données RVB dématricées, par exemple ?

[Zaphod]

Ca me parait normal.
La sortie dng nouvellement ajoutée correspond à décocher les outils qui modifient les couleurs ou les courbes.
S'ils ne sont pas sélectionnés, ça ne change rien.

Si par exemple tu choisis un autre rendu couleur ou que tu coches le lighting, là les deux sorties seront différentes.

La nouvelle option est intéressante car elle permet d'éviter d'avoir un effet indésirable pour un outil coché par mégarde.
Elle permet aussi d'avoir deux sorties à la fois, une avec toutes les corrections, une avec seulement optique et bruit.

[Verso92]

Petite erreur pour la "b", désolé... là voici :

[Verso92]

Ca me parait normal.
La sortie dng nouvellement ajoutée correspond à décocher les outils qui modifient les couleurs ou les courbes.
S'ils ne sont pas sélectionnés, ça ne change rien.

Si par exemple tu choisis un autre rendu couleur ou que tu coches le lighting, là les deux sorties seront différentes.

La nouvelle option est intéressante car elle permet d'éviter d'avoir un effet indésirable pour un outil coché par mégarde.
Elle permet aussi d'avoir deux sorties à la fois, une avec toutes les corrections, une avec seulement optique et bruit.

Oui, tu as sans doute raison (il y a juste un pouillème dans les HL sur la "c", mais c'est peut-être un réglage qui traine que je n'ai pas vu...).

Mébon, c'est mieux, quand même, de le savoir : en l'occurrence, ceux qui ont DPL2, par exemple, en bénéficient aussi (avec PRIME au lieu de DeepPRIME). Il faut juste faire attention à dévalider les réglages ad-hoc dans DPL...

[tenmangu81]

L'explication du DNG Linéaire a été dejà donnée plus haut (voir message de Pieloe) et est différente de celle-ci parceque si ce fameux dng ne contient pas plus d'information que le tiff 16bits dans ce cas là il serait tout simplement impossible de pouvoir developper de manière identique le raw original et le dng linéaire (en tout cas dans la version correction bruit+optique) ce qui n'est pas le cas et ce qui a été démontré. Sors un Tiff 16bits depuis la version de base en linéaire et essayes de le developper comme un raw tu vas tout de suite voir ne serait ce n'est pas la même chose, ...un tiff est un fichier bitmap donc rendu de manière définitive (même si on peut évidemment travailler dessus mais sans commune mesure avec un fichier raw non développé dematricé ou non).

A mon avis (mais je me trompe peut-être), c'est justement parce que le TIFF contient plus d'information que le RAW qu'il laisse moins de possibilités de développement. Si la courbe de tonalité et la BdB sont déjà dans le TIFF, ça réduit son aptitude à un développement. Au contraire, le RAW, qui contient moins d'information de ce point de vue, se laisse plus facilement traiter car rien n'est encore figé, en tout cas pas au niveau de la tonalité ni de la BdB.
Et d'ailleurs, qu'entend-on par fichier bitmap ? Un fichier RGB, fût-il DNG, n'en est-il pas un ?

[Verso92]

Et d'ailleurs, qu'entend-on par fichier bitmap ?

C'est un des termes qui a été détourné de son sens originel (un peu comme full frame)...


Un fichier bitmap est un fichier qui contient des infos liées à ses coordonnées x/y (d'ailleurs, l'expression parle d'elle-même : "carte de points"), contrairement au vectoriel, par exemple. Un RAW est donc un fichier bitmap, au sens étymologique de l'expression.

Aujourd'hui, on a tendance à parler de bitmap pour un fichier dont les pixels contiennent les valeurs RVB. Développé, donc, dans la plupart des cas (ce qui remet de l'ambiguïté pour le DNG linéaire, soit dit en passant...  ;-).

[gerarto]

Mais si tu passes le même fichier dans ACR/Lr je suis a peu près certain que tu auras une valeur différente en TC. Tu ne démontre rien d'autre que C1 est un des rare logiciel a reporter exactement les valeurs du boitier mais ça change quoi au final si tu as visuellement un résultat identique malgré des valeurs un peu différentes? Es tu sûr que les valeurs de bdb de C1 sont parfaitement étalonnées?

Je me suis amusé à voir un fichier natif de 5DMkII dans DxO/C1 et Lr et sa version DNG linéaire :

Original :
C1 : 5588 +0,9
DxO : 5514 +12
Lr/ACR : 5100 +2

DNG Linéaire DxO :
C1 : 5150 +1,4
DxO : 5514 +12
Lr/ACR : 5200 +15

Malgré la variété de ces valeurs j'ai exactement les mêmes images, que faut il en conclure? 

Déjà en 2011, j'écrivais que "ça ne date pas d'aujourd'hui"...: 

L'autre possibilité est donc de récupérer la BdB d'origine, si elle est exacte : BdB personnalisée mesurée, ou BdB  "préprogrammée" de l'appareil qui colle avec la situation : une BdB lumière du jour par ex. est souvent assez exacte par temps normal ensoleillé, en tout cas de l'expérience que j'ai avec Sony.

On utilise donc la BdB "d'origine" récupérée par le dématriceur et normalement, je dis bien normalement, on retombe sur ce qu'on est censé avoir mesuré. Et d'ailleurs, les "dématriceurs sérieux" affichent les valeurs de TC et de teinte (les autres se contentent souvent d'un curseur sans unités).

Et c'est précisément là où il y a problème !

J'ignore comment les "références" DxO et LR3 (ACR) récupèrent ces valeurs, mais il faudrait qu'ils se mettent d'accord entre eux puisque les valeurs de TC et de teinte qu'ils affichent ne concordent jamais !  Je veux bien pour la teinte (et encore ! ) puisqu'ils ne disent pas à quelle unité cela correspond (par ex. valeurs en CC), mais pour la TC c'est assez incompréhensible ! Et il semble que de plus ce soit variable en fonction de la marque et du boîtier et Sony ne semble pas trop mal loti : je me souviens d'une une photo issue d'un Pentax où les différences (de valeurs) étaient énormes !

Par exemple, sur la série de photo de ce comparatif, voici quelques valeurs relevées pour les BdB suivantes, réglées sur un A850  :
Réglage :        Lumière du jour :        exemple auto :        Tungstène :       Personnalisée 2600 G1 (=5CC)
----------------------------------------------------------------------------------------------------------------------------
Valeurs DxO :      5453 -1                      3413 -6                      2909 -2                        2599 -5
Valeurs LR :        5000 +11                   3050 +3                     2750 +3                       2500 0

Etonnant, non ?

Je suis bien conscient que chaque APN peut avoir ses caractéristiques, mais en théorie les valeurs au moins de TC sont sensées être absolues.

Mais ce qui est encore plus étonnant, et cette constatation ne date pas d'aujourd'hui, c'est qu'au dématriçage DxO comme LR donnent des images très similaires - sinon identiques - en colorimétrie alors qu'ils n'annoncent pas les mêmes valeurs !
Si je me réfère à ma petite expérience, j'ai l'impression que DxO est plus près de la vérité des chiffres de TC que LR(ACR). Par exemple la TC imposée à 2600 est annoncée à 2599 par DxO, ce qui est bien proche, contre 2500 pour LR. Mais que les fanas de LR ne prennent pas la mouche, puisque le résultat colorimétrique sera généralement bien voisin !

[Benaparis]

A mon avis (mais je me trompe peut-être), c'est justement parce que le TIFF contient plus d'information que le RAW qu'il laisse moins de possibilités de développement. Si la courbe de tonalité et la BdB sont déjà dans le TIFF, ça réduit son aptitude à un développement. Au contraire, le RAW, qui contient moins d'information de ce point de vue, se laisse plus facilement traiter car rien n'est encore figé, en tout cas pas au niveau de la tonalité ni de la BdB.
Et d'ailleurs, qu'entend-on par fichier bitmap ? Un fichier RGB, fût-il DNG, n'en est-il pas un ?

Une image bitmap au sens où je l'entends est une image figée ce qui explique qu'elle se dégrade mécaniquement quand on la manipule dans les valeurs ou la chromie alors qu'un raw dispose d'une véritable faculté de développement qui n'est bien sûr pas infinie mais sans comparaison. Voir mon exemple posté précédemment avec l'image sous-exposée. Par ailleurs et sauf erreur la nature d'un bitmap d'un TIFF fait que la courbe et la balance des blanc est déjà écrasée.

Pour faire de l'analogie avec la cuisine dans un raw fut-il natif ou DNG linéaire issu de DxO Dpl4 c'est comme si on avait tous les ingrédients à disposition et qu'on les assemblait manuellement pour aboutir au résultat souhaité, le Tiff quand à lui c'est déjà un plat cuisiné alors tu peux réassaisonner et lui ajouter quelques ingrédients supplémentaires mais c'est tout.

Ps : quand je parlais d'informations je parlais de matière première disponible pour aboutir à un résultat final. Par ailleurs si on s'en tient au poids de fichier j'avais déjà expliqué qu'un TIFF 16 bits était sensiblement plus lourd qu'un DNG linéaire issu de DxO dont le poids final est particulièrement variable et dépend de la densité de l'image (il contient les 3 couches RVB dematricées).

[Benaparis]

C'est un des termes qui a été détourné de son sens originel (un peu comme full frame)...
Un fichier bitmap est un fichier qui contient des infos liées à ses coordonnées x/y (d'ailleurs, l'expression parle d'elle-même : "carte de points"), contrairement au vectoriel, par exemple. Un RAW est donc un fichier bitmap, au sens étymologique de l'expression.

Aujourd'hui, on a tendance à parler de bitmap pour un fichier dont les pixels contiennent les valeurs RVB. Développé, donc, dans la plupart des cas (ce qui remet de l'ambiguïté pour le DNG linéaire, soit dit en passant...  ;-).

Dans un raw contenant ou non des données matricées les coordonnées pour reprendre l'analogie numérique sont latentes elles ne sont pas encore figées. C'est sans doute pour cette raison que l'on exclue communément le raw des fichiers bitmap.

[frmfrm]

La façon dont LR calcule une valeur numérique pour la balance des blancs est clairement expliquée dans le SDK fourni par adobe. Pas besoin de faire des expérimentations à la mord moi le noeud pour voir si cela est significatif ;-)

Maintenant, je pense que les valeurs stockées dans un raw sont aussi figées  ( dépendent de la scène, de l'expo , de la temp. de couleur de l'illuminant, de l'objectif ( flare et couleur) ). Ce qui me semble important c'est comment et de combien il va falloir utiliser/tirer sur les valeurs du raw pour obtenir un tif ou un jpg.

[Benaparis]

Maintenant, je pense que les valeurs stockées dans un raw sont aussi figées  ( dépendent de la scène, de l'expo , de la temp. de couleur de l'illuminant, de l'objectif ( flare et couleur) ). Ce qui me semble important c'est comment et de combien il va falloir utiliser/tirer sur les valeurs du raw pour obtenir un tif ou un jpg.

Oui elles sont figées dans la mesure où pour reprendre mon analogie culinaire tu as une quantité d'ingrédients définie contenu dans ton raw (ça reste de la photo hein!) mais le mélange et la cuisson c'est l'utilisateur qui le défini alors que dans un fichier Bitmap (aïe Verso  ) bah tu subi le mélange et la cuisson et tu te débrouilles avec

[Verso92]

Dans un raw contenant ou non des données matricées les coordonnées pour reprendre l'analogie numérique sont latentes elles ne sont pas encore figées. C'est sans doute pour cette raison que l'on exclue communément le raw des fichiers bitmap.

Mouais... tu sais, Benjamin, au début des années 90, on n'en parlait pas de la même façon.

[Benaparis]

 

Mouais... tu sais, Benjamin, au début des années 90, on n'en parlait pas de la même façon.

Ca tombe bien on est en 2020 il faut t'y faire.

PS : je parlais d'analogie argentique, mais tu l'avais corrigé de toi même.

[Verso92]

Ca tombe bien on est en 2020 il faut t'y faire.

PS : je parlais d'analogie argentique, mais tu l'avais corrigé de toi même.

En 1990, il m'est arrivé de travailler sur des images numériques bitmap (ce n'était pas de la photo, mais de la reconnaissance automatique d'image. Enfin, bref, on ne va pas s'appesantir...  ;-).


Sinon, ci-dessous pour illustration un RAW ouvert avec IRIS, non dématricé (on est bien en bitmap) :

(mébon, on s'éloigne un peu du sujet, n'est-ce pas ?  ;-)

[frmfrm]

Oui elles sont figées dans la mesure où pour reprendre mon analogie culinaire tu as une quantité d'ingrédients définie mais le mélange et la cuisson c'est l'utilisateur qui le défini.

L'utilisateur le défini aussi à la prise de vue. Sana parler d'expo et ( et d'optimisation d'expo :-) ) . Tu peux aussi filtrer à la prise de vue pour compenser 1- la balance des blancs et  2 - les différénces de sensibilités des canaux RGB :-)

Enfin juste en passant et pour en rajouter une couche ;-) , ce qui est intéressant à connaitre c'est l'algorithme utilisé pour l'adaptation chromatique. Dans le cas de LR c'est aussi indiqué dans le SDK en fonction du profil DCP  . Et le gain/choix à effectuer peut être intéressant .... dans certains cas.