Tout savoir sur : Faut il convertir les fichiers RAW au format DNG?

Verso92 · Avril 27, 2015, 18:18:05

Citation de: Nikojorj le Avril 27, 2015, 17:56:02
Pour le blanc, oui, c'est physique.

Oui, c'est vrai... à condition que l'on considère ces signaux aléatoires gaussiens comme stationnaires et ergodiques.

Citation de: Nikojorj le Avril 27, 2015, 17:56:02
Par contre, pour la manière sur ça influe sur les couleurs autour, telles que perçues par nos très imparfaits cerveaux (enfin, surtout le mien)... C'est là où le doute m'habite furieusement.
Je suis bien d'accord que ça ne répond pas à la problématique de la BdB qui se balade entre le NEF et le DNG, les données de base étant les mêmes. mais ça peut expliquer pourquoi ça se balade entre différents logiciels, au moins.

Que les traitements diffèrent, c'est bien normal... mais cette BdB fantaisiste m'interpelle.

gigi4lm · Avril 27, 2015, 18:28:26

Je suis comme Verso92, je sent bien que vous avez raison ... mais ma raison ne le sent pas.

Nikojorj · Avril 27, 2015, 19:03:23

Citation de: Verso92 le Avril 27, 2015, 18:18:05
Oui, c'est vrai... à condition que l'on considère ces signaux aléatoires gaussiens comme stationnaires et ergodiques.

C'est vrai qu'on pourrait ouvrir pas mal de possibilités de traitement avec des capteurs qui comptent les photons un par un! Ça existe peut-être d'ailleurs dans les labos (pour de l'imagerie et pas seulement des trucs genre accélérateur de particules)?
Mais bon, en cette actuelle vallée de larmes, il va falloir nous contenter de moyennes... Life sucks.

Verso92 · Avril 27, 2015, 19:18:16

Bon, au moins, si ça peut rassurer : la valeur "6 670K" codée "en dur" sur le D700 est bien codée "telle quelle" dans le DNG (de $1F0A à $1F0E)...
Ci-dessous, copie d'écran du fichier D700 6670K.dng* ouvert avec un éditeur hexadécimal :

*regénéré pour l'occasion sans incorporer les aperçus et le NEF d'origine.

THG · Avril 27, 2015, 19:24:43

Citation de: Verso92 le Avril 27, 2015, 19:18:16
Bon, au moins, si ça peut rassurer : la valeur "6 670K" codée "en dur" sur le D700 est bien codée "telle quelle" dans le DNG...
Ci-dessous, copie d'écran du fichier DNG* ouvert avec un éditeur hexadécimal :

*regénéré pour l'occasion sans incorporer les aperçus et le NEF d'origine.

Ben voilà... et après, tout dépend du profil d'entrée du logiciel, qui va "relire" ces données.

fred134 · Avril 27, 2015, 21:07:52

Citation de: Verso92 le Avril 27, 2015, 19:18:16
Bon, au moins, si ça peut rassurer : la valeur "6 670K" codée "en dur" sur le D700 est bien codée "telle quelle" dans le DNG (de $1F0A à $1F0E)...

Je me demande à quoi correspond le champ que tu as trouvé...

Comme je suis méfiant, j'aimerais bien savoir ce que tu y trouverais en réglant ton D700 sur BdB "auto" ?
- la température de couleur choisie par le boitier ?
- les lettres "AUTO" ?
- ...

Aurais-tu la gentillesse de regarder ?

Verso92 · Avril 27, 2015, 21:16:22

Citation de: fred134 le Avril 27, 2015, 21:07:52
Je me demande à quoi correspond le champ que tu as trouvé...

Comme je suis méfiant, j'aimerais bien savoir ce que tu y trouverais en réglant ton D700 sur BdB "auto" ?
- la température de couleur choisie par le boitier ?
- les lettres "AUTO" ?
- ...

Aurais-tu la gentillesse de regarder ?

J'ai la flemme de tout relancer (ordi, DNG Converter, etc...).
J'avais repéré ce champ dans le NEF précédent (6 670K). J'ai fait une photo en BdB "auto", et édité le fichier aux mêmes adresses ($0714 et suivantes) que celle où figurait "6670K"... on y trouve la chaine de caractères "AUTO".

fred134 · Avril 27, 2015, 21:57:39

