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.