7Menu photo

Mise à jour de la page :23 juin 2009

Exécutable dcraw_95op.exe (version 3.56) -

Bibliothèques LCMS 1.18 modifiées.

code Dcraw 8.95 du 9 juin 2009- réalisé avec le compilateur Microsoft -  n'a pas besoin des bibliothèques Cygwin (à tester sous Vista !)

Vers site SFR-Neuf -même page mais à jour

----------------------------------------------

Le code C est disponible pour toute personne qui me le demande (sauf bien sûr le code "protégé").

-------------------------------------

Tutoriel DCRAW (en cours)

-------------------------------------------

Comparaison de divers dématriceurs et divers boîtiers (en cours 2 février 2009)

Version de Dcraw  avec options : (ligne de commande en français)

3.51  3.52 3.53 3.56

3.49 3.50

3.48 et 3.48a

3.46 3.47

3.37

3.25 13 février

3.23 10 février

3.21 4 février

3.00 7 janvier

2.98 5 janvier

2.97 2 janvier 2009

2.95 31 décembre

2.93 et 2.93 a 28 et 30 décembre

2.90  22 décembre 2008

2.88

2.86 - 2.87

2.83  2.84 12 décembre

2.81 6 décembre

2.80 5 décembre 2008

2.75 1 décembre 2008

2.73 28 novembre

2.71 - 2.72a - 27 novembre

2.65  et 2.66 19 novembre

2.55 13 novembre 2008

2.51 - 2.52 - 2.53 - 2.54

2.46  et 2.47 7 novembre 2008

2.20 18 octobre

2.18 16 octobre 2008

2.17 15/10/2008

Version 2.15  puis 2.16 - 14 octobre

Version 2.13 11 octobre

Version 2.12 10 octobre 2008

Version 2.11 9 octobre 2008

Version 2.0 7 octobre 2008

Version 1.94 7 octobre 2008

Version 1.92 6 octobre 2008

Version 1.91 4 octobre 2008

Version 1.88 30 septembre 2008

Version 1.74 22 septembre 2008

Version 1.7 18 septembre 2008

Version 1.5 9 septembre 2008

Version 1.43 7 septembre 2008

Version 1.42 5 septembre 2008.

Version 1.40 puis 1.41 - 4 septembre 2008

Version 1.32 30 août 2008

Version 1.31 24 août 2008

Version 1.30 22 août 2008

Version 1.25 25 juin 18h00

Versions 1.24 24 juin 11h00

Version 1.23a 23 juin 13h30

Version 1.23 22 juin 15h00

Version 1.22 21 juin 18h00

Version 1.21 20 juin 18h00

Version 1.20 20 juin 11h00

Version 1.19 19 juin 14h00

Version 1.18 18 juin 2008 9h00

Version 1.17 17 juin 2008 18h00

Version 1.15 16 juin 2008 14h00

Version 1.13 13 juin 2008 17h00

Version 1.11 12 juin 2008 10h00

Version 1.0 11 juin 2008 15h00

Version 3.52

• mise à jour 8.95 D.Coffin

Version 3.51

• possibilité de régler la précision de calcul du gamma (voir tutoriel Gamma LUT ou pas LUT)

Version 3.50 a

• divers bugs de compatibilité 16 bits, 8 bits, mode JD et mode D.Coffin pour les gamma (a priori) supprimés

Version 3.48a

• suppression du bug général dans gamma

Version 3.48

• accroissement de la compatibilité des 2 modes de gamma (JDC et D.Coffin)

• les fonctions développées par moi même (niveau, espaces,...) deviennent utilisables y compris avec les options D.Coffin -6 et -g 0 <p>

• la commande -g 0 <pente> donne un gamma logarithmique (voir le tutoriel)

Version 3.47

• base Dcraw 8.94 du 16 mai 2009

• ajout de la commande -6 par compatibilité avec la version D.Coffin :

  • -6 : active le mode 16 bits D.Coffin avec gamma; par exemple en entrant -6 -g 2.2 4

  • ce mode rend inactives les fonctions spécifiques que j'aie développées : niveaux(); gamma spécifiques; espaces colorimétriques supplémentaires

  • bien sûr si on entre -4 au lieu de -6 toutes les possibilités "anciennes" sont préservées

• l'ancienne commande -6  a b qui activait "REINFORCE EECI" est remplacée par -9 REINFORCE a b

Version 3.45

• choix algorithme EECI Refine : -6 a b  où 'a' nombre de passes, 'b' algorithme b=0 ou b=1

Version 3.42

• quelques bugs supprimés dans traitement du bruit

Version 3.39a et b et 3.40 3.41

• code plus rapide pour les opérations avec réels (Mode Lab et fonctions associées)

• modifications pour éviter, lorsque gamma=1, l'ajustement automatique des niveaux

• quelques compléments et bug supprimés

• commande -9 "Texte" plus nombreuses élargies à l'accentuation (ACCENT ou SHARP), visualisation des valeurs des pixels (PIXELS), rendus de type portrait, paysage (RENDU ou LOOK), etc.

  • voir l'écran après la ligne  de commande : "draw_93op"

  • voir le didacticiel en cours de réalisation

Version 3.39

• code compatible OpenMP

• possibilité de traiter les images à forte dynamique, c'est à dire qui ont à la fois les hautes lumières surexposées et les basses lumières sous exposées

  • peut être activée en mode RGB  :  -9 DYNR val ou en mode Lab - 9 DYNL val

  • val peut prendre les valeurs 0 1 2 3 ou 4 selon la "force" souhaitée pour traiter les BL : 0 ne fait rien...4 maximum

  • ces 2 commandes :

    • travaillent en mode Prophoto, 16 bits et en sortie TIFF, il n'est donc pas nécessaire d'entrer -o 4 -4 -T

    • ajustent automatiquement les niveaux avec un "contraste" (nombre de pixels qui débordent en dessous de 0 et au dessus de 65535 mis à zéro)

    • utilisent l'interpolation AFD

    • utilisent un gamma LUT de 1.3 afin de préserver les nuances

    • protègent les ultraBL de l'action des commandes BL

    • utilisent par défaut la commande -H 2

    • utilisent la commande BL avec un seuil automatique (en dessous duquel une action BL est réalisée) situé entre 70% et 80% de l'amplitude de l'histogramme réduit par la commande -H et une courbe adaptée

  • exemple : Dcraw_93op -w -v -9 DYNR 2 _dsc2209.NEF

Version 3.37

• quelques fonctions obsolètes supprimées

• code compatible C++ au lieu de C ANSI

Version 3.36a

• bibliothèque LCMS 1.18

Version 3.36

• modification de forme afin de "faciliter" la ligne de commande:

  • du fait que le nombre de commande dépasse le nombre de caractères disponibles (A..Z, a..z, 0..9) sans faire usage des caractères dont le code est supérieur à 128...J'ai "arrangé" une solution acceptable.

  • il suffit d'entrer : -9 <texte> [paramètres], où  -9 est le caractère unique (actuel) de basculement, <texte> une série de commande à passer en clair (attention seule la syntaxe proposée fonctionne en respectant la case (maj/min), et [paramètres] sont les paramètres numériques à passer

  • à ce jour plusieurs commandes sont disponibles

  Commande	Equivalent
  'expose' val : corrige exposition	identique a -y"
  'blanc' val : point blanc <val> 0 ou 1
  'PSD' format de sortie en PSD	identique a -£
  'renforce' <num>: renforce pixels apres interpolation	identique a -6
  'bright16' <num> <num> <num>:	identique a -µ  - commande obsolète
  'rgbmin' <num><num>: active RGB min max	identique a -7
  'gamma' <num>: gamma préétablis	identique a -5"
  'Lab' <num><num><num>: initialise rgb=>Lab=>rgb	identique a -N 2 x x
  'niveaux' <num><num><num>:niveaux histogramme	identique a -B
  'BL' <a b c d e>: relève les basses lumières en mode RGB 16 bits	similaire à -R

Traitement des basses lumières (D-ligting) 

J'ai implanté une commande similaire à -R (amplifie les basses lumières en mode Lab), mais en mode RGB.

C'est la commande -9 BL a b c d  ci-dessus.

• a = amplification de base, valable pour RGB peu différent de zéro ou L (Lab) peu différent de zéro

• b = seuil limite d'action en pourcentage de l'histogramme: 100 % va agir sur l'ensemble de l'histogramme (en 16 bits de 0 à 65535), 60% va agir de 0 à 39320

• c = forme de la courbe  de régression : '0' = linéaire...; c peut varier de 0 à 9 y compris les nombres réels 1.5 est un nombre valide. Plus le nombre est élevé plus l'action sera concentrée sur les basses lumières (voir commentaires plus bas)

• d = seuil de protection des ultra BL, en valeurs L: 1.5 >d> 0 : 0.5 recommandé...

• e = algorithme de calcul de la luminance : O = YIQ, 1 = HSL, 2= R709, 3=Lab  (en mode Lab entrer une valeur 'a' d'amplification un peu plus faible - environ 30%)

Pour le mode Lab, la commande entrée par - N 2 1 x et -R 0 a b c est toujours utilisable...et donc paramétrable à souhait, y compris la façon de gérer la colorimétrie pour les hors gamut (-N 2 1 6 recommandé)

Par défaut lorsqu'on active la commande de traitement des BL (similaire à D-lighting de Capture NX), la commande "niveau" est activée avec '0' et '0' comme pourcentage de pixels qui dépassent 0 et 65535. Si bien que sur des images à fort contraste, on peut lancer une commande de type : -H 2 -9 BL 2 60 1 0.5 0 -g 1.3 3.5 qui automatiquement donnera une image acceptable...Bien sûr on peut modifier...

L'utilisateur pourra remarquer la supériorité évidente de l'algorithme Lab sur les autres (YIQ, HSL, R709). Par défaut lorsqu'on entre pour 'e' = 3, la commande -N 2 1 6 est activée ainsi que "niveau" avec '0' et '0' pour le contraste. Cette supériorité peut se voir :

• en examinant l'histogramme avec 'histogrammar': la version Lab est nettement plus propre

• en examinant une mire de référence. Dans le cas de Lab l'algorithme essaye au mieux de maintenir les teintes en jouant sur la chromaticité et la luminance. Dans le cas des algorithmes RGB, ceux-ci sont incapables (du moins dans la version que je propose) d'assurer un gestion des couleurs sinon par "cliping", ce qui se traduit par des dérives d'autant plus importantes qu'on s'éloigne des couleurs neutres ou grises.

• néanmoins l'algorithme Lab consomme du temps (quelques secondes supplémentaires) et de la mémoire.

• sur les cas courants, l'algorithme RGB YIQ donne d'assez bons résultats.

Comparaison de quelques couleurs avec traitement des BL

(traitement fait en Prophoto)

Ces quelques exemple montrent la supériorité de Lab.. Naturellement cet essai est (un peu) faussé dans la mesure où j'ai choisi un espace très large (Prophoto)...Avec un espace plus petit, un grand nombre de valeurs sortent du gamut... et sont notamment (très) mal gérées par l'algorithme RGB.

Comparaison des histogrammes (pour les très basses lumières)

En mode RGB:

et en mode Lab

Autres modifications

• la commande -V  a  b c d qui affiche les valeurs rgb et lab n'est plus buggée

• la commande -N 2 1 1 ou -N 2 1 2 peut prendre une autre option de colorimétrie - 2 6 qui assure un traitement similaire à -N 2 1 6 mais produit un fichier "horsgamut.txt"

Version 3.35

• modification de la commande "niveau"

• elle n'agit qu'en 16 bits

• par défaut elle met le contraste , traduit en % de pixels qui dépassent 65535 à 0.001 et qui sont en égaux ou inférieurs à 0 à 0.0001

• pour désactiver il faut entrer -W

• deux options sont possibles :

  • -B 0 a b  : remplit complètement l'intervalle 0..65535 avec l'histogramme  'a' et 'b' sont les pourcentages de dépassement (comme ci-dessus), en entrant 'a' et 'b' = 0 l'histogramme remplit sans déborder l'intervalle 0..65535

  • -B 1 a b : ne remplit pas complètement l'intervalle 0..65535, mais laisse 'a' et 'b' pourcent des 2 intervalles , respectivement entre 0 et le début de l'histo et entre la fin de l'histo et 65535.

    • -B 1 0 0 remplit l'intervalle comme -B 0 0 0

    • -B 1 1 1 est similaire à -W et laisse inchangé l'histogramme.

Version 3.31 et 3.33

• prise en compte de la version 8.92 de Dcraw, puis 8.93

• D.Coffin a notamment modifié les fonctions gamma: afin de rendre compatible son code et le mien..j'ai un peu "bricolé"

• l'ancienne fonction de Dcraw_91 -g qui pouvait prendre comme paramètre des entiers de 0 à 9 ou des réels comme 2.2 est remplacée par -5 plus les mêmes valeurs

• exemple : -g 4 est remplacé par -5 4 ; -g 0 est remplacé par -5 0

• la nouvelle fonction -g <a b> de D.Coffin implémentée en 8 bits dans sa version de Dcraw est utilisable en 8 bits et 16 bits

  • exemple -g 2.22 4.5  (qui en fait correspond à l'ancien -g 4  et au nouveau -5 4) va se traduire en 16 bits par l'équivalent de la commande -5 4 qu'il n'est pas utile d'entrer

  • exemple -g 2.4 12.92  est l'équivalent de -5 0

• on peut donc soit entrer les anciennes valeurs préétablies  de 0 à 9  : -5 4 ; -5 0; -5 7; soit entrer les valeurs par -g  <a b>

• de plus j'ai simplifié le gamma TRC  qui auparavant prenait deux paramètre -Y <a b>; le premier 'a' est directement calculé; seul le second 'b' facultatif qui modifie la valeur de base est encore utilisable

• pour avoir un rendu linéaire : - 5 1

• J'ai également fait par compatibilité quelques modifications mineures d'appel des fonctions rares...(voir la ligne de commande)

Version 3.30

• réincorporation bibliothèque 1.17 (1.18 a priori buggée)

• quelques modifs LCMS (me contacter)

Version 3.28

• incorporation des bibliothèques LCMS 1.18

• modification de LCMS pour améliorer le traitement en cas d'étalonnage du boîtier : processus dit "externe" (après conversion RGB)

• me contacter si vous êtes intéressés.

Version 3.25

• modification d'une option à la commande "niveau", où par ailleurs l'algorithme est plus performant

  • si vous entrez pour b et c des valeurs comprises entre 0.1 et 1.0, le contraste sera accru, mais en préservant une marge. Par exemple si les maxi et mini de l'histogramme avant "niveau" sont 45000 et 21000, au lieu de porter ces valeurs à 65535 et 0, le coefficient entré entre 0.1 et 1, amènera les maxi et les mini à des valeurs comprises entre 0 et 21000 pour les mini et entre 45000 et 65535 pour les maxi.

• 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 satisfaisant...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 :

       • à 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);

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

       • c'est ici que j'ai modifié Dcraw et LCMS (de manière ponctuelle)...

       • 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...et également et comparables à ce qu'on obtient avec les logiciels habituels du commerce (DxO, NX2, Photoshop...)

     

Version 3.23

• possibilité de modifier les "niveaux": à noter que la modifications maintien l'équilibre des couleurs. Seul le canal "luminance" est affecté (c'est un choix).

• l'opération s'effectue après la conversion RGB et le gamma

• vous pouvez entrer 2 coefficients qui dans chaque cas correspondent au pourcentage de pixels :

  • qui dépasseront la valeur RGB=65535 pour les HL

  • qui seront en dessous de RGB=0 pour les BL

  • des valeurs de l'ordre de 0.001 soit pour un capteur de 10M° = 1000 pixels sont généralement acceptables et accroissent le contraste apparent sur les images "ternes".

  • si on met 0 pour les 2 paramètres, les histogrammes colleront à zéro pour les BL et 65535 pour les HL

