Colorimétrie : Capture One, DxO, ACR, Nikon Capture NX2...Dcraw

jdc · Janvier 11, 2009, 17:27:06

Vous pourrez trouver en cliquant sur le lien ci-dessous, un comparatif entre les logiciels cités dans le titre.
http://desmisja.perso.cegetel.net/geraud/compar.php#renducouleur

Olivier-P · Janvier 19, 2009, 02:44:56

Beau travail !

Eh oui qui osera dire qu'un dématriceur est neutre ensuite ?

Et pourtant, ces chiffres ne le disent pas, mais cela est.

Tout profil est un compromis. On notera tt de mm des valeurs moyennes de DE absolument correctes, le numérique est vraiment une fée pour la photo. A l'observation, à qq secondes d'intervalles, la mémoire chromatique étant pratiquement nulle, il est impossible de faire la différence. Ce n'est pas vrai pour la luminance, mais c'est un autre sujet très long.

Ensuite ? se rappeler pour toujours que la vie est subjective. Ce sont les courbes qui créent ces écarts, les saturations choisies, et des compromis ( obligatoires ) plus subtils non explicables ici, dans les dématricages. Se dire que le moindre coup de contraste, la moindre saturation infime, fait passer les DE au dessus de 30. La photo est un art subjectif. Aucune des minuscules valeurs notées ici ( ou ailleurs ) ne reste en l'état pour un photographe, il manipule automatiquement la totalité de ses fichiers.

Il y aurait ensuite à dire quels DE sont sensibles, Lab n'a pas tout résolu.

Ce systeme perceptuel a été calé pour représenter les écarts "perçus" par l'homme, comme des couleurs différentes. C'est une approche psycho visuelle. Les DE représentent parfois d'immenses zone de différenciation de couleurs, parfois des zones tres proches en xyY. De plus, pour rajouter à la complexité, percu ( donc DE par lab ) ne veut pas dire sensible forcément, la correspondance n'est pas évidente. Surtout en saturation fortes. Ce débat est immense, des livres n'y ont pas suffi. Il faudrait rapprocher cela d'expériences, et de comparaisons. Hélas, à cause de la fameuse mémoire des couleurs quasi impossible ( adapt chroma, en tc des cretes des blancs aussi ) c'est un pari perdu d'avance. Se souvenir des galères en 31 ...

A part superposer les plans chromatiques, c'est impossible. Dans une photo in situ, on en parle mm pas, si elles sont décalées dans le temps.

Sans pédagogie, toute lecture de ce type, passionnante pour un lecteur averti, sera complétement inutile pour les autres, ou bien interprétés de travers. Je crains que tu n'aies pas énormément de lecteurs

Mais j'en suis

polohc · Janvier 19, 2009, 17:28:33

Moi aussi je suis un lecteur attentif des articles de jdc

De plus je me suis pris au jeu avec l'utilisation de sa version DCRaw évoluée

Cela m'a permis de mieux comprendre le traitement numérique et de faire un choix (provisoire, les derawtiseurs évoluent vite) :
DxO en généraliste et DCRaw_90 en spécialiste des images délicates, notamment à grande dynamique.

Olivier-P · Janvier 20, 2009, 06:28:05

Eh oui Polloc en plus de cela, tu es utilisateur des charmes de la ligne de code

Et là par contre, pas saisi encore (?), on attend que Jacques nous fasse des raccourcis sous forme de potards et autres icones, ou de menus

on ne désespère pas pour juger ensuite de la prod possible.

polohc · Janvier 20, 2009, 10:08:29

Citation de: Olivier-P le Janvier 20, 2009, 06:28:05

Eh oui Polloc en plus de cela, tu es utilisateur des charmes de la ligne de code

Et là par contre, pas saisi encore (?), on attend que Jacques nous fasse des raccourcis sous forme de potards et autres icones, ou de menus on ne désespère pas pour juger ensuite de la prod possible.

Oui Olivier, la LC c'est prenant un certain temps, puis çà devient un peu fastidieux ! Mais je n'ai pas l'impression d'avoir perdu mon temps, bien au contraire

Je pense que jdc, contributeur à PerfectRaw, voit dans ce projet l'évolution graphique sans concession de DCRaw. La v. 0.65 est déjà très performante en Q de dématriçage

chelmimage · Janvier 21, 2009, 09:37:08

Merci pour l'ampleur du travail effectué très intéressant..
Une question dont je m'excuse à l'avance: par rapport à ces résultats qui montrent un progrès vers l'excellence, que pourrait (encore) faire gagner la caractérisation du boîtier?

Olivier-P · Janvier 22, 2009, 02:31:34

Citation de: polohc le Janvier 20, 2009, 10:08:29
Oui Olivier, la LC c'est prenant un certain temps, puis çà devient un peu fastidieux ! Mais je n'ai pas l'impression d'avoir perdu mon temps, bien au contraire

Je pense que jdc, contributeur à PerfectRaw, voit dans ce projet l'évolution graphique sans concession de DCRaw. La v. 0.65 est déjà très performante en Q de dématriçage

Bien entendu, aucune raison d'être plus mauvais ou moins bien en LC

je parlais de rendement. Pour les gens qui travaillent, ce n'est pas jouable, hors justement avoir un log gratuit et aussi performant serait sympa, avec les qualités des deux mondes. De plus l'intéret de parler au dev direcetemnet, car je ne refuse pas de payer un bon soft, ce n'est pas le pb, le pb c'est le discours et le partage direct. Pour l'instant c'est redibitoire, à par amateurs qui ont du temps. En rendement, les autres, on est toujours à la bourre. Revenir à la LC ce serait comme revenir aux pelliculles, on ne peut pas.

