(Vers page accueil)          RSS météo

7Menu photo


Mise à jour de la page 14 juin 2011

 

Windows XP et 7 32 bits - v 5.05 -D.Coffin 9.07

Windows 7 - 64 bits - v 5.05Light* D.Coffin 9.07

 
Exécutable

 dcrawjdc

 dcrawjdc64 avec Rawzor

 
DLL

vcomp100.dll

vcomp100.dll

rwz_sdk.dll

 
Package

Redistribuable package VC++2010 (x86)

Redistribuable package VC++2010 (x86)

 

* Light = fonctionnalités essentielles

Ces DLL doivent être dans le même dossier que dcrawjdc64.exe ou dcrawjdc.exe

Si aucune version de VC++2008 ou VC++2010  n'est présente sur votre ordinateur il faut installer :

"Microsoft Visual C++ 2010 Redistributable Package (x86)" (ou la version 2008 pour dcraw901.exe)  disponible sur le site de Microsoft

Utilise les bibliothèques LCMS recompilées (version 2.1)  en 32 bits et 64 bits

base Dcraw D.Coffin Dcraw 9.08 du 15 mai 2011- réalisé avec le compilateur Microsoft - 

Site web de Manuel LLorens

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

Le batch rapide avec la ligne de commande (M.LLorens)

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

Le code C est disponible pour toute personne qui me le demande (sauf bien sûr le code "protégé" ou celui qui n'est pas ma propriété).

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

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)

14 juin 2011: version 5.05 MAJ réalisée à 14h00

 

20 avril 2011: version 5.04 MAJ réalisée à 12h00

 

 

11 février 2011: version 5.03 MAJ réalisée à 12h00

 

3 février 2011: version 5.02 MAJ réalisée à 6h00

 

3 février 2011: version 5.01a MAJ réalisée à 5h00

 

10 janvier 2011: version 5.01 MAJ réalisée à 11h00

 

5 janvier 2011: version 5.0 MAJ réalisée à 15h00

 

4 janvier 2011: version 4.99 MAJ réalisée à 22h00

2 janvier 2011: version 4.98a MAJ réalisée à 11h00

 

1 janvier 2011: version 4.98 MAJ réalisée à 17h00

 

27 décembre 2010: version 4.97 MAJ réalisée à 10h00

 

24 décembre 2010: version 4.96 MAJ réalisée à 9h00

19 décembre 2010: version 4.95a MAJ réalisée à 14h00 puis à 16h30 (bug dans la compilation...= image noire!)

18 décembre 2010: version 4.95 MAJ réalisée à 18h00

 

16 décembre 2010: version 4.94 MAJ réalisée à 15h00

 

13 décembre 2010: version 4.93 MAJ réalisée à 12h00

 

10 et 11 décembre 2010: version 4.92 MAJ réalisée à 14h00

3 décembre 2010: version 4.91- MAJ réalisée à 11h00

 

1 décembre 2010: version 4.90- MAJ réalisée à 17h00

 

30 novembre 2010: version 4.89- MAJ réalisée à 14h00

 

28 novembre 2010: version 4.89- MAJ réalisée à 9h00

27 novembre 2010: version 4.88- MAJ réalisée à 11h00

 

11 novembre 2010: version 4.86 - MAJ réalisée à 16h00

4 novembre 2010: version 4.85 - MAJ réalisée à 16h00

 

 

29 octobre 2010: - MAJ réalisée à 9h00

 

27 octobre 2010: - MAJ réalisée à 9h00

 

 

22 octobre 2010: - MAJ réalisée à 10h00

 

