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

[Verso92]

Oui et c'est compréhensible.
Pour moi le point faible du DNG c'est que même si c'est un format ouvert, ça reste un format dont les specs ne sont décidées que par Adobe.
Et qui bien sur, sont faites selon les besoins des logiciels Adobe.

Ceci dit, dans ce cas là, autant annoncer clairement ne pas supporter le DNG - sauf quand il s'agit de DNG natifs.
Si tu achètes Capture One qui annonce traiter les DNG et que tu as plein de photos d'Oly E-M10 déja converties... il y a de quoi être déçu.

Je ne dis pas le contraire, Zaphod (comme déjà expliqué, je ne participe pas à ce fil pour "défendre" tel ou tel éditeur... en plus, j'utilise les deux, en l'occurrence !).

[Shepherd]

...

Je n'adhère pas complètement à ton analyse... les différences entre les différents formats RAW, comme tu les appelles, c'est juste l'encodage de certaines données et des adresses différentes pour les différents champs. Tous les RAW sont fondés sur l'architecture TIFF, et les données sont codées de façon voisine pour tous les Bayer*...

*pour les Foveon, la donne est différente : d'où les réticences, sans doute, des éditeurs tiers à s'investir dans ce format.

Suis tout à fait d'accord. Comparer la manipulation des valeurs d'une unité de mesure avec la différence des formats RAW, revient - dans un ordre d'esprit proche - à comparer la manipulation du nombre de kilo-octets d'un disque dur (ce que font très bien les constructeurs en ramenant souvent la valeur du ko à 1000) aux différents formats des fichiers qui peuvent s'y trouver. Pour moi, ça n'a rien à voir !

[Zaphod]

Enfin, si les constructeurs automobiles se mettaient à interpréter les valeurs du kilomètre ou du mile, trouverais-tu la chose logique ?

Justement, les compteurs de vitesse des voitures sont des interprétations des vitesses
Ce sont des valeurs parfois totalement bidonnées.

Ça ne l'est pas davantage avec le kelvin (et que l'impact n'ait pas la même importance en pratique ne rend pas la chose plus logique), d'où que vienne la manip, si celle-ci est "volontaire", non une limite de la "technique embarquée".
Merci de relire ce post signé Jean Delmas : http://www.chassimages.com/forum/index.php/topic,232950.msg5341180.html#msg5341180.

Pour ce qui est de l'existence d'une norme, je veux bien céder sur ce point

Mais pour moi ça ne change pas le problème, qui est qu'un 5000 K canon et un 5000 K Sony ça ne représente pas la même chose.

Pour ce qui est des ISO (c'est Verso qui faisait le rapprochement, car là aussi un 200 ISO Canon n'est pas un 200 ISO Sony, ça change même selon chaque boitier), c'est différent car Lightroom ne prend ça que comme donnée "indicative".
Donc il peut afficher la valeur indiquée par le constructeur.
Alors que la balance des blancs fait partie des paramètres qui peuvent être changés par Lightroom, donc là le soft est obligé d'avoir le même système de valeur pour chaque constructeur.

[Verso92]

Justement, les compteurs de vitesse des voitures sont des interprétations des vitesses
Ce sont des valeurs parfois totalement bidonnées.

Heu... non, justement.
(je te prie de croire que le fabricant sait exactement ce qu'il fait, en l'occurrence, et qu'il ne fait que gérer les tolérances et les seuils de détection des cinémomètres...)

Pour ce qui est des ISO (c'est Verso qui faisait le rapprochement, car là aussi un 200 ISO Canon n'est pas un 200 ISO Sony, ça change même selon chaque boitier), c'est différent car Lightroom ne prend ça que comme donnée "indicative".

On peut en effet reconnaitre que LR respecte la sensibilité ISO choisie sur le boitier... c'est déjà un bon point !

[Zaphod]

Suis tout à fait d'accord. Comparer la manipulation des valeurs d'une unité de mesure avec la différence des formats RAW, revient - dans un ordre d'esprit proche - à comparer la manipulation du nombre de kilo-octets d'un disque dur (ce que font très bien les constructeurs en ramenant souvent la valeur du ko à 1000) aux différents formats des fichiers qui peuvent s'y trouver. Pour moi, ça n'a rien à voir !

Je citais l'exemple notamment pour le fait que la colorimétrie est différente pour chaque type de RAW (même au sein d'un même constructeur).
Et c'est justement tout le but d'un logiciel de traitement de RAW, de prendre une valeur mesurée (la valeur sur un pixel de capteur), et de l'interpréter pour donner quelque chose d'utilisable.