Olivier-P · Janvier 22, 2009, 02:34:36

Citation de: chelmimage le Janvier 21, 2009, 09:37:08
Merci pour l'ampleur du travail effectué très intéressant..
Une question dont je m'excuse à l'avance: par rapport à ces résultats qui montrent un progrès vers l'excellence, que pourrait (encore) faire gagner la caractérisation du boîtier?

C'est un "marché" réel Michel. les icc boitiers.
Utiles en TC fixes, et en repro TRES utiles. En calage parc ( donc des pro ) aussi.

Pour celui qui "arrange" ses photos, je suis dans les mm remarques, qq dizaines de DE sont alors banaux. Donc peu utile. A part apn médiocres, compacts etc ...

FTQL · Janvier 24, 2009, 18:33:34

Citation de: Sansame le Janvier 24, 2009, 17:48:08
Je n'ai pas encore testé le nouveau système de calibrage d'APN "DNG Profile Editor" développé par Adobe pour "remplacer la méthode Fraser". Il est aussi basé, semble-t-il sur les couleurs d'une ColorChecker classique... Si qq a déjà testé cette nouvelle méthode, bien plus facile à exploiter que la méthode Fraser, ça m'intéresse !

Je viens de commander une Color Checker pour une utilisation de DNG Profile Editor. Mais mes buts sont bien modestes par rapport à ce fil vu qu'il s'agit juste de régler un problème de rendu sur un compact. Actuellement les jpegs boitiers sont pour moi meilleurs que les raws que j'obtiens sous Lightroom. En effet sous LR, je n'arrive pas à obtenir de détail dans les couleurs saturées. Exemple :

Le Jpeg :

Le Raw "par défaut" de Lightroom 2.2 avec un profil Adobe Standard :

Regarder en particulier l'arête verticale de droite de la cabine téléphonique.

Je ne suis donc pas très préoccupé par l'obtention de couleurs "fidèles", d'autant plus que je bouscule beaucoup le rendu en post-traitement, mais je trouverai agréable de régler ce problème de détail. J'espère ne pas mettre tromper en m'imaginant qu'une calibration boitier pourrait être efficace. Je verrai bien

polohc · Janvier 24, 2009, 22:56:48

Citation de: FTQL le Janvier 24, 2009, 18:33:34
...
Actuellement les jpegs boitiers sont pour moi meilleurs que les raws que j'obtiens sous Lightroom. En effet sous LR, je n'arrive pas à obtenir de détail dans les couleurs saturées. Exemple :

...

Ce rendu des détails est généré par l'application d'une courbe de tonalité (gamma et contraste) et par l'accentuation (en général assez fortes dans un JPEG)
Les réglages du traitement du RAW permettent de retrouver si on le souhaite (?) l'aspect du JPEG mais avec beaucoup plus de nuances et de possibilités de retouche

FTQL · Janvier 24, 2009, 23:16:55

Je vois ce que tu veux dire et effectivement je ne cherche pas à avoir le rendu flatteur du jpeg dans l'absolu. Mais en l'occurrence, je pense qu'il y a quand même un problème dans les couleurs saturées sous Lightroom dans le cas de mon boitier.

Je ne dis pas ça parce que le jpeg est plus flatteur, saturé, contrasté ou accentué. Mais à partir du Raw, soit je désature les rouges pour avoir de la matière mais dans ce cas je perds de la couleur. Et si j'ai la couleur, je perds la matière. Le jpeg, en dehors de toute considération de fidélité des couleurs, est à la fois saturé et détaillé. Et j'ai l'impression que ce n'est pas qu'une question de gamma, de contraste et d'accentuation, car j'ai essayé de jouer sur ces paramètres à partir du Raw, mais autre chose. Je vais explorer la piste de la calibration quand j'aurai reçu ma charte. Je suis cette piste car pour l'instant les meilleurs résultats que j'obtiens sont en jouant sur le panneau Etalonnage en désaturant un peu les rouges et en augmentant légèrement la teinte. Avec la calibration DNG, j'espère réussir à trouver un bon compromis sans tâtonner.

Désolé de polluer ce fil avec ces considérations basiques, vaguement reliées au sujet.

Si certains sont intéressés par la question :
Le jpeg boitier : http://img.photographyblog.com/reviews/panasonic_lumix_dmc_lx3/sample_images/panasonic_lumix_dmc_lx3_10.jpg
Le raw : http://img.photographyblog.com/reviews/panasonic_lumix_dmc_lx3/sample_images/panasonic_lumix_dmc_lx3_02.rw2
En l'occurence, ces images ne sont pas de moi mais sont des samples récupérés dans un test pour me faire une idée du compact.

Olivier-P · Janvier 25, 2009, 00:15:07

Citation de: Sansame le Janvier 24, 2009, 17:48:08
Ce travail est très intéressant. Je voudrais juste y ajouter une remarque sur le DeltaE envisagé comme la mesure de la justesse d'un ensemble APN+dématriçage.

Quand on mesure ou qu'on compare les performances de logiciels de développements RAW ou d'APN, on est confronté à une difficulté assez fondamentale : l'écart colorimétrique entre scène et image mesuré sous la forme d'un DeltaE n'est pas un critère pertinent.

L'objectif d'un APN (avec son logiciel de développement embarqué) ou d'un logiciel de développement externe n'est pas en effet de minimiser ce DeltaE mais de produire de "belles images" ce qui, compte tenu des dynamiques réduites de nos engins réels, n'est pas une mince affaire. Ce processus de rendu qui permet de passer de la scène à l'image est complexe. Il comprime les énormes dynamiques de la "nature" et laisse une part d'initiative importante au talent des concepteurs de logiciels... Il est donc normal que les différents logiciels de développement donnent des résultats sensiblement différents...