• commande : -B a b c

  • a= 1 active la fonction

  • b= pourcentage pour les HL

  • c=pourcentage pour les BL

Version 3.22

• Code version 8.91 du 4 février, D.Coffin

Version 3.21

• bug -qui rendait l'appel des fonctions LCMS dans la version compilateur Microsoft - supprimé

• légère modification du coefficient -Y 0 b  : par défaut b=1.0 produit le même rendu qu'auparavant avec 1.064

Version 3.17 à 3.20

• bug gestion mémoire retiré par D.Coffin dans "Wavelet Denoise"

• code Dcraw 8.90 du 15 janvier 2009

• modifications de détails

• option -u <a b c d e f> modifiée en supprimant 'c' 'limitation du bruit'

Version 3.16

• petit bug retiré...dans la commande -u

• simplification (?) des commandes. J'ai supprimé la troisème option du Laplacien (seuil) et ajouté cette option à -8

• Laplacien devient :

  • -E a b : a type de Laplacien; b: nombre de passes

• la commande -8 devient celle des options "rares", celles qui m'ont permis d'optimiser...et que on peut changer si on le souhaite

  • -8 a b c d : a : multiplicateur seuil VCD par défaut 1; b: multiplicateur seuil AHD par défaut 1; c : nombre de passes hybrid par défaut 2; d= seuil Laplacien en % par défaut 100

Version 3.14

• code de D.Coffin 11 janvier : 8.90

• option de -u a b c d e f : f peut prendre les valeurs 8 9 et 10 : 8 filtre hybride seul pour VCD, AHD, AFD

• quelques réglages (un peu) différents

Version 3.11

• quelques modifications de détail

• prise en compte du code de D.Coffin de début janvier 2009

• et j'espère pas de bug...dans les transcriptions, car le code de D.Coffin n'est pas commenté...(ou si peu)

Version 3.00

• intégration des dernières modifications de Paul Lee et Manuel LLorens : AFD, VCD, Es_median_filter, AHD qui sont un peu plus performants

• suppression du bug pour "débruitage par ondelettes" et "aberrations chromatiques"

• apparition d'un premier débruitage pour AFD noise : réduction du bruit chromatique par filtre hybride , optio supplémentaire pour -u

  • -u a b c d e f : a b c d e inchangés, f peut prendre la valeur supplémentaire 8 ou 9 - 8 avec median 3x3 et 9 avec median 5x5

Version 2.98

• possibilité accrue des 4 "median" et "edge-sensitive" : il est possible en plus de leur position habituelle, cad juste après l'interpolation, de les mettre en oeuvre après l'accentuation si on constate des artefacts.

• pour les activer, il suffit d'ajouter +5 à la commande initiale, par exemple

  • -m 2 1 active un filtre median différentiel 3x3; -m 7 1 activera ce même filtre juste après l'interpolation, puis après l'accentaution

  • -E 1 1 100 active un Laplacien 3x3; -E 6 1 100 active ce même Laplacien juste après l'interpolation, puis après l'accentuation

• quelques paramètre internes de l'accentuation ont été légèrement modifiés pour la protection des valeurs RGB > 65535

Version 2.97

• ajout d'une interpolation expérimentale de Paul Lee VCD + AHD

• -q 8 avec en option un seuil AHD qui est par défaut à 8, mais réglable par -8 <a b> : 'a' multiplicateur seuil VCD (inchangé par défaut 1) et 'b' seuil AHD partiel. J'ai mis en q 14 l'interpolation 'zone de couleur'

Version 2.95 - 2.96

• Bug signalé par P.Lee dans un "median 3x3" supprimé

• modification du seuil par défaut de VCD mis à 1.36 au lieu de 2: de mon point de vue un peu moins d'artefacts dans certains cas..D'où le coefficient pour le modifier éventuellement qui change pour l'intervalle [1..1.6]

• ajout des versions modifiées par P.Lee de AHD et PPG

• les anciennes versions sont toujours appelables et portent l'appellation AHD2 ou PPG2 -q 11 ou -q 13...ou -q 12 pour AFD+AHD. Ces anciennes versions sont les seules à supporter les fonctions RGBMIN ...dont l'intérêt se limite

• ajout des fonctions RGBMIN aux "median" différentiels

• quelques détails...

• ...

Version 2.92 - 2.93

• Prise en compte des dernières modifications de Paul Lee

  • Interpolation VCD meilleure qu'auparavant

  • Filtre Laplacien pour réduire les moirés et les aliasing efficace et qui ne crée plus d'artefacts : "Es_median_filter"

  • filtre median differentiel pour réduire les artefacts de couleurs

• J'ai un peu aménagé ces options...

• les possibilités d'utiliser RGBMIN et RGBMax ont été réduites (elles créaient dans certains cas des artefacts), elles sont maintenant limitées à une option -7 1 x (x variant de 5 à 21) qu'il faut déclarer pour quelle soit prise en compte. Elle ne sert plus que dasn AHD, PPG et filtre median 'normal' -m 0 x ou -m 1 x

• Pour l'option VCD j'ai maintenu la possibilité de faire varier le seuil, par défaut ce seuil vaut T=2.0, mais on peut le faire varier par un multiplicateur 0.68 à 1.1...Ces changements peuvent amener un rapport signal sur bruit plus faible (ou plus élevé) et un DeltaE plus faible ou plus élevé : -8 mult

• L'option 'renforcement' des pixels ' "EECI Refine"  est inchangée, même si le code C l'est un peu: -6 <n>

• Le filtre Laplacien qui peut réduire le moiré et l'aliasing  peut prendre les mêmes options qu'auparavant - E a b c  (voir plus bas)

• Paul Lee a introduit un nouveau median dit différentiel 3x3, je l'ai complété par un median différentiel 5x5 : -m 2 x ou -m 3 x et maintenu les median de D.Coffin -m 0 x et J.Desmis -m 1 x

• j'ai ajouté une interpolation mixte : AFD+VCD - q 10

• Les résultats sur les images tests sont un peu améliorés

Version 2.90

• j'ai fait un essai ce jour 22 décembre 2008, de NEF du D3x.. et oh miracle même si ce boîtier n'est pas prévu..cela fonctionne.. J'ai testé avec les mêmes réglages un D700 et un D3X à 6400 ISO..The winner is D3x...mieux en définition et sensiblement pareil, voire moins en bruit (l'image choisie sur "image ressource" est NOISE Reduction OFF).

• après observation des remarques faites par 'Lassus' sur OjoDigital où il a modifié le code C, j'ai procédé à quelques modifications qui s'avèrent excellentes en s'inspirant des principes énoncés:

• toutes ces remarques concernent l'interpolation

• possibilité de changer les références du calcul RGBMIN et RGMAX (origine Paul Lee) qui par défaut concernent une cellule 7x7: on peut entrer 5, 7, 9, 13...21. Bien sûr le temps de traitement augmente mais la qualité de l'interpolation notamment la diminution des artefacts est importante. Pour activer cette fonction

  • -7 1 <val>  : 1 active la fonction, <val> = 7 par défaut... 13 convient très bien : -7 1 13

• possibilité de renforcer les pixels interpolés après la première interpolation. Cet algorithme présent dans VCD de Paul Lee est maintenant utilisable avec toutes les interpolations, notamment AHD. On peut également déterminer le nombre de passes. Cet algorithme minimise le bruit et réduit les artefacts

  • -6 <n> : -6 4

• ces 2 dispositifs sont valables pour toutes les interpolations et réduisent les artefacts aussi bien en ISO élevés  (3200 et plus) qu'en ISO bas (200...)

• il est bien sûr possible de combiner les interpolations et paramètres divers :

  • -q <0...9> : type d'interpolation

  • -u <a b c d e f> se fonde sur AFD pour détecter et réduire le bruit

  • -7 1 <val>: détection des valeurs mini et maxi RGB dans une cellule WxW - à noter que VCD, AHD et PPG optimisent l'utilisation de cette détection

  • -6 <n> : boucle de renforcement des pixels interpolés

  • -m a b : filtre median RV - BV de type 3x3 ou 5x5 : réduit les artefacts de couleurs

  • -E a b c : filtre median 3x3 ou 5x5 + Laplacien : réduit (?) les artefacts et minimise le bruit...

• Par exemple -q 3 -7 1 13 -6 4 -m 0 2 donne d'excellents résultats pour des images en bas ISO, de mon point de vue nettement supérieurs à NX2, ACR, DXO53...(sur une image test de D700 à 200 ISO chargée sur "image ressources")

Version 2.88

• peu de changements sinon la commande -u qui "perd" l'option seuil VCD

• j'ai ajouté l'option -8 : seuil VCD

  •  -8 <val>

  • avec <val> à mettre entre 0.8 et 2

• j'ai aussi introduit une nouvelle compilation, avec le compilateur Microsoft...je n'ai pas le moyen de vérifier s'il fonctionne sous Vista

Version 2.86

• peu de modifications de fond...mais j'essaie de rendre les commandes des diverses interpolations et filtres (un peu) moins obscures

• les commandes d'interpolations inchangées

• -q :

  • 0 = bilinéaire

  • 1 = VNG

  • 2= PPG

  • 3= AHD

  • 4= bilinéaire 4 couleurs

  • 5 = AFD

  • 6 = AFD+AHD

  • 7 = Pixel Shift

  • 8=  Zone de couleurs

  • 9 = VCD

• le paramètre -u qui ajoute des phases à  l'interpolation ou la complète en agissant principalement sur Noise AFD, mais aussi AFD seul

  •  -u abcdef

    • les paramètres a b et c peuvent s'appliquer à l'ensemble des interpolations et agissent en amont de l'interpolation principale

      • a = active la fonction a=1

      • b= détecte le bruit 0.100

      • c= enlève le bruit 0.100

    • les paramètres d et e ne concernent que AFD ou VCD

      • d= niveau de luminance 0 2 3 = par défaut 2  - AFD seul  (ou VCD seul dans ce cas modifie le seuil (2 par défaut  amène le seuil à 1.366 ; 1=1.26  3=1.97) - supprimé dans version 2.88)

      • e= luminance seule e=1 - AFD seul

    • le paramètre f peut selon sa valeur être spécifique à AFD ou commun à toutes les interpolations

      • f=1 - toutes interpolations - agit sur Noise AFD - en amont des autres , il met en place un filtre passe bas plus doux que celui d'origine

      • f=0 ou f=2 - toutes interpolations - agit sur Noise AFD - met en place un filtre median "map de texture" réducteur de bruit 3x3

      • f=3 - toutes interpolations - agit sur Noise AFD - met en place un filtre median"map de texture" réducteur de bruit 5x5

      • les option suivantes sont de mon point de vue à n'utiliser que si on ne peut faire autrement...(absence de produit type Noise Ninja...)

      • f=4 - AFD seul - met en place un filtre median  réducteur de bruit global  3x3

      • f=5 - AFD seul - met en place un filtre median  réducteur de bruit global  5x5

      • f=6 - AFD seul - met en place un filtre median  réducteur de bruit global  3x3 et utilise le filtre passe bas plus doux

      • f=7 - AFD seul - met en place un filtre median  réducteur de bruit global  5x5 et utilise le filtre passe bas plus doux

• le filtre -E combiné median + Laplacien qui vise la suppression des artefacts

  • a= 1 active le filtre median 3x3 + Laplacien 3x3 de type "-4" - conforme à l'algorithme de Paul Lee

  • a= 2 active le filtre median 5x5 + Laplacien 3x3 de type "-4" - ajout de ma part - conforme à l'algorithmes des auteurs

  • a= 3 active le filtre median 5x5 + Laplacien 3x3 de type "-8" (plus fort) - ajout de ma part

  • b = nombre de passes - si b=0, le filtre 7x7 est activé, les interpolations AHD et PPG prennent en compte cette information

  • c= seuil pour le Laplacien en %; par défaut 100%..peut varier en théorie de 1% à 1000%...ajout de ma part

De mon point de vue, ce qui donne le meilleur résultat sur des images très bruitées (Image de D700 à 25600 ISO)

 -q 6 -6 15 -7 1 21 -m 0 15  -y 1.3 -u 1 5 90 2 0 3 ...puis un complément avec un produit spécialisé "bruit" de type Noise Ninja (avec un réglage a minima) ...l'ensemble donne un rendu un peu supérieur à DxO5.3 qui présente un plus d'artetacts et que Capture NX2 qui dénature un peu trop le chromatisme.

Version 2.83 et 2.84

• 2.84 bug retiré dans AHD..qui donnait des teintes vertes...

• prise en compte des modifications de Paul Lee aussi bien pour l'interpolation VCD que pour le median Laplacien

• j'ai quelque peu modifié l'appel des options

• -m  a b

  • ne peut prendre que 2 possibilités 0= median 3x3  1=median 5x5

  • à noter que si l'option VCD est prise ou l'option Laplacien, ces 2 filtres ont un algorithme légèrement différent

• -E  a b c

  • j'ai ajouté cette option afin de la rendre "compatible" avec celle de la version de Dcraw de P.Lee

  • (a = 0 - n'active pas le filtre RGB min et max = gain de temps et d'occupation mémoire)

  • a= 1 active le filtre median 3x3 + Laplacien 3x3

  • a= 2 active le filtre median 5x5 + Laplacien 3x3 - ajout de ma part

  • b = nombre de passes

  • c= seuil pour le Laplacien en %; par défaut 100%..peut varier en théorie de 1% à 1000%...ajout de ma part

  • à noter que si a est différent de 0, les algorithmes de l'interpolation AHD et PPG sont légèrement modifiés.

Version 2.81 et oubli de ma part (11 décembre 2008)

• Paul Lee a modifié le code de VCD et du filtre median+ Laplacien...j'ai moi même apporté un complément

• De plus pour "faciliter" l'utilisation les 2 options -m et -u sont utilisables avec toutes les interpolations

• - m peut prendre 4 options :

  • -m 0 : filtre median 3x3 (origine)

  • -m 1 : filtre median 5x5 (J.D)

  • -m 2 : filtre median 3x3 +  Laplacien (P.Lee)

  • -m 3: filtre median 5x5 + Laplacien

• et -u abcdef

  • a = active la fonction a=1

  • b= détecte le bruit 0.100

  • c= enlève le bruit 0.100

  • d= niveau de luminance 0 2 3 = par défaut 2  - AFD seul

  • e= luminance seule e=1 - AFD seul

  • f = option complémentaire : défaut=0 - 1 = passe bas plus doux (AFD)  2=median carte de texture 3x3 3= median carte de texture 5x5  4 = comme 2 plus median 3x3 (AFD)  5=comme 3 plus median 5x5 (AFD)

• oubli de ma part :

  • j'ai simplifié l'accès aux diverses interpolations, mais j'ai oublié de le mentionner...(c'est sous entendu avec l'option -u) et présent dans l'aide de la ligne de comande

  • -q :

    • 0 = bilinéaire

    • 1 = VNG

    • 2= PPG

    • 3= AHD

    • 4= bilinéaire 4 couleurs

    • 5 = AFD

    • 6 = AFD+AHD

    • 7 = Pixel Shift

    • 8=  Zone de couleurs

    • 9 = VCD

    avec ces différentes interpolations on peut faire l'usage (je n'ai pas tout vérifié) de -u et -m

Version 2.80

• j'ai introduit 2 nouveaux algorithmes d'interpolation

  • -q 11 : area_color

  • -q 12 : interpolation VCD de P.Lee. Cette interpolation se "marie" avec un filtre median et Laplacien adapté :

    • -m 2 x   : x = nb de passes

• j'ai mis à jour AFD avec les dernières modifications de M.LLorens

• pour toutes les interpolations il est possible d'utiliser le filtre median et laplacien

• à noter que la commande de débruitage par ondelettes "-n x" ne fonctionne pas avec AFD

Version 2.77