20 octobre 2010: - MAJ réalisée à 14h 40

  • traitement d'une image de D700 200 ISO:

    • dcrawjdc -9 P -q 3 -F 1.8 3 0.1 dossier\D700-200.NEF

    • avec -9 P  qui globalement se substitue à -w -v -o 4 -4 -T -5 4 -W, c'est à dire: w= BdB du boitier, v= affiche informations pendant le traitement , o 4 =Prophoto, -4 = 16 bits, -T =TIF, -W = pas de niveaux auto, -5 4 = gamma LUT 18 bits BT709

    • -q 3 : interpolation AMaZE + Correction aberration chromatique avant interpolation

    • -F 1.8 3 0.1 : correction d'exposition après interpolation  avec 0.1IL de protection des HL

    • pour information, temps de traitement total sur mon ordinateur: 6.5 secondes

     

  • traitement d'une image de D3x à 6400 ISO

    • dcrawjdc -9 P -q 3 -F 2 3 0.1 -H 295 -9 LE 0.005 -9 NW 10 1 30 1.8 1 50 0.7 4 1 0.5 20 dossier\D3x_6400.NEF

    • avec -9 P -q 3 et -F comme ci-dessus, -F agit après traitement du bruit

    • -H 295 récupère les HL en modifiant légèrement l'exposition avant interpolation et mélange les HL : (300-295)/300 soit 5/300 de réduction des multiplicateurs de canaux

    • -9 LE 0.005 : réduit le bruit de ligne (banding)

    • -9 NW :

      •  10 = traitement bruit impulsion et gaussien HF avant interpolation + bruit  impulsion en fin de traitement bruit, on peut essayer 5..10..20..40..60..

      • 1 = nombre de passes luminance à utiliser dans 99% des cas

      • 30 = force wavelet luminance, on peut essayer 20..40..50..60 : valeur moyenne qui traite globalement le bruit de luminance

      • 1.8 : traitement des aplats luminance, renforce x 1.8 le traitement des aplats, 1 annule, on peut essayer 1.3 2 2.5

      • 1: corrige plus ou moins les aplats haute lumière, 1= normal, 0.8 moins fort, 1.5 plus fort

      • 50 : force wavelet chrominance, on peut essayer 40.. 60..80..100, attention aux bavures et risque de désaturation

      • 0.7 : coefficient de réduction pour mieux rendre les rouges (ceux proches de la primaire)

      • 4 : précision du wavelet, on peut essayer 3 (pour bruit faible) ou 5..

      • 1 : edge luminance aplats, on peut essayer 0 1 2 3 ou plus jusque 8, plus on accroît plus les bords seront nets, mais moins les aplats seront traités

      • 0.5 : edge luminance, 1 supprime le edge, plus on baisse entre 0 et 1 plus il y a de détails.. et de bruit

      • 20 : force du micro-contraste final , on peut essayer 10..30

      • pour information temps de traitement sur mon ordinateur: 35 secondes

18 octobre 2010:

Version 4.81 (16 octobre 2010)

Version 4.80 (15 octobre 2010)

Bref cela a pris du temps...

Une fois résolu ces problèmes, j'ai testé l'exécutable...qui plante  sous Windows 7 64 alors qu'il ne plantait pas sous XP...Après débogage (certaines "anomalies" présentes dans le code W7-64 étaient également présentes sous XP, mais ne déclenchaient rien.).je pense avoir traité l'essentiel des bugs et anomalies et apporté quelques menues modifications:

L'exécution de Dcrawjdc.exe s'effectue sans problème sur Windows 7 64 bits, mais en mode 32 bits : si plusieurs processeurs sont présents, ils sont utilisés avec un temps de traitement considérablement réduit; j'ai vérifié sur une autre machine (XP monoprocesseur) que le code s'exécute bien. Par soucis de compatibilité je laisse sur mon site la version précédente dcraw901.exe.

 

Version 4.74(20 août 2010)

Version 4.73(3 août 2010)

 

Version 4.71b (5 juillet 2010)

 

Version 4.71a (3 juillet 2010)

 

Version 4.71 (29 juin 2010)

 

 

Version 4.70 (26 juin 2010)

 

 

Version 4.69 (24 juin 2010)

Version 4.68 (21 juin 2010)

Version 4.67 (19 juin 2010)

Version 4.65 4.66

Version 4.64 (7 juin)

 

 

Version 4.63 (4 juin)

 

 

Version 4.62 (31 mai)

 

 