La seule application pour laquelle il est clair qu'on doit viser un DeltaE aussi faible que possible est la reproduction d'objets plans, par exemple la reproduction d'oeuvres d'art. On se trouve alors dans une "situation ICC" proche de celle d'un scanner... et il est légitime de rendre le DeltaE aussi faible que possible.

Dans les autres cas, non seulement minimiser le DeltaE ne doit pas être l'objectif essentiel, mais quand on se fixe cet unique objectif, on débouche sur des résultats médiocres. On peut vérifier cette triste conclusion sur deux exemples. D'abord la "méthode Fraser" de calibrage d'APN avec ACR, qui étalonne l'APN par itérations en minimisant le DeltaE d'une ColorChecker classique : les images produites avec ce calibrage sont... moches. Autre exemple, le logiciel de calibrage d'APN inCamera, qui construit un profil ICC à partir d'un algorithme qui réduit au minimum le DeltaE d'une ColorChecker SG : l'application du profil ICC issu de inCamera donne des photos... moches.

Je n'ai pas encore testé le nouveau système de calibrage d'APN "DNG Profile Editor" développé par Adobe pour "remplacer la méthode Fraser". Il est aussi basé, semble-t-il sur les couleurs d'une ColorChecker classique... Si qq a déjà testé cette nouvelle méthode, bien plus facile à exploiter que la méthode Fraser, ça m'intéresse !

Idem pareil.

Quand aux DNG profile, toujours la mm critique, mire de gamut banal.

Pascal Méheut · Janvier 25, 2009, 20:22:29

Citation de: FTQL le Janvier 24, 2009, 18:33:34
Actuellement les jpegs boitiers sont pour moi meilleurs que les raws que j'obtiens sous Lightroom. En effet sous LR, je n'arrive pas à obtenir de détail dans les couleurs saturées.

Marrant, j'ai eu exactement le même problème avec Camera Raw et les fichiers du DMR il y a 3 ou 4 ans. Je pensais qu'Adobe avait pas mal avancé.
Tu as comparé avec Capture One ou un autre ? Même s'il n'offre pas les fonctions de Lightroom...

FTQL · Janvier 25, 2009, 20:43:29

Non je n'ai pas comparé avec d'autres développeurs. Sur le fil consacré au LX3, quelqu'un a traité le raw avec le développeur constructeur (Silkypix) et a retrouvé un résultat plus proche du jpeg, ce qu'on pouvait espérer. Comme je tiens à travailler sous Lightroom, avec lequel je développe les images issues de mes autres boitiers, je ne compte pas essayer d'autres logiciels. Comme il s'agit là d'un problème de rendu de raw venant d'un compact, je suis de toute manière moins exigeant. Je ne tiendrai sans doute pas le même raisonnement avec le DMR.