• vues les incompatibilités de caractères rencontrées avec Linux... J'ai changé l'appel de certaines fonctions..en utilisant toutes les lettres de notre alphabet, plus quelques chiffres

  •  u remplace £

  • G remplace %

  • O remplace @

  • Q remplace µ

  • R remplace [

  • V remplace $

  • 1 remplace ]

  • 2 remplace #

  • 3 remplace ç

  • et 5 convertit la sortie en PSD

  Bien sûr cela change...mais c'est comme tout on s'y habitue

Version 2.75

• M.LLorens m'a adressé des changements et ajouts de code pour l'interpolation

  • amélioration (légère) de AFD

  • interpolation mixte AFD - AHD

  • interpolation "pixel shift" : très rapide, peu génératrice de bruit, mais qui altère les couleurs...

   

  • de plus j'ai mieux "intégré" (et je pense un peu) facilité les commandes AFD-Noise

  • dorénavant les commandes sont les suivantes :

  • -q <0..10>

    • avec

    • q=0 biliniéaire

    • q=1 VNG

    • q=2 PPG

    • q=3 AHD

    • q=4 bilinéaire 4 couleurs

    • q=5 AFD

    • q=6 AFD Noise

    • q= 7 AHD Noise

    • q=8 AFD+AHD

    • q=9 AFD Noise + AHD

    • q= 10 Interpolation "pixel Shift"

  • et les compléments AFD et  Noise qui s'activent par

  • -£ a b c d e

    • a et b : seuil détection du bruit  et réduction du bruit

    • c: passes de luminance = 2 par défaut, essayer 0 ou 1..

    • d: luminance seule = 0 par défaut

    • e : peut valoir 0 2 3 4 ou 5

      • =0 pas de filtre median

      • =2 filtre median 3 x 3  "map de texture"

      • =3 filtre median 5 x5 "map de texture"

      • =4 comme 2 + débruitage total (chroma + luminance) par median 3x3

      • =5 comme 3 + débruitage total (chroma + luminance) par median 5x5

Version 2.73

• nouvelle version de Dcraw de base (D.Coffin) : 8.89 avec nouveaux boîtiers dont EOS5D MKII, G10, 50D, etc.

Version 2.71 - 2.72

• pas de "révolution" sinon un suivi dans le rapport à l'écran à l'exécution de DCraw...:

  • des incidences des réglages notamment du contraste (force et seuil) qui peut être très destructeur

  • pour les opérations demandées (contraste, luminosité...), je limite volontairement (avant conversion rgb) les valeurs de L à 0..100

  • j'indique aussi le nombre d'itérations pour réintégrer le gamut

  • etc.

  • tout ceci vise à guider l'utilisateur pour régler au mieux...sans trop sortir du gamut (ou mieux ne pas sortir du tout) afin d'éviter les aplats, dérives de couleurs,...

• 2.72 : l'option -N 2 x 1 -# 5 produit un fichier texte : "horsgamut.txt".. qui reprend les valeurs Lab (avant gamma), les coordonnées des pixels concernés..et la valeur du hors gamut (0...65535).

Version 2.70

• introduction d'un filtre median RGB en plus de celui déjà présent

• on peut soit activer en filtre 3x3 (9 pixels) ou 5x5 (25 pixels) : le second est bien sûr plus lent d'environ 4 fois...

• la version d'origine est 3x3

• en théorie plus on accroît la dimension du filtre, plus on gagne en "douceur" pour réduire les artefacts

• commande -m a b

  • a = 0 : 3x3

  • a=  1 : 5x5

  • b= nb de passes...

Version 2.65 - 2.66...+  2.68

• bug retiré dans contraste...2.68

• bug retiré en colorimétrie relative

• bug retiré dans les fenêtres multiples

• plus de possibilités pour colorimétrie relative : -# peut être à 4 ou 5  : 4 plus "précis", 5 plus rapide (très peu d'écarts entre 3 4 et 5)

• possibilité de baisser la chromaticité pour réduire le bruit

  • -ç a b c

    • a = numéro de fenêtre

    • b=  seuil en luminance en dessous duquel la chromaticité sera réduite

    • c : % de baisse de chromaticité

Version 2.62 et 2.63

• introduction d'une "mini" gestion des couleurs

• avec -N 2 x 1 ou -N 2 x 2

• compléter par -# a

  • a = 0 laisse comme tel

  • a= 1 Clip => colorimétrie absolue

  • a= 2 remplace par anciennes valeurs (avant modifications souhaitées)

  • a= 3 colorimétrie relative - agit pour l'essentiel sur la chromaticité pour "entrer" dans le gamut (le traitement peut être un peu plus long)

  • recommandé sauf en debugage - # 3

• 2.63 : correction d'un bug (petit ??)..certes la colorimétrie relative "fonctionne", mais le processus a oublié de traiter une partie des données normales = corrigé...

• 2.63 : ajout des option -N 2 x 6 et -N 2 x 7 : qui font la même chose que -N 2 x 1 ou -N 2 x 2 avec -# 3

Version 2.60

• j'ai trouvé un bug de l'environnement "cygwin"... qui par calcul attribuait aux très faibles valeurs de L ...des valeurs négatives. Ce bug est résolu...

• dorénavant - ce qui n'exclue pas les hors gamut - les images pour les valeurs L < 1 sont nettement plus propres...

Version 2.55

La version 2.54 présente un très gros bug...

La "correction" du hors gamut est délicate... quoi faire ? (au delà des bugs de programmation).

Je propose la démarche suivante:

• lorsqu'on se sert de -N 2 x y , seule les options -N 2 x 1 et -N 2 x 2 vont permettre de traiter le gamut spécifiquement. Les autres paramètres gardent leurs caractéristiques précédentes (avant les version > 2.50)

• par défaut tous les paramètres qui vont suivre sont à zéro

• la commande nouvelle

  • -# a b c d e f g h

  • cette commande est à associer avec -N 2 1 1 par exemple

  • pour les basses valeurs rgb (je ne dis pas BL, car le hors gamut peut être partout : lorsque je vérifie avec ma mire 468 couleurs où j'ai volontairement exagéré contraste et saturation ce sont des couleurs vers L=75 a=-11 b=-23 qui demandent les plus gros correctifs), on utilisera les paramètres 'a' 'b' et 'c' respectivement pour les canaux rouge, vert et bleu. par exemple en réglant 'b' sur 500 on "récupèrera" les valeurs 'g' jusqu'à g=-500 en le ramenant à 0 . je pense qu'il ne faut pas dépasser zéro' et laisser un peu de négatif

  • pour les hautes valeurs rgb (je ne dis pas HL, car le hors gamut peut être partout), on utilisera les paramètres 'd' 'e' et 'f' respectivement pour les canaux rouge, vert et bleu

  • le paramètre 'g' permet de décaler le gamut globalement (je n'aime pas)  : l'intervalle [0..65535] devient [g... 65535-g]

  • enfin le dernier paramètre laisse 3 choix à l'utilisateur :

    • h= 0 - l'image reste comme telle avec d'éventuels dépassements de gamut (visibles)

    • h=1 -  en fonction des nouvelles valeurs entrées en (a..f), ce qui excède sera "clipé"

    • h=2 -  en fonction des nouvelles valeurs entrées en (a..f), ce qui excède se verra attribuer les valeurs 'rgb' initiales du capteur.

• quelles paramètres et valeurs : en examinant l'histogramme on verra ce qui "déborde", le canal bleu par exemple, pour les valeurs inférieures à 0.

   

Version 2.54

• après réflexion sur le dépassement de gamut, j'avais plusieurs possibilités en termes de gestion des couleurs. Dans l'esprit de Dcraw (et de Perfectraw) de laisser totalement la main à l'utilisateur, j'ai modifié l'approche de la version 2.53. Plutôt que de borner l'espace par  une valeur arbitraire et pour tenir compte des différents gamma (variables,...), et des différents TRC...Je propose la démarche suivante.

• 1) j'ai réduit le réglage par défaut à rgb=100 ce qui veut dire que tout ce qui est au-dessus de 100 et en dessous de 65435 sera laissé comme tel en fonction du choix proposé par -N 2 x y

• 2) je propose, si bien sûr on soupçonne un dépassement de gamut, où qu'on veuille le voir, d'utiliser l'option "-N 2 1 1 reglage", avec réglage la valeur entrée jusqu'à obtenir (si bien sûr on le souhaite) la suppression du hors gamut. Ce 'réglage' par exemple 150 va permettre ensuite, en fonction du choix -N 2 1 0 reg ou  -N 2 1 9 reg ou etc. d'avoir le résultat voulu

• Nota : j'ai arbitrairement choisi la même valeur 'reg' pour les basses valeurs 'rgb' ou les hautes valeurs 'rgb' (le dépassement de gamut étant le plus souvent dans les basses valeurs... ce qui ne veut pas dire obligatoirement basses lumières). Bien sûr je peux changer cette façon de faire...

Version 2.53

• J'ai ajouté un paramètre à la commande -N a b c d : 'd' - celui-ci autorise l'utilisateur à modifier la gestion des couleurs (cas où c vaut 4 , 5 ou 9) en instaurant un seuil (en valeurs 16 bits) en deçà duquel les valeurs rgb initiales ont conservées. Par défaut si vous entrez d='0', cette valeur sera à 500 (soit environ rgb=2  dans l'intervalle [0..255]). On peut entrer n'importe quelle valeur comprise entre 0.01 et 5000

• j'ai incorporé un nouvel algorithme (plus rapide) de traitement du gamma, mis au point à l'occasion d'un (petit) problème de Perfectraw. Il fait gagner environ 1.5 secondes de temps de traitement pour un résultat quasi identique.

Version 2.51

• j'ai modifié, homogénéisé les paramètres "accentuation" (tout le reste est identique)

  • -µ 'a'.... : 'a' peut valoir 1 2 3 ou 4. Cette option "marque" plus ou moins les pixels - elle est différente de l'option "force"

    • 1 = doux

    • 2 = normal

    • 3 =  fort

    • 4 = très fort

• j'ai aussi intégré la possibilité de "débruiter" l'option AHD (avec la même procédure que pour AFD):

  • -q 7  = AHD Noise

  • la commande -£ est opérationnelle, mais seuls les paramètres 'a' (détection du bruit) et 'b' (réduction du bruit)  sont pris en compte

• quelques commentaires sur les options AFD :

  • le paramètre -£ 'c' : passes de luminance vaut 2 par défaut. Selon les auteurs de rares images peuvent nécessiter 'c' = 1 ou 3

  • si on utilise l'option "AFD  - AFD Noise ou AHD Noise" il ne faut pas utiliser l'option -n xx (débruitage par ondelettes") qui amènera des artefacts colorés.

  • les essais réalisés par M.LLorens amènent des réglages de -£ 'a' 'b' du type 'a'=10 à 30 et  du type 'b'=70 à 95

Version 2.50

• Introduction de l'algorithme d'interpolation AFD

  • origine Lian Naixiang, Chang Lanlan and Prof. Tan Yap Peng. et interprété par Manuel LLorens

  • j'en dirais plus , mais..:

    • ligne de commande

    • AFD seul : -q 5

    • AFD noise : -q 6

    • options -£ a b c d : a :seuil de bruit (0 100), b: réduction bruit (0 100), c=passes de luminance (0..3)  défaut =2, d: luminance seule =1 défaut =0;

• j'ai changé (un peu) les paramètres de -µ (accentuation) et il y a 5 algorithmes 1 2 3 4 5 .. avec 1 et 2 plutôt pour les petits rayons (2 + fort)

Version 2.46 et 2.47

Peu de modifications, sinon la possibilité pour l'utilisateur d'utiliser 3 algorithmes de convolution légèrement différents.

Le premier, par défaut a=1, est celui de base.

Les second, troisième et quatrième donnent progressivement (un petit peu) plus de poids aux pixels extérieurs à la matrice (7x7 dans ce cas au lieu de 5x5) et donc un peu moins au centre. Ces 3 algorithmes "devraient" être un peu plus appropriés pour les rayons plus élevé et le '1' pour les très faibles rayons.

Ces 4 options se commandent par le premier paramètre 'a' : a = 1  2  3 ou 4.

J'ai aussi introduit un "rayon" de 0.375 !

Remarque importante: l'accentuation proposée dans ce produit (Dcraw) ne vise pas à résoudre les problèmes d'impression ou de fabriquer des effets spéciaux. Son objectif, c'est de profiter du fichier brut (avant conversion RGB et gamma) pour (re)donner à l'image un rendu voulu, sans faire monter le bruit, après les traitements d'interpolation...ou pour (re)donner à l'image ce que le photographe avait initialement réglé sur son boîtier et que le logiciel (ici Dcraw) ne sait pas interpréter. En ce sens sont à privilégier:

• les faibles rayons 0.5 - 1 ou 1.5

• le travail en 1 passe

• des niveaux de "force" réduits : 10 à 70

• la prévention par absence de traitement des BL et des HL : L > 3 ou 5

• juste ce qu'il faut pour traiter les aplats (détails) et éviter les images granuleuses : L=1 à 3

• ...

Version 2.45

• Algorithme de convolution différent

• algorithme rapide différent qui amène sensiblement les mêmes résultats que l'algorithme "lent"

• aucun décalage de pixel n'est effectué (voir plus loin)

• je pense résultats meilleurs : surtout une image plus précise.

  De mes premiers essais (que je publierais..) résultats au moins égaux à ceux de Photoshop et supérieurs à ceux de ACR. J'ai fait des tests sur des crops 600% afin de voir et mesurer les pixels (en 16 bits). L'image choisie est volontairement difficile avec une transition "oblique" entre un ciel et une montagne de calcaire à Pamukkale (Turquie). J'ai choisi une image réelle plutôt qu'une mire car il y a plus d'incidences réciproques des pixels entre eux. La transition n'est pas "simple" (du clair au foncé) mais multiple. Pour l'instant (6 novembre), j'ai testé plus de 15 transitions de 9 pixels - toujours les mêmes - pour des rayons de 0.5 et 3 et pour différents réglages : force, filtres, rapidité, aplats,...

  • la commande "aplat" est mise par défaut à L=2 et n'amène pas d'écarts sur cette transition complexe selon que la commande est activée ou non - sinon pour des valeurs très importantes L=10 ou 15.. Par contre elle adoucit les ciels et les zones lisses ou presque lisses (en fonction du réglage)

  • la commande vitesse qui est mise par défaut sur "rapide" n'amène pas (ou très peu) de différences mesurables

  • j'ai fait les comparaisons avec ACR et Photoshop en tâtonnant pour ces deux produits  pour trouver les réglages proches afin d'obtenir des résultats comparables

  • les images sont toujours propres, très semblables... (en crops 600%), si Photoshop travaille en mode normal la qualité des couleurs est inférieure, si on travaille en mode fusion "luminosité" les résultats sont quasi identiques (aux petits écarts de réglages près..)

  • bien sûr il faut "apprendre"  à se servir des paramètres qui sont différents de ceux des autres produits.

  • à suivre.

• ligne de commande actualisée

• -µ a b c d  e f  g h i

  • a : active la fonction  1

  • b: nombre de passes, 1 à 2 recommandées

  • c: rayon-contraste,  0.5 ou 1  ou 1.5 ou 2 ou 3

  • d : force de 0 à 100, des valeurs de 10 à 70 semblent raisonnables. Attention entre les 5 réglages possibles de "rayon-contraste" les valeurs de force ne sont pas exactement semblables...et peuvent donner des résultats différents - dit autrement le 50 de l'un peut être 40 ou 60 pour un autre rayon.

  • e: fixe la rapidité d'exécution e=0 normal - e=1 plus lent seulement pour les rayons 1.5 2 et 3

  • f: filtre de limitation de la force entre 0 et 100 - maxi effet à 100 - n'a d'effet que si 'g' est différent de zéro

  • g: filtre d'action sur le seuil (qui n'est pas celui repris en e) de 0 à 100...et il fonctionne

    • après de nombreux essais, ces filtres fonctionnent, mais le résultat demande une visualisation graphique en temps réel pour "voir" les changements, donc en ligne de commande je ne recommande pas ces 2 paramètres qu'il vaut mieux laisser à 0.

    • néanmoins si on entre par exemple d=70 avec f=20 et g=90 on obtient une transition correspondant à force=90, mais avec un contraste supérieur. Si on entre d=70 et f=70 et g=95 on obtient une transition correspondant à d=60 mais avec un contraste plus faible

  • h : filtre de protection des aplats ou de rendu des détails en écarts de luminance de 0 à 5. De faibles valeurs laissent agir tout et montrent tout. Par exemple h=2 n'agit pas si les écarts entre 9 points de mesure du rayon 1, sont inférieurs à L=2. Ressemble à "détails" de certains logiciels. Par défaut si on entre h=0 dans la ligne de commande, la valeur sélectionnée par le logiciel sera de 2, valeur moyenne qui améliorera les aplats et portraits. Si vous entrez une autre valeur 0.01 ou 5 ou 10, c'est cette valeur qui sera choisie

  • i: protection des BL (et HL) - n'accentue pas les valeurs inférieures pour limiter le bruit - en valeurs L (de 0 à 4), par défaut l=2. si vous entre 0.01 ou 5 ou 10 c'est cette valeur qui sera choisie

  • un affichage apparaît après l'accentuation pour montrer le nombre de pixels concernés par les actions :

    • la ligne supérieure :

      •  BL-HL et Aplats exclues parle d'elle même, ce sont le nombre de pixels qui ne sont pas concernés par l'accentuation des très basses (ou hautes) lumière. Par exemple le logiciel n'accentuera pas les valeurs dont L est inférieur à 1. Pour les aplats c'est le nombre e pixels concernés par un écart de luminance donné et qui ne sont pas accentués

      • Préserver LH xxxxxx LB yyyyyy; ce sont le nombre de pixels - proches des transitions non concernés par le filtre de force - le filtre 'g' agit sur cette limite. Il est souhaitable que ces valeurs soient supérieures à zéro...

    • la ligne inférieure :

      • Action filtre : intermédiaires LH wwwwww LB zzzzzzzz, ce sont le nombre de pixels sur lesquels est appliqué le filtre de force 'f'

    • par LH et LB il faut entendre pour chaque transition les pixels dont la valeur L est inférieure ou supérieure à la moyenne du pixel en cause.

• je supprime volontairement les commentaires realtifs aux versions précédentes d'accentuation pour éviter les confusions

Version 2.34

• 2 bugs importants ont été retirés. Ils provoquaient un obscurcissement des ombres et une dérive colorimétrique (pour ces ombres) dans le cas d'images hors gamut.

• A priori résolu

• j'ai de plus arbitrairement monté le seuil possible de limitation des BL à L=15...on n'est pas obligé de s'en servir.

• Pour éviter le problème lors d'images à fort gamut ... au lieu d'activer la fonction rgb=> Lab => rgb par -N 2 1 0 ou -N 2 1 3 utiliser -N 2 1 9 (rapide) ou -N 2 1 5 (affichage) ou -N 2 1 4 (précis)

Modification version 2.01 à 2.27  2.28 et 2.30 et 2.31...2.32

Modifications version 2.0

• cette option est "buggée"...

• attention version totalement buggée... que je revois...

• je "profite" du travail fait sur les zones de contrôle, pour me servir des mêmes procédures, mais en les adaptant au "micro-contraste". Ce micro-contraste (accentuation ?) peut se décrire comme suit, car c'est cet algorithme que j'ai mis au point et qui est actuellement présent dans cette version. J'ai choisi des termes proches de ceux utilisés par ailleurs pour que l'utilisateur ne soit pas trop perdu, même si l'algorithme paraît différent de ceux habituels.

• L'utilisateur définit :

  • un "rayon" (en fait le demi côté) d'un carré de pixels. Ce rayon permet de calculer le nombre de zones en partant de la largeur et de la hauteur en pixels de l'image.

    • dans une première étape, le logiciel va calculer la moyenne de la luminance de chaque zone; par exemple si on définit un rayon de 2 pixels, la machine va faire environ 650000 fois le calcul pour un capteur de 10M°.

  • une "force" - pour chaque zone,je me sers de la routine "contraste" en entrant "force" comme paramètres après la virgule de 1. Le contraste entré devient 1.34 si on entre 34 comme force

  • un seuil limite d'action : cette routine a besoin d'un seuil limite d'action en valeur L, à partir duquel le contraste va diminuer progressivement. (et 100-L pour les basses lumières).

  • une progressivité : je me sers de la progressivité pour masquer les ruptures trop franches aux variations importantes de luminance.

• la commande se traduit comme suit (exemple):

•  -£ a b c d e

  • a = 1 ou plus: active la fonction, a = nombre de passes

  • b = force  - des valeurs comprises entre 5 et 40 sont acceptables.. rien n'interdit d'entrer plus

  • c = rayon en pixels - des valeurs comprises entre 1 et 10 sont acceptables, on peut bien sûr entrer plus

  • d = progressivité en pixels. Ce paramètre est important pour masquer les créneaux...Des valeurs proches du rayon (en étant inférieures) sont recommandées.

  • e = seuil limite d'action - en valeurs L, des valeurs entre 60 et 85 donnent de bons résultats.. on peut entrer plus.. jusque 90

• cette version est expérimentale  et donne un effet d'accentuation, avec des algorithmes de mon cru. On doit pouvoir améliorer (peut être en jouant également sur la chromaticité ??)

• un bug actuel que j'espère résoudre rend impossible l'usage simultané de cette fonction avec d'autres options -N

Modifications version 1.94

• possibilité d'utiliser jusqu'à 50 zones de contrôle secondaires... Il "suffit" (!) d'utiliser la syntaxe -] suivie du numéro...ex -] 1 xxxxx  et -] 2 yyyy  et bien sûr d'y associer les traitements souhaités associés à chaque zone

Par exemple on peut entrer : dcrawggt88 -w -v -o 4 -4 -T -g 2 -Y 0 1 -N 2 1 0 -U 0 6 0 -] 1 50 50 500 1387 100 -@ 1 1.1 1.4 1.2 -] 2 50 1000 291 334 140 -Z 2 1.3 60 -] 3 2500 200 500 500 5 -@ 3 1 1.1 0.8 -% 3 1.3 80 _asc4145.NEF

