DxO est-il si mauvais que çà ?

[Benaparis]

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

Je m'en doutais, mais à un moment donné il ne faut pas s'arc-bouter sur une définition stricte même si on pourrait évidemment en discuter, il faut juste que tout le monde comprenne en faisant la distinction entre les deux nature de fichier.

[Verso92]

Je m'en doutais, mais à un moment donné il ne faut pas s'arc-bouter sur une définition stricte même si on pourrait évidemment en discuter, il faut juste que tout le monde comprenne en faisant la distinction entre les deux nature de fichier.

C'est pour ça que j'essaie d'être le plus précis possible, en donnant d'une part la définition d'origine mais aussi celle communément "admise" aujourd'hui...  ;-)

[Benaparis]

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

Oui merci on fait de la photo pas de l'image de synthèse issu de notre propre imagination. Je ne vois pas en quoi cela contredit mon propos in fine ton capteur a enregistré des données que tu as maitrisé en tant que bon photographe comme un bon cuisinier tu sais où et comment faire tes courses pour préparer et cuisiner toi même ton plat avec ton propre talent, il n'en demeure pas moins qu'il existe une différence entre un plat précuisiné et précuit en terme de possibilité et donc de résultat final

[ricoco]

Quel est le but de ton intervention

gerarto n'a rien inventé : https://www.chassimages.com/forum/index.php/topic,314074.msg7810018.html#msg7810018

Tu verra donc le contexte et quand on veut faire des leçons de moral, il vaut mieux vérifier ses dires

Et ne viens pas importer sur le forum DxO, le mauvais esprit qui règne sur celui de C1

Hello,

L'intérêt d'une discussion n'est pas de donner du grain à moudre, en balançant un truc sans donner d'info c'est de la désinformation

et quand on cite quelque chose / un article, on poste le lien, ça ne t'intéresse peut être pas mais moi oui
je ne me base pas sur c'est "super" ou c'est "nul"

même si les gens ont un avis ici, j'aurais repris depuis la source si elle y était

[ricoco]

Dis donc, tu es qui pour balancer un tel ramassis d'injures ?
Où est l'impolitesse dans mon post initial ?
C'est qui le troll ?
Que viens faire la politique là dedans ?

J'ai bien pris la précaution préalable de lire les contributions de justvr (que je ne connaissais pas plus que ça) pour écrire que je ne le classais pas dans les trolls, et que par conséquent son avis m'interpelait.
Après, je ne crois pas non plus avoir dénigré C1 pour la bonne raison que je ne le pratique pas et que je n'ai pas l'habitude de parler de ce que je ne connais pas.
Quant à DxO, là, je pense avoir une certaine légitimité pour en parler sur ce coin du forum...

Hello,

Troll, n'est pas une injure d'ailleurs, tu l'as mis dans ton premier post ici ...

[tenmangu81]

Ps : quand je parlais d'informations je parlais de matière première disponible pour aboutir à un résultat final.

S'il s'agit d'information latente, disponible nous sommes complètement d'accord !

[tenmangu81]

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.

Pour moi, les fichiers RAW non dématricés ne sont pas des bitmaps. Les dématricés le sont. Les DNG linéaires issus de DPL4 aussi, selon ma définition. On peut associer à chaque point x/y une valeur de la triplette RGB, ce qui n'est pas le cas d'un RAW.
Et d'ailleurs, les images dites "RAW" issues d'un scan Silverfast ou Vuescan, que sont-elles  ?

[frmfrm]

Pour moi, les fichiers RAW non dématricés ne sont pas des bitmaps. Les dématricés le sont. Les DNG linéaires issus de DPL4 aussi, selon ma définition. On peut associer à chaque point x/y une valeur de la triplette RGB, ce qui n'est pas le cas d'un RAW.
Et d'ailleurs, les images dites "RAW" issues d'un scan Silverfast ou Vuescan, que sont-elles  ?

Juste pour chipoter Robert, c'est quoi un jpg avec un sous-échantillonage de chrominance ( ou plus généralement  une image bitmap ;-) 4:2:2 ou 4:2:0 ;-) ) . Bitmap ou pas  :-)