Cela dit la colorimétrie de Lightroom a évolué entre les versions 1 et 2. On le voit bien quand on applique les anciens profils. Et surtout Adobe a répondu à la critique qui lui était faite de divergence avec le rendu jpeg des Canon et Nikon grace au Color Matching. Et les nouvelles spécifications DNG avec le nouvel éditeur de profil ouvrent peut-être des pistes intéressantes. Sur le fil consacré à la Color Checker (http://www.chassimages.com/forum/index.php/topic,36003.msg593627.html) nous sommes quatre à avoir commandé une charte pour une utilisation avec DNG Profile Editor dont Olivier Chauvignat qui est sans doute le plus pointu d'entre nous. Peut-être que ce sera l'occasion d'avoir des retours d'utilisateurs non experts en colorimétrie. Je suis en tous cas curieux de voir si ça aidera à résoudre mon problème de rendu, même si anecdotique

Pascal Méheut · Janvier 26, 2009, 07:47:07

Tiens moi au courant. J'ai utilisé une ColorChecker pour faire des profils soit avec ProfileMaker soit avec le plugin freeware pour CameraRaw et ce que je gagnais par endroit, je le perdais ailleurs, soit en dynamique, soit en gamut.

Ceci dit, c'était il y a déjà 2 ans et je n'ai pas non plus passé énormément de temps sur le sujet. Donc, ca me m'étonnerait pas qu'on atteigne qque chose de satisfaisant de nos jours avec la progression des outils et l'aide de gens expérimentés.

chelmimage · Janvier 28, 2009, 09:18:13

Dans la veine de ce thème, je me permets de vous signaler quelques reflexions et essais que j'ai faits dans le cadre du fil suivant.
http://www.chassimages.com/forum/index.php/topic,36412.msg598659.html#msg598659
Vous pouvez lire la suite du fil à partir de ce stade. Si vous remontez dans le fil vous n'en comprendrez que mieux les objectifs. Sans moyens particuliers, avoir une synthèse analysable facilement et en valeurs relatives du comportement d'un boîtier.
En une seule photo.

FTQL · Janvier 29, 2009, 00:09:14

Voilà, carte reçue aujourd'hui. Un rapide essai mais rien de conclusif pour le moment. Je commencerai à regarder tout ça lundi.

Premières impressions ci-jamais : http://www.chassimages.com/forum/index.php/topic,36003.msg602648.html#msg602648

jdc · Février 02, 2009, 11:04:13

Quelques compléments et informations :
* certes la ligne de commande peut paraître une forte contrainte, néanmoins si on réserve l'usage de Dcraw_90 aux images délicates, cela me semble un problème secondaire.
* le développement de Perfectraw qui possède une interface graphique (certes ce n'est pas encore Lihtroom ou Capture NX) est en cours. Cette version de Perfectraw (0.65a) reprend une partie des fonctionnalités de la version Dcraw_90... A terme elle utilisera OpenGL pour avoir plus de commodités et de rapidité. Néanmoins les fonctionnalités seront semblables. Je joins la page web (en Espagnol) pour télécharger Perfectraw http://www.ojodigital.com/foro/perfectraw-perfectblend/240581-perfectraw-0-65-a.html

Au sujet du rendu des images, bien sûr on peut discuter à l'infini sur le rendu des couleurs...Néanmoins lorsqu'on fait du développement logiciel à partir de couleurs étalonnées et même si Lab n'est pas parfait, il est important de mesurer les écarts apporté par telle ou telle partie du traitement.

Les chercheurs se servent de DeltaE (CIE76) pour mesurer notamment:
* les incidences de l'interpolation qui rappelons le - toutes choses égales par ailleurs - est source de DE et surtout de bruit
* le traitement du bruit
On s'aperçoit en examinant :
* les histogrammes en partie basse http://jacques.desmis.perso.neuf.fr/D7_200_histob.html
* le rendu de la dynamique et du gamut (limités à ce que je peux mesurer)http://desmisja.perso.cegetel.net/geraud/compar.php#gamutd
Que les profils "maison" sont probablement la source, qui va faire accroître les DE, notamment pour deux aspects :
* éviter la montée du bruit dans les BL en modifiant luminance et chromaticité...voire la teinte
* minimiser les problèmes d'application du gamma dans les BL qui prend beaucoup de temps calcul. Dans le cas de Dcraw_90 j'utilise une LUT à 262144 points pour éviter les histogrammes en arêtes de poisson...

De plus il y a plusieurs manières en programmation de faire la conversion rgb (ce qui est sur le capteur après interpolation) en RGB où intervient l'espace colorimétrique (sRGb, Prophoto,...) et le gamma :
* soit par des moteurs de gestion de couleurs (Adobe, LCMS,...),
* soit par calcul direct
C'est cette deuxième manière de faire qu'utilise Dcraw qui est nettement plus performante en termes de qualité des histogrammes...

De mon point de vue en colorimétrie qui peut le plus peut le moins...Il vaut mieux je pense partir d'images neutres avec les deltaE les plus faibles possibles, car il est plus facile d'ajouter du contraste, de la saturation, etc. que d'en retirer....
Certes les images avec des DE faibles sont ternes - car on est habitué notamment par l'argentique - à avoir des teintes saturées et contrastées. De plus lorsqu'on souhaite élaborer des profils ICC d'étalonnage de boîtier, il est important d'avoir des mires où les BL et HL sont suffisamment représentatives et proches des limites (0 et 100) pour éviter les pertes de dynamique...Mais dans le cas présenté ici pour Dcraw_90, il n'y a aucun profil...La conversion rgb==> RGB est faite par calcul.

Néanmoins j'ai tenu sur une image de D700 à 200 ISO (traitée avec Dcraw_90) à voir l'incidence des réglages habituels :
* contraste : +15% avec courbe en S
* saturation : environ +15% différenciée sur teintes ternes, pastels et saturées
* luminosité : +8%
ces réglages ont obtenus par calcul en mode Lab / Lch. et ajoutés à la page web http://jacques.desmis.perso.neuf.fr/D7_200_color.html

En synthèse certes les deltaE augmentent, ils passent de 4.9 à 8.6 (CIE76); l'image a plus de claquant, mais l'accroissement reste très raisonnable

FTQL · Février 02, 2009, 12:29:06

Merci pour ces informations qui me font relativiser mes petits essais de gestion de la couleur. Fait amusant, je viens justement de remarquer ce matin que mes premiers essai de calibration du boîtier avec mire ColorChecker et DNG Profile Editor augmentaient le bruit de manière visible même à 100 isos.

Petite question naïve : Pourquoi est-ce qu'Adobe et consorts ne font pas la conversion par calcul direct si elle est plus performante en terme de qualité des histogrammes ? Coût calcul, rendu moins clinquant... ?

polohc · Février 02, 2009, 12:34:47

Jacques, tu es de retour en forme

Tes mesures confirment bien ce que je te disais constater visuellement pour DxO "réaliste",
j'en ai fait un preset par défaut, je trouve que c'est plus simple et logique d'appliquer ensuite les divers réglages souhaitables.

Ensuite, si je n'arrive pas à ce que je souhaite, notamment sur les images à grande dynamique, je passe à DCRaw_90 imbattable pour tirer le maximum d'un RAW

jdc · Février 02, 2009, 12:56:08

[at] FTQL

C'est une bonne question...que je me suis posé plusieurs fois..Le calcul direct est plus "complexe" et surtout plus long. Dans le cas de Dcraw_90 dans certaines options j'ai laissé la possibilité de calcul précis en n'utilisant pas de LUT mais la fonction Pow()...Les temps de calcul sur une image de D3X ou 5D2 peuvent prendre - juste pour cette opération de 10 à 30 secondes supplémentaires... Et si je réduis le LUT à 32000 points au lieu de 260000, certes le calcul est quasi instantané, mais l'histogramme est "moche"...

[at] polohc

Tu fais très bien de te servir de "realiste" qui donne de très bons résultats..contrairement aux autres options (sauf si on aime)...Et derrière tu peux ajouter contraste, saturation, courbes.. en partant d'une base propre..A noter que pour l'élaboration de profils ICC de boîtier, DxO se sert de l'option "réaliste"...dommage que le TIFF soit uniquement en AdobeRGB.

jdc · Février 02, 2009, 13:45:20

[at] Sansame
D'abord pour éviter les incompréhensions je vais décrire le processus (simplifié) :
1) lecture du fichier : CR2, NEF,...et utilisation éventuelle de la matrice de couleur
2) décodage matrice de Bayer
3) avant-interpolation pour cartographier et prétraiter le bruit
4) éventuel débruitage par ondelettes
5) balance des blancs et aberration chromatiques
6) interpolation au choix (AHD, AFD, VCD, PPG, VNG, ou mixtes, etc.) et donc optimisation du bruit (et non suppression)
7) application de filtres median et Laplaciens pour réduire les artefacts
8- traitement éventuel des HL
9) accentuation éventuelle
10) application éventuelle de medians et Laplaciens
11) application éventuelle de profils ICC input et conversion espace (via LCMS)
12) conversion rgb==> Lab ==>rgb : pour traiter le gamut, modifier contraste, saturation, basses lumières, etc.
13) conversion rggb ==> RGB : attribution d'un esapce colorimétrique, et d'une TRC (rendus de tons)
14) conversion RGB: application d'un gamma variable : choix parmi plusieurs "linéaire + puissance ".
15) écriture du TIFF