Version 4.61c (22 mai)

 

Version 4.61 (20 mai)

 

Version 4.60 (19 mai)

 

 

Version 4.59a MAX (16 mai)

 

 

Version 4.59 MAX (11 mai)

Avec les modifications sur le temps de traitement "bruit" et l'interpolation, les temps de traitement globaux (de l'ouverture du raw à la fin d'écriture du TIF) sur ma machine sont les suivants.

 

Version 4.58 MAX (8 mai)

J'ai également ajouté 4 commandes rapides pour limiter les saisies

 

Version 4.57 MAX (6 et 7 mai)

 

Version 4.56 MAX (28 avril)

 

 

Version 4.55 MAX (27 avril)

et aussi amélioration de la vitesse de traitement de mes fonctions noise -9 NW (en partie grâce à OpenMP...) pas de changements de la ligne de commande depuis le 16 avril.

 

 

 

Version 4.54 L (26 avril)

 

Version 4.53a L (24 avril) et 4.53aMax

 

 

 

Version 4.53 (22 avril)

 

Version 4.52b et 4.52c (17 avril 2010 - 19 avril)

 

Version 4.52 (16 avril 2010)

 - 9 NW' a b c d e f g h i j k: reduit bruit luminance Gauss + chrominance"));
 <a> bruit impulsion[0..100] rec=5..65
 <b> nombre passes luminance wavelet 1..2
 <c> puissance wavelet luminance [0..150] rec=20..60
 <d> lissage des aplats [1..2] rec=1.25 d<=1 annule action
 <e> correction haute lumiere des aplats - def=1 [0.01..1.5];
 <f> puissance wavelet chrominance [0..150] rec=30..120]
 <g> filtre sur les rouges [0.1..1] rec=0.5 1=maxi traitement chroma
 <h> precision/qualité wavelet [1..10] rec 4 5 ou 6
 <i> edge luminance aplats [0..8] rec=1 2 3
 <j> edge luminance bords [0.1..1] rec=0.3 a 0.8
 <k> force microcontraste > 10 ..200

 

Exemple de ligne de commande pour D3x 6400 ISO :

Dcraw_99 -w -v -o 4 -4 -T -5 4 -W -q 4 -F 1.8 3 0.1 -9 LE 0.003 -9 NW 5 1 30 1.25 1 100 0.5 4 2 0.5 20 D3x_6400.NEF

 

Noter:

 

 

Version 4.51 (15 avril 2010)

 

 

Version 4.50b (14 avril 2010)

 

 

 

Version 4.50 (10 avril 2010)

 

 

Version 4.49d  et 4.49 e (9 avril 2010)

 

Version 4.49c (8 avril 2010)

 

Version 4.49 et 4.49b (8 avril 2010)

 

Version 4.47 et 4.48 (6 avril 2010)

 

 

Version 4.46 (4 avril 2010)

 

 

 

Version 4.45 (1 avril 2010)

<e> parametre HL  def=1
<f> puissance wavelet chrominance [0..150] rec=30..120
 <g> precision wavelet [1..10] rec 4 5 ou 6
<h> edge [-4000..3000] rec -1000 +1000
<h> g=0 annule la construction du 'edge'
<i> force microcontraste > 10 ..200
 
Pour image D3x 6400 ISO : -9 NW 5 1 30 1.25 1 120 5 0 20

 

 

 

Version 4.44a (30 mars 2010)

 

 

Version 4.44 (30 mars 2010)

 

 

 

Version 4.43 (29 mars 2010)

 

 

Version 4.42b (26 mars 2010)

 

Version 4.42 (25 mars 2010)

 

 

Version 4.41c (23 mars 2010)

 

 

Version 4.40 et 4.40a (23 mars 2010)

 

 

Version 4.39 (20 mars 2010)

 

 

Version 4.38 (17 mars 2010)

 

Version 4.37b (16 mars 2010)

 

Version 4.37 (15 mars 2010)

 

Version 4.35 (11 mars 2010)

 

 

Version 4.34 et 4.34a (9 mars 2010)

 

 