Aïe.
Donc ce n'est très probablement pas un champ exploité par les logiciels de dév pour faire la BdB. Ils savent aussi retrouver la balance "auto" effectuée par l'appareil, donc cela doit être ailleurs...
Là, cela me semble plus être de l'informatif (réglages de l'appareil).

Merci !

(NB : mais dans la spec, il y a bien des champs pour la BdB ceci dit, comme je le signalais plus haut.)

Verso92 · Avril 27, 2015, 22:03:45

Citation de: fred134 le Avril 27, 2015, 21:57:39
Aïe.
Donc ce n'est très probablement pas un champ exploité par les logiciels de dév pour faire la BdB. Ils savent aussi retrouver la balance "auto" effectuée par l'appareil, donc cela doit être ailleurs...
Là, cela me semble plus être de l'informatif (réglages de l'appareil).

Merci !

C'est fort possible...

Citation de: fred134 le Avril 27, 2015, 21:57:39
(NB : mais dans la spec, il y a bien des champs pour la BdB ceci dit, comme je le signalais plus haut.)

J'ai parcouru la spec' du DNG, mais n'étant pas softeux de formation, c'est un peu ardu pour moi...

fred134 · Avril 27, 2015, 22:30:48

Citation de: Verso92 le Avril 27, 2015, 22:03:45
J'ai parcouru la spec' du DNG, mais n'étant pas softeux de formation, c'est un peu ardu pour moi...

Les deux tags p37 semblent correspondre (AsShotNeutral et AsShotWhiteXY), cf mon message plus haut pour un aperçu de ce que j'en ai compris.

Zaphod · Avril 27, 2015, 22:37:17

Ca me semble être des champs EXIF qui donnent la valeur de prise de vue.
Mais ça doit bien être quelque part

fred134 · Avril 27, 2015, 22:54:13

Citation de: Zaphod le Avril 27, 2015, 22:37:17
Ca me semble être des champs EXIF qui donnent la valeur de prise de vue.

Oui, c'est ce que je crois aussi.

Citation de: Zaphod le Avril 27, 2015, 22:37:17
Mais ça doit bien être quelque part

Pas sûr :-) Cf les champs que j'ai indiqués ci-dessus - qui reposent a priori sur l'interprétation du boitier par le convertisseur DNG...

Zaphod · Avril 27, 2015, 23:07:56

Citation de: Verso92 le Avril 27, 2015, 11:05:55
A ce propos, je n'ai pas trouvé comment convertir un fichier en DNG linéaire...

C'est dans Préférences / Compatibilité / Personnalisée.
Et là tu peux cocher l'option.

Zaphod · Avril 27, 2015, 23:19:15

Sinon j'ai fait un test avec plusieurs boitiers, en choisissant plusieurs valeurs de balance des blancs.
(2500 - 3500 - 5600 - 8000 - 10000)

Les valeurs dans Lightroom changent.
Par exemple sur mon 40D : 5600K devient : 5350 / +1
Sur mon Pana GM1 : 5600K devient : 5150 / -5
Sur mon Olympus E-M10 : 5600K devient : 5300 / +5

Rien de bien étonnant (j'ai regardé dans Rawtherapee, c'est le même principe avec des valeurs différentes)

Ce qui est marrant c'est que si je passe sur l'E-M10 sur le profil couleur "Huelight", la balance des blancs devient : 4950 / +8.
Lightroom fait donc une interprétation de la balance des blancs qui dépend du profil couleur choisi.
Ca ne marche, bien sur, que pour les balances des blancs de l'appareil photo (en auto ça marche aussi). Si on personnalise et qu'on change d'un chouilla la BdB, ça ne fait plus la conversion.
La fonction "auto" de Lightroom tient aussi compte du profil et ne donne pas les mêmes résultats selon le profil.

Du coup ça me permet de comprendre un comportement bizarre :
- J'importe avec le profil Adobe Standard. Balance des blancs telle quelle = 5300 / +5.
- Je choisis le profil "Huelight", la balance des blancs telle quelle passe à 4950 / +8.
- Je réininitalise la température (en double cliquant sur le slider), ça me repasse la température à 5300.
Je ne comprenais pas pourquoi réinitialiser la balance des blancs ne la remettait pas sur la valeur "telle quelle" alors que c'est ce que j'ai dans mes réglages par défaut...

Arnaud17 · Avril 27, 2015, 23:29:35

Tout ça me fait penser aux compteurs de vitesse des voitures.

Verso92 · Avril 27, 2015, 23:36:40