• il est possible (je l'ai testé..sans la ligne de commande) de créer 10000000 de zones !...pour un usage futur!

Modifications version 1.91

• cette version me parait une évolution assez importante et a nécessité un certain niveau de travail - du fait du fonctionnement en lignes de commandes. Si bien sûr une interface graphique interactive reprenait ces modifications, elle permettrait facilement une extension des possibilités.

• La possibilité est donnée de créer des fenêtres supplémentaires (une seule pour simplifier dans le cas de la ligne de commande). A l'intérieur de ces fenêtres on peut faire varier l'ensemble des paramètres concernés par l'option -N (travail en mode Lch Lab), c'est à dire à ce jour : luminosité, exposition , traitement des basses lumières, chromaticité (saturation), contraste, rendu (paysage, portrait, standard..), mais il serait possible si le code de Dcraw évolue, de prendre en compte également l'accentuation et le débruitage (tous les deux en mode Lab).

• Cette fenêtre supplémentaire se comporte ainsi comme une zone de contrôle (à l'image des points de contrôle de Nikon Capture NX).

• On peut d'une part appliquer une modification de son choix à l'ensemble de l'image (par exemple contraste et chromaticité) et agir sur la fenêtre secondaire sur la chromaticité (avec d'autres valeurs) et le traitement des basses lumières, etc. Tous les paramètres sont combinables.

• Le traitement en lignes de commandes étant contraignant, j'ai été amené pour chacun des paramètres qui intervient sur l'option -N (sauf  -$ qui mesure et -B pour traiter manuellement les HL qui est plus qu'expérimental et non aboutit), à ajouter en tête de commande le numéro de fenêtre  , '0' agit sur l'image entière, '1' agit sur la fenêtre sélectionnée; Par exemple l'ancienne commande -@ 1.1 1.3 1.2 qui agissait sur la chromaticité devient @ 0 1.1 1.3 1.2 pour une action sur l'image entière et @ 1 1.1 1.3 1.2 pour une action sur la fenêtre.

• il est bien sûr indispensable de déclarer la fenêtre avec l'option -]

  • -] prend 6 paramètres (a b c d e f):

    • a = 1 : seule fenêtre à ce jour possible

    • b : position de la fenêtre par rapport au bord gauche de l'image (en pixels)

    • c  : position de la fenêtre par rapport au bord supérieur de l'image

    • d : largeur de la fenêtre

    • e: hauteur de la fenêtre

    • f: nombre de pixels traduisant la progressivité entre l'image modifiée et les parties voisines. Ce nombre peut varier de 1, on voit nettement apparaître les contours, à la moitié de la plus petit valeur entre largeur et hauteur, dans ce cas la transition est difficilement visible. Cette progressivité joue sur les 3 composantes L c et h.

    • Par exemple en entrant -] 1 50 200 1500 700 100, on crée une fenêtre secondaire positionnée à x=50 et y=200 et faisant 1500 pixels de large et 700 de haut. L'image est pleinement modifiée dans la zone centrale soit un rectangle dans ce cas de 1300 par 500 et sur 100 pixels de chaque côtés on assure une progressivité.

    • Bien sûr pour prendre les coordonnées il faut insérer dans la ligne de commande -j -t 0 qui va positionner l'image dans les conditions de capture de l'appareil.

• éditer le menu 'prompt' pour voir les modifications aux commandes.

   

Modifications version 1.88

• Un apport qui peut sembler inutile...mais qui en réalité permet à nouveau de comprendre ce que fait le logiciel...