Version 4.33b (8 mars 2010)

 

 

Version 4.32 et 4.33 (7 mars 2010)

 

 

Version 4.31 (4 mars 2010)

 

 

Version 4.30 (21 et 23 février 2010)

 

 

Version 4.29a (20 février 2010)

 

Version 4.29(19 février 2010)

 

 

Version 4.28a (18 février 2010)

 

Version 4.28 (17 février 2010)

 

Version 4.27 (16 février 2010)

 

 

Version 4.25 - 4.26 (14 15 février 2010)

 

 

Version 4.23  - 4.24(12 13 février 2010)

Version 4.22 (11 février 2010)

 

 

 

Version 4.21 (7 février 2010)

 

 

Version 4.20 (5 février 2010)

 

 

Version 4.17 (6 janvier 2010)

 

 

 

Version 4.16 (5 janvier 2010)

 

 

Version 4.15 (3 janvier 2010)

 

 

Version 4.13 (29 décembre 2009)

 

Le traitement pour une image à 25600ISO - D700 : -9 NRM 50 2 2 -3 8 400 -9 et pour une image à 6400 ISO - D3x: -9 NRM 50 1 2 -3 6 1000 -9

 

 

 

 

Version 4.11 (27 décembre 2009)

Le traitement pour une image à 25600ISO - D7000 : -9 NRM 50 2 2 3 4 0 -3 et pour une image à 6400 ISO - D3x: -9 NRM 50 1 2 3 3 0 -3

 

Les temps de tri pour les 2 canaux 'a' et 'b' sont au total pour l'image de D700 à 25600 ISO de 3,7 sec et pour celle de D3x à 6400 ISO de 5,5 sec.

 

 

Version 4.09 (24 décembre 2009)

Version 4.07 (19 décembre 2009)

 

Version 4.06 (18 décembre 2009)

 

 

 

 

Version 4.05 (15 décembre 2009)

 

 

 

Version 4.04 (14 décembre 2009):

 

Version 4.03

 

Version 4.01

 

Version 4.0

 

 

Version 3.99

 

Version 3.98

 

 

Version 3.96

 

 

 

Version 3.94 - 24 nov 2009

 

 

 

 

Version 3.93 - 22 nov 2009

 

 

 

Version 3.92 et 3.92a - 21 nov 2009

 

 

Version 3.90 et 3.90 b

 

Version 3.89

 

 

Version 3.86

 

 

Version 3.85

 

 

Version 3.83a

 

 

Version 3.81

 

Version 3.80

 

Version 3.79

 

Version 3.78

 

Version 3.77

 

 

Version 3.76

 

Version 3.73  (voir tutoriel)

 

Version 3.62

 

 

Version 3.52

 

Version 3.51

 

Version 3.50 a

 

 

Version 3.48a

Version 3.48

 

Version 3.47

 

 

Version 3.45

Version 3.42

 

Version 3.39a et b et 3.40 3.41

 

Version 3.39

 

Version 3.37

 

Version 3.36a

Version 3.36

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.

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 :

Comparaison de quelques couleurs avec traitement des BL

(traitement fait en Prophoto)

référence mire 468 couleurs

Origine

BL avec algo RGB YIQ

BL avec algo Lab

b1 - gris neutre

L=5 a=1 b=-3

L=15 a=2 b=-4

L=12 a=1 b=-3

k23 - rouge < sRGB

L=9 a=6 b=4

L=17 a=12 b=5

L=15 a=9 b=5

L16 - vert - limite sRGB

L=14 a=-16 b=5

L=25 a=-18 b=6

L=23 a=-15 b=5

K3 - bleu - limite sRGB

L=9 a=0 b=-24

L=20 a=0 b=-28

L=19 a=0 b=-23

H9 -bleu hors sRGB

L=6 a=30 b=-58

L=14 a=37 b=-69

L=16 a=25 b=-54

H10 - bleu hors Adobe

L=29 a=1 b=-69

L=40 a=0 b=-80

L=40 a=-2 b=66

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


 

 