Je pense avoir décrit sommairement le processus sans trop en oublier...

jdc · Février 02, 2009, 14:27:51

[at] Sansame : suite

Avant la conversion RGB, on part donc de composantes rggb qui ont déjà subi un traitement fin, qui préserve le gamut, accentue, traite les artefacts,les BL, les HL, la Bdb, etc.

A partir de ce moment 2 options :
* la plus courante (de ce que je connais, car je n'ai pas les codes de Capture NX ni de DxO...), qu'on retrouve par exemple dans UFRAW, mais qui doit être semblable dans Capture NX car on dispose des fonctions "attribution et conversion de profil". Dans ce cas le logiciel se sert pour l'attribution de profil, la conversion, le gamma, du moteur du gestionnaire de couleur, qui a l'avantage de pouvoir traiter tous les profils et espaces du commerce, d'être rapide et simple à l'utilisation. Ces moteurs font certes du calcul, mais se servent beaucoup de LUT, notamment celles des profils et espaces qui sont relativement "grossières"

* la plus rare, celle dont se sert de base Dcraw 8bits:
1) à partir des valeurs "rggb" précédemment calculées, on réalise une conversion rgb=>XYZ en prenant en compte : la matrice 3x3 de l'espace choisi, les caractéristiques du point blanc, les matrices couleurs du boîtier. On ne corrige plus ici le "niveau de noir" ni la "saturation" qui sont des caractéristiques du boîtier et qui ont éventuellement été traité en amont.
2) DCRAW ajuste les valeurs TRC de manière unique
3) puis application d'un gamma unique de type D.Coffin: linéaire + partie variable en puissance
4) toutes ces données sont écrites dans un "buffer" y compris les entêtes de fichier: nom de l'espace, gamma, etc.

* Dans la version 16 bits (peu développée par D.Coffin, et je me demande pourquoi ?), mes collègues Espagnols et moi même avons gardé sensiblement le même processus, mais qui est plus lourd et plus lent du fait du traitement sur 16 bits (RGB de 0 à 65536), voir plus (262144) :
* dans la réalité, en amont, je recommande de faire une conversion rggb==> Lab==> rggb - en choisissant l'espace de calcul qui peut être différent de celui de travail - pour traiter les valeurs hors gamut. J'ai mis au point un "petit moteur" de conversion qui travaille soit en colorimétrie absolue, soit relative et traite les valeurs négatives rggb ou supérieures à 65535 et affiche (dans un fichier texte) si on le souhaite les pixels hors gamut.
* bien sûr ce "traitement" non présent à ce jour dans Perfectraw est optionnel
* j'ai ajouté au traitement de base de D.Coffin (sRGB, Adobe, XYZ, Prophoto, WideGamut), 4 autres espaces CIE_RGB, Bruce_RGB, Don_rgb et Beta_RGB.