Citation de: Zaphod le Avril 27, 2015, 23:07:56
C'est dans Préférences / Compatibilité / Personnalisée.
Et là tu peux cocher l'option.

Ah, OK... merci !

(je n'avais pas poussé jusque là...)

MBe · Avril 27, 2015, 23:53:04

Pour le format du raw dans le DNG, après avoir lu / parcouru la spécification DNG 1.4.0.0, 2 phrases retiennent mon attention :
P 16/101 Opcode lists (relatif aux corrections optiques) :
"This also allows processing steps to be specified, such as lens corrections, which ideally should be performed on the image data after it has been demosaiced, while still retaining the advantages of a raw mosaic data format."

P20/101 PhotometricInterpretation :
"The LinearRaw PhotometricInterpretation value is intended for use by cameras that do not use color filter arrays [comme pour un capteur Foveon - Sigma], but instead capture all color components at each pixel. It can also be used for CFA data that has already been de-mosaiced."

CFA = Color Filter Array

La conclusion serait/est que le fichier "raw" encapsulé dans le DNG n'est pas dématricé.
(Avec les outils Adobe (PSE, PS), l'ouverture d'ACR est également systématique, signe d'un fichier non dématricé)

Il est également facile de faire les essais suivants :

En modifiant le *.DNG en *.tif, l'ouverture avec PSE du fichier ouvre la vignette JPEG embarquée (RT se comporte à l'identique)
en modifiant le *.DNG en *.TIFF, l'ouverture avec PSE ouvre ACR et vous ouvrez le "raw" encapsulé dans le DNG. ( RT continue à ouvrir le JPEG)

Pour la Balance des blancs : j'ai constaté que de nombreux softs ( sauf C1*, Cnx2*...;la liste n'est pas exhaustive) n'utilisent pas, n'affichent pas la valeur de BdB enregistrée dans les valeurs EXIF de l'APN, pourquoi? la valeur affichée n'est pas trop éloignée, mais je ne vois pas de bonnes raisons pour ne pas utiliser celle de l'APN.

* lorsque l'APN est en valeur auto, la valeur affichée est calculée à partir des données du raw.

fred134 · Avril 28, 2015, 00:01:16

Citation de: MBe le Avril 27, 2015, 23:53:04
* lorsque l'APN est en valeur auto, la valeur affichée est calculée à partir des données du raw.

Juste pour être sûr qu'on se comprend : pour moi, quand mon boitier est sur BdB auto, LR récupère ce que le boitier a calculé. C'est différent de la BdB auto de LR, calculée par l'algorithme de celui-ci à partir des données image.

LR va a priori chercher cette valeur de BdB "boitier" dans le raw (dans les données autres que les RGGB image).

MBe · Avril 28, 2015, 00:19:17

Citation de: fred134 le Avril 28, 2015, 00:01:16
Juste pour être sûr qu'on se comprend : pour moi, quand mon boitier est sur BdB auto, LR récupère ce que le boitier a calculé. C'est différent de la BdB auto de LR, calculée par l'algorithme de celui-ci à partir des données image.
LR va a priori chercher cette valeur de BdB "boitier" dans le raw (dans les données autres que les RGGB image).

Peut être? je n'ai pas fait d'essais sur ce cas. Mais j'ai un doute que Lr (ou un autre soft qui ne lit pas spécialement les données Exif) prenne la valeur calculée par le boîtier, plutôt une valeur encapsulée dans le raw ou d'un calcul réalisé sur une zone image (pas sur l'ensemble des photosites du capteur comme le fait Lr ou d'autres). (J'ai fait les mêmes constatations que Verso avec un éditeur Hexa de fichier)

Un autre essai que j'ai fait de nombreuses fois, est de faire une mesure de BdB avec l'APN avec une charte de gris BdB , de faire dans la foulée une photo avec cette Bdb calculée par l'APN, au développement, avec la pipette sur la charte de gris BdB, il y a un écart... pas top important, mais quand même... L'APN n'est pas un instrument de mesure calibré et les calculs réalisés (par rapport à un corps noir) par les softs ne sont pas parfaits

J'ai également des écarts entre 3 chartes de gris BdB... car les valeurs a* et b* (de L*a*b*) ne sont pas totalement nulles!

fred134 · Avril 28, 2015, 00:32:34

Je ne suis non plus évidemment sûr de rien :-)