Version 3.35

 

 

Version 3.31 et 3.33

 

 

 

Version 3.30

 

Version 3.28

 

 

Version 3.25

 

 

Version 3.23

 

 

Version 3.22

 

 

Version 3.21

 

Version 3.17 à 3.20

 

 

Version 3.16

 

 

 

Version 3.14

 

 

Version 3.11

 

Version 3.00

 

 

 

Version 2.98

 

 

Version 2.97

 

Version 2.95 - 2.96

 

 

Version 2.92 - 2.93

 

Version 2.90

 

Version 2.88

 

Version 2.86

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

 

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

 

 

Version 2.80

 

 

 

Version 2.77

 

 

Version 2.75

 

Version 2.73

 

 

Version 2.71 - 2.72

 

Version 2.70

 

 

 

Version 2.65 - 2.66...+  2.68

 

Version 2.62 et 2.63

 

 

Version 2.60

 

 

 

 

 

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:

 

Version 2.54

 

 

Version 2.53

 

 

Version 2.51

 

Version 2.50

 

 

 

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:

 

 

Version 2.45

 

Version 2.34

 

 

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

 

 

Modifications version 2.0

 

Modifications version 1.94

 

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

 

 

Modifications version 1.91

 

 

Modifications version 1.88

 

 

Modifications version 1.85

 

 

 

Modifications version 1.84

 

Modifications version 1.83

Modification  version 1.80

 

Modifications version(s) 1.70 à 1.79

 

 

 

Modifications version(s) 1.60


                 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




                 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

 

                 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 :
 

 

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 :

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.

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

  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 :

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

  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:

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

 

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

     

  • 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

     

     

     

     

     

     

     

    Pour les allergiques à la ligne de commande

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

    Valeurs (15 bits***)

    Original avant accentuation

    DCRAW avec accentuation

    Photoshop(1) (filtre renforcement)

    ACR* **

    L

    20681

    20681

    20681

    20681

    a

    -602

    -602

    -580

    -602

    b

    -1713

    -1712

    -1720

    -1714

    remarque

    ""

    pas de dérive de couleur , aussi bien en chromaticité que teinte

    dérive faible de couleur en chromaticité et teinte

    pas de dérive de couleurs, en chromaticité ou teinte

    Zone de transition après accentuation

    Valeurs (15 bits)

    Original avant accentuation

    DCRAW avec accentuation

    Photoshop(1) (filtre renforcement)

    ACR* **

    L

    23654

    23162

    23937

    23162

    a

    -426

    -420

    -491

    -420

    b

    5986

    6026

    6150

    -6058

    remarque

    ""

    dérive très faible de teinte et chromaticité

    dérive de couleur en chromaticité et teinte

    dérive  faible de couleurs en teinte et chromaticité

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

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

    3

    3

    2.5

    2.5

    2.5

    3

    3

    3

    2

    2

    1.5

    2

    2

    3

    2.5

    2

    1

    0.5

    1

    2

    2.5

    2.5

    1.5

    0.5

     

    0.5

    1.5

    2.5

    2.5

    2

    1

    0.5

    1

    2

    2.5

    3

    2

    2

    1.5

    2

    2

    3

    3

    3

    2.5

    2.5

    2.5

    3

    3

    A partir de la cellule noire:

    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!...

     

     

     


     

    Quelques utilitaires

    Calcul du DeltaE94 d'un volume de données (tableau)(mise à jour 7/04/2007)

    Conversion d'un volume de données (tableau) Lab en CIE XYZ et RGB (2/2007) et des valeurs RGB>0 ou > 255 - incidences sur les saturations -(6/2007)

    Conversion d'un volume de données (tableau) RGB en CIE XYZ et Lab (12/2006)

    Matrice de conversion  RGB / XYZ - espace colorimétrique  et adaptation chromatique (Bradford et CAM02)- calcul des points blancs- (20 mars 2008)

    Information sur les calculs à partir des données spectrales

    Profondeur de champ, angle de champ, cadrage... (2006)

    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.



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

     

    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.