On voit immédiatement les inconvénients (?) de ce mode de calcul, il est obligatoire si on veut un espace en plus de modifier le code (pointeurs, calculs...) de D.Coffin qui n'est pas d'une lisibilité exemplaire (c'est un euphémisme) et deuxièmement ceci n'est opératoire que pour des espaces matriciels (pour PhotoGamutRGB je me sers de l'application de profil LCMS incorporée)

Plusieurs points importants concernant les rendus et la qualité :
* les conversion rggb=> Lab ==> rggb se font "sans pertes" (ou négligeables de l'ordre de 1/100000) au niveau du calcul ce qui impose beaucoup de contraintes et de rigueur et un certain temps de calcul...
* l'utilisateur à le choix de plusieurs "courbes de rendus de tons TRC" - on agit par calcul dans l'entête du fichier TIFF en simulant un profil ICC- on peut donc dissocier ces valeurs de celles de l'étendue de l'histogramme. Ces courbes TRC ne modifient pas l'histogramme.
* l'utilisateur a le choix entre plusieurs courbes de gamma - une dizaine - qui permettent en combinant une partie linéaire et une partie puissance, qui bien sûr doivent se raccorder y compris pour les dérivées. Ce gamma ne modifie pas les TRC. Ces courbes "variables" associées au TRC permettent :
a) d'avoir des histogrammes propres et lisses
b) de donner des rendus appropriés à tous les cas, depuis le traitement linéaire, jusqu'à des gamma de 2.6, en passant par un traitement adapté des BL.

polohc · Février 02, 2009, 15:27:40

Citation de: jdc le Février 02, 2009, 12:56:08
... A noter que pour l'élaboration de profils ICC de boîtier, DxO se sert de l'option "réaliste"...dommage que le TIFF soit uniquement en AdobeRGB.

C'est une constante DxO en fait tj trop dans ses réglages

Le profil ICC du TIFF en sortie peut être choisi parmi la liste des profils installés dans Windows (j'utilise ProPhoto)

jdc · Février 02, 2009, 15:35:05

Je n'ai DxO en vrai que dans la version 4.5. J'ai eu la 5.3 en essai...

Je parle du TIFF qui sert de base pour élaborer les profils ICC et non du TIFF de sortie qui lui est paramétrable y compris en Prophoto. Peut être que dans les options je n'ai pas trouvé, mais ce point me semble comme l'espace de travail - celui dans lequel se font les traitements (avant la conversion JPG ou TIF...) - non paramétrable, mais bref c'est assez secondaire.. surtout que je ne m'en suis servi que pour tester...comparer.

jdc · Février 02, 2009, 18:38:17

[at] Sansame

Dans le domaine du traitement de dématricage, il y a des querelles...mais ce qui ressort en point communs :
* il vaut mieux traiter le bruit avant interpolation (il y a mieux que les ondelettes, mais aujourd'hui c'est la base de Dcraw, un membre de l'équipe, un chercheur Americain, Emil Martinec développe actuellement de nouveaux processus très innovants et très prometteurs...).
* le bruit est aussi traité de manière préventive, en cartographiant les pixels à risque, pendant l'interpolation, c'est le cas de AFD qui est un processus entièrement nouveau issu de chercheurs à Hong-Kong et mis au point par M.LLorens et Paul Lee (lui même co-auteur de AHD, interpolation qui se trouve en variante dans de nombreux produits tels ACR, Lightroom...)
* pour la balance des blancs, là aussi , il vaut mieux le faire en RGGB, avant interpolation, pour diminuer les artefacts.
* etc.
Néanmoins il est également possible de le faire après... ce qui ne pose(rait) pas de problème...

La conversion rgb==> Lab ==> rgb est entièrement réalisée avec des "float" et/ou "en double précision". selon les cas (le 8 bits ferait tout perdre), de même les conversion rgb==>XYZ par inversion de matrice sont faits par calcul en double précision au lieu de copier la matrice inverse (pertes de précision). Les constantes utilisées pour la conversion XYZ=> Lab (epsilon, kappa, ..) sont définies en double précision, etc. Il est indispensable de traiter le cas des valeurs de luminance 'L' et 'a' et 'b' qui sortent des limites > 128, > 100 ou négatives...De plus je vérifie (et j'ai vérifié) l'exactitude des résultats en comparant pour des pixels donnés les valeurs rgb avant et après conversion Lab en n'exécutant aucune opération. Les erreurs sont infimes de l'ordre de 1/100000 donc de l'ordre de la précision 16 bits (1/65536).

Je sais (on en parle dans certains forums aux USA) que cette pratique est contestée si on utilise les entiers et les calculs sur 8 bits- mais si on prend les précautions suffisantes - les risques sont quasi nuls...Le mode Lab permet d'accentuer en mode Lab (l'accentuation se fait juste après l'interpolation) et de traiter contraste / saturation sans toucher aux autres composantes.

Le filtre Laplacien (moiré, aliasing) ainsi que d'autres ("reinforce EECI", "median différentiel" pour artefacts de couleurs,...) ont pour origine les chercheurs de Hong-Kong et ont été mis au point en langage C par Paul Lee. J'ai juste apporté ma contribution, par exemple en rendant possible le choix du seuil du Laplacien, ou encore le nombre de pixels qui servent au calcul (3x3 pour les travaux de Paul Lee et D.Coffin... que j'ai porté à 5x5 bien sûr au choix car les temps de calcul sont plus longs).

J'espère avoir été assez clair...

jdc · Février 02, 2009, 21:56:00

Pour la balance des blancs, c'est le travail de Dave Coffin, il n'y a rien de changé à son code, sinon quelques "arrangements" personnels, pour ajuster l'exposition et la récupération des HL..

Guillermo Luijk a fait un bon tutoriel sur Dcraw où il explique (en anglais ou en espagnol) les inconvénients de faire la BdB après interpolation
http://www.guillermoluijk.com/tutorial/dcraw/index_en.htm

En fait cette balance des blancs consiste à équilibrer 4 canaux RGGB. pour cela le logiciel possède plusieurs algorithmes qui sont ceux qu'ont retrouve habituellement :
* soit on se sert de la Bdb du boîtier, c'est à dire qu'on se sert des 4 multiplicateurs de canaux, r1, r2, r3 et r4 inscrits dans les exifs. Ces coefficients valent par exemple pour un D700 :
* pour 2700K 1.066406, 1, 2.679687, 1
* pour 4170K 1.523437, 1, 1.566406, 1
* pour 10000K 2.480469, 1, 1,1
* la table comprend pour un D700 : 65 listes de valeurs... et chaque type de boîtier (5DII, D3, A900, etc) possède ses caractéristiques propres.
* soit on se sert de la surface entière de l'image qu'on considère comme une "box" grise de 10M° de pixels (ou plus) qu'on essaye d'équilibrer
* soit on se sert d'une zone réputée grise parfaite (référence à la prise de vue = charte de gris,...) et on équilibre les 4 canaux RGGB, à l'issue on a de nouvelles valeurs r1,r2,r3,r4 qu'on fait agir sur la matrice de Bayer.

Les canaux verts peuvent être déséquilibrés ce qui dans certains cas peut entraîner des labyrinthes avec notamment l'interpolation AHD et certains capteurs (Olympus..). Manuel LLorens a mis au point (il a un Olympus...) un processus pour équilibrer ces canaux verts et ceci avant même la BdB.

L'interpolation en "bricolant" (c'est un peu péjoratif, mais traduit bien les arrangements des pixels qui se font par convolution) va légèrement fausser les calculs en introduisant de petites erreurs.
Une fois cela fait, on opère un éventuel débruitage (ondelletes), j'ai inversé ces données dans l'information que j'ai donnée sur le processus...

Je connais très bien les travaux de b.Lindbloom, mais ces exemples comme vous le dites se référent a des calculs sur 8 bits, qui si on les fait entraînent de lourdes erreurs

Olivier-P · Février 06, 2009, 21:55:04

Avant interpolation, mais forcément vis à vis d'un espace ( profil ).

Il y a des documents, illisibles en détails pour ma connaissance personnelle, qui argumentent les choix possibles, et la méthode. J'ignore ce que Coffin a retenu. Principalement deux écoles s'affrontaient si ma mémoire est bonne, un espace de taille restreinte genre srgb, ou un CIERGB. Le papier indique que le CIERGB a été plus ou moins abandonné pour caler les blancs, car donnant des résultats moins bons. Ce profil premier n'indique en aucun cas les profils suivants, soyons clairs.

Olivier-P · Février 07, 2009, 04:25:24

Pardon, CIE XYZ, pas CIERGB.

"The advantage of the white point preservation constraint
when assuming maximum ignorance (MI) spectral
correlation statistics is discussed elsewhere. For
consistency's sake, the least squares regressions were
performed on linear RGB values. There may be some
advantage to minimizing the mean square error in a more
perceptual RGB space, such as one with a gamma function
of approximately 2.2, but this was not investigated.
However, it is important to note that the mean square error
was minimized in linear ITU-R BT.709 RGB space, as
opposed to linear CIE XYZ space."

nb : ITU709 = sRGB.
Voici une étude de différentes expérimentations de dématricage.

www.photus.eu/img/gamut_cic97.pdf

jdc · Février 07, 2009, 08:10:20

Je ne sais pas ce que font les autres produits...

Mais dans le cas de Dcraw, la balance des blancs est assurée avant interpolation, sur des valeurs rggb, c'est à dire où un espace couleur n'a pas été affecté.

Le calcul est "simple" et prend en compte les multiplicateurs de canaux enregistrés lors de la prise de vue.

1- Soit on se sert de ces valeurs (paramètre -w) et on obtient la bdb du boîtier.

2- Soit on entre les coordonnées d'une zone réputée neutre(paramètre -A x y dx dy), le logiciel calcule avec la matrice de Bayer, la valeur moyenne correspondant à la somme des 4 composantes rggb, divisée par le nombre de pixels de la zone et corrige les coefficients initiaux. A noter que si x=0, y=0 dx=largeur dy=hauteur, on réalise la fonction balance des blancs automatique en prenant en compte la surface du capteur en entier.

3- Soit on entre des valeurs libres (paramètre - r a b c d), et là le logiciel prend en compte ces valeurs.

C'est sur ce point 3 que Dcraw est aujourd'hui "limité". Dans la version de Perfectraw - qui reprend une interface graphique - la future version 1.0 (aujourd'hui c'est la 0.65) introduira les possibilités d'entrer par choix de l'utilisateur des valeurs préétablies données par les constructeurs et qui permettront de "corriger" sensiblement la Bdb, en entrant des valeurs de type "tungstène", "fluorescent", "nuageux", etc., 6300K, 3200K,...A noter qu'il est possible d'entrer ces valeurs manuellement par la commande -r de Dcraw.

A titre d'information, par exemple pour un Nikon D3 les coefficients à appliquer à -r a b c d sont :
* pour Incandescent a=1.16796 b=1 c=2.31640 d=1
* pour Fluorescent a=1.6875 b=1 c=2.10156 d=1
* pour Daylight a=1.8164 b=1 c=1.35546 d=1
* etc.

C'est après interpolation et d'autres traitements qu'on affecte un espace colorimétrique (sRGB, Adobe, Prophoto...

Olivier-P · Février 07, 2009, 20:39:34

Si tu n'as pas un espace, rggb ou n'importe quelle autre valeur n'a pas de référent. Il faut donc un espace temporaire.

jdc · Février 08, 2009, 08:04:38

Dans le code source en langage C, réalisé par Dave Coffin, les valeurs rggb qui servent :
a) à réaliser la balance des blancs
b) retoucher les aberrations chromatiques
c) réduire le bruit par ondelettes
d) interpoler
d) retoucher les HL
f) etc.
Ont pour origine la lecture de la matrice de Bayer : fonction FC() et BAYER() qui décryptent les valeurs inscrites sur le capteur.