Tu ne peux faire un logiciel de traitement de RAW en étudiant juste la structure du fichier, sinon les couleurs sont à la rue.
C'est pareil - pour moi - pour la balance des blancs. Tu ne peux pas te contenter de lire la valeur constructeur et l'appliquer à ton soft. Il faut tester le référenciel pour savoir à quoi correspond chez le constructeur XXX un 2000 K, un 5000 K, et un 8000 K.

Je suppose que chaque constructeur et chaque éditeur de logiciel doit être persuadé que son système de valeur de balance des blancs est le plus juste... le fait est qu'en pratique, ils sont tous différents.

[Zaphod]

Heu... non, justement.
(je te prie de croire que le fabricant sait exactement ce qu'il fait, en l'occurrence, et qu'il ne fait que gérer les tolérances et les seuils de détection des cinémomètres...)

Exactement non, car sur toute mesure il y a une marge d'erreur
Ensuite chaque constructeur sait peut-être ce qu'il fait, mais 80 km/h compteur sur deux voitures ne correspondent pas à la même vitesse.
(évidemment il y a moins d'écart que sur les températures couleurs de balance blancs...)

[Verso92]

Ensuite chaque constructeur sait peut-être ce qu'il fait [...]

Je peux t'assurer que chaque constructeur (équipementier) sait exactement ce qu'il fait...

[belnea]

on ne va pas rentrer dans le degré d'usure des pneus qui, selon la dimension de la roue de la voiture, va influencer sur le compteur, non ? 

[Shepherd]

Justement, les compteurs de vitesse des voitures sont des interprétations des vitesses
Ce sont des valeurs parfois totalement bidonnées.
Pour ce qui est de l'existence d'une norme, je veux bien céder sur ce point

Mais pour moi ça ne change pas le problème, qui est qu'un 5000 K canon et un 5000 K Sony ça ne représente pas la même chose.

Pour ce qui est des ISO (c'est Verso qui faisait le rapprochement, car là aussi un 200 ISO Canon n'est pas un 200 ISO Sony, ça change même selon chaque boitier), c'est différent car Lightroom ne prend ça que comme donnée "indicative".
Donc il peut afficher la valeur indiquée par le constructeur.
Alors que la balance des blancs fait partie des paramètres qui peuvent être changés par Lightroom, donc là le soft est obligé d'avoir le même système de valeur pour chaque constructeur.

Et alors ? Est-ce une raison pour cumuler les marges d'interprétation ou d'erreur ?
Comme dit et redit, si plus simple (ou que sais-je encore) pour l'éditeur de modifier la recette "officielle", soit ! Mais la moindre des choses serait dans ce cas d'afficher la valeur boîtier (on sait qu'elle est inexacte, pas la peine de nous resservir en boucle un argument que nous ne discutons pas, mais qui permet de limiter les "dégâts" à défaut de les régler intégralement).

Et justement, Verso a raison : manquerait plus que les logiciels interprètent aussi les valeurs ISO boîtier (ce qu'ils font peut-être à partir de tests DxO par exemple, sans afficher le résultat de la "conversion", who knows?) sous prétexte qu'elles ne sont en effet pas justes.

[Nikojorj]

(le Kelvin fait partie des unités SI)

Rendons à César ce qui est à César : la norme, ici, c'est le CIE qui définit les illuminants (notamment les D), et aussi la notion de T° de couleur proximale (correlated en angliche). Mais ça n'a à voir que d'assez loin avec le SI.

Là où on sort complètement de la norme, c'est dans l'interprétation d'une scène qui fait deviner l'illuminant d'après ce qu'on voit de la scène, en lumière réfléchie. C'est de la cuisine assez empirique, encore plus casse-gueule que la mesure de l'exposition en lumière réfléchie, avec des trucs par-ci par-là pour éviter de se faire avoir par des feuillages verts ou autre fond coloré.
Et c'est bien là qu'est le (somme toute assez vague ) problème : le boîtier est là pour capturer les information de la scène, mais une fois ça de fait, il n'est pas forcément le mieux placé pour décider de cette interprétation subjective.

les différences entre les différents formats RAW, comme tu les appelles, c'est juste l'encodage de certaines données et des adresses différentes pour les différents champs.

Tu omets de citer les différents spectres de filtration R, G, B du filtre de Bayer, quand même... qui sont aussi là pour mettre encore un peu plus de flou, ou pour le dire de façon positive de liberté d'interprétation, dans le rendu des couleurs.
Ah ben zut Zaphod l'a déjà dit. Bon, bis repetita placent comme disait l'autre.
Et c'est surtout l'absence d'informations sur ce point qui oblige les éditeurs de logiciels à attendre la sortie d'un boîtier pour pouvoir le supporter : la structure du raw est connue, d'ailleurs souvent il suffit de changer le nom de l'appareil dans le fichier pour pouvoir l'ouvrir, mais on peut obtenir des couleurs un peu à la rue avec cette méthode...

Enfin, si les constructeurs automobiles se mettaient à interpréter les valeurs du kilomètre ou du mile, trouverais-tu la chose logique ?

Et ils ne s'en privent pas! Les compteurs sont étalonnés pour n'avoir de marge d'incertitude que dans un sens (compte tenu de l'usure des pneus, de leur pression, de la géométrie des trains roulants, etc), et du coup ils sont plus ou moins optimistes sur la vitesse annoncée et donc la distance parcourue.
Le fait est que les kilomètres de ma Ford sont un peu plus courts que ceux de la Renault de ma femme, et au boulot différentes Renault utilisent différentes versions du mètre de Breteuil.

Revenons au débat :

Merci de relire ce post signé Jean Delmas : http://www.chassimages.com/forum/index.php/topic,232950.msg5341180.html#msg5341180.

Comme dit en premier par Jean Delmas et redit après, la donnée de T°Couleur produite par les appareils serait juste si et seulement si on ne photographiait que des mires spectralement neutres. En pratique, c'est assez loin d'être le cas, et c'est bien ce qui fait que la valeur en question n'est qu'une interprétation subjective. Allez, je graisse.

Pour reprendre un exemple précédent, la sensibilité ISO est quelque chose de normalisée.

Excellent exemple! En effet, la norme ISO12232 précise (parmi d'autres) la méthode dite Recommended Exposure Index, qui précise tout simplement que le fabricant juge de la meilleure valeur susceptible de produire des images correctement exposées. Épicétou. Et c'est la seule méthode utilisable selon la norme avec la mesure matricielle, ou avec une sortie qui n'est pas en sRGB (source WP, il est malheureusement difficile de citer une norme ISO en ligne).
DxOMark a d'ailleurs dû s'écarter (un peu) de cette norme pour pouvoir mesurer une sensibilité ISO objective (méthode basée sur la saturation, mais en raw, la norme ne la prévoyant qu'en jpeg sRGB).
Bon, ne nous écartons pas trop du débat originel même si on en est déjà loin, mais en l'occurrence une norme peut être un concept à double tranchant. Dans le cas en question, la norme se contente de dire "si vous voulez faire ce que vous voulez, je vois rien j'entends rien et je dis rien".
Edit :

On peut en effet reconnaitre que LR respecte la sensibilité ISO choisie sur le boitier... c'est déjà un bon point !

Même pas (et heureusement vu le bordel que c'est)... y'a en plus une correction d'exposition propre à chaque appareil, chercher le paramètre baseline exposure dans les XMP.

[Zaphod]

Et alors ? Est-ce une raison pour cumuler les marges d'interprétation ou d'erreur ?
Comme dit et redit, si plus simple (ou que sais-je encore) pour l'éditeur de modifier la recette "officielle", soit ! Mais la moindre des choses serait dans ce cas d'afficher la valeur boîtier (on sait qu'elle est inexacte, pas la peine de nous resservir en boucle un argument que nous ne discutons pas, mais qui permet de limiter les "dégâts" à défaut de les régler intégralement).

Et justement, Verso a raison : manquerait plus que les logiciels interprètent aussi les valeurs ISO boîtier (ce qu'ils font peut-être à partir de tests DxO par exemple, sans afficher le résultat de la "conversion", who knows?) sous prétexte qu'elles ne sont en effet pas justes.

J'en parlais plus haut. C'est très différent car cette donnée n'est qu'indicative. Ca n'est pas un paramètre de post-traitement.

Lightroom pourrait te dire "balance des blancs constructeur initiale : 5600 K / -3 / +6".
Mais une fois que tu as changé la balance des blancs dans le logiciel... ça n'a plus aucun sens.

[Verso92]

on ne va pas rentrer dans le degré d'usure des pneus qui, selon la dimension de la roue de la voiture, va influencer sur le compteur, non ?  

Pfff... si ça continue, je vais être en retard !

;-)

Edit :Même pas (et heureusement vu le bordel que c'est)... y'a en plus une correction d'exposition propre à chaque appareil, chercher le paramètre baseline exposure dans les XMP.

Oui : j'ai constaté que LR posait quelquefois un peu plus clair que mon Nikon...

[Shepherd]

...

....

Enfin, si les constructeurs automobiles se mettaient à interpréter les valeurs du kilomètre ou du mile, trouverais-tu la chose logique ?
Ça ne l'est pas davantage avec le kelvin (et que l'impact n'ait pas la même importance en pratique ne rend pas la chose plus logique), d'où que vienne la manip, si celle-ci est "volontaire", non une limite de la "technique embarquée".
...

Et ils ne s'en privent pas! Les compteurs sont étalonnés pour n'avoir de marge d'incertitude que dans un sens (compte tenu de l'usure des pneus, de leur pression, de la géométrie des trains roulants, etc), et du coup ils sont plus ou moins optimistes sur la vitesse annoncée et donc la distance parcourue.
Le fait est que les kilomètres de ma Ford sont un peu plus courts que ceux de la Renault de ma femme.

D'un, je remets la seconde phrase que tu avais tronquée dans ma citation et qui en nuançait pourtant le sens.

De deux, en admettant que l'exemple soit mal choisi, ça ne le rend pas logique dans l'absolu, seulement dans un contexte dicté par des impératifs ou des limites techniques.
Mais je n'ai jamais vu les différents logiciels internes aux instruments des concessionnaires/garagistes/des centres de contrôle technique venir modifier le kilométrage affiché (qu'il soit juste ou non) en fonction d'une salade interne quelconque .

[Zaphod]

Dans ce cas, tu peux aussi trouver anormal que Ligthroom vienne modifier la colorimétrie constructeur.

Un RAW ce sont des données brutes qui sont traitées et interprétées diffémment dans chaque soft.  Et notamment... tout ce qui touche à la colorimétrie.

Deux softs de RAW ont une manière parfois radicalement différente de gérer la colorimétrie, et donc la balance des blancs (dans mes exemples plus haut, on voit bien que même le nombre de variables utilisées pour gérer la balance des blancs est différente - la température en Kelvin n'étant jamais le seul paramètre)
Bouger le slider de teinte de balance des blancs n'aura pas le même effet dans deux softs, tout comme bouger le slider saturation.

[Zaphod]

Il faut quand même bien différencier tout ce qui est paramètre de prise de vue : ouverture, temps de pose, ISO etc... ces valeurs peuvent être approchées/fausses etc... mais elles ne bougeront pas.
Donc le soft les affiche pour information.

Et tout ce qui est paramètre de post-traitement comme la balance des blancs, la saturation, etc... etc... qui est amené à être modifié quand on traite un RAW, et qui est forcément lié aux alogrithmes de traitement de l'image et des couleurs du soft.

[Shepherd]

Il faut quand même bien différencier tout ce qui est paramètre de prise de vue : ouverture, temps de pose, ISO etc... ces valeurs peuvent être approchées/fausses etc... mais elles ne bougeront pas.
Donc le soft les affiche pour information.

Et tout ce qui est paramètre de post-traitement comme la balance des blancs, la saturation, etc... etc... qui est amené à être modifié quand on traite un RAW, et qui est forcément lié aux alogrithmes de traitement de l'image et des couleurs du soft.

Certes .
Cela dit, dans DxO par ex, la sensibilité semble aussi intégrée pour le calcul auto de la réduction du bruit (les valeurs de cette dernière restant manuellement modifiables bien sûr).

[Nikojorj]

Cela dit, dans DxO par ex, la sensibilité semble aussi intégrée pour le calcul auto de la réduction du bruit (les valeurs de cette dernière restant manuellement modifiables bien sûr).

C'est le cas dans LR/ACR aussi, je crois.

[Shepherd]

Je peux t'assurer que chaque constructeur (équipementier) sait exactement ce qu'il fait...

Sur mon A1, le compteur kilométrique semble juste. Les données que me communique mon GPS autonome tendent à confirmer ce point.

[fred134]

En tant qu'ancienne analyste-programmeur et en admettant que la solution facilite la gestion d'un vaste ensemble d'appareils, je choisirais ce que j'ai déjà mentionné. A savoir, d'afficher la TC boîtier et celle qui relève de ma sauce interne.

En ce qui concerne le double affichage :
- les BdB "manuelles" saisies en Kelvin dans le boitier sont dans les EXIF (mais je comprends que ça ne réponde pas au besoin).
- pas les autres types de BdB (où le boitier n'affiche pas les K non plus).
- Pourquoi pas en effet un vrai double affichage en option. Il y a juste amha une question de balance demande/risque dans un logiciel "tous publics". Le nombres de personnes satisfaites risquerait d'être nettement inférieur à ceux que cela trouble... mais ton choix se défend bien sûr.

Dans le même genre (en plus gênant selon moi), certaines corrections optiques sont embarquées dans le raw. Je ne suis pas sûr que l'on puisse accéder à l'image vraiment brute (ex avant correction de la distorsion) dans LR. Je me trompe peut-être, mais je crois que c'était le cas avec mon Panasonic LX3.

Ce serait attentionné de ta part de ne pas vouloir "être à la merci d'un changement d'échelle d'un constructeur, qui pourrait troubler tes utilisateurs", mais c'est oublier (entre autres) :
- que le niveau de référence des utilisateurs reste celui dont leur boîtier fonctionne, que ces valeurs soient plus ou moins justes ;
- que des utilisateurs peuvent avoir besoin de sortir des séries avec telle ou telle TC (là encore, elles seront réalisées selon les valeurs et le "comportement" du boîtier), voire de les classer selon telle ou telle TC, et que ce n'est pas à toi, développeur, de juger les critères de tes utilisateurs ;
- enfin, que si tes utilisateurs ont besoin de recourir à d'autres logiciels, peu en importe la raison, ça devient franchement le bordel si la donnée TC est un critère important pour eux.

- D'accord avec ton 3ème point. (Il est amusant que le choix des éditeurs défavorise l'usage de plusieurs logiciels, tout comme celui des constructeurs défavorise l'usage de plusieurs marques - la situation est assez symétrique :-)

- tes points 1 et 2 me semblent vrais pour quelqu'un qui règle sa BdB en manuel sur le boitier. Vois-tu d'autres cas ?
Pour quelqu'un qui utilise son boitier en Raw et règle la BdB sur le logiciel (mon cas, mais je ne suis sans doute pas le seul), la situation est inversée. La TC logiciel est alors plus importante que la TC boitier. Je préfère avoir une idée de ce que donne 5200K dans mon logiciel, que devoir me souvenir du décalage de TC entre mon Sony et mon Canon.

Bon, enfin, je crois que maintenant la situation est claire.
J'insiste juste sur un point : la racine du problème est chez les constructeurs, c'est à la source qu'il faut le régler. Les éditeurs sont dépendants de la qualité des données qu'ils reçoivent et doivent faire un compromis.
Libre à chacun bien sûr d'avoir des priorités différentes ;-)

[Zaphod]

Certes .
Cela dit, dans DxO par ex, la sensibilité semble aussi intégrée pour le calcul auto de la réduction du bruit (les valeurs de cette dernière restant manuellement modifiables bien sûr).

Yep, mais c'est lié à la batterie de tests que fait DxO justement pour mesurer le bruit généré pour chaque valeur de sensibilité.
Un 200 ISO d'un boitier X ne sera pas corrigé pareil qu'un 200 ISO d'un boitier Y.

[belnea]

 [at] paul_steunebrink
Part of the DNG standard is open standard, part is not. That is the confusion, and base of the frustration users have when they try to get out of the DNG trap.

Regarding DNG conversion: the only way out is when you have included (embedded) the original raw file into the DNG file during conversion.

This feature was designed as the emergency exit for those who have second thoughts after some time. A feature for a reason, but virtually nobody uses it because you do not see the need until you need it but then it is to late.

DNG (conversion and storing adjustments in it) is a proprietary standard sold as open. Once you're in, you're stuck

on peut même trouver des discussions sur le sujet en cherchant "dng trap"

ps : je viens de convertir un cr2 en dng.
j'ouvre les deux dans camera raw, je retrouve 5600 K° et ils sont pareil.
j'ouvre les deux dans C1, le dng se retrouve à 4840 K° le profil camera n'est plus sur canon 7d mais sur dng neutral. les saturations ont changé.
si je change la temp ou reviens sur le profil du 7D, le dng ne ressemble plus à rien.

[Shepherd]

Yep, mais c'est lié à la batterie de tests que fait DxO justement pour mesurer le bruit généré pour chaque valeur de sensibilité.
Un 200 ISO d'un boitier X ne sera pas corrigé pareil qu'un 200 ISO d'un boitier Y.

Si tu le dis (moi, je n'ai pas fait suffisamment de recherches dans les articles pour savoir si l'info y est divulguée et je ne suis pas non plus assez intime avec DxO pour l'affirmer).

Mais faut-il que je te traduise au passage dans une autre langue ce que j'avais déjà écrit dans un post précédent ?

Et alors ? Est-ce une raison pour cumuler les marges d'interprétation ou d'erreur ?
Comme dit et redit, si plus simple (ou que sais-je encore) pour l'éditeur de modifier la recette "officielle", soit ! Mais la moindre des choses serait dans ce cas d'afficher la valeur boîtier (on sait qu'elle est inexacte, pas la peine de nous resservir en boucle un argument que nous ne discutons pas, mais qui permet de limiter les "dégâts" à défaut de les régler intégralement).

Et justement, Verso a raison : manquerait plus que les logiciels interprètent aussi les valeurs ISO boîtier (ce qu'ils font peut-être à partir de tests DxO par exemple, sans afficher le résultat de la "conversion", who knows?) sous prétexte qu'elles ne sont en effet pas justes.

Merci de bien noter la présence de guillemets autour du mot "conversion".

[THG]

"Basta !" ? En voilà une affirmation autocrate pour l'importance du sujet .

Dans la vie, il y a des normes, des conventions, des unités de mesure... et elles ne sont pas faites pour les chiens !
Reste à espérer que les fabricants ne manipulent pas les valeurs des volts et ampères comme les éditeurs de logiciels les kelvins .

Que le résultat final soit quasi identique est - en pratique - le plus important en effet, mais dans le fond, modifier les valeurs d'une unité de mesure paramétrée par/pour le boîtier (puisse-t-elle être relative) est une hérésie.
Dans ce cas, le logiciel devrait au moins afficher la TC paramétrée sur le boîtier (pour info) et celle calculée via sa salade interne. Le sujet devrait être un minimum documenté, ce qui est certainement possible sans dévoiler de "secrets industriels", hein !

Le problème n'est ici pas les rares qu'une telle approche interpelle, mais les trop nombreux qu'elle n'effleure même pas ou qui, pire, la soutiennent.

Merci à Verso92 et Jean Delmas pour leurs interventions .

Sauf que l'interprétation des valeurs - qui à la base ne sont pas des K - doit se faire au travers du profil de rendu du logiciel, et donc passer par une table de conversion, et qu'il n'y a pas de normes dans le domaine, chacun faisant sa petite soupe.

Et le basta, c'était simplement pour dire qu'à la fin, concrètement, lorsqu'on se retrouve avec la pipette à la main - ou au bout de la souris - on s'en tape quand même un petit peu de savoir ce qu'il y a sous le capot, et c'est bien l'aspect de l'image qui m'intéresse, et non pas les variations de valeurs de température d'un logiciel à l'autre, alors que l'aspect est le même.

[Shepherd]

En ce qui concerne le double affichage :
- les BdB "manuelles" saisies en Kelvin dans le boitier sont dans les EXIF (mais je comprends que ça ne réponde pas au besoin).
- pas les autres types de BdB (où le boitier n'affiche pas les K non plus).
- Pourquoi pas en effet un vrai double affichage en option. Il y a juste amha une question de balance demande/risque dans un logiciel "tous publics". Le nombres de personnes satisfaites risquerait d'être nettement inférieur à ceux que cela trouble... mais ton choix se défend bien sûr.

Rapidement, je dois filer...

L'affichage de la valeur boîtier pourrait parfaitement être commandée par une option à cocher dans les préférences/propriétés, qui ne le serait pas par défaut. Mais c'est fou, tout le monde y trouverait son compte .

Dans le même genre (en plus gênant selon moi), certaines corrections optiques sont embarquées dans le raw. Je ne suis pas sûr que l'on puisse accéder à l'image vraiment brute (ex avant correction de la distorsion) dans LR. Je me trompe peut-être, mais je crois que c'était le cas avec mon Panasonic LX3.
- D'accord avec ton 3ème point. (Il est amusant que le choix des éditeurs défavorise l'usage de plusieurs logiciels, tout comme celui des constructeurs défavorise l'usage de plusieurs marques - la situation est assez symétrique :-)

Chacun défend son territoire, surtout quand il n'offre pas ce dont les "clients" peuvent avoir besoin et qui est dispo ailleurs.

- tes points 1 et 2 me semblent vrais pour quelqu'un qui règle sa BdB en manuel sur le boitier. Vois-tu d'autres cas ?
Pour quelqu'un qui utilise son boitier en Raw et règle la BdB sur le logiciel (mon cas, mais je ne suis sans doute pas le seul), la situation est inversée. La TC logiciel est alors plus importante que la TC boitier. Je préfère avoir une idée de ce que donne 5200K dans mon logiciel, que devoir me souvenir du décalage de TC entre mon Sony et mon Canon.

Je n'ai même pas à y réfléchir, ce cas étant à lui seul défendable.
Tu omets également le cas de ceux qui font du RAW+JPG. Et encore une fois, certains utilisateurs peuvent avoir besoin de la valeur de la TC qu'ils avaient sélectionnée.

Bon, enfin, je crois que maintenant la situation est claire.
J'insiste juste sur un point : la racine du problème est chez les constructeurs, c'est à la source qu'il faut le régler. Les éditeurs sont dépendants de la qualité des données qu'ils reçoivent et doivent faire un compromis.
Libre à chacun bien sûr d'avoir des priorités différentes ;-)

Nous sommes d'accord sur ce point, moins visiblement sur le fait que rien ne sert de rajouter une couche .

Pardon si pas claire, je dois vraiment y aller .

[fred134]

Nous sommes d'accord sur ce point, moins visiblement sur le fait que rien ne sert de rajouter une couche .

Non non, ton choix se défend à mes yeux, comme je te disais.

Mais imagine le foin que ferait ce double affichage, il y aurait 40x plus de gens qu'aujourd'hui pour hurler au scandale et dire que l'éditeur en question gère les couleurs comme un sagouin, incapable de respecter la BdB réglée dans l'appareil :-)