DxO est-il si mauvais que çà ?

[Zaphod]

Yep, mais on peut se demander si c'est toujours un RAW ou pas.
Pour moi ça ne l'est pas, même si ça ne veut pas dire que c'est un fichier sans intérêt, ou sans marge de développement.

Après oui, les RAW générés par les appareils ne sont pas (plus) totalement bruts non plus.

[Zaphod]

Ca n'est pas juste une question de sémantique.

Sur un raw classique, je sais ce que je peux en tirer, même quand c'est issu de mon téléphone.
Sur un raw déjà en partie traité (ce qui est le cas d'un dng linéaire), une partie des choix a déjà été fait.

Si les fins détails ont été bouffés par le traitement du bruit, ils sont perdus (bien sur pour un workflow qui passe par dxo, je garde toujours le raw d'origine).
C'est pour ça que je suis assez prudent sur les réglages....

Sur du apple proraw en revanche, aucune option n'est disponible... donc oui on garde une latitude de développement bien supérieure à un jpeg, mais on a une marge de manœuvre réduite sur le bruit et les détails.

[nicolas-p]

Est-ce que la sémantique fait avancer le schmilblick..
Perso j'ai lâché depuis longtemps, ce qui ne veut pas dire que je n'ai rien appris (en particulier sur les DNG linéaires. J'ai manipulé un peu plus DXO, simple d'utilisation et donnant des résultats qualitatifs simplement et ses limites se sont affirmées pour moi.
Il y a des écarts couleurs vus par certains flux, d'autres non. Mais les utilisateurs y trouvent leur compte et sont satisfaits ce qui est bien le principal.
Merci

D'accord !
Sage analyse

[Verso92]

Ca n'est pas juste une question de sémantique.

Sur un raw classique, je sais ce que je peux en tirer, même quand c'est issu de mon téléphone.
Sur un raw déjà en partie traité (ce qui est le cas d'un dng linéaire), une partie des choix a déjà été fait.

Si les fins détails ont été bouffés par le traitement du bruit, ils sont perdus (bien sur pour un workflow qui passe par dxo, je garde toujours le raw d'origine).
C'est pour ça que je suis assez prudent sur les réglages....

Sur du apple proraw en revanche, aucune option n'est disponible... donc oui on garde une latitude de développement bien supérieure à un jpeg, mais on a une marge de manœuvre réduite sur le bruit et les détails.

+1

[gerarto]

J'ai fait un test assez poussé cet après-midi qui m'a permis de mettre en évidence la nuance entre dématriçage et développement relevée par Pieloe à la page précédente.

La procédure :
Un fichier raw de Sony A7RIII "compressé Sony" pesant 41.4 Mo. 3200 iso donc justifiable d'un traitement DeepPRIME.

1 - Traitement dans DxO PL4 avec pour seules corrections celles de l'optique et du débruitage (DeepPRIME). Avec un export jpeg de ce traitement, soit dématriçage + développement (limité ici).
2a - Export dans PL4 d'un DGN de type "Débruitage et corrections optiques seulement"
2b - Ouverture de ce DGN dans ACR. Tous réglages à Zéro. Les corrections optiques sont désactivées par ACR à l'ouverture (bruit, aussi, mais c'est probablement le comportement normal).
2c - Image ouverte dans PS, et enregistrement d'un jpeg.
3a - Ouverture du raw original dans ACR avec tous les réglages à zéro. Les corrections optiques (profil d'objectif) sont activées par ACR à l'ouverture (le bruit, non, même interrogation... ).
3b - Image ouverte dans PS, et enregistrement d'un jpeg.

Au final, j'ai
- un raw original
- un DNG issu du raw
- un jpeg issu du traitement par DxO PL4
- un jpeg issu du traitement du DNG par ACR
- un jpeg issu du traitement du raw par ACR

Je visualise tout ce petit monde dans ACDSee qui est ma visionneuse habituelle, et dans laquelle la gestion des couleurs est activée (ce qu'ACDSee fait plutôt depuis pas mal de versions déjà... ) et sur écran Eizo CG 2420 Adobe RGB

- Visualisation du raw : ACDSee affiche dans un premier temps la vignette intégrée dans le raw = les réglages jpeg boîtier. Quelques instant après, affichage du fichier pleine taille via son propre décodeur raw. Ce qui au passage m'a permis de constater qu'ACDSee avait fait de sacrés progrès sur ce point (je ne m'en sers jamais pour ça, les anciennes versions étant assez "limitées" [euphémisme] en traitement).

- Visualisation du DNG : surprise (ou pas... ), ACDSee se comporte exactement pareil. D'abord "vignette" puis "décodeur raw". Ce qui signifie que le DNG embarque également une vignette (aperçu, etc... ) exactement comme un raw. Mais ce n'est pas celle du raw (jpeg boîtier), c'est celle correspondant au dématriçage/traitement du jpeg PL4 !
Point à noter : la visualisation du DNG est évidemment celle issue du traitement ACDSee. Elle diffère un peu en colorimétrie/luminosité de celle du même DNG ouvert dans ACR. Ce qui prouve que la partie "traitement" est bien propre à chaque logiciel puisque l'on part d'un même DNG dématricé. Mais la différence est assez ténue. Je n'ai pas fait de traitement dans ACDSee, ce qui était évidemment possible, mais je ne l'utilise ici que comme "arbitre" entre DxO PL et ACR.   
   
- Visualisation du jpeg issu de DxO : pas de remarque particulière, il est... ce qu'il est.

- Visualisation du jpeg issu du DNG traité par ACR : comme dit ci-dessus, je note une différence visible mais relativement faible de luminosité et très ténue de colorimétrie. Avec le même constat : le développement même tous réglages à zéro est bien propre à chaque soft.

- Visualisation du jpeg issu du raw traité par ACR : c'est assez bluffant, ils serait quasi identique au précédent... sauf que le profil de correction d'objectif (y compris donc vignetage) de DxO est manifestement meilleur, ce qui donne un résultat différent et variable à l'approche des bords/angles (géométrie et luminosité).

Conclusion : le dématriçage et le développement sont comme indiqué en ouverture de ce post deux actions indépendantes. L'utilisateur habituel d'ACR (PS, LR) pourra sans aucun problème utiliser un DNG avec les corrections de bruit (DeepPRIME) et d'objectif de PL sans que ça change quoi que ce soit pour le reste de ses réglages.

____

Les fausses bonne idées :
- forcer les corrections de profil d'objectif incorporé dans ACR avec un DNG DxO revient à additionner les deux corrections. Pas glop.
- La valeur de BdB "telle qu'elle" affichée dans ACR pour le DNG est différente de celle affichée pour le raw correspondant. Pourquoi ? je n'en ai aucune idée mais le résultat écran est identique ! Inutile de chercher à imposer les mêmes valeurs de l'un vers l'autre et réciproquement : la colorimétrie s'en trouverait nettement changée. Evidemment ça ne concerne pas des ajustements volontaires de ladite BdB...   

[egtegt²]

J'avoue que vous m'avez un peu perdu sur un point :  Pour moi jusqu'à ce soir, le dématriçage faisait partie du développement. Et là vous dites que non. C'est quoi pour vous la différence entre dématriçage et développement ?

[Benaparis]

Ca n'est pas juste une question de sémantique.

Sur un raw classique, je sais ce que je peux en tirer, même quand c'est issu de mon téléphone.
Sur un raw déjà en partie traité (ce qui est le cas d'un dng linéaire), une partie des choix a déjà été fait.

Si les fins détails ont été bouffés par le traitement du bruit, ils sont perdus (bien sur pour un workflow qui passe par dxo, je garde toujours le raw d'origine).
C'est pour ça que je suis assez prudent sur les réglages....

Sur du apple proraw en revanche, aucune option n'est disponible... donc oui on garde une latitude de développement bien supérieure à un jpeg, mais on a une marge de manœuvre réduite sur le bruit et les détails.

De tout cela je ne dis pas le contraire et je pense être un de ceux parmi les différents intervenants de ce fil qui utilise les systèmes où les interventions électroniques sur le fichier au niveau du boitier sont les plus minimes du marché pour privilégier la meilleure qualité d'image possible...au risque de me répéter quand vous générez un DNG linéaire via DxO parceque vous avez besoin de correction optique et/ou de réduire le bruit c'est un choix conscient en non subi, idem concernant le futur Proraw d'Apple le système ne vous l'impose pas (comme le système de compression bitmap HEIC)...Donc pour moi c'est un peu un faux débat surtout dans la mesure où les raw 100% bio n'existent pas en tout cas pour les APN que nous sommes amenés à utiliser (j'imagine que ça doit exister pour les APN scientifiques de pointe) et que ces raw optimisés gardent l'essentiel de ce que l'on attend d'un raw à savoir de permettre un travail a posteriori sur la tonalité et éventuellement les couleurs de l'image.

[Benaparis]

J'avoue que vous m'avez un peu perdu sur un point :  Pour moi jusqu'à ce soir, le dématriçage faisait partie du développement. Et là vous dites que non. C'est quoi pour vous la différence entre dématriçage et développement ?

Le dématricage n'est une opération utile que pour les APN a matrice, cela ne fait pas partie du développement (ici la sémantique est importante) qui est essentiellement un travail sur la tonalité et éventuellement les couleurs (les APN monochromes ou les systèmes Multishot qui génère des fichiers en couleur directe n'ont pas besoin de passer par cette étape).

[Zaphod]

au risque de me répéter quand vous générez un DNG linéaire via DxO parceque vous avez besoin de correction optique et/ou de réduire le bruit c'est un choix conscient en non subi, idem concernant le futur Proraw d'Apple le système ne vous l'impose pas (comme le système de compression bitmap HEIC)...Donc pour moi c'est un peu un faux débat surtout dans la mesure où les raw 100% bio n'existent pas.

Je pas dit que c'était subi
La question c'est de comprendre un peu plus ce qui est fait dans ces différents fichiers pour justement pouvoir choisir en connaissance de cause.
On peut très bien choisir d'utiliser ces fichiers "semi bruts" si ça marche bien pour son utilisation.

C'est comme la limite de l'Adobe RVB pour DxO, c'est bien de le savoir, après à chacun de voir si c'est un problème ou pas pour lui.
De mon côté, l'impression (ou la visualisation) sera de toute façon au moins aussi restrictive que ça.

[Benaparis]

Je pas dit que c'était subi
La question c'est de comprendre un peu plus ce qui est fait dans ces différents fichiers pour justement pouvoir choisir en connaissance de cause.
On peut très bien choisir d'utiliser ces fichiers "semi bruts" si ça marche bien pour son utilisation.

C'est comme la limite de l'Adobe RVB pour DxO, c'est bien de le savoir, après à chacun de voir si c'est un problème ou pas pour lui.
De mon côté, l'impression (ou la visualisation) sera de toute façon au moins aussi restrictive que ça.

Je suis bien d'accord qu'il est important d'avoir conscience des choix que l'on opère d'abord parceque l'on comprend mieux ce que l'on fait et qu'ensuite ça évite de propager des mythes et légendes sur des propriétés supposées, je me suis toujours battu sur ce forum pour la clarté, la précision de ce que l'on avance quitte à me répéter ad nauseam. Mais je trouve que les choses ici sont plutôt claires, pour ma part à aucun moment je n'ai supposé qu'une fois la moulinette Prime passé sur mon fichier généré ensuite en DNG linéaire je pourrai revenir en arrière sur cette action dans mon éditeur CaptureOne, l'essentiel j'insiste c'est donc conserver avec ces raws optimisés les facultés essentielles du développement attendues avec ce type de fichier à savoir le travail sur la tonalité et éventuellement la couleur de l'image là où les fichiers bitmap (non raw) ont des capacités extrêmement limitées pour ne pas dire nulles en comparaison.

[Zaphod]

, l'essentiel j'insiste c'est donc conserver avec ces raws optimisés les facultés essentielles du développement attendues avec ce type de fichier à savoir le travail sur la tonalité et éventuellement la couleur de l'image là où les fichiers bitmap (non raw) ont des capacités extrêmement limitées pour ne pas dire nulles en comparaison.

Oui tout à fait.
Comme je disais en général je copie/colle les réglages du RAW (la plupart du temps, je commence à traiter le RAW avec Lightroom, et je m'aperçois ensuite qu'elle bénéficierait d'un passage dans DxO. Pas seulement pour le bruit, mais parce qu'à partir d'un certain niveau d'iso lightroom commence à bouffer les couleurs).
Et ça marche bien même si des légers décalages peuvent se voir (qui ressemblent plus à un décalage de balance des blancs qu'à un problème d'espace de travail, surtout sur mon écran qui n'affiche "que" de l'Adobe RVB, à peu de choses près).

Je ne suppose - mais je peux me tromper - qu'il peut y avoir une différence sur l'application de la balance des blancs selon qu'on part d'un fichier matricé ou pas.
Ou que les corrections effectuées par dxo (vignetage, meilleures conservations de couleurs là où lightroom les rend fades) ont aussi une influence...
(faudrait que je vérifie si ça n'est pas juste que la balance des blancs "as shot" est décalée, mais il me semble que les valeurs étaient identiques.

[gerarto]

Lorsque vous faites des comparaisons couleur à l'écran c'est bulshit.
Les comparaisons doivent se faire sur des fichiers qui ont des valeurs de couleur dépassant l'Adobe98. Et pour qu'ils aient ces valeurs il faut que les profil colorimétrique du boitier soient de qualité et proche du Prophoto. Enfin seules des mesures peuvent vous donner des indications fiables.
D'ailleurs j'aimerai bien connaitre l'emplacement (sous mac) de leurs profils boitier. Merci

Evidemment que j'aurais pu faire des comparaisons chiffrées des valeurs RVB d'un point particulier. Tant pis si le pixel d'à côté à d'autres valeurs... ou alors il faut moyenner, oui mais sur quelle base ?
J'aurais même pu mettre des copies d'écran sur lesquelles chacun pu juger des différences... pour la plupart sur un écran sRVB !
Mais j'estime avoir passé assez de temps sur cette manip qui avait principalement pour but de bien comprendre la différence entre dématriçage et développement. Chacun pourra à sa guise la reproduire.
Et qui te dis que je n'ai pas soigneusement choisi mon raw parce que justement il me semblait présenter des couleurs limites ?

Alors, certes je ne dispose pas des moyens techniques ni d'un labo high-tech pour délivrer des pages de résultats (DxO, si ! ). Mais j'ai un œil qui n'est pas si mauvais et qui sait parfaitement faire la différence sur un bon écran (et j'espère que le mien est bon) lorsque je fais défiler alternativement les images. C'est ma méthode "merdique (bullshit in french)", mais c'est probablement celle que nous utilisons tous lorsque l'on fait des réglages dans nos logiciels favoris. 

Après, pour moi ce type de comparatif c'est du temps perdu - n'était-ce l'intérêt de faire avancer le schmilblick - dans la mesure où je ne sort pas du flux complet DxO PL de l'ouverture du raw aux sorties finales jpeg et à l'impression sur imprimante photo A3+
Mais si ça peut aider ceux qui n'ont pas le même flux...
   
NB : ancien ingénieur dans un tout autre domaine, j'espère avoir gardé l'habitude des procédures cadrées et vérifiées, et de la chasse aux biais trompeurs possibles.

[egtegt²]

Le dématricage n'est une opération utile que pour les APN a matrice, cela ne fait pas partie du développement (ici la sémantique est importante) qui est essentiellement un travail sur la tonalité et éventuellement les couleurs (les APN monochromes ou les systèmes Multishot qui génère des fichiers en couleur directe n'ont pas besoin de passer par cette étape).

Mais alors comment peut-on séparer le dématriçage du développement ? A moins que je n'ai pas tout compris, la raison pour laquelle il est très fortement recommandé de rester sur un RAW pour la BDB, c'est parce que cette étape fait partie du dématriçage. Si cette étape est faite ultérieurement, alors on pourrait la faire aussi bien sur un tiff 16 bits que sur un RAW, ce qui n'est pas le cas pour autant que je sache (j'avoue que je te fais confiance sur ce point, je n'ai jamais essayé).

Toujours si j'ai bien compris comment ça marche, le problème est qu'au dématriçage, il va déjà commencer à interpréter la photo et si on n'en profile pas pour faire la BDB à ce moment, certaines informations sont définitivement perdues par cette opération. Ne serait-ce que parce qu'on a deux photosites vert pour chaque pixel et on réduit les valeurs de ces deux photosites à une seule. En fait je ne sais d'ailleurs pas si cette histoire de photosites verts en double est la seule raison ou s'il y en a d'autres. Dans les faits c'est même plus complexe car la plupart des dématriceurs utilisent plus de 4 photosites pour chaque pixel, ils tiennent également compte des photosites adjacents.

[Zaphod]

Ce qui est sur c'est qu'au départ il faut une photo qui ait des couleurs dans le ProPhoto mais pas dans l'Adobe RVB.
Ce qui n'est pas forcément évident à choisir

[polohc]

Ce qui est sur c'est qu'au départ il faut une photo qui ait des couleurs dans le ProPhoto mais pas dans l'Adobe RVB.
Ce qui n'est pas forcément évident à choisir

... et à trouver pour avoir le choix

[gerarto]

...

Toujours si j'ai bien compris comment ça marche, le problème est qu'au dématriçage, il va déjà commencer à interpréter la photo et si on n'en profile pas pour faire la BDB à ce moment, certaines informations sont définitivement perdues par cette opération. Ne serait-ce que parce qu'on a deux photosites vert pour chaque pixel et on réduit les valeurs de ces deux photosites à une seule. En fait je ne sais d'ailleurs pas si cette histoire de photosites verts en double est la seule raison ou s'il y en a d'autres. Dans les faits c'est même plus complexe car la plupart des dématriceurs utilisent plus de 4 photosites pour chaque pixel, ils tiennent également compte des photosites adjacents.

Dois-je comprendre que tu penses qu'il faut 4 photosites pour faire un pixel ?

Pour schématiser :
Un photosite = un pixel
Un photosite "compte" le nombre de photons que lui laisse passer le filtre coloré qui est au dessus. Il a donc une valeur de luminance et une info sur la couleur du filtre résultant de sa position en lignes/colonnes sur le capteur. Les deux autres valeurs de luminance sont déduites de celles des photosites contigus (matrice). Comme pour chaque photosite une valeur est exacte et deux sont approchées, les valeurs de vert sont privilégiées (donc plus précises) puisque c'est la couleur auquel l'œil humain est le plus sensible (c'était au moins l'idée de départ de Bayer). Au stade du raw, il n'y a pas de couleur, simplement une suite de valeurs de luminance et les infos pour traduire ces valeurs en couleurs selon les indications du fabriquant sur les caractéristiques des filtres colorés (différents pour chaque marque/type/modèle de capteur). Le dématriçage, c'est faire l'opération qui consiste à transformer le photosite en pixel en combinant ces informations.
Aucune information de BdB n'est nécessaire à ce stade : le capteur a mesuré ce qui lui arrivé dessus comme photons. Et le dématriçage ne fait que le retranscrire. Ce n'est qu'une fois dématriçé que l'on peut intervenir sur la BdB. Les valeurs de BdB données dans les exifs ne sont qu'indicatives : la meilleure preuve, c'est que chaque logiciel les interprète à sa façon.
Pour DxO, les corrections de bruit PRIME et maintenant DeepPRIME sont faites au moment du dématriçage en allant étudier les valeurs caractéristiques (le bruit...) des photosites bien au delà des seuls voisins. De mémoire pour PRIME je crois me souvenir que pour un pixel c'est de l'ordre de 1000 autour qui sont pris en compte.   

[gerarto]

Ce n'est as le titre qui fait la qualité. Dans votre prose au moins trois biais concernant l'aspect couleur, objet de ma remarque initiale concernant DXO.

Alors je veux bien savoir quels sont ces biais...

NB : le titre, je m'en fous, je n'en ai plus l'usage depuis quelques années.

[gerarto]

Pour en revenir à la balance des blancs, une preuve évidente qu'elle est bien déconnectée du dématriçage, c'est que l'on peut avoir deux BdB différentes sur une même image.

J'ai repris la photo de ce post : https://www.chassimages.com/forum/index.php/topic,314483.msg7820697.html#msg7820697

que j'avais postée "telle qu'elle", et je l'ai reprise pour corriger la BdB de l'écran. On a donc la balance des blancs générale de la scène : 4146 K, -23 qui correspond à l'éclairement général. Et celle de l'écran que j'ai modifiée en réglages locaux à 6500 K, 0. J'ai également modifié (baissé) la luminosité puisque l'écran était plus lumineux que la moyenne de la scène, mais en aucun cas je n'ai touché aux autres réglages de colorimétrie.

[Verso92]

Les valeurs de BdB données dans les exifs ne sont qu'indicatives : la meilleure preuve, c'est que chaque logiciel les interprète à sa façon.

Pas compris... si tu mesures 3 114K au thermocolorimètre et que tu reportes la valeur dans l'appareil, tu vas la retrouver telle quelle dans C1.


Je m'étais d'ailleurs livré à quelques essais, il y a quelques années :

[Benaparis]

Mais alors comment peut-on séparer le dématriçage du développement ? A moins que je n'ai pas tout compris, la raison pour laquelle il est très fortement recommandé de rester sur un RAW pour la BDB, c'est parce que cette étape fait partie du dématriçage. Si cette étape est faite ultérieurement, alors on pourrait la faire aussi bien sur un tiff 16 bits que sur un RAW, ce qui n'est pas le cas pour autant que je sache (j'avoue que je te fais confiance sur ce point, je n'ai jamais essayé).

Toujours si j'ai bien compris comment ça marche, le problème est qu'au dématriçage, il va déjà commencer à interpréter la photo et si on n'en profile pas pour faire la BDB à ce moment, certaines informations sont définitivement perdues par cette opération. Ne serait-ce que parce qu'on a deux photosites vert pour chaque pixel et on réduit les valeurs de ces deux photosites à une seule. En fait je ne sais d'ailleurs pas si cette histoire de photosites verts en double est la seule raison ou s'il y en a d'autres. Dans les faits c'est même plus complexe car la plupart des dématriceurs utilisent plus de 4 photosites pour chaque pixel, ils tiennent également compte des photosites adjacents.

Parceque vous confondez dematricage qui est la recomposition couleur et l'opération d'ajustement qu'est la balance des blancs...Un fichier raw multishot de dos Hasselblad MS n'est pas matricé (il est en couleur directe comme les fichiers raw Multishot du GFX100 au demeurant), cela n'empêche pas qu'il faille ajuster la balance des blancs qui est une opération de développement. Après je ne suis pas un spécialiste du process de dématricage et ne saurait l'expliquer, j'insiste juste sur le fait que dematricage et développement sont des operations indépendantes parcequ'un fichier en couleur directe (Multishot ou DNG Linéaire DxO) ou monochrome se développe exactement de la même manière.

[Benaparis]

Pas compris... si tu mesures 3 114K au thermocolorimètre et que tu reportes la valeur dans l'appareil, tu vas la retrouver telle quelle dans C1.
Je m'étais d'ailleurs livré à quelques essais, il y a quelques années :

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? 

[tenmangu81]

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.

[Verso92]

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.

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

J'avais lu un article de Fraser* à ce sujet (qui ne m'avait pas plus convaincu que ça), mais je n'arrive pas à remettre la main dessus...


*il avait dû être mis en lien par un intervenant dans une discussion sur un thème voisin.

Es tu sûr que les valeurs de bdb de C1 sont parfaitement étalonnées?

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

[Benaparis]

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.

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).

[Verso92]

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.

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