L'équipe de développement de Perfectraw (G.Luijk, M.LLorens, F.Ariznav, Egon, P.Lee, E.Martinec...) et moi même, avons ajouté des fonctionnalités toujours avant l'affectation d'un espace colorimétrique :
a) réglage pondéré de l'exposition
b) nouveaux algorithmes d'interpolation
c) filtres medians et Laplaciens
d) etc.

Je réalise (ce n'est pas repris dans Perfectraw à ce jour), une conversion rgb ==> XYZ => Lab puis "opérations", puis le traitement inverse Lab ==> XYZ==>rgb, pour effectuer des "opérations" en mode Lab : accentuation, examen du gamut, traitement du contraste et de la saturation, traitement des BL, etc.
Cette conversion de travail provisoire est effectuée après l'interpolation.

La conversion rgb==XYZ où on affecte l'espace de travail de sortie (sRGB, Adobe, WideGamut, Prophoto...), ainsi que l'affectation d'un gamma est réalisée en final, juste avant la production du TIFF.

Olivier-P · Février 08, 2009, 17:29:16

L'espace de la balance n'a strictement rien à voir avec celui de sortie.

Si tu ne vois aucune application de profil, c'est que les rgbcam sont en XYZ par défaut. Autrement dit les valeurs sont déjà alignées, en D65 d'ailleurs, dans l'équilibre du capteur. "Ne pas avoir d'espace" est une impossibilité totale. XYZ est la donne de départ ( sauf tc en D65 à traduire en XYZ D50 dans les docs, à voir selon ).

C'est donc l'option de rester en XYZ chez Coffin, indiquée dans le papier.
Une autre est possible, comme dans C1 pour exemple, avec une primo projection en un espace court pour faire les balances*, c'est le "no-correction" inclus dans le logiciel. C'est la seconde option du papier pdf. Elle est plus précise en crète des gris d'apres cette étude.

Naturellement, très loin de cela, on applique ensuite un profil LUT de sortie aux raw, bien différents du XYZ ou autre.
* la recommandation de C1 pour admettre des profils créés à la place de leur grand profils externe, est de sortir les chartes dans ce no-correction, c'est la seule façon d'accepter un autre profil externe dans la routine de C1. Certains n'ayant pas compris cela se heurte à des impossibilités. La primo projection est toujours "no-correction" chez C1, et ensuite seulement on peut appliquer notre profil perso par exemple. C'est pourquoi on doit imprimer le no correction, et l'analyser, pour correspondre au premier travail de C1 et poursuivre les taches.i]

jdc · Février 13, 2009, 14:05:40

Je viens de mettre à jour mon site avec 2 évolutions de ma version personnelle de Dcraw :
1) possibilité d'agir sur les "niveaux" par la commande -B a b c : 'a' active la commande, 'b' et 'c' permettent d'agir sur le contraste. Ces deux paramètres correspondent au pourcentage de pixels qui après la commande "niveau" seraient supérieurs à 65535 ou inférieurs à 0. (les valeurs sont bien évidemment bornées). Pour 'a' et 'b' des valeurs vers 0.001 donnent généralement des résultats acceptables (à tester bien sûr)