Pour voir les effets du sous-échantillonage, on peut enregistrer en jpg, un image constituée d'un alternance de lignes colorées d'1 px de large. Sous photoshop  on voit une différence avec un facteur de qualité inférieur ou supérieur à 50.

[gerarto]

Hello,

Troll, n'est pas une injure d'ailleurs, tu l'as mis dans ton premier post ici ...

On ne va pas faire le réveillon là dessus, mais puisque tu en remets une couche après mon explication que je pensais claire, je répète :

Un tour rapide dans l'historique des contributions de l'auteur semble montrer qu'il ne fait pas partie de la race des trolls, d'où mon étonnement.
...

C'est assez clair comme ça ?
Maintenant si tu as des interventions pertinentes à ajouter aux discussions actuelles sur ce fil, tu y es le bienvenu ! 

[Verso92]

Pour moi, les fichiers RAW non dématricés ne sont pas des bitmaps.

Pourtant, ils le sont...


(clin d'œil supplémentaire : au format "bmp"...  ;-)

[Benaparis]

Pour moi, les fichiers RAW non dématricés ne sont pas des bitmaps. Les dématricés le sont. Les DNG linéaires issus de DPL4 aussi, selon ma définition. On peut associer à chaque point x/y une valeur de la triplette RGB, ce qui n'est pas le cas d'un RAW.
Et d'ailleurs, les images dites "RAW" issues d'un scan Silverfast ou Vuescan, que sont-elles  ?

Donc si je suis ton raisonnement un raw de Leica monochrome ou PhaseOne achromatique qui n'est pas matricé par nature n'est pas un raw mais un bitmap tout comme les raw de dos Hasselblad MS quand shooté en mode Multishot ou les raws Multishot du Fuji GFX 100 qui sont générés hors caméra? Pourtant ils ont un comportement au développement parfaitement équivalent voire identique aux fichiers matricés. Mais peut être as tu une 3ème définition qui est personnelle du fichier bitmap? Je parle en langage courant photo (pas illustration) c'est à dire d'un ficher qui ne peut plus être développé ce qui ne veut pas dire qu'il ne puisse être modifié.
Quand aux raws de scanners notamment de Silverfast (j'ai oublié depuis longtemps VueScan) tout ce que je peux dire c'est leur capacité de développement est incomparable à celle des raw(.nef) de Nikon Scan qui ne valaient pas mieux que des Tiffs 16bits, mais je n'ai d'ailleurs pas poussé l'analyse de ces fameux raws vu que le résultat et cette méthode d'acquisition demeure pour moi et d'expérience la plus puissante et la plus souple pour numériser les films avec un scanner, en résumé équivalente à un raw d'APN.

[tenmangu81]

Donc si je suis ton raisonnement un raw de Leica monochrome ou PhaseOne achromatique qui n'est pas matricé par nature n'est pas un raw mais un bitmap tout comme les raw de dos Hasselblad MS quand shooté en mode Multishot ou les raws Multishot du Fuji GFX 100 qui sont générés hors caméra?

Bonne remarque ! C'est là qu'on voit que la limite entre RAW et bitmap est floue. Et d'ailleurs, Fabrice n'a pas manqué de me faire remarquer qu'un RAW est aussi un bitmap. Les fichiers RAW couleur bayerisés ont ceci de caractéristique que, comme tu le sais, il y a 2V pour un R et un B, et qu'en outre les pixels adjacents sont aussi pris en compte. C'est donc beaucoup plus complexe qu'un RAW monochrome ou qu'un DNG linéaire. C'est d'ailleurs ce mélange subtil qui fait que chaque constructeur a son propre format RAW, sinon ce serait trop simple !

[frmfrm]

Pourtant, ils le sont...

Ben des filtres colorés devant un capteur monochrome, ça me fait penser à la techno des autochromes, donc j'aurai tendance à penser aussi que ce sont des images, mais la fécule de pommes de terre utilisés dans ces derniers peut effectivement amener à faire des analogies avec les plats cuisinés ;-)

Je parle en langage courant photo (pas illustration) c'est à dire d'un ficher qui ne peut plus être développé ce qui ne veut pas dire qu'il ne puisse être modifié.

C'est quoi développer un fichier ? Dans le cas le plus simple c'est un dématricage, une balance des blancs,  passage dans un espace connu et éventuellement l'application d'une trc.

Le seul point sur lequel tu as peux jouer facilement avec ton logiciel de dév, c'est la balance des blancs.

Si ton logiciel travaille en 16 bits, ta ne perdras pas grand chose à générer un tif à cette étape puis travailler sur celui ci.

Une image peut avoir plusieurs états. Une image tif 'scene refered' obtenue avec le process simplifié décrit ci-dessus nécessitera un traitement poussé pour avoir une photo présentable.

Si tu sous-traites l'étalonnage et que tu ne veux pas donner ton raw, c'est je crois la meilleur chose à transmettre/fournir.

Quand aux raws de scanners notamment de Silverfast (j'ai oublié depuis longtemps VueScan) tout ce que je peux dire c'est leur capacité de développement est incomparable à celle des raw(.nef) de Nikon Scan qui ne valaient pas mieux que des Tiffs 16bits, mais je n'ai d'ailleurs pas poussé l'analyse de ces fameux raws vu que le résultat et cette méthode d'acquisition demeure pour moi et d'expérience la plus puissante et la plus souple pour numériser les films avec un scanner, en résumé équivalente à un raw d'APN.

Silverfast nécessite t-il l'installation du driver fourni par le fabricant du scanner ?

[egtegt²]

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.   

Non, j'ai bien compris qu'un capteur avec 24 millions de photosites produisait bien une image de 24 millions de pixels.

Par contre la couleur d'un pixel est exacte pour une des trois composantes (celle qui correspond à la couleur de la cellule de la matrice de Bayer du photosite correspondante) et interpolée pour les autres à partir des couleurs des photosites proches. (j'ai lu il y a longtemps un article sur le sujet, je pensais auparavant que c'était juste une moyenne sur les photosites directement adjacents, mais en fait ça fait en général intervenir plus de photosites que ça).

Ca a permis à certains de prétendre qu'un capteur de 24 millions de pixels n'avait en fait que 8 ou même 6 millions de pixels. Ce qui strictement parlant est défendable mais ne serait dans les faits vrai que si on photographiait un "bruit" lumineux avec chaque pixel ayant une luminosité et une couleur totalement indépendante des pixels adjacents, ce qui n'est évidemment jamais le cas.

Ce qui me fait parler des photosites verts, c'est que quand on détermine la composante vertes d'un photosite, on a deux fois plus d'information que pour le bleu et le rouge. Donc je me demande si ça ne serait pas ce surcroît d'information qui permettrait des traitements plus précis sur Prime ou DeepPrime ou justement sur la BdB. Car strictement parlant, rien n'empêche de modifier la BdB sur un JPEG ou un TIFF. Et pourtant si DXO par exemple n'offre pas la possibilité de régler la BdB ni d'utiliser Prime ou DeepPrime sur un JPEG, il doit bien y avoir une raison. Mais quelle est-elle ?

[Benaparis]

C'est quoi développer un fichier ? Dans le cas le plus simple c'est un dématricage, une balance des blancs,  passage dans un espace connu et éventuellement l'application d'une trc.

Le seul point sur lequel tu as peux jouer facilement avec ton logiciel de dév, c'est la balance des blancs.

Si ton logiciel travaille en 16 bits, ta ne perdras pas grand chose à générer un tif à cette étape puis travailler sur celui ci.

Une image peut avoir plusieurs états. Une image tif 'scene refered' obtenue avec le process simplifié décrit ci-dessus nécessitera un traitement poussé pour avoir une photo présentable.

Si tu sous-traites l'étalonnage et que tu ne veux pas donner ton raw, c'est je crois la meilleur chose à transmettre/fournir.

On ne va pas remettre un vieux sujet sur la table. La malléabilité d'un fichier raw est sans commune mesure avec celle d'un Tiff fut-il 16bits qui est un fichier "fini" alors qu'un raw est un fichier en devenir c'est bien pour cela que l'on parle de développement. D'ailleurs quand on parle d'un raw on parle aussi de négatif numérique c'est d'ailleurs la signification de l'acronyme .dng. Mais si tu veux je peux te mettre au défi avec l'exemple du chien que j'ai posté plus haut.

Alors oui bien sûr depuis que l'on numérise du film des labos et des retoucheurs ont travaillé et travaillent sur des Tiff 16bits avec excellence néanmoins cela ne va pas sans une numérisation ou des fichiers d'APN à la base impeccable ou en tout cas les plus propres possible. Quand je scannais en Tiff 16bits je veillais toujours à faire le scan le plus doux possible récupérer le maximum d'information sur le film pour pouvoir ajuster correctement derrière, pour la chromie avec NikonScan pour mon 9000ED je jouais sur l'intensité de chaque lampe R,V et B pour être au plus près du résultat final et ainsi dégrader au minimum le fichier avec des corrections chromatique. A ce titre un raw d'APN est tellement moins contraignant, idem avec Silverfast, j'ai simplement à me mettre en mode HDR48bits ou HDRi64bits si je rajoute une couche infrarouge pour corriger les poussières, l'image, la résolution finale, éventuellement une multi-exposition si l'image est particulièrement contrastée, la mise au point précise (dispo pour le Nikon 9000 mais pas pour l'Epson V750) et basta je lance la numérisation toute les corrections se font a posteriori avec une souplesse comparable à un raw d'APN et au final le gain en temps et en qualité est très appréciable.

Silverfast nécessite t-il l'installation du driver fourni par le fabricant du scanner ?

Non ce n'est pas nécessaire. En revanche pour bénéficier de toute la "puissance" de numérisation de SilverFast il faut passer par la version Archive Suite (même si la version Studio permet de générer de "raws" je mets de guillemets car je veux rester prudent sur le terme dans ce cas précis)

[Benaparis]

Et histoire d'arrêter de tourner en rond (mais ce n'est pas faute que le lien ait été publié 2 fois par Pieloe et une 3eme fois ici) voici ce que dit le staff DxO a propos des DNG linéaire correction optique+bruit  :

You might say this is the same as exporting a 16 bits TIFF image then working on it, but it's not the case: TIFF export handles color and dynamic range from the picture in a destructive way, like JPEG.

C'est plus clair maintenant? 

https://feedback.dxo.com/t/partial-solution-to-work-with-deepprime-in-photolabs-main-viewer/15509

[frmfrm]

On ne va pas remettre un vieux sujet sur la table. La malléabilité d'un fichier raw est sans commune mesure avec celle d'un Tiff fut-il 16bits qui est un fichier "fini" alors qu'un raw est un fichier en devenir c'est bien pour cela que l'on parle de développement. ......

Je ne parle pas de malléabilité d"un raw. Je dis juste que l'on peut adapter sons workflow en analysant le pipeline du moteur ( 16 bits ) de son logiciel de développement.  Mais si ça ne t'interresse pas c'est po grave....

De la même façon, si depuis la dernière fois  où je suis intervenu ici, tu n'as pas compris l'avantage de scanner à la résolution donné du scanner, ça n'est pas grave non plus ;-) .

Enfin, lorsque tu parles de RAW issu d'un scanner, il ne contient pas plus d'information et n'est pas pls neutre que ce qu'est capable de fournir le driver. Et on a pas besoin d'avoir Silverfast pour avoir ce RAW. Epson Scan le fait très bien ;-)

[frmfrm]

... Donc je me demande si ça ne serait pas ce surcroît d'information qui permettrait des traitements plus précis sur Prime ou DeepPrime ou justement sur la BdB. Car strictement parlant, rien n'empêche de modifier la BdB sur un JPEG ou un TIFF. Et pourtant si DXO par exemple n'offre pas la possibilité de régler la BdB ni d'utiliser Prime ou DeepPrime sur un JPEG, il doit bien y avoir une raison. Mais quelle est-elle ?

Ben pour la balance des blancs, il faut partir de préférence sur une base linéaire . Ca n'est généralement pas le cas pour un jpg qui est souvent dans un état 'display rendering' et où une courbe de contraste en S a été appliquée. Enfin, si le JPG de dispose plus des donénes EXIF, il me semble difficile de calculer une matrice d'adaptation chromatique Bradford ou Von Kries.

Pour le débruitage, je pense qu'il est préférable de le faire au début du process de développement. L'algorithmne de compression jpg , l'accentuation etc.. appliqués sur le jpg va grandement le dénaturer. Enfin, le jpg ne contient plus les informations des zones non exposées du capteur. ( elles sont présentes dans le raw ).

[Benaparis]

Je ne parle pas de malléabilité d"un raw. Je dis juste que l'on peut adapter sons workflow en analysant le pipeline du moteur ( 16 bits ) de son logiciel de développement.  Mais si ça ne t'interresse pas c'est po grave....

Mais bien sûr que ça m'intéresse, mais je t'en prie sois plus clair parcequ'en l'état je ne vois absolument pas où tu veux en venir, parceque si j'insiste sur la différence entre un raw et un tiff 16bits c'est justement parce que la malléabilité n'est pas la même, et que concernant les DNG linéaire délivrés par DxO c'était le plus important à comprendre. Je connais ton talent pour simuler des rendus de films donc je ne mets pas en cause ta parole juste que pour moi elle est sur le sujet obscure.

De la même façon, si depuis la dernière fois  où je suis intervenu ici, tu n'as pas compris l'avantage de scanner à la résolution donné du scanner, ça n'est pas grave non plus ;-)

Ah bon, c'est nouveau ça? Je connais parfaitement bien mes scanners et leur limite de résolution optique et j'ai toujours numérisé à leur limite optique https://www.chassimages.com/forum/index.php/topic,286080.0.html

Enfin, lorsque tu parles de RAW issu d'un scanner, il ne contient pas plus d'information et n'est pas pls neutre que ce qu'est capable de fournir le driver. Et on a pas besoin d'avoir Silverfast pour avoir ce RAW. Epson Scan le fait très bien ;-)

Je veux bien te croire, mais connais tu au moins ces "raws" Silverfast? De plus quand je ne comprends j'aime bien que l'on essaye de se mettre à mon niveau de compréhension et que l'on m'illustre ce que l'on m'avance, je suis un pragmatique donc j'ai aussi besoin de voir. D'expérience pendant plus de 10ans j'ai eu beau scanner des fichiers le plus flat/neutres possible que ce soit sous Nikon Scan ou Epson Scan et cela n'a rien à voir avec les HDR 48/64bits Silverfast en terme de potentiel de traitement et de souplesse vu que tout le travail tonal et chromatique se fait a posteriori et non a priori (auparavant il m'arrivait régulièrement de devoir rescanner car j'avais fait une petite erreur) ce qui fait que le fichier est beaucoup moins figé. Bien entendu ce n'est pas magique et je n'ai jamais écrit ni sous entendu que le fichier ainsi généré allait au delà des capacités propres du scanner, juste ce type de fichier est bien moins contraignant tant dans le process d'acquisition qu'au niveau traitement ce qui le rend très similaire de ce point de vue au traitement d'un raw d'APN. J'ai incontestablement gagné en productivité et en qualité, et quand tu monnayes ces services ce qui m'arrive occasionnellement tu ne vas pas chercher midi à 14h sauf si on te proposes une solution tout aussi efficace et moins onéreuse.

[frmfrm]

Désolé, j'ai du taf et pas trop de temps pour entrer dans les détails.  ( et surtout je n'ai plus le courage de m'embraquer dans des discussions interminable :-) )

Donc je vais m'arrêter là.

Ah bon, c'est nouveau ça? Je connais parfaitement bien mes scanners et leur limite de résolution optique et j'ai toujours numérisé à leur limite optique https://www.chassimages.com/forum/index.php/topic,286080.0.html

Ah si quand même, un petit truc en passant :

Là où je bosse , on a un traceur qui permet de sortir des films à 50000 dpi. Le diamètre du spot du laser est bien plus grand qu'1/50000 inch. Pourtant on perd notre temps à tracer à 50000 dpi  . Je crois que c'est parce que l'on gagne en précision sur les largeurs de ligne et en propreté de "l'aliasing" du bord de trait ... Maintenant pourquoi je dis ça, ;-)

[Benaparis]

Désolé, j'ai du taf et pas trop de temps pour entrer dans les détails.  ( et surtout je n'ai plus le courage de m'embraquer dans des discussions interminable :-) )

Donc je vais m'arrêter là.

Faut pas teaser dans ce cas Dommage c'est intéressant de bénéficier d'un savoir/expérience qui sort du lot c'est suffisamment rare.

Ah si quand même, un petit truc en passant :

Là où je bosse , on a un traceur qui permet de sortir des films à 50000 dpi. Le diamètre du spot du laser est bien plus grand qu'1/50000 inch. Pourtant on perd notre temps à tracer à 50000 dpi  . Je crois que c'est parce que l'on gagne en précision sur les largeurs de ligne et en propreté de "l'aliasing" du bord de trait ... Maintenant pourquoi je dis ça, ;-)

Quelle est votre domaine d'application? Vous tracez du vectoriel? Je crois comprendre la logique ; pour mes besoins en photo en tout cas concernant mon Epson (vu qu'avec le Nikon je ne peux dépasser la résolution optique) je n'ai pas constaté de bénéfice pratique à aller plus beaucoup plus loin que la résolution optique (j'ai pourtant fait des tirages dépassant le mètre) mais je veux bien croire que dans d'autres cas ou avec d'autres machines il y ait un bénéfice.

[frmfrm]

Quelle est votre domaine d'application? Vous tracez du vectoriel? ...

Ce sont des traceurs utilisés dans l'électronique. pour tracer des films destinés à la fabrication des PCBs et ce sont des traceurs rasters.

- Les 1ers traceurs rasters sont apparus à la fin des années 80. Et le passage au raster n'a pas été facile à vendre/faire accepter :-) Avant on utilisait effectivement des traceurs vectoriels, mais aussi des bancs de repros qui ne tenaient pas dans une pièce de 20 m2................................

- Hein, comment ça vieux con ...... Attends que je t'attrape sac à m...

Bon, faut que j'vous laisse ;-)

[Benaparis]

Ce sont des traceurs utilisés dans l'électronique. pour tracer des films destinés à la fabrication des PCBs et ce sont des traceurs rasters.

- Les 1ers traceurs rasters sont apparus à la fin des années 80. Et le passage au raster n'a pas été facile à vendre/faire accepter :-) Avant on utilisait effectivement des traceurs vectoriels, mais aussi des bancs de repros qui ne tenaient pas dans une pièce de 20 m2................................

- Hein, comment ça vieux con ...... Attends que je t'attrape sac à m...

Bon, faut que j'vous laisse ;-)

Merci 

PS : j'ai retrouvé cette discussion pour les résolution d'acquisition et j'ai oublié de te donner une réponse : moi aussi quand sous-échantillonne j'évite le "au plus proche" et je choisi bicubique dégradé lisse

Bon dimanche.

[gerarto]

...
Ce qui me fait parler des photosites verts, c'est que quand on détermine la composante vertes d'un photosite, on a deux fois plus d'information que pour le bleu et le rouge. Donc je me demande si ça ne serait pas ce surcroît d'information qui permettrait des traitements plus précis sur Prime ou DeepPrime ou justement sur la BdB. Car strictement parlant, rien n'empêche de modifier la BdB sur un JPEG ou un TIFF. Et pourtant si DXO par exemple n'offre pas la possibilité de régler la BdB ni d'utiliser Prime ou DeepPrime sur un JPEG, il doit bien y avoir une raison. Mais quelle est-elle ?

Prime et DeepPrime ne peuvent être utilisés sur un jpeg ou un tiff, tout simplement parce que ces traitements de bruit sont réalisés avant le dématriçage, le plus en amont possible. Le "bruit" (schématiquement une variation anormale du signal par rapport à la valeur attendue) n'a pas de couleur en théorie. En pratique, les photosites situés derrière un filtre rouge auront plus de bruit que ceux derrière un vert par exemple car à flux égal moins de photons arrivent, et donc le rapport signal/bruit est moins favorable. 

En traitant le bruit avant le dématriçage, on peut supposer (évidemment DxO est peu loquace sur le détail de la manip, ce qui est compréhensible ! ) que ça revient à modifier les données des photosites pour leur réattribuer des valeurs corrigées.

La balance des blancs, c'est une autre étape qui est réalisée après le dématriçage : ce dernier "crée" chaque pixel RVB à partir de la valeur du photosite, en complétant les infos manquantes par celles tirées des photosites voisins de la matrice (et des données du fabriquant quant aux caractéristiques colorimétriques des filtres colorés).
Le résultat est celui sensé être vu par le capteur... s'il n'y avait pas eu les filtres de la matrice de bayer.
Et le résultat dépend de l'illuminant de la scène : si sa température de couleur est équilibrée (autour de 5000/5500 K) le blanc sera blanc et il n'y aura pas besoin de faire intervenir la BdB. Cela correspond à la valeur "original" ou "telle qu'elle" suivant les logiciels.
Si l'illuminant a une TC bien plus basse (par ex. 3000 K) le blanc sera orangé et il va falloir faire une correction de BdB (et idem si plus haute) pour le ramener au blanc. Cette correction consiste à déplacer l'ensemble des valeurs. Quand tu indiques 3000K pour valeur de l'illuminant, cela revient à recalculer l'ensemble des valeurs RVB en y ajoutant +/- 2000 K. Ce qui au passage explique que les curseurs de réglages de BdB vont du bleu au jaune alors que l'échelle des valeurs K est l'inverse.
(il faut également prendre en compte les corrections de teinte)
Ce qui au passage explique pourquoi les softs peuvent afficher des valeurs de TC légèrement différentes alors que les résultats colorimétriques sont identiques.

Pour faire une image lisible il faut :
- la dématricer
- faire - ou pas - une correction de BdB
- appliquer une courbe
- et appliquer un profil colorimétrique. (sans préjuger de l'ordre à l'exception de la première étape) 

Une fois cette image créée, l'enregistrer en Tiff ou en jpeg fixe les valeurs. On pourra toujours faire une correction colorimétrique sur ces sorties - qu'on l'appelle balance de blancs ou pas - mais elle sera bien plus limitée. On va faire une correction en valeurs relatives par rapport à une TC fixe au lieu de faire une correction en valeurs absolues sur l'ensemble des valeurs.
Pour faire une analogie : une correction de BdB de raw, c'est comme faire coulisser la partie mobile d'une règle à calcul (je vous parle d'un temps, etc. ) alors que une correction de jpeg, c'est tirer vers la gauche ou la droite un curseur qui serait fixé par un élastique à un point fixe (le milieu de l'échelle de réglage).   

[Benaparis]

Par rapport à l'origine du sujet: la couleur.
Sujet qui a quelque peu dérivé sur d'autres informations très interessantes par la suite.
J'ai passé le DNG Leica d'origine dans RawDigger et j'ai ensuite passé le dng linéaire de DXO
On voit quelques différences non négligeables dans la répartition d'information.Les deux canaux verts sont fusionnés, et il y a une "sorte d'amplification" (d'où les modifications d'échelles qui se font automatiquement) et les formes des histogrammes sont quelques peu différentes. L'exportation en .dng linéaire n'est pas aussi inoffensive que ce que l'on veut bien se persuader au niveau du signal RVB

Cela,ne vient il pas du fait que le DNG Linéraire contient une source dématricée contrairement au raw originel?
Que peut on conclure véritablement et concrètement parlant?
On pourrait bien sûr s'interroger sur la qualité du dématricage de DxO mais ayant testé la chose sur des images difficiles je n'ai pas trouvé de problèmes.