• J'ai introduit la possibilité - toujours en activant l'option -N (travail en mode Lab, Lch) - de scruter une partie de l'image - avant les conversions RGB (gamma, espace..). Pour que ce soit opérationnel il est nécessaire (comme pour une balance des blancs sur une zone grise) d'entrer dans la ligne de commande " -j -t 0 " qui va mettre l'image avec les pixels orientés comme à la prise de vue.

  • ensuite en entrant -$ pixels gauche, pixels haut, delta1, delta2

    * où pixels gauche: nombre de pixels à partir de la gauche de l'image, qui marque le début de la zone à mesurer

    * où pixels haut : nombre de pixels à partir du haut de l'image, qui marque le début de la zone à mesurer

    * delta1 = largeur de la zone en pixels (> 0)  5 à 20 sont a priori des choix possibles

    * delta2 = hauteur de la zone en pixels.

  • on obtient au traitement 2 lignes :

    • la première donne pour cette zone les valeurs Lab "moyennes" correspondant à l'espace colorimétrique choisi pour le calcul.

    • la seconde donne les valeurs rgb "moyennes" (avant conversion RGB via l'espace colorimétrique de travail). J'ai exprimé ces valeurs dans l'intervalle [0..255] qui est plus familier que (0..65535).

• Dans les possibilités offertes, cela permet entre autres un "bricolage manuel" des couleurs via l'option -B a b c d e f   - en complément de -H 3 à 9 (voir le prompt de Dcrawggt88 pour informations!), mais qui permettrait en faisant du développement complémentaire et avec une interface graphique de simuler sensiblement une partie des fonctionnalités des points de contrôle

• mais cela permet de comprendre ce qui se passe et les incidences des paramètres de gestion des couleurs. Par exemple, on constatera... ce qui peut paraître évident... que le choix de sortir le TIFF sans espace de couleur (option -o 0 ) inscrit les valeurs (rgb) dans le TIFF (cqfd)..les valeurs rgb calculées  (après interpolation, balance des blancs, etc. mais sans gamma ni espace) et rgb affichées sont les mêmes.

Modifications version 1.85

• j'ai modifié l'algorithme de l'option -@ chromaticité. Au lieu systématiquement d'appliquer un coefficient aux tons ternes, pastels et saturés , je mesure d'abord pour chaque pixel la saturation RGB et en fonction de sa valeur (terne, pastel, saturée)..j'applique le coefficient ad hoc ou je le minore pour éviter de déborder de l'espace colorimétrique de calcul. C'est un autre choix, qui prend quelques millisecondes de calcul en plus, mais est (un peu) plus respectueux des habitudes et de la colorimétrie...lorsque bien sûr on pousse loin les saturations. En effet saturation et chromaticité n'ont pas les mêmes références, une couleur peut avoir une faible chromaticité et être saturée...

Modifications version 1.84

• toujours avec l'option -N, ajout de l'option -U <a b> qui agit sur la luminosité

  • 'a' : déplace l'histogramme de 'L' (luminance) vers la droite ou la gauche

  • 'b' : 0 accroît la luminosité, 1 diminue la luminosité

  • attention il n'y a volontairement aucun contrôle, si vous entrez -U 50 0, l'histogramme va être déplacé de la moitié.. cad le point zéro se retrouver à L=50. Donc à utiliser avec modération par exemple -U 5 1 ou -U 10 0.

Modifications version 1.83

• essentiellement de forme ou pour prévenir de mauvaise commandes

• changement du format du seuil pour l'option -Z (exposition en mode Lch). J'ai mis le même type de données que pour -[ (basses lumières) et -% contraste, en valeurs de luminance.

• prévention des mauvaises entrées - par exemple seuil < 50 qui devient 50 automatiquement, etc.

• forme du "menu" après le prompt : lignes plus courtes donc a priori plus lisibles.

• un petit bug retiré.

Modification  version 1.80

• paramètre supplémentaire pour l'option -[ (basses lumières): un quatrième paramètre compris entre 0 et 4 (valeurs L) fixe le seuil en dessous duquel aucune action ne se produit, afin de limiter la montée du bruit dans les BL. Si ce seuil vaut zéro, l'ensemble de l'histogramme est traité. Si L=0.7 les valeurs en dessous de 0.7 ne seront pas modifiées...

Modifications version(s) 1.70 à 1.79

• elles visent pour l'essentiel :

  • corriger les bugs, plantages, etc.

  • optimiser le trio : performances graphiques, rapidité et encombrement mémoire : le langage C n'a pas de "garbage collector" ce qui rend problématique la gestion de la mémoire qui est très fortement sollicitée dans l'opération rgb=> Lch, Lch => rgb

• Apports version 1.74 : ajout de 2 espaces colorimétriques  de conversion pour l'option -N : AdobeRGB et Bruce RGB

• Optimisation du code C - plus compact - pour l'option -N

• affichage plus complet des dépassements d'espaces colorimétriques par l'ajout de 3 lignes qui apparaissent après la ligne : "Conversion Lch ==> Lab => xyz => rgb"

  • la ligne suivante est maintenue (exemple) : "depas: i_r Rouge  133623 i_g vert 13197  i_b bleu 0" - elle dit que par rapport à l'espace de conversion choisi (ici Prophoto) 133263 pixels ne sont pas par calcul dans l'intervalle (0...65535) pour le canal rouge, 13197 pour le vert et 0 pour le bleu

  • apparaît ensuite la ligne "minimum rgb calcul -1749  maximum rgb calcul 65536"; ce qui veut dire que la valeur minimal théorique est de -1749 par rapport à (0 ...65535) et le maxi à 65536 soit +1

  • apparaît ensuite 2 lignes - une pour le minimum et l'autre pour le maximum : "Minimum 'traduit par option' en rgb = 296 63787 60 et couleur fausse= vert " (et similaire pour le maximum), veut dire que la valeur rgb correspondant au minimum par calcul (-1749) est le trio rgb : r 296  g:63787  b:60 et que la couleur fausse est le canal vert.

  • selon l'option choisie :

    •  -1 ou -2:  - qui ne borne pas les valeurs - va prendre en compte les valeurs -1749  et 65536 et "essayer" de rendre quelque chose. Bien sûr le type de variable déclarée dans DCraw pour l'image est de type 'ushort', qui ne peut prendre des valeurs qu'entre 0 et 65535. Dans ce cas le transtypage va amener la valeur fausse à 65536-1749 = 63787... au lieu de -1749. Ce qui va amener à l'écran des couleurs atypiques qui vont montrer les pixels défectueux

    • -3     - qui borne les valeurs, va ramener la valeur -1749 à zéro. Cette option affichera qu'il y a des pixels 'out' mais donnera un résultat à l'écran et dans le TIF conforme aux règles habituelles de la colorimétrie relative.

    • -4 ou -5 : - laisse les anciennes valeurs rgb. Cette option affichera qu'il y a des pixels 'out', mais donnera un résultat à l'écran et dans le TIF correspondant aux valeurs avant conversion rgb => Lch; Lch=>rgb

    • 0 : fera comme -1 mais sans affichage

    • 9 : fera comme 5 sans afficher

  • sur une image saine devrait apparaître : i_r Rouge 0  i_g vert 0 i_b bleu 0 et la ligne "minimum rgb calcul 0 et maximum rgb calcul 0"....Seule les valeurs < 0 et > 65535 seront prises en compte, par exemple si la conversion trouve 65535,3, maximum rgb calcul donnera 65535.

  • bien sûr en traitement d'image normal les options -1 et -2 ne sont pas à utiliser car les couleurs seront vraiment fausses

• Apports version 1.76 :

  • action sur le contraste : -% a b :

    • 'a' :agit sur le contraste 1.0 ne fait rien, 0.8 baisse le contraste de 20% de manière uniforme, 1.1 ..1.4 accroît le contraste de manière différenciée selon le seuil 'b'

    • 'b': seuil d'action. Il faut entrer une valeur > 50 et < 90 (valeurs de luminance). Le contraste va prendre la valeur 'a' dans l'intervalle '100-b' <==> 'b' puis se réduire pour atteindre 1 pour L=0 et L=100.Par exemple si vous fixez le seuil L=80, de L=0 à L=20 le contraste à 1.10 le contraste croit progressivement  de 1.0 pour L=0 pour atteindre sa valeur nominale à L=20. Puis de L=20 à L=80 le contraste vaut 1.1, puis de L=80 à L=100 le contraste baisse progressivement de 1.1 à 1.0.

• Apports version 1.78 -

  • voir action sur les BL plus bas (bug a priori retiré et action changée)

  • plusieurs rendus spécifiques : -J a  qui agissent simultanément sur contraste, chromaticité et exposition et donnent des "rendus" typés paysage, portrait ou standard... ne pas mettre l'option -J amène le rendu neutre.(si bien sûr on n'agit sur rien par ailleurs)

    • a = 2 : paysage

    • a= 3 : portrait

    • a= 4 : standard

• Apports version 1.79

  • bug retiré dans l'option contraste

  • version de base de D.Coffin , passée de 8.87 à 8.88

Modifications version(s) 1.60

• Équilibrage des canaux verts : en première étape j'ai repris le code que M.Llorens a modifié pour traiter l'équilibre des verts de la matrice de Bayer. L'ancien algorithme est remplacé par un "nouveau" où sont pris en compte 2 paramètres : a) général = équilibre les canaux verts globalement; b) général + local = fait comme a) mais en plus agit localement autour de chaque pixel. Pour cela on ajoute le paramètre "rayon" (en pixel) qui est en fait le nombre de cases du carré de pixels retouchés autour du pixel de référence.Ce rayon peut varier de 2 à 12 soit dans le premier cas 2x2 pixels retouchés et dans le second 12x12 = 144. Cette option se traduit par un (léger) accroissement du temps de traitement. Cet équilibrage des canaux verts améliore notablement le traitement de l'image (interpolation) en réduisant ou supprimant les artefacts (labyrinthes, etc.)

• Prise en compte des possibilités liées à la transformation rgb ==> xyz ==> Lab ==> Lch et réciproque.

  • lors de l'utilisation de cette option -N , il est en première étape possible de choisir , l'espace de travail de conversion, (Prophoto ou sRGB  ou WideGamut ou CIE RGB ou BetaRGB) pour limiter les "clipping" d'images, ainsi que la possibilité ou non en fin de traitement de borner (clip) les résultats ou si il y a dépassement de laisser la valeur rgb initiale. Ces options permettent de "voir" à l'image les débordements de l'espace de conversion choisi  lors du traitement. Les quelques essais que j'ai pu faire confirment sur de vraies images (en plus de celles d'une mire) qu'un APN a un profil très large et très supérieur à sRGB et incite à modérer les actions sur saturation, exposition, contraste, etc...sinon au détriment des vraies couleurs.

  • -N a b c :

    • a = 2 utilise la conversion rgb==> Lch ;

    • b =1 via calcul  XYZ par espace Prophoto (recommandé)  b=2 via sRGB  b=3 via WideGamut b=4 via CIE RGB b=5 via BetaRGB (1 recommandé); 

    • c : ces options permettent de voir (soit à l'écran et /ou soit par calcul) les dépassements d'espaces.

      • c=0 Calcul rapide - borne valeurs rgb espace de calcul choisi

      • c=1 Calcul rapide -affiche données - ne borne pas valeurs rgb espace de calcul choisi

      • c=2 Calcul précis et lent -affiche données- ne borne pas valeurs rgb espace de calcul choisi

      • c=3 Calcul précis et lent -affiche données - borne valeurs rgb espace de calcul choisi

      • c=4 Calcul précis et lent -affiche- laisse les valeurs rgb initiales si dépassement

      • c=5 Calcul rapide - affiche données- laisse les valeurs rgb initiales si dépassement

      • c=9 Calcul rapide - laisse les valeurs rgb initiales si dépassement

       

    • De petites valeurs (aux environ de 100 et jusque 5000) sont pour l'essentiel sans importance car dues aux "erreurs" de calcul liées à la double transformation (rgb => lch =rgb), inversions de matrices, puissances, sinus, cosinus, arctg, limitations des calculs sur les réels - ici en valeurs 'double', etc.

     

  • j'ai jouté un affichage (option c = 1 ,2,3 4 ou 5) pendant le traitement qui montre a minima les dépassements de l'espace de conversion . Si il y a dépassement ici , il est sur que il y aura débordement de l'espace. Il s'affiche la ligne suivante :

    • dépassements: i_r rouge <val>, i_g vert <val>, i_b bleu <val> après modifications Lch.

    • les valeurs <val> traduisent le nombre de pixels qui ont "débordé"

    • i_r, i_g  i_b traduisent le dépassement rgb après conversion et modifications Lch, mais bien sûr avant application du gamma. Souvent ces indicateurs traduisent des valeurs rgb négatives. On arrive assez facilement à des valeurs de 200000 lorsqu'on sature une image saine et voir plus de 2000000 lorsqu'on a une image surexposée.

  • option recommandée pour traiter les images rapidement -N 2 1 0 ou -N 2 1 5 , les autres options -N 2 2 0, -N 2 3 0, -N 2 4 0 -N 2 5 0  etc. peuvent servir de test ! Les options sur 'c' permettent de voir et comprendre.

  • dans le cas d'images surexposées, cette double conversion peut amener dans certains cas des artefacts (sauf c=4 5 ), dans ce cas, baisser l'exposition par la commande -y <val> par exemple -y 0.9 et/ou agir sur les hautes lumières avec -H <2..9>

• A ce stade je n'ai mis en oeuvre et de manière spartiate et expérimentale que 3 options qui utilisent la conversion Lch

  • action sur la chromaticité (C de Lch) qui ressemble à la saturation, avec 3 possibilités : tons ternes, pastels et saturés:

    • -@ <a b c> : a agit sur les tons ternes, b sur les pastels et c sur les saturés (a=b=c=1.0 ne fait rien;par exemple  a=0.9 b=1.3 c=1.2, réduit les tons ternes de 10%, accroît les pastels de 30% et les saturés de 20%)

  • action sur l'exposition par la luminance L avec 2 paramètres, accroissement exposition, et seuil à partir duquel se produit une limitation progressive de l'action

    • -Z <a b> : a agit sur l'exposition (doit être supérieur à 1) et b sur le seuil, de L=50 à 90. Par exemple -Z 1.2 65, accroît l'exposition (la luminance) de 20% pour les valeurs de L inférieures 65, puis réduit cet accroissement au dessus de L=65.

    • on peut constater une meilleure conservation des teintes lors de l'utilisation de cette option "luminance", plutôt que -F (exposition)

  • action sur les basses lumières (modification version 1.78)

    • -[ a b c d:

      • 'a' : valeur d'amplification des BL entre 0.5 et 3...1.5 à 2 recommandé , a<1 accroît les ombres;

      • 'b' : seuil limite d'action entre L=10 et L=50 ou plus..,jusque 100; 20 à 40 recommandé ;

      • 'c': profondeur de la courbe par rapport au linéaire=0, de 0,5 à 2 ou plus ...10; 1 à 2 recommandé (coefficients logarithmiques). Par exemple -[ 2 40 1 double  les BL pour L proche de zéro et n'agit plus à partir de L=40. La courbe de type '3'  réduit vite son action par rapport à une décroissance linéaire, plus vite que la '3', etc. On peut essayer par exemple -[ 2 80 1, ou -[ 2.5 80 2  qui vont "éclaircir" globalement une image;

      • 'd' : (à partir de version 1.80) = seuil de protection des ultra basses lumières. Ce seuil compris entre (en valeurs L) 0 et 4 empêche - sous ce seuil - la modification des valeurs L. Ce paramètre prévient l'accroissement du bruit. Des valeurs proches de à.5 sont recommandées.

    • remarque : contrairement à d'autres logiciels, il n'y a pas ici "d'amplificateur de saturation", car en travaillant sur les valeurs Lch, seule la composante L est touchée.

    • Quelques exemples d'utilisation des paramètres :

      • exemple d'amplification de la luminance pour un seuil à L=50 et une amplification de base de 2,5, pour 5 profondeurs et 2 valeurs intermédiaires de L

  Profondeur =>	0	0,5	1	3	10
  L=0	2,5	2,5	2,5	2,5	2,5
  L=10	2,2	2,07	1,96	1,61	1,133
  L=25	1,75	1,53	1,38	1,31	1,04
  L=50	1	1	1	1	1

  • exemple pour un seuil à L=20 et une amplification de 2

  Profondeur =>	0	0,5	1	3	10
  L=0	2	2	2	2	2
  L=5	1,75	1,65	1,56	1,61	1,13
  L=10	1,5	1,35	1,25	1,06	1,00
  L=20	1	1	1	1	1

• exemple pour un seuil à 90 et une amplification de base de 1,5

Profondeur =>	0	0,5	1	3	10
L=0	1,5	1,5	1,5	1,5	1,5
L=10	1,44	1,42	1,39	1,31	1,14
L=50	1,22	1,15	1,10	1,02	1,00
L=90	1	1	1	1	1

• exemple pour un seuil à L=30 et une amplification de base de 0,5 (réduction de 50% de la luminance des BL)

Profondeur =>	0	0,5	1	3	10
L=0	0,5	0,5	0,5	0,5	0,5
L=5	0,58	0,62	0,65	0,76	0,93
L=15	0,75	0,82	0,87	0,97	1,00
L=30	1	1	1	1	1

 

Exemple de représentation graphique des paramètres d'action sur les basses lumières :

• amplification : ici 2.2 fois la référence. On peut choisir n'importe quelle valeur.. mais 1.5 à 2 semblent usuelles
• seuil : jusqu'à L=62,5 l'amplification a une action. On peut choisir L=25..on n'agira que sur les basses lumières ou L=95 quasiment tout l'histogramme est concerné
• profondeur : en rouge décroissance linéaire, puis 3 possibilités de décroissance. Par commodité de visualisation je n'ai mis que 4 courbes...il y en a une infinité.
• protection : ici le seuil est amplifié pour 'voir', des valeurs de L vers 0.5 ou 1 semblent correctes
• en bleu, la luminance de référence comprise entre L=0 et L=100.
• bien sûr le logiciel fait autant de fois l'opération qu'il y a de pixels...soit environ entre 7 et 22 millions de fois.

 

• Toutes les options ( @, Z, [, %, J) sont opérationnelles si on a entré dans la ligne de commande l'option -N - attention les options @ et [  doivent être utilisées simultanément avec précautions.

Modifications version 1.50

A ce stade la modification est expérimentale et ne sert à rien!.

L'option -N <a b c >  avec <a> différent de 1, procède à une conversion : rgb => xyz => Lab ==> Lch,  puis fait exactement l'inverse pour revenir à rgb. Essayez pour constater que l'image et l'histogrammes sont inchangés... Sinon dans les images sur exposées ou qui "débordent" de l'espace Prophoto. Dans ce cas on verra apparaître à l'écran des artefacts de couleurs...Pour y "remédier ?", appliquer -y <val>.

Le temps de traitement est acceptable... sur ma machine avec des fichiers NEF de D200, ce traitement à vide (rgb => Lch puis Lch => rgb)  prend environ 4  secondes.

Par contre, la possibilité d'avoir les valeurs Lch (et Lab), ainsi que les XYZ obtenues avec conversion en espace Prophoto, va permettre de se servir de ces modèles qui sont plus réputés pour manipuler les couleurs que RGB ou HSV ou HSL.

Donc il est dans les possibilités de faire varier :

• exposition bien sûr, notamment agir sur les BL  ;

• contraste, avec un contraste variable

• chromaticité C (peu différent de la saturation) en agissant séparément sur les teintes ternes, pastels et saturées

• teinte H en pouvant agir par "tranches de couleurs" par exemple en découpant l'ensemble des teintes en 9 sous groupes et en agissant séparément

• combinaison possible des 3 paramètres L C et H pour agir par exemple sur les zones cramées..

Mais il sera aussi possible de se servir des modèles de Bradford et mieux encore CIECAM02 pour ajuster le rendu en fonction des illuminants.

Également il pourra être dressé des cartes ou statistiques en termes de deltaE.

etc.

Bien sûr si c'est nécessaire et utile!

Modifications versions 1.40

1. Elles concernent les espaces colorimétriques de sortie incorporés à DCRAW. En version 'standard' DCRAW propose 'raw'(sans espace), 'XYZ', 'sRGB', 'AdobeRGB', 'WideGamutRGB', 'Prophoto'. Ont été ajoutés 4 espaces de grande taille soit pour leurs caractéristiques spécifiques, soit pour leur réputation.

   • Ce sont CIE RGB qui a un point blanc spécifique (1,1,1) , Bruce RGB (de Bruce Frazer), DonRGB (de Don Hutcheson), et BetaRGB (de B.Lindbloom). Pour activer ces options il suffit dans la ligne de commande de remplacer -o [0..5], par -o [0..9] : -o 6 = CIE RGB; -o 7 = Bruce RGB D65; -o 8 = DonRGB D50; -o 9 = BetaRGB D50.

   • Ces modifications se font par calcul et agissent sur la conversion en 16 bits XYZ ==> RGB et non comme le fait un profil colorimétrique (voir plus loin les options -p fichier.icm -o fichier.icm ); il suffit d'examiner les histogrammes par exemple en comparant l'action de "-o 6" (espace CIE RGB) et celle de -p CIERGB.icc -o CIERGB.icc. En termes qualitatifs il n'y a pas photo, d'un côté un histogramme régulier et de l'autre un histogramme haché...!

   • Ces "grands" espaces sont souhaitables pour traiter les fichiers RAW afin de conserver toutes les données, quitte bien sûr si on le souhaite, en post traitement, convertir vers un espace plus petit.

   • avec ces nouveaux espaces pris en compte, les options -g  (gamma) et -Y (TRC) restent opérationnelles.

2. L'autre modification est la possibilité d'agir sur l'exposition. Je me suis servi du code C de G.Luijk (trouvé sur le web) que j'ai modifié (si on examine l'action de "exposition" dans PerfectRaw et dans ma version de Dcraw, on peut voir des algorithmes différents...)  pour prendre en compte un niveau de 'seuil' variable pour préserver les HL. Par défaut ce seuil est à 32768 (par rapport à 65536), on peut choisir n'importe quelle valeur entre 50% histogramme (32768) et environ 95% (62768).

   • cette option se commande par -F a b c (voir plus loin la commande complète) : a = valeur de la variation d'exposition (exemples 0.6 0.8 1.4 2 ...), b=choix entre protection des HL  algorithme CIE ou HSL et sans protection, c= niveau du seuil (de 32768 à 62768 par rapport à 65536).

   • elle agit avant la transformation matricielle XYZ RGB et la prise en compte du gamma; elle est donc différente de l'option -L qui elle agit a posteriori de ces actions. Ces deux options peuvent être complémentaires: -F abaisse l'exposition et -L relève les BL.

3. à partir de la version 1.41 , j'ai ajouté l'option -y <val>. Ce coefficient agir directement et proportionnellement sur les multiplicateurs de canaux. Par exemple si l'option -w (balance des blancs du boîtier)  indique - 1.93594 1.00 1.2539 1.00 et qu'on entre la valeur 0.8 on obtiendra 1.5468 0.8 1.003 0.8. La balance des blancs ne sera pas modifiée mais l'exposition le sera... Alors à quoi cela sert-il car il existe déjà les options -F et -L. Dans le cas d'un histogramme normal (cad qui ne déborde pas), pas de différence sinon qu'on ne peut agir sur l'éclaircissement des BL ou la préservation des HL. Lorsqu'il y a surexposition, essayez de comparer l'option -F et -y. Dans le premier cas l'histogramme est "coupé", dans le second cas on "récupère" ce qu'il y a au delà de la limite... Bien sûr avec toutes les conséquences possibles notamment des dérives de couleurs pour les ciels vers les magentas... Plusieurs utilisations possibles :

   • récupérer les HL par glissement de l'histogramme sans autre actions...

   • compléter les options -H 2 ou -H 3 à 9 (vers 1.42), soit en récupérant encore plus les HL, lorsque la modification proposée par DCRAW est insuffisante. Par exemple -H 9 amène comme coefficients (avec l'exemple cité plus haut) 1.00 0.517 0.648 0.517, mais dans certains cas fait encore apparaître du magenta. Ajouter le paramètre -y 0.85 va amener comme nouveaux coefficients 0.85 0.4395 0.55 0.439 et une image avec une quasi absence de magenta.

   • compléter les options -H 2 ou -H 3 à 9 lorsque le paramètre par défaut amène une image sans zones magentas, mais sombre. Dans ce cas entrer - y 1.4 (exemple) redonnera de la luminosité à l'image et accroît les coefficients qui deviennent 1.40 0.724 0.907 0.724

   • etc.

4. j'ai activé la directive de compilation TIMER (V 1.42) qui permet de voir la durée de 4 phases de traitement :

   • lecture fichier et matrice de Bayer

   • interpolation (dématricage) et compléments

   • traitement des HL

   • conversion RGB dont gamma variable

5. Ajout de l'option -x a b (v 1.43)  . Il est possible (c'est un ajout mineur) de modifier séparément les canaux rouge et bleu de la balance des blancs (comme le fait le point gris de Capture NX). Par exemple si le réglage du boîtier (-w) est 1.82 1.0 1.25 1.0, si on modifie par l'option -x , on obtient si a et b valent 0.95 et 1.03  de nouveaux coefficients  1.729 1.0 1.1875 1.0. Cette option permet de retoucher "à la marge" le réglage par défaut du boîtier.

    

    

Modifications version 1.32

Uniquement de forme (menus, messages...)

Modifications version 1.31

Elles sont minimes:

• utilisation de la bibliothèque LCMS 1.17 au lieu de 1.14

• suppression des caractères accentués dans les menus et rapports

• affichage D65 ou D50 pour Prophoto et WideGamut selon le choix au lieu de Dxx

Commentaires sur la version 1.30 - août 2008

1. j'ai intégré les bibliothèques LCMS et JPEG, ce qui rend possible l'utilisation des options -o et -p. Malheureusement un bug persistant (DCRAW ou LCMS ?) rend inefficace  son utilisation pour les profils d'entrée. Son intérêt est de pouvoir travailler dans d'autres espaces colorimétriques que ceux prévus à l'origine (sRGB, AdobeRGB, WideGamut, Prophoto, Sans espace, XYZ). Dans ce cas l'option -Y qui ajuste le rendu gamma TRC est inopérante.

2. Dans certains cas (pour certains processeurs) l'option -l qui ajuste les canaux verts pour améliorer le dématricage (suppression des labyrinthes notamment dans l'algorithmes AHD) fonctionnait très très mal. Ceci tient aux calculs en réels "long double" qui assurent une précision jusque 10^4932...qui dans certains cas étaient entachés d'erreurs importantes. J'ai apporté le correctif en ajoutant des options mathématiques de compilation,....au prix d'un léger ralentissement.

3. Je donne le choix par l'option -I 1 de remettre les espaces de sortie Prophoto et WideGamut en D65

4. J'ai (je pense) amélioré la présentation des options possibles des lignes de commandes (lorsqu'on tape : Dcrawggt87)

5. La version courante de Dcraw - celle réalisée par D.Coffin est la 8.87 du 12 août 2008 qui rend possible le traitement Raw des boîtiers récents notamment Canon EOS1000D et Nikon D700.

A titre pédagogique, j'ai ajouté des commentaires lors du travail de Dcraw, afin de voir l'action et l'ordre des divers paramètres.

Action des commandes ajoutées

• 16 bits 'gamma', 'courbes de contraste TRC' (Tone Reproduction Curve):

  • le gamma 16 bits (origine G.Luijk et M.LLorens pour l'option -g 0 ou sRGB qui ont fait un travail remarquable à la fois par son originalité et sa vitesse), modifié par moi même : option -g) peut prendre les valeurs variables raccordant une partie linéaire et une partie de type puissance, l'ensemble peut être appelé LUT. Attention les gamma de base se traduisent en réalité par un gamma moyen plus faible (de l'ordre de 5 à 10%)

    • '0  / sRGB' ou '9'  gamma de base de 2.4  '0' doux débouche les ombres - '9' plus dur... (moyenne réelle proche de 2.2)

    • '2' ou 3' ou '4' / varia' , '3' doux, débouche plus les ombres que '4' - '2' très doux , débouche plus les ombres que '3' ; gamma de base 2.2 (moyenne réelle proche de 1.95)

    • '5  / var' , - gamma de base 1.8 (moyenne réelle proche de 1.6)

    • '6'  - gamma de base 1.3 - quasi idéal pour images à très forte dynamique (associer avec option - Y 3 1.0), en fait peu différent du linéaire pur, mais associé à -Y 3 "ravive" les images , étend l'histogramme et amène moins de correction. Il est possible en plus de régler le gamma du logiciel de post-traitement à 1.3.

    • '7' ou '8'  - '7' normal, '8' dur - gamma de base 2.6 (moyenne réelle proche de 2.4)

    • '1' - linéaire

    • ou toutes valeurs constantes comprises entre 0,xxx et 3,xxx (exemple 2,16).

    • Ces gamma variables permettent un rendu différent des basses lumières, par rapport aux gammas constants. Plus le gamma est "dur" plus la courbe de l'histogramme sera verticale dans les basses lumières.

    • Formes de la courbe gamma - 16 bits :

      • Si les composantes IN_lin < seuil,   OUT_gamma = mult*IN_lin

      • Si les composantes IN_lin > seuil,  OUT_gamma = 1.0+const * IN_lin^1/gamma - const

      Ainsi pour les valeurs sRGB (g = 0 et gamma=2.4) choisies par G.Luijk et M.Llorens on aboutit à :

      OUT_gamma = 12.92 * IN_lin      pour  IN_lin<=0.00304
      
      OUT_gamma = 1.055 * IN_lin^1/2.4 - 0.055      pour  IN_lin>0.00304

      et par exemple pour g = 4 (valeurs par ailleurs choisies par D.Coffin dans sa LUT 8 bits)

      OUT_gamma = 4.5 * IN_lin      pour  IN_lin<=0.018
      
      OUT_gamma = 1.099 * IN_lin^1/2.2 - 0.099      pour  IN_lin>0.018

      ou encore pour g = 7

      OUT_gamma = 6.9 * IN_lin      pour  IN_lin<=0.01
      
      OUT_gamma = 1.1225 * IN_lin^1/2.6 - 0.1225      pour  IN_lin>0.01

      etc.

       

      • Valeurs de seuil, mult, gamma, const

    • paramètre de -g	Seuil	mult	gamma	const	Type de rendu	Observations
      1					Linéaire pur	Suppose ensuite des corrections manuelles de ton et contraste
      0	0,00304	12,92	2,4	0,055	2,4 sRGB doux	Standard sRGB - utilisé notamment par Lightroom en Prophoto ainsi que par G.Luijk et M.LLorens dans Dcraw
      9	0,018	4,5	2,4	0,1232	2,4 sRGB dur	Gamma 2,4 comme 0  mais attaque plus raide des ombres
      2	0,00304	12,92	2,2	0,0371	2,2 très doux	Comme 3 et 4, mais encore plus doux
      3	0,01	5,58	2,2	0,0802	2,2 doux	Comme 4, mais plus doux
      4	0,018	4,5	2,2	0,099	2,2 dur	Utilisé par D.Coffin en mode 8 bits - standard
      5	0,018	3,35	1,8	0,0529	1,8 normal	Gamma 1.8, mais avec amorce linéaire
      6	0,00304	3,35	1,3	0,0014	1,3 doux	Option que je recommande pour les images à forte dynamique (compromis) - retouches manuelles plus faibles que linéaire pur. Essayer de mettre un peu de TRC -Y 3 ou 2
      7	0,01	6,9	2,6	0,1225	2,6 doux	Pour images très peu contrastée, ombres douces
      8	0,018	4,5	2,6	0,1689	2,6 dur	Pour images très peu contrastée, ombres plus dures

    • Essayez plusieurs valeurs de -g et comparez. Ensuite essayez l'option -Y ci-dessous.
    • la modification du gamma par l'option -g modifie la forme de l'histogramme, en l'étendant vers la gauche pour les valeurs croissantes du gamma

     

  • 5 courbes de contraste "TRC" (Tone Reproduction Curve) sont disponibles (option -Y [a b]) :

    • 'a'  choix du type de contraste gamma TRC ==>

      • 0=standard pour gamma 'varia', gamma=1.82 - à associer en général avec -g 2 ou -g 3 ou -g 4

      • 1=sRGB pour gamma 'sRGB', gamma=2.19 - à associer en général avec -g 0

      • 2=faible, gamma=1.58 -  à associer en général avec -g 5

      • 3=très faible, gamma=1.28 -  à associer en général avec -g 6

      • 4=très fort.; gamma=2.4 -  à associer en général avec -g 7

    • 'b' ajuste le contraste TRC doit être à 1.0 par défaut; faire varier de 0.9 à 1.1 voire beaucoup plus ou  moins 0.6 ... 1.5. Exemple -Y 0 1.064  amène un gamma TRC de 1.94; exemple -Y 4 1.5 amène un gamma TRC de 3.6. Peut être utile pour des images sans contraste...

    • Rien n'interdit d'appliquer une courbe de contraste à un autre gamma! Ces 2 paramètres agissent sur les 3 courbes TRC (R, G et B) et rendent ainsi un gamma spécifique. J'ai modifié (légèrement) le rendu de base prévu par D.Coffin en l'abaissant légèrement (environ 6%).

    • le gamma TRC modifie le rendu de l'image (son contraste) sans toucher à la forme de l'histogramme. Il agit sensiblement comme le ferait un profil colorimétrique, mais sans en être un. Pour s'en convaincre, il suffit d'examiner l'incidence de ces réglages sur le profil perçu par Photoshop à l'ouverture des TIF: a) si le paramètre -g varie, Photoshop demande toujours de choisir entre l'espace réglé sur Photoshop et celui réglé sur le TIF ; b) si Y varie et par exemple vaut 0 (soit un gamma TRC de 1.82), si l'espace de travail de Photoshop est Prophoto (avec un gamma de 1.8), l'ouverture du fichier se fera sans poser de questions de choix  de profil.

     

  • les réglages de base que je recommande  : option -g = 4 ; option -Y =0 1.0 (en Prophoto)

  • ainsi configuré DCRAW peut avoir le même rendu en 16 bits qu'en 8 bits, sinon un peu mieux dans les HL et BL. Bien sûr en jouant sur les paramètres 16 bits: linéaire, gamma, contraste TRC, H et S on peut "ajuster" à souhait le traitement des images à forte dynamique et ou aux ombres bouchées et/ou aux HL cramées.

  A ma connaissance Dcraw ainsi modifié est parmi les seuls à proposer des choix de ce type en dissociant : espace colorimétrique de travail, 'courbes' avec divers gamma variables composés d'une partie linéaire et d'une autre classique, rendu TRC variable

   

• Modification de l'exposition

  • j'ai "emprunté" sur le web le code G.Luijk, que j'ai modifié. On peut avec cette option :

    • modifier l'exposition sans protéger les HL. Le coefficient appliqué agit sur tout l'histogramme avec la même valeur

    • modifier l'exposition avec protection des HL que ce soit en augmentant ou en baissant l'exposition. Dans ce cas, il est possible d'entrer le seuil à partir duquel les HL seront préservées. Par exemple si on fixe un niveau d'exposition de 1.4 et un seuil de 32768. De 0 à 32768 l'exposition s'accroît de 40% et de 32768 à 65536 l'augmentation d'exposition se réduit de 40% à 0%. (c'est sensiblement ce que fait Lightroom).

    • Il est mentionné dans le rapport de traitement le niveau de seuil, ainsi que la valeur en EV correspondant à cette variation d'exposition (EV = log(exposition)/log 2).

  • -F a b c

    • a : modifie l'exposition en plus ou en moins: 1.0 pas de modification; <1.0 réduit l'exposition; > 1.0 accroît l'exposition ;

    • b: préserve ou non les HL ; 0= sans préservation ; 1= avec préservation calcul de la luminosité par modèle CIE ; 2= avec préservation HL calcul de la luminosité par modèle HSL;

    • c: niveau de seuil : 0= 32768, 1=42768, 2=52768, 3=62768. Il peut être entré n'importe quelle valeur positive entre 0 et 3, par exemple 1.35.

     

  • mais aussi -y <val> (voir les commentaires à modification version 1.41).

  • mais voir aussi -Z <a b> (voir les commentaires à modification version 1.6).

   

   

• 16 bits 'clarté' ou ajustement de la 'luminosité et du contraste' (en gros la racine carré de l'exposition):

  • j'ai introduit cette option sensiblement équivalente à -b (brightness) en 8 bits. Elle permet d'ajuster contraste et luminosité (exposition) -avec une seule option. Cette commande est proche dans son action de la "correction d'exposition" des logiciels classiques, mais elle agit a posteriori du traitement XYZ RGB et des prises en compte de gamma. Du fait de la nouvelle option -F, l'option -L n'est vraiment utile que pour déboucher  les ombres. Par exemple après une réduction d'exposition avec -F, on peut ajouter de l'exposition avec -L en accroissant la valeur pour les BL ce qui globalement débouchera les ombres... (ex -F 0.8 1 0 et -L 1.1 1.4 1.0)

    • option -L [a b c] : a fait varier la clarté globalement, des valeurs comprises entre 0.9 et 1.1 sont souvent nécessaires... mais 1.3 est possible; b permet d'ajuster la clarté (luminosité - contraste) dans les BL mais uniquement pour les options à gamma variable; b est sensible et les coefficients  doivent être très modérés souvent les mêmes que 'a' (0.9 à 1.1..voire 1.3..mais dans certains cas jusque 2.. ou plus),...attention aux artefacts. Par exemple -L 1.1 1.3 1.0 accroît la clarté globale de 10% et celle des ombres de 30%

    • ne se servir de b différent de a que si on n'a pas pu régler le problème par le choix des gamma variables.

    • cette option amène  un recalcul  du coefficient linéaire de gamma variable lorsque a et b sont différent de 1.0

    • éventuellement utiliser en plus  'c' entre 0.9 et 1.1 pour corriger l'histogramme au lien entre partie linéaire et partie puissance (vers valeurs RGB aux environs de 20).[trou vertical ou à l'inverse pic vertical] surtout utile pour les gamma élevés et à partie linéaire dure. Utiliser 'Histogrammar' de G.Luijk qui permet une observation  fine des histogrammes en 16 bits.

    • le plus souvent : -L 1.2 1.2 1.0 - si bien sûr on souhaite accroître la clarté de l'image!

    • sur les gamma constants, seul le premier paramètre est pris en compte (nécessité d'entrer les 3)

    • par exemple en comparant l'action de cette commande à "correction d'exposition" de Nikon Capture Nx , avec réglage du gamma -g 4

      •  L 0.6 0.6 0.9 correspond sensiblement à -1,8 IL sous NX (noter le dernier paramètre 0,9 pour corriger l'histogramme)

      • L 1.0 1.0 1.0 correspond sensiblement à -0,1 IL sous NX

      • L 1.2 1.2 1.0 correspond sensiblement à  +0,4 IL sous NX

• Remarque sur l'utilisation des options -p - o

  • il pourra m'être rétorqué que en utilisant les options -p fichier.icm et -o fichier.icm, on arrive sensiblement au même résultat! Pas exactement car l'utilisation des bibliothèques LCMS (ici la 1.17) se traduit par des gamma uniformes liés aux 'conventions', par exemple si fichier.icm est Prophoto.icm, le gamma TRC sera de 1.8, si fichier.icm est AdobeRGB le gamma TRC sera de 2.2. Alors que l'option -Y permet de s'affranchir de cette imposition, en associant si on le souhaite par exemple: a) l'espace Prophoto; b) un gamma variable général de 2.2; c) un gamma TRC de 1.6...

  • l'utilisation de l'option -p seule donne des résultats variables et force Dcraw à se mettre en "sans espace de sortie". J'ai essayé d'élaborer un profil interne d'étalonnage pour mon boîtier et les résultats sont mauvais, alors qu'avec le profil externe (c'est à dire appliqué sur le TIF de sortie) tout fonctionne correctement.

  • l'option -o fichier.icm seul est inopérante!

  • l'utilisation des bibliothèques LCMS (qu'utilisent par ailleurs Capture NX et Gimp) se traduit par un mauvais rendu des ombres très profondes - voir par ailleurs sur mon site ces tests, en particulier en estompant le rendu des bleus dont L est compris entre 0 et 2..Cette restriction semble avoir été levée avec la bibliothèque 1.17.1 pour Nikon Capture NX2, où les ombres bleues sont maintenant conformes. A vérifier toutefois avec d'autres logiciels.

  • la comparaison entre les options -p fichier.icm -o fichier.icm et -o [0..9] est évidemment en faveur de -o [0..9]. Essayer le même fichier avec les 2 options et voyez les différences...elles sont énormes.

  • ces 2 options -p -o fonctionnent assez correctement avec les espaces qui ne sont pas à triplet matriciel (avec des LUT).

• Option -o : espace colorimétrique de sortie

  • inchangés :

    • -o 0  :- sortie en raw sans espace de couleur

    • -o 1  : sRGB D65

    • -o 2  : AdobeRGB D65

    • -o 3  : WideGamutRGB D50 ou D65

    • -o 4 : Prophoto D50 ou D65

    • -o 5 : XYZ

     

  • Ajoutés à partir de version 1.40

    • -o 6 : CIE RGB

    • -o 7 : Bruce RGB D65

    • -o 8 : DonRGB D50

    • -o 9 : Beta RGB D50

    Bien sûr il est possible d'en ajouter si ces espaces sont à triplet matriciel (ce qui exclue par exemple PhotoGamutRGB ou sRGB_V4_ICC_reference...).

• Ligne de commande possible (celle que j'utilise en 16 bits)

  • Dcrawggt87 -w -v -4 -o 4 -T +M -g 4 -Y 0 1.0  -L 1.2 1.2 1.0 xxx.nef

  • En utilisant ces options (à moduler pour -L) on obtient une image 16 bits quasi identique en rendu aux images 8 bits

   

• Équilibrage des canaux verts :

  • lors de l'interpolation AHD il peut se produire des labyrinthes, M.LLorens   a mis au point l'option -l avec 2 paramètres . Cette option ajuste la matrice de Bayer et semble très efficace.

  • un bug dans mes versions précédente à la 1.30 pouvait perturber le fonctionnement.

  • L'interpolation AHD tend à faire accroître le bruit : recommandation, lui associer un débruitage léger - n 100

  • -l  <a b> :

    • a : 0 ne fait rien, 1 corrige globalement , 2 corrige globalement et localement

    • b: rayon en pixels : 2 à 12

     

• Gamma variable 8 bits :

  • possibilité de 5 options pour ajuster le gamma 8 bits (je maintiens cette option pour mémoire!)

   

• D50 :

  • j'ai modifié les variables "8 bits" et "16 bits" pour ajuster les espaces de sortie en D50 plutôt que D65 (les écarts sont faibles) pour les espaces WideGamutRGB et Prophoto

  • l'option -I 1 repositionne Widegamut et Prophoto en D65

• autres options : entrer dcrawggt87et lire les commentaires

Un petit fichier Dcrawggt.bat qu'il suffit de placer dans c:\Documents and settings\utilisateur\Send to    En remplaçant 'utilisateur' par votre code / nom .

Puis une fois cela fait, ouvrez l'explorateur de windows, allez jusqu'au(x) fichiers à traiter et cliquez droit sur "envoyer vers" et là bien sûr dcrawggt.bat.

Vous devez modifier dcrawggt.bat pour adapter le dossier dans lequel vous placez Dcrawggt88.exe et aussi les paramètres de la ligne de commande. Par défaut vous avez mon répertoire de travail et le traitement 16 bits en Prophoto.

 Commentaires sur la conversion rgb => Lab (Lch) => rgb

(21 octobre 2008)

Il est naturel de se poser la question de la pertinence d'une telle conversion. En effet si personne (?) ne conteste la supériorité du mode Lab (ou Lch) sur le mode rgb pour travailler l'image (contraste, saturation , accentuation, etc.) en agissant sur un seul canal à la fois (souvent le canal L), un certain nombre d'acteurs s'appuyant sur les travaux de B.Lindbloom  et d'autres encore qui affirment que cela ne sert à rien  et même pire détruirait l'image... notamment pour l'accentuation...en particulier du fait des erreurs de calcul et de leur imprécision dans les conversions.

Il est certain que si on ne prend pas de précautions on va droit à la catastrophe...

Ces précautions, quelles sont elles ?

D'abord bien sûr on part des valeurs 'rgb' en 16 bits, qui sont définies en valeurs 'ushort' , c'est à dire de 0 à 65535 et codée sur 2 octets.

La première erreur serait d'utiliser pour les valeurs Lab (Lch) des entiers ou des 'short' qui a priori conviendrait....d'un seul coup on limite le nombre de couleurs. J'ai fait le choix des 'float' (réels sur 4 octets) - et éventuellement des doubles (réels sur 8 octets) pour plus de précision.

La deuxième tient au "clipping" des valeurs lors de la conversion rgb => XYZ => Lab. Les valeurs Lab sont en théorie pour L de 0 à 100, et pour a et b de -128 à +128. Il faut laisser faire les calculs - en s'assurant qu'il puissent se faire - même si on obtient des valeurs aberrantes du type L=-4 ou a=143. il en est de même lors de conversion Lab => XYZ => rgb, où il est important de garder les valeurs négatives 'rgb' qui traduisent le dépassement de gamut, même si par ailleurs il faut offrir la possibilité de "cliper".

La troisième tient au choix de l'espace de conversion pour le calcul - plus on choisira un espace restreint plus le risque de "débordement" sera grand. C'est pourquoi je propose 7 choix en privilégiant le Prophoto. Bien sûr ces choix permettent de "voir" les dépassements de gamut et régler ainsi exposition, contraste, saturation, etc. avant de fabriquer le TIF pour être travaillé sous Photoshop ou équivalent.

La quatrième tient à la méthode calcul,:

• la conversion XYZ => Lab présente des discontinuités qui si elles sont mal gérées vont amener des (petits) artefacts. je peux citer  les constantes 'epsilon' et 'kappa' qui ne doivent pas être entrées comme des réels à virgule mais comme des nombres fractionnaires;
• l'algorithme pour calculer x^1/3,
• etc.

La cinquième tient à la précision des matrices et matrices inverses [3x3]. Il ne faut pas se contenter d'entrer les 2 matrices par leurs valeurs, mais à partir de la matrice [M], calculer en double précision le matrice [M-1] par inversion de matrice. Il faut s'assurer aussi que les points blancs de référence correspondent bien aux définitions des matrices (vérification par calcul).

Si on fait ces choix et qu'on vérifié les calculs - j'ai doté ma version de Dcraw de la fonction -$ a b c d ( ab c d coordonnées de la fenêtre), qui permet de voir les valeurs 'rgb' et 'Lab' avant une opération et après. En théorie si on ne fait aucune opération, et seulement la conversion rgb=>Lab puis Lab =>rgb, on devrait retrouver les mêmes valeurs.

Les essais (nombreux) faits sur de petites zones ou de grandes, sur des clichés "normaux" ou sur des images avec un gamut important (celles de la mire 468 couleurs dont 40 environ sont hors WidegamutRGB, amènent des erreurs quasi négligeables de l'ordre de la troisième décimale après la virgule pour des valeurs rgb mis dans l'intervalle [0..255]. Par exemple on trouvera une valeur r=65.347 avant conversion et r=65.345 après conversion. ce qui est sommes toutes plus que négligeable et du même ordre de grandeur que l'approximation des ushorts (entre 2 valeurs 16 bits, l'arrondi se fait avec une imprécision de 0.5 / 65535. Bien sûr on obtiendra souvent des écarts plus importants de l'ordre de 0.1 valeurs rgb, par exemple 118.703 et 118.695 dans le cas d'images très fortement surexposées ou sous exposées (car là on est tellement hors gamut...)

Toujours dans ces contrôles, en prenant 2 fois le même TIF (à partir du même NEF), mais en ajoutant au deuxième la transformation rgb=> Lab =>rgb, et en faisant un calque de différences en mode Lab 16 bits (L varie dans ce cas de 0 à 32768), l'image est absolument noire, et si on déplace la pipette, en général Lab affiche 0,0,0; quelques pixels affichent 0,1,0 ou 1,0,0 ou 1,0,1..soit des écarts très faibles.

L'examen de l'histogramme en 16 bits avec 'Histogrammar' ne montre pas de différences notables.

J'obtiens le même type de résultat pour l'opération "accentuation" (sharpen). A titre de comparaison, afin de montrer l'incidence du choix "Lab" plutôt que 'rgb' pour l'accentuation, j'ai tenu à comparer 2 couleurs (une dans une zone d'aplat et l'autre dans une transition) par 3 accentuations qui à l'oeil donnent le même sentiment de netteté: a) avec Dcraw modifié à partir du NEF avec l'option -µ; b) avec Photoshop (sur l'image TIF neutre obtenue par DCRAW sans l'option -µ); c) avec ACR à partir du NEF..

Si le système est parfait on doit avoir les composantes a et b de Lab inchangées après accentuation:

Zone d'aplat après accentuation

Zone de transition après accentuation

(1) je n'ai pas fait volontairement usage des masques de fusion avec le canal luminosité; Dans ce cas de 'utilisation d'un tel masque, les valeurs 'a' et 'b' sont sensiblement conservées.

* ramené par calcul aux valeurs "L" et "a" équivalentes, car pour ACR il est difficile d'obtenir les mêmes chiffres que DCRAW du fait des réglages de luminosité et contraste de ACR... et aussi du fait d'une colorimétrie différente..(voir mes essais avec mire sur mon site). Donc... ACR travaille  a priori en mode Lab (ce qui se confirme lorsqu'on active les fonctions avec Alt en mode >= 100%)

** le repérage des pixels n'est pas évident car ACR (contrairement à DCRAW) "mange" quelques pixels sur les bords...d'où quelques imprécisions.

*** contrairement aux "croyances" Photoshop travaille en 15 bits et non en 16 bits

De plus, si on va à des valeurs extrêmes  (qui n'ont que peu d'intérêt photographique, mais montrent l'efficacité par absence de chromatisme) - rayon (3) et force élevés...on voit apparaître avec Photoshop de forts artefacts chromatiques (sauf si on active un masque de fusion "luminosité"), qui sont quasi absents avec Dcraw...et présents modérément avec ACR

Les résultats parlent d'eux mêmes. On dira que j'enc..e les mouches, mais pas plus que ceux qui regardent une image à 300% pour voir les différences entre logiciels pour l'interpolation...C'est ici DCRAW qui conserve le mieux les couleurs aussi bien en aplats qu'en transitions, suivi de près par ACR... et Photoshop ferme la marche, sans être catastrophique. A noter  que ces "dérives" sont invisibles à (mon) oeil...et avec (mon) moniteur sRGB!

Donc moralité, j'ai volontairement limité le choix des valeurs Lab à 'float' (le passage à 'double' occupant beaucoup plus de mémoire et ne faisant quasiment rien gagner, mais bien sûr si on passait les 'rgb' à 32 bits...il faudrait passer la conversion en 'double').

Conclusion: avec ces précautions on peut sans problèmes utiliser la conversion rgb=> Lab et réciproque pour toutes les opérations y compris l'accentuation.

Présentation de l'algorithme d'accentuation (maj 14/11/2008)

Description de l'algorithme de base

Une boucle est initialisée qui scrute chaque pixel de l'image (en débutant toutefois, à la deuxième ligne et deuxième colonne, afin de loger une matrice de travail 5x5  (un peu plus..) ci-dessus.. (en réalité on va jusqu'à une matrice 7x7 pour le microcontraste).

Pour chaque pixel, repéré en noir ci-dessus, on calcule la "moyenne" des pixels colorés (matrice 5x5) en donnant aux pixels les plus proches du centre plus de poids que ceux situés sur les bords. On a à faire à un filtre "passe-bas" dont j'ai mis 4 options de "doux" à "dur" dans l'algorithme. Les cellules autre que blanches ci-dessus correspondent à celles utilisées par le passe-bas

Aucun décalage de pixel n'est effectué.

Ensuite, selon le rayon 0,5 - 1 - 1.5  - 2  ou 3, on mesure les minima et maxima de la zone concernée. Par exemple pour un rayon de 0.5, on mesure 4 cellules  (les verts et les parmes ), pour un rayon de 1.5 on mesure 12 cellules  (les verts, les parmes,  les bleus (2), et les jaunes), etc... pour finir avec les balncs...pour un rayon de 2.. en ajoutant les 24 blanches supplémentaires pour un rayon de 3.etc.

Ces valeurs permettent de calculer un contraste progressif  qui s'applique à chaque zone choisie correspondant au choix du rayon. La valeur moyenne est la valeur du pixel central (noir), les minima et maxima permettent de déterminer deux  seuils à partir desquels agit un filtre  qui modifie la "force" (en dessous du seuil) et laisse la "force" au-dessus du seuil, avec une réduction progressive pour amener la force à 1 aux limites. Le niveau du seuil est déterminé par le second filtre "seuil" qui agit sur le rapport aux minima et maxima. On crée ainsi une courbe en "S" pour chaque paquet de pixels, courbe en "S" dont la pente est la "force" et les points d'inflexions tracés par les deux filtres. Ces filtres agissent sur les transitions sans trop affecter la texture.On notera que la valeur moyenne peut être très différente de L=50 et que les minima et maxima ne sont pas symétriques...

Attention cette courbe est de principe et ne traduit que partiellement la réalité. En effet on travaille souvent avec 8 pixels ou 12 (voire moins), on a donc affaire à une distribution discrète et non continue.

Bien sûr le système est récursif, au pixel suivant, le noir se déplace d'un cran vers la droite, puis à la ligne suivante, d'un cran vers le bas. Chaque pixel est donc "visité" plusieurs fois et ainsi recalculé (jusque 24 fois pour un rayon de 2 ), aussi bien pour la "moyenne" du point central que pour les contrastes.

On se rend compte que cet algorithme consomme beaucoup de temps de calcul dès qu'on accroît le rayon. Par exemple pour un capteur de 10M°, on effectue jusque (pour une "passe") 250 Millions de calculs de contrastes local.

J'ai ajouté deux paramètres supplémentaires dans la boucle de calcul:

• a) à partir d'une mesure de la cellule centrale en valeur L (luminance Lab), si cette valeur est inférieure à 'x' la partie contraste n'est pas effectuée pour ne pas générer du bruit; ce paramètre agit également dans la courbe de contraste pour limiter l'accentuation  des valeurs et ainsi éviter les BL trop basses et HL trop hautes.
• b) si l'écart maxi-mini est inférieur à une certaine valeur (faible) c'est probablement qu'on se trouve dans un aplat. Dans ce cas , là aussi le contraste est omis. Ce qui de plus fait gagner du temps de calcul et évite de créer des artefacts et rend mieux les ciels ou la peau par exemple. Ce paramètre joue sur la texture (les détails) sans agir sur les transitions (ou alors il faut entrer de très fortes valeurs)

J'ai ajouté un paramètre qui réduit le nombre de cellules  pour réaliser le calcul du contraste. Rien n'est changé pour les rayons de 0.5 , 1  mais pour 1.5, 2  et 3 environ 2 fois moins de cellules sont concernées (celles situées en périphérie sont maintenues).En premier examen la qualité semble inchangée (la valeur "rapide" est le paramètre par défaut).

Bien sûr tout est effectué en mode Lab sur le seul canal de la luminance.

Quand faut-il accentuer ?

Vaste débat, on entend tout et son contraire... En première étape du dématricage après l'interpolation, en deuxième après le bruit..ou en post traitement.

Car bien sûr l'accentuation peut faire monter le bruit. Notamment les algorithmes traditionnels (Unsharp mask) qui agissent de la même manière quelque soit la luminance.

D'où ma volonté de sortir des sentiers battus et pouvoir agir sur le canal de la luminance en différenciant les BL et HL. C'est possible avec l'algorithme que j'ai mis au point...

Donc de mon point de vue il faut faire après le débruitage, avec de petits rayons... quitte à faire une deuxième accentuation en post traitement.

Pourquoi en Lab

Ceci peut paraître évident...mais là encore il suffit d'un essai comparatif pour voir que pour toutes les gammes de couleurs, mais c'est vraiment visible dans les blancs et gris, que le mode Lab (L) maintient la teinte, chose que par exemple Photoshop ne fait pas.

Mais quels sont les inconvénients de cette accentuation ?

J'en vois plusieurs:

1. celui d'être différent.. et rien que cela suffit pour discréditer
2. en étant différent les paramètres et leurs influences ne sont pas les mêmes, donc difficulté d'apprentissage
3. le nombre de paramètre est plus important d'où plus de complexité à maîtriser
4. et enfin l'algorithme devient consommateur de temps (comme le carré du rayon) pour les rayons importants (à pondérer avec l'option "rapide" par défaut).
5. plus les défauts qui peuvent apparaître

Remarque sur les "rayons"

Je ne sais pas comment font les "autres", mais il est très difficile.. d'une part d'imaginer un rayon lorsqu'on évoque des pixels et d'autre part de penser qu'il puisse y avoir des rayons inférieurs à 1 pixel.

En effet les pixels ne pouvant se couper en deux, c'est un exercice intellectuel de "haut niveau".

Voilà simplement comment je conçois les rayons (interprétation toute personnelle).

A partir de la cellule noire:

• le rayon de 3 correspond aux coins de la matrice 7x7..on pourrait imaginer un 2.5
• celui de 2 aux cellules externes de la cellule 5x5
• celui de 1.5 aux cellules jaunes
• pour 1 les bleus
• pour 0.5 les verts et parmes
• et pour 0.375 ce sont les verts et parmes mais une fois sur 2

Effectivement les pixels en diagonale sont "plus loin" que les adjacents.. d'où 0.5 et 1.. et 1.5 et 2. Je reconnais que pour 0.375 c'est un peu tiré par les cheveux...Mais l'idée est bien pour réduire le rayon de scruter  par un algorithme les pixels les plus proches du centre.

Ensuite selon les algorithmes rapides ou lent, on incorpore plus ou moins les pixels centraux dans le calcul en plus de ceux en périphérie (bien sûr ce n'est vrai que pour les rayons supérieurs à 1).

Mais bon!...

Les calculs données ci-dessous en 2) 3) 4) 5) sont des extraits des feuilles qui me servent à élaborer les profils ICC. En ce sens ces extraits ne contiennent pas toutes les fonctionnalités que j'aie pu utiliser.

1° Quelle profondeur de champ, quel angle de champ, quels cadrages en fonction du format (pellicule, capteur) et de la focale

I1 -Information sur les calculs à partir des données spectrales Je ne donnerais pas de feuilles de calculs, car le volume de données est vraiment trop important (de l'ordre de 6 à 8M°), mais j'informerai sur la manière de la faire. La feuille de calcul permet de traiter plus de 500 données spectrales, les convertir en XYZ en fonction de l'illuminant et de T. Bien sur si quelqu'un est intéressé ! Elle adapte le résultat à la fois par la méthode de Bradford (utilisée par Photoshop) et CIECAMO2 (utilisée par certains profilers). Les valeurs RGB sont calculées en Prophoto, WideGamutRGB et AdobeRGB, en incluant les valeurs > 255 et les valeurs négatives pour traduire le dépassement de l'espace. Si on appelle : (les calculs relatifs aux données spectrales ci-dessous sont dérivés de ceux fournis par B.Lindbloom) Pi la distribution spectrale de la source émettrice, xi yi zi qui correspondent à l'observateur standard 2° de la CIE Ii la distribution spectrale de l'illuminant N =SyiIi On obtient : X = 1/N (S xiPiIi) et similaire pour Y et Z. Pour l'illuminant lumière du jour on a : Id(l) = Io(l) + M1*I1(l) + M2*I2(l) avec : M1 = (-1,3515 - 1,7703xd + 5,9114yd) / M M2 = (0,03 - 31,424 xd + 30,0717 yd) / M M = 0,0241 + 0,2562 xd - 0,7341 yd Avec xd et yd point blancs calculés en fonction de la température T : xd = -4,607*109 / T3 + 2,9678 * 106/T2 + 0,09911* 103 / T + 0,244063 pour compris entre 4000K et 7000K et yd =-3 xd2 + 2,87xd - 0,275 Il existe un calcul "semblable" pour l'illuminant incandescent...Pour les autres illuminants F, etc., on se référera à des normes de données. Les calcules des valeurs RGB sont similaires, mais ne font pas intervenir I.   Une fois les calculs de X, Y et Z réalisés pour l'illuminant en cause (D, incandescent, F, etc.), on ajuste le calcul pour tenir compte de l'adaptation chromatique. J'ai choisi la dernière modélisation qui prend le mieux en compte les aspects physiologique et psychologique qui est la méthode CIECAM02, dont le processus est décrit ci-dessous Puis on réalise une conversion "classique" vers Lab...

2° Matrice de conversion RGB - XYZ 2°bis Matrice de conversion RGB - XYZ et matrice d'adaptation chromatique (BradFord et CAM02)- calcul des points blancs Ce petit utilitaire permet facilement de reconstruire les caractéristiques globales d'un espace colorimétrique (Adobe98, BruceRGB, ProPhoto, sRGB, etc.) : il "ne fait" que calculer la matrice de conversion RGB ==> XYZ en partant des données du point blanc et des 3 couleurs primaires (rouge, vert, bleu). La version 2°bis réalise de plus par la méthode de Bradford les conversions d'adaptation chromatique pour passer par exemple de D55 à D50 ou plus originalement d'avoir les caractéristiques d'un illuminant comme D45. Elle permet aussi les conversions d'adaptation chromatique par la méthode CAM02 plus récente. Nouveau : vous pouvez calculer directement les valeurs des points blancs en xyY ou XYZ soit pour l'illuminant D (lumière du jour) de 4000K à 10000K, soit pour l'éclairage tungstène (dont l'illuminant A) à partir de formules de rayonnement du corps noir (entre 2500 et 4000K)

3° Conversion RGB en CIE XYZ et Lab: J'ai eu besoin, dans certaines circonstances de convertir des valeurs RGB (RVB) en valeurs Lab (et CIE XYZ). Il existe de nombreux sites dont celui de B.Lindbloom qui font ce genre de choses mais : 1) les résultats obtenus à partir de ces calculateurs différent sensiblement... et pas toujours dans un rapport faible ou fiable... 2) je n'ai pas trouvé de site qui convertissent des données sous forme de tableaux - on ne trouve que des saisies élémentaires de trio R,G,B. Après maintes recherches, il s'avère que les algorithmes utilisés par B.Lindbroom (copyright) : (http://www.brucelindbloom.com , merci à lui pour les concepts et les calculs...) soient les plus conformes (les plus récents); de plus ce site est très bien fait en termes de pédagogie et contenu... Je n'ai fait qu'utiliser ce qu'on trouve également en cherchant bien par ailleurs sur Wikipedia...ou d'autres sites... J'ai utilisé les formules et les matrices de son site ou de similaires...(wikipedia...) - les calculs sont simples et font appel des mathématiques élémentaires  (fonction linéaires, matricielles, puissance,...). Dans la feuille de calcul tout est paramétrable, depuis l'espace de travail (SRGB, Adobe RGB,...), le point blanc (D65, D50...), le gamma, etc. Il suffit de changer les paramètres des matrices... Bien sûr rien n'interdit d'utiliser le tableur pour des calculs élémentaires (une ou deux valeurs RGB). J'ai réalisé ces feuilles de calcul avec OpenOffice en 2 formats, ce qui permet de les lire sous Excel et Linux Feuille calcul Windows Xls Feuille calcul format ods Si ce travail peut être utile à certains!

4° Conversion Lab en CIE XYZ et RGB Ce calcul est l'inverse du précédent, il m'a essentiellement servi, pour l'élaboration de profils, comme vérificateur de calculs mais également pour "évaluer" le rapport entre saturation et chromaticité. Comme dans l'exemple précédent, le calcul est fait pour l'espace AdobeRGB et l'illuminant D50 avec les conversions appropriées D65 ainsi qu'un gamma de 2,2. La méthode de conversion choisie utilise d'une part, les matrices de conversion RGB==> XYZ et réciproquement, et d'autre part les conversions d'illuminant soit par la méthode de Bradford ou soit par celle de Von Kries (à vous de charger les valeurs appropriées). Le tableau est limité à une vingtaine de lignes, vous pouvez bien sûr l'augmenter en copiant les formules...   Feuille de calcul Windows.xls Feuille de calcul format ods J'ai tenu à compléter ce travail par une feuille de calcul plus approfondie (travail en cours à ce jour 25 juin 07) : prise en compte : a) de valeurs RGB négatives par calcul; b) de valeurs RGB maxi évaluation de la saturation résultante (en %) y compris si elle dépasse 100% La feuille ici présentée (j'en possède de nombreuses variantes) présente à partir des valeurs Lab fournies avec la mire DT003 (C.Metairie) - il est possible de prendre n'importe quelles valeurs Lab - : une conversion XYZ à partir du blanc de référence D50 une conversion xyY puis pour chaque espace colorimétrique (AdobeRGB, Prophoto, sRGB) une éventuelle conversion d'illuminant (D50 vers D65), une conversion "rgb" avec le triplet matriciel adhoc, puis une conversion RGB avec le gamma adapté. pour chacun des cas, il est extrait les saturations résultantes y compris > 100%, les valeurs négatives RGB, les valeurs RGB supérieures à 255 J'ai ensuite ajouté à titre de comparaison la conversion dans l'espace PhotogamutRGB_av6c  (avec l'intention colorimétrie relative) qui n'a pas pu se faire par calcul, mais par mesure des 285 valeurs RGB. Je laisse chacun interpréter ! Feuille de calcul 2 Windows.xls

5° Calcul du DeltaE94 d'un volume de données (mise à jour 7 avril 07) J'ai eu besoin pour l'élaboration des profils ICC, d'une évaluation des DeltaE94 en temps réel, c'est-à-dire de pouvoir voir l'incidence des diverses modifications (luminance, contraste, chromaticité, teintes...) sur les deltaE94. La formule de calcul du DeltaE94 est donnée sur ce site. J'ai tenu en plus des mesures de  DeltaE habituelles (moyenne, écart-type, maximum, minimum), à évaluer les 3 delta des 3 composantes L (luminance), C (chromaticité), H (teinte). Le tableau est limité à une vingtaine de lignes à partir des données Lab. Vous pouvez ajouter des lignes... attention toutefois à revoir les limites des formules qui dans l'exemple (xls) sont limitées au nombre de lignes actuelles; j'ai mis à titre d'information au format ods (OpenOffice), une feuille de calcul plus complète, mesurant les écarts par gamme de couleur (cyan, rouge, jaune...) en prenant comme exemple la mire d'étalonnage  du boîtier et les fichiers utilisés. Feuille de calcul Windows.xls Feuille de calcul format ods     Rappel: le "Delta E" a plusieurs références , delta E standard qui correspond sensiblement à :  L1,a1,b1 sont les coordonnées dans l'espace colorimétrique CIE Lab de la première couleur à comparer et L2,a2,b2 celles de la seconde. On reconnaît la formule de la distance Euclidienne. Le delta E correspond à la distance entre deux couleurs placées dans cet espace de couleur. L'espace CIE L* a* b* étant presque perceptuellement uniforme, des couleurs à égale distance dans l'espace Lab (donc ayant un même delta E) devraient être perçues par l'œil humain comme ayant la même différence de couleur. Il existe aujourd'hui d'autres formules plus avancées pour calculer ce delta E (CIE 1976, CIE 1994, CIE 2000, CMC).  Ces nouvelles formules introduisent des coefficients pour ajuster le résultat en fonction de la teinte ou du domaine d’application (arts graphique, textile). La forme dont je me sers dans les calculs qui suivent, notamment pour évaluer les profils, est celle de Delta E94: avec     KL, KC, KH, SL valant 1 pour Delta_E94 et sont différents pour Delta_E2000 Sc = 1+0,045*C1  avec C1=SQRT(a12 +b12) et C2=SQRT(a22 +b22) Sh=1+0,015*C1 Pour laquelle : "L" représente la luminance, "a" la composante rouge / vert variant entre 127 et -128, "b" la composante jaune / bleu "C" représente la chromaticité (peu différente dans sa perception de la saturation) : C= SQRT(a2+b2), variant de 0 à 180 "H" représente la teinte : H=arctg(b/a), variant de -PI à +PI Ces formules et mesures notamment en référence à L*a*b* sont contestables et contestées, néanmoins elles ont à ce jour le mérite d'être les plus universelles, surtout lorsque les valeurs de DeltaE sont faibles. De plus la formule du DeltaE94 (et 2000) est dissymétrique, elle ne se comporte pas exactement de la même manière selon la manière dont on considère la référence. Si "LabRef" est l'ensemble des valeurs de référence (ici reprise en repère 1 dans la formule) et si "LabTest" est l'ensemble des valeurs à tester (ici reprise en 2 dans la formule), les 2 valeurs de DeltaE94 ; "LabRef comparée à LabTest" et "LabTest comparée à LabRef" pourront présenter de petits écarts sur l'ensemble des valeurs, mais ces écarts peuvent être significatifs sur une ou deux valeurs.