2) ajout d'une possibilité supplémentaire de la bibliothèque LCMS

J'ai modifié en profondeur les paramètres d'accès aux fonctionnalités "LCMS" de Dcraw :

* en maintenant les fonctionnalités prévues par Dave Coffin, activées par -p profil.icc -o espace.icm, qui concernent ce qui est couramment appelé les profils "internes", c'est à dire qui s'appliquent avant l'affectation d'un espace colorimétrique, je n'ai jamais réussi, malgré de nombreux essais, sans gamma, avec gamma, en modifiant ou non la cible des données spectrales et/ou XYZ/Lab, à obtenir des résultats satisfaisants...d'où le choix d'un nouveau processus
* Nouveau processus pour travailler avec des profils d'entrée :
1. élaboration d'un profil ICC d'étalonnage de boîtier :
o à partir d'une mire étalonnée et d'une prise de vue conforme en termes de balance des blancs et d'exposition (voir mon site);
o traiter le raw avec Dcraw_91 avec la ligne de commande suivante : Dcraw_91 -v -A a b c d -o e -4 -T -g 4 -Y 0 1 -y f Mire.raw, ou 'a b c et d' sont les coordonnées de la cellule servant à la balance des blancs, 'f ' le paramètre pour ajuster l'exposition et 'e' le choix de l'espace de construction du profil:
+ après expérience, il vaut mieux choisir pour 'e' 4 (Prophoto) qui préservera au mieux l'ensemble du gamut, mais on peut aussi choisir, sRGB ou AdobeRGb voire '10' sans espace colorimétrique. Dans ce dernier cas, les résultats sont acceptables au lieu de très bons pour Prophoto.
+ élaborer le profil ICC avec le profileur à partir des données spectrales ou XYZ/Lab et du TIIF obtenu précédemment

2. utilisation du profil ICC:
o c'est ici que j'ai modifié Dcraw et LCMS (de manière ponctuelle)...
o On se sert à la fois de l'espace de référence d'élaboration du profil, et de l'espace de travail qu'on choisira. Ligne de commande :
+ Dcraw_91 -w -v -o 4 -4 -T -g 4 -L profil.icc -X output.icm i photo.raw; où:
# 'profil.icc' est le profil d'étalonnage (avec ou sans modifications de type contraste, saturation,...)
# 'output.icm' est l'espace de travail choisi, par exemple AdobeRGB, PhotogamutRGB, Prophoto, sRGB
# 'i' est l'intention : 0=perceptuel; 1 relative; 2 saturation; 3 absolue

3. les résultats sur la mire 'JDC-Rouli' 468 couleurs sont excellents...comparables à ce qu'on obtient avec les logiciels habituels du commerce (DxO, NX2, Photoshop...)

Terapixel · Janvier 19, 2010, 15:19:54

Up !

Jean-Claude · Janvier 25, 2010, 21:16:37

Dommage pour tout ce travail, alors que les conditions de départ ne sont pas correctes !

NX2 est un logiciel qui tient compte de la configuration du boitier qui a pris le NEF et qui ici était config par défaut Nikon si j'ai bien compris les explications !

Le rendu par défaut Nikon est fait pour plaire pour accrocher les regard aussi bien en couleurs, qu'en saturation, contraste et accentuation.
Le Nikoniste averti cale son boitier ou NX2 pour un rendu juste, neutre, avec une dynamique maximale,