Mais j'ai cru constater que la BdB auto de mes boitiers (Canon), que je récupère et utilise dans LR (option "telle quelle"), n'a rien à voir avec celle de LR en "auto". Et que celle de mon 6D est différente du 5D que j'avais avant.

C'est pourquoi j'ai tendance à penser (sans preuve) que LR récupère la valeur calculée par le boitier dans le raw.

Les tags que je signalais p37 des specs DNG vont dans le même sens, il me semble.

MBe · Avril 28, 2015, 07:59:11

Oui pour Asshotwhitexy dans l espace couleur XYZ

Jean Delmas · Avril 28, 2015, 12:24:54

Merci à Verso92 pour ses expériences et ses commentaires très intéressants. Je suis moi-même très loin de chez moi en ce moment, et je n'ai pas pu contribuer à ces essais...

Je voudrais juste rappeler ici que la température de couleur (et la teinte associée) d'une photographie ne constituent pas un "réglage de prise de vue" comme l'ouverture du diaphragme ou le temps de pose, mais mesurent tout simplement la couleur de l'illuminant de la scène au moment de la prise de vue. Cette donnée est donc FACTUELLE. Elle peut se mesurer, et est indispensable pour l'interprétation des nombres RGB du fichier RAW dématricé. Elle permet en effet de rendre achromatiques les objets de la scène dont la couleur est « neutre » c'est-à-dire les objets qui renvoient vers l'objectif des rayonnements « identiques » à l'illuminant. Cette opération, dite « balance des blancs » ne fait qu'imiter ce que la perception du photographe avait faite, lors de la prise de vue, sous l'effet de l'adaptation chromatique de sa vision.

En supposant que l'illuminant de la scène soit uniforme, sa couleur (TC+teinte) peut être estimée par l'APN ou peut être fixée par l'opérateur sur son APN au moment de la prise de vue (qui l'a peut-être mesurée avec un thermocolorimètre...) Inscrite dans le fichier de prise de vue, cette couleur peut donc être fausse et même légitimement fausse si le photographe cherche à obtenir un résultat colorimétrique particulier, ce qui est son droit.

Je ne vois donc pas pour quelle raison un logiciel de développement ou de conversion, se permettrait d'apporter une modification à cette valeur factuelle « de prise de vue » inscrite par le boitier. Il est vrai que chaque logiciel de développement intègre sa propre mécanique d'interprétation des images, son propre modèle de comportement colorimétrique de l'APN, son propre profil d'APN, mais je ne vois pas comment cela justifierait qu'il modifie une donnée mesurant une condition factuelle de la prise de vue.

Maintenant, on peut bien entendu vouloir que le logiciel de développement nous aide à modifier la couleur de l'illuminant, en particulier dans les cas fréquents où son estimation par l'APN est erronée, mais cette légitime capacité de correction ne peut en aucun cas justifier que le logiciel modifie sans sommation (et même avec sommation) la valeur inscrite dans le fichier, même si elle est fausse.

J'avoue que j'attribuais trop souvent, jusqu'à présent, les modifications de couleur d'illuminant apportées par LR (avec l'option par défaut dite « Telle quelle ») au fait que la donnée inscrite dans le RAW pouvait être cryptée. C'était vrai il y a qq années mais ce ne peut plus être le cas aujourd'hui avec des NEF modernes. On ne voit d'ailleurs pas comment Phase ONE saurait les décrypter mais pas Adobe...

Ce serait pas mal qu'Adobe s'exprime sur le sujet. Mais l'explication existe peut-être déjà dans une documentation Adobe que je n'ai pas assez bien lue... La seule explication qui me vient aujourd'hui à l'esprit, c'est que LR modifie la couleur de l'illuminant quand il juge qu'elle est erronée... mais alors, comment traiter les données volontairement et légitimement fausses ?

Verso92 · Avril 28, 2015, 14:50:30

Citation de: Jean Delmas le Avril 28, 2015, 12:24:54
Je voudrais juste rappeler ici que la température de couleur (et la teinte associée) d'une photographie ne constituent pas un "réglage de prise de vue" comme l'ouverture du diaphragme ou le temps de pose, mais mesurent tout simplement la couleur de l'illuminant de la scène au moment de la prise de vue. Cette donnée est donc FACTUELLE. Elle peut se mesurer, et est indispensable pour l'interprétation des nombres RGB du fichier RAW dématricé.

Bon, cela me rassure sur ce que j'avais cru comprendre... ;-)

Citation de: Jean Delmas le Avril 28, 2015, 12:24:54
J'avoue que j'attribuais trop souvent, jusqu'à présent, les modifications de couleur d'illuminant apportées par LR (avec l'option par défaut dite « Telle quelle ») au fait que la donnée inscrite dans le RAW pouvait être cryptée. C'était vrai il y a qq années mais ce ne peut plus être le cas aujourd'hui avec des NEF modernes. On ne voit d'ailleurs pas comment Phase ONE saurait les décrypter mais pas Adobe...

Après, il reste des mystères sur le codage des informations...
J'ai fait ce matin des essais avec mon D700, en programmant BdB = "Ensoleillé", et en faisant une correction sur la grille (programmation = +6 sur l'axe Vert/Magenta*), pour voir.
Capture Nx2 et Capture One trouvent tous les deux une BdB égale à 4 699K à l'ouverture du fichier NEF (normal, a priori). Mais je n'ai pas trouvé trace de "4699" dans le code du fichier NEF... juste "SUNNY". Que les deux logiciels trouvent pile-poil la même valeur de BdB, au degré Kelvin près, n'est certainement pas le fruit d'une coïncidence...

*même essai avec +6 sur l'axe Ambre/Bleu : 6 175K avec C1 et 6 176K avec Capture Nx2.

Jean Delmas · Avril 28, 2015, 14:54:17

Citation de: photocor le Avril 28, 2015, 13:03:28
Depuis longtemps des anonymes le disent. Mais vu qu'ils n'ont pas pignon sur rue "on" (experts compris) ne les croit pas. Il en est de même pour des connus interdits de forum mais qui ont une façon de s'exprimer qui ne convient pas aux "théseux".
Avec cette intervention, peut être qu'"on" va enfin prendre nos remarques en compte et réviser la simplicité du traitement de la couleur par les produits Adobe.
Ceci étant cela n'empêche pas de produire des images (avec Phase One ).

Merci d'attribuer un tel pouvoir à mon intervention. Mais, je crois à peu près comprendre vos sous-entendus complotistes et je ne m'y associe absolument pas. Je suppose que vous appelez "théseux" les gens qui élaborent ou défendent une thèse de manière scientifique. Alors je suis l'un d'eux et il est vrai que je préfère enseigner la science à des élèves que prêcher des incantations à des adeptes. Par ailleurs, opposer comme vous le faites méchants "instruits" aux malheureux "anonymes" supposés avoir la science infuse me rappelle de mauvais souvenirs. Ceci étant, tout cela ne m'empêche pas de produire des images avec LR et avec C1...

Jean Delmas · Avril 28, 2015, 15:37:06

Citation de: Verso92 le Avril 28, 2015, 14:50:30
Capture Nx2 et Capture One trouvent tous les deux une BdB égale à 4 699K à l'ouverture du fichier NEF (normal, a priori). Mais je n'ai pas trouvé trace de "4699" dans le code du fichier NEF... juste "SUNNY". Que les deux logiciels trouvent pile-poil la même valeur de BdB, au degré Kelvin près, n'est certainement pas le fruit d'une coïncidence...

Vous avez peut-être bien découvert une partie du pot au rose !

La couleur de l'illuminant (TC+teinte) n'est sans doute pas CRYPTÉE par Nikon mais plus simplement CODÉE (ce qui, par parenthèse, est une solution très discutable). Si Nikon inscrit le mot "Sunny" dans son fichier RAW et non des données numériques, alors il n'est pas étonnant, il est même inévitable, que chaque logiciel de développement donne sa propre versions de ce qu'il pense être la couleur du "ciel ensoleillé".

Dans cette hypothèse, on peut imaginer que les éditeurs de logiciels de développement aient deux approches différentes selon le degré d'irritation dans lequel les a plongé ce codage ambigu, certains, comme Phase ONE, passant un coup de téléphone à Monsieur Nikon pour lui demander ce qu'il entend par "Sunny" (et Nikon de répondre "4699 K") alors que d'autres, comme sans doute Adobe, préférant quantifier "Sunny" selon sa propre science des couleurs du soleil...

Ceci dit, cette disposition n'éclaire en rien le cas où le photographe entre une valeur arbitraire de TC sur son boitier, par exemple 5555 K, valeur que C1, si j'ai bien compris, adopte telle quelle, alors que LR la modifie.