Le meilleur dématriceur ?

[Olivier-P]

Le fichier en entier est ici .

En densifiant le ciel, on fait apparaître une dérive magenta dans les nuages.

Aie aie aie. Ce serait absolument catastrophique en tirage, ne peut se permettre que le A6 ou A5 à peine.

Tous les dégradés de chroma sur les nuages sont délirants, passant de gris divers à des roses, des bleus de contours, des magentas, etc ...

Ce n'est pas une critique, c'est un pb connu, et c'est exactement pour cela que les ingés interdisent à ces zones d'être "pseudo rattrapées", je tire en grande taille depuis des années, pour des clients et pour bibi et nous avons de plus en plus ce type de fichier. Ce n'est pas la bonne méthode pour tirer un fichier abimé, altéré définitivement, vers une impression ou une présentation "acceptable" comme je disais. Descendre les chromies est la seule façon possible, l'oeil est absolument impitoyables sur les changements de TC (des zones à forte luminance).

De plus il n'est interdit de penser que les interprétations du logiciel avec plusieurs zones tres bleues sont parfaitement fausses, la zone verte centrale oui comme je le disais, mais TOUTES celles cramées doivent être des nuages blancs et gris. Pourquoi ? parce que la luminances des ciels bleus est largement inférieur aux nuages, c'est une observation incontournable. C'est pourquoi par défaut le graphiste ne se trompe que peu en mettant une chromie abaissée, et surtout sans dominantes, bref une zone grise-blanche.

La limite de ces logiciels ou de ces ruses n'est pas imputable à un mauvais codage, mais au dépassement de la linéarité des canaux rvb des apn, parfaitement anarchiques lorsqu'ils dépassent ou approchent les saturations, et aussi des dérives de BDB. Par exemple ici, pour trouver le maximum de l'apn, se caler à 7300k, et comme par hasard on retrouve les gris manquants ( mais dérives sur les bords ) car les apn ont un calage usine tres haut ( donc évite le cramage ) mais c'est faux sur le reste. Néanmoins on obtient au moins les infos à mettre dans un calque. Ainsi il n'y a pas de zones bleues autant, et on reste en chromie égale ( ou presque ) en TC des nuages.

C'est néanmoins de l'invention, il manque un canal, devenu anarchique ( ou cramé parfois ) ici.

Il est complétement illusoire de croire récréer cette photo.

Il est totalement impossible de rendre la chromie du ciel, sans détruire la chromie ... C'est un sacrifice mais c'est le seul utile et tirer alors en grand format. Je le répète, il y a peu ou aucune chance de se tromper, les TC des ciels sont uniformes à ces heures de la journée, l'illuminant étant unique et complétement dominant de fait.

[jdc]

J'ai fait une mini mise à jour de la version de Dcrawggt87 (version 1.31)

    * 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

[polohc]

Aie aie aie. Ce serait absolument catastrophique en tirage, ne peut se permettre que le A6 ou A5 à peine.
Tous les dégradés de chroma sur les nuages sont délirants, passant de gris divers à des roses, des bleus de contours, des magentas, etc ...

C'est sans doute maintenant le point à vérifier en A3+ par ex.
Des nuages rose ne gênent pas forcément, on en voit dans la vraie vie !
Le plus embêtant et rédhibitoire est vient plutôt des zones de transition colorées
Un traitement de désaturation suivi d'une saturation localisée comme tu le fais peut sauver un peu (si c'est impératif) une telle photo
Mais bon, çà a été un exercice enrichissant

Bonne journée

[polohc]

jdc,

Je vais faire la MAJ et continuer en visualisant ce qu'apporte chacun des paramètres,
mais çà devient compliqué quand il faut voir ce que l'un apporte à l'autre dans toutes les combinaisons possibles, c'est au moins une bonne formation

Je suis aussi surpris de la Q de dématriçage de DCRaw avec -m 10 qui donne très, très peu d'artefacts/labyrinthes dans les fines résolutions d'une mire progressive en préservant aussi une bonne définition

[stingray]

C'est sans doute maintenant le point à vérifier en A3+ par ex.
Des nuages rose ne gênent pas forcément, on en voit dans la vraie vie !
Le plus embêtant et rédhibitoire est vient plutôt des zones de transition colorées
Un traitement de désaturation suivi d'une saturation localisée comme tu le fais peut sauver un peu (si c'est impératif) une telle photo
Mais bon, çà a été un exercice enrichissant

Bonne journée

Je suis en effet au max niveau récup, quoi que avec l'autre mode de récupération, je retrouve peut être un peu plus de nuances, mais au prix de l'apparition de la zone cyan en haut au centre, comme les autres. Avec le mode HSV je n'ai pas cette zone cyan. Cette zone devrait elle être grise comme le dit Olivier ? je ne sais pas, je regarderais de près ce qu'il y a dans le raw pour donner une base de réflexion.

Il n'y a quand même pas trop de zones de transitions colorées dans la deuxième version, donc je pense que les couleurs viennent plus du traitement un peu costaud en 8 bits dans Gimp (que j'évite en temps normal) que de la recup des hautes lumières.

[Olivier-P]

C'est sans doute maintenant le point à vérifier en A3+ par ex.
Des nuages rose ne gênent pas forcément, on en voit dans la vraie vie !
Le plus embêtant et rédhibitoire est vient plutôt des zones de transition colorées
Un traitement de désaturation suivi d'une saturation localisée comme tu le fais peut sauver un peu (si c'est impératif) une telle photo
Mais bon, çà a été un exercice enrichissant

Bonne journée

Oui c'est cela, ne pas hésiter à être créatif ensuite, en paliant les délires des machines, et récréer la scène.

Sinon on est esclave des techniques, contre le sens logique.

Oui désaturer sur la totalité des gris horribles ( je parlais bien des transistions ), faire des masques sur les plaques colorées seules.

[Olivier-P]

Je suis en effet au max niveau récup, quoi que avec l'autre mode de récupération, je retrouve peut être un peu plus de nuances, mais au prix de l'apparition de la zone cyan en haut au centre, comme les autres. Avec le mode HSV je n'ai pas cette zone cyan. Cette zone devrait elle être grise comme le dit Olivier ? je ne sais pas, je regarderais de près ce qu'il y a dans le raw pour donner une base de réflexion.

Il n'y a quand même pas trop de zones de transitions colorées dans la deuxième version, donc je pense que les couleurs viennent plus du traitement un peu costaud en 8 bits dans Gimp (que j'évite en temps normal) que de la recup des hautes lumières.

Bien entendu ton log de bitmap te renforce les abberations. Mais c'est justement un révélateur.

Jamais dans une photo en pose normale, tu ne retrouverais ces kaliédoscopes. Donc tu dois neutraliser les folies de récupérations en chroma, être parfaitement heureux du beau boulot en luminance, et t'appuyer sur lui seul. Ce compromis est alors viable.

""L'engin apn"" a été dépassé à l'origine. Il est logique que ton intelligence humaine supplée.

[Olivier-P]

Cette zone devrait elle être grise comme le dit Olivier ? je ne sais pas,

Et personne ne sait.

En théorie oui, les bleus ont des luminances inférieures aux gris, avec des paliers ENORMES entre les deux zones. Genre deux à trois fois moins lumineux. Il est presque impossible que cela soit des bleus. Simplement des gris qui ont explosé tes canaux, d'apres le réglage de balances des blancs.

Car un apn est calé en usine pour les blancs maxi à 6500k env.

Si un blanc n'est pas à 6500k, l'un des canaux peut exploser avant, d'où dominantes pseudo colorées.

Les derniers paliers du dernier bit d'un apn sont à ce titre interdit au dematriceurs. A JUSTE TITRE, car on entre dans un no man' land suspect et impossible à interpréter.

[jdc]

J'ai modifié la version de Dcraw (en ligne de commande) qui est sur mon site.

Modifications apportées.

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, 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 différemment d'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!

* 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 et -Y 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 que j'ai modifié 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 et sans protection, c= niveau du seuil 

* 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.
Rappel: cette version supporte les nouveaux boitiers (D700, EOS1000,...) et peut fonctionner sous Vista y compris Vista 64 bits.

[polohc]

 [at]  jdc,

Je trouve très intéressant le réglage de l'expo dans ta version DCRaw
Les corrections à suivre dans le logiciel de retouche se trouvent maintenant généralement limitées à l'accentuation, à une courbe points noir/blanc et contraste/colorimétrie localisé si nécessaire.
C'est tout, si on est pas un fan de trituration d'images !
L'histogramme vérifié avec Histogrammar est exceptionnellement très propre

Par contre je n'utilise pas toutes les possibilités que tu as implémentées, mes lignes de commande sont dans ce style :
dcrawggt87 -v -w +M -H 0 -o 4 -I 1 -q 3 -l 2 8 -m 8 -C 0.9995 0.9998 -g 7 -F 0.73 0 0 -L 1.14 1.14 1.02 -Y 2 1.0 -4 -T DSC_0416.NEF

Avec un peu d'organisation (navigation entre DCRaw, Histogrammar et le soft de retouche) et l'expérience aidant (banque de données "ligne de commande") sortir une image tip-top est assez rapide et prenante

[jdc]

 [at]  Polohc

Merci pour ces essais qui confirment s'il le fallait l'exceptionnelle qualité des images produites par DCraw.
Bien sûr on fera remarquer que les lignes de commandes !!
Les espagnols (dont G.Luijk et M.LLorens) travaillent sur le code de PerfectRaw, qui dote Dcraw d'une interface graphique. D'ici quelques temps (??) ce produit permettra d'exploiter Dcraw, sans ligne de commande, avec une interface graphique, mais sans les commodités des produits phares (NX, LR2, Phase one,...). L'esprit de Dcraw sera conservé.

Quelques remarques sur ta ligne de commande (sauf si bien sûr tu as essayé et que cela ne te convient pas).
Remplace : -F 0.73 0 0 -L 1.14 1.14 1.02  par -y 0.73  (ou un chiffre approchant) et -F "quelque chose"
* -y  agit sur les multiplicateurs de canaux et préserve tout l'histogramme  alors que -F ne le fait pas
* je maintiens la commande -L par compatibilité et parce qu'elle est là...

As-tu essayé les dernières options que j'aie mises en place ? Celle qui permet de travailler en mode Lab / Lch plutôt qu'en rgb. Certes cela prend selon la machine et selon l'option de 4 à 15 secondes supplémentaires, mais il me semble que le détour en vaut le coup.

1) on peut choisir l'espace colorimétrique utilisé par la conversion (à ne pas confondre avec l'espace de travail / sortie) et ainsi voir ce que l'image "a dans le ventre", aussi bien en comptant les pixels hors espace, qu'en le visualisant à l'écran, et en choisissant ce qu'on fait de ces pixels.

2) on peut travailler directement séparément ou ensemble sur les 3 canaux : L = luminance, C= chromaticité, H = teinte. L'avantage du mode Lab / Lch est qu'un travail sur un canal n'a pas d'incidence sur les autres.

3) j'ai implanté à titre expérimental et sans fioriture, 3 fonctions
  a) correction d'exposition avec la luminance, protection des HL et choix du seuil à partir duquel se fait la protection. Par exemple - Z 1.3 1, accroit l'exposition de 30% jusque L=65, puis cet accroissement se réduit pour devenir nul à L=100.
  b) correction de la chromaticité en agissant (arbitrairement) sur 3 paliers (tons ternes, pastels et saturés). Ainsi on a une correction possible qui allie les commandes habituelles saturation et vibrance. Par exemple - [at]  1.1 1.2 0.9  accroit la "saturation" (en réalité la chromaticité) de 10% sur les tons ternes, de 20% sur les pastels et réduit de 10% les tons saturés.
  c) correction des basses lumières en agissant sur la luminance des BL par une commande faisant agir 3 paramètres : 1 - niveau d'accroissement des BL ,2- seuil limite d'application de cet accroissement en valeurs de luminance , 3 - 'profondeur' de la courbe (qui est une courbe logarithmique , plus la profondeur est grande, plus la zone des très basses lumières est concernée) . Par exemple -[ 2.5 60 6  amplifie de 2.5 fois les valeurs L vers L=0, ne fait plus rien à partir de L=60. Cette commande n'a pas besoin d'amplificateur de saturation.

Bien sûr ces fonction sont en cours de développement et il ya encore des bugs..

Merci

[polohc]

D'ici quelques temps (??) ce produit permettra d'exploiter Dcraw, sans ligne de commande, avec une interface graphique, mais sans les commodités des produits phares (NX, LR2, Phase one,...). L'esprit de Dcraw sera conservé.

Oui, j'attends PerfectRaw v. 1, les résultats de la v. 0.5 sont déjà très bons, le cahier des charges est prometteur.
Le fait de développer le fichier après chaque train de modif. des réglages n'est pas très contraignant.
Je préfère que ce soft ne bride pas DCRaw à une interface sophistiquée

As-tu essayé les dernières options que j'aie mises en place ? Celle qui permet de travailler en mode Lab / Lch plutôt qu'en rgb

Non, je viens de rentrer chez moi et de voir cette évolution.
Je vais essayer, mais çà semble assez ardu à mettre en oeuvre.
Toutefois, chaque évolution me fait un peu cet effet et puis, on se prend au jeu et on s'accroche pour y arriver, après tout s'éclaire
C'est formateur et la Q du traitement donne envie de continuer

A+

[polohc]

jdc,

Remplace : -F 0.73 0 0 -L 1.14 1.14 1.02  par -y 0.73  (ou un chiffre approchant) et -F "quelque chose"

J'ai essayé, l'histo ne va pas tout à D, donc j'ai augmenté la valeur de -y, l'histo va alors bien à D mais les HL perdent tout détail
Dans un cas d'image à HL cramées, -y doit-il tj être associé à -L ?

[jdc]

Il n'y a pas de réponse standard...

Sur la photo (excellente pour réaliser des tests -dsc1254.NEF) qui est extrêmement superposées, essaye :
a) l'option -H 2 : elle récupère les HL avec ses avantages et inconvénients, mais il reste du "gras" à droite sur l'histogramme
b) si tu prends l'option -H 3 à 9 il reste du magenta, car l'abaissement prévu par D.Coffin de ramener le canal rouge à 1.0 est insuffisant.

Dans le premier cas en agissant sur -y 1.1 ou 1.2 l'histo se déplace vers la droite sans recréer des zones magentas
Dans le second cas en agissant sur -y 0.7 ou 0.8 les zones magentas disparaissent et on obtient ainsi un autre algorithme de traitement des HL. J'ai légèrement retouché le code de la fonction -H 3 à 9 pour prendre en compte les effets de -y sur la saturation.

Mais bien sûr on peut se servir de -y tout seul, avec ou sans -F... et encore mieux avec -Z  en se servant de la conversion rgb==> Lch   {----} Lch => rgb. Les options -Z (action sur l'exposition), - [at]  (action sur la chromaticité) et -[ (action sur les BL), agissent dans la zone {----} ci-dessus.

[polohc]

OK jdc, j'ai bien testé ces diverses options (sauf -N avec -Z, - [at] , -[ qu'il me faut assimiler) et pour moi qui n'est pas (plus) fana de la récup des HL à outrance (les images rendues sont trop surnaturelles à l'instar des HDR) ma conclusion provisoire :

-H 0 pour les photos sans HL cramées, sinon -H 2 si je souhaite y retrouver quelques détails
-g [0~9] choix à l'aide d'un graph (que j'ai créé) des courbes résultantes
-F ou -y (le résultat est le même si on utilise pas b et c pour -F) je m'aide d'UFRaw pour démarrer avec une valeur pas trop pifométrique
-L pour étirer l'histo en limite D (contrôle avec Histogrammar) et éventuellement + déboucher les ombres
-Y pour affiner le contraste

A ce stade les retouches dans PS se limitent à l'accentuation et à une courbe de contraste/colorimétrie ciblée sur les tons à mieux différencier et sur points noir/blanc
Je vais continuer de faire qq tirages avec ce workflow et pour me "distraire" tenter des traitements avec -N (je pense que je vais avoir du boulot !)

PS : J'ai vu sur leur forum que tu étais en contact avec les développeurs de PerfectRaw... je te souhaite d'aboutir à une collaboration

[jdc]

 [at]  Polohc

Ton graph sur les courbes résultantes des options -g m'intéresse ...

Remarque : -F et -y donnent le même résultat si et seulement si l'histogramme ne "déborde" pas...Sinon si il y a débordement (surexposition, dépassement de l'espace, etc.), -y ramènera l'histogramme dans l'intervalle visible et -F non.

J'ai mis à jour mon site avec une version 1.75 plus "rapide" pour traiter l'option -N.

[polohc]

 [at]  jdc

Mon graph n'est pas d'une grande précision, j'ai photographié en lum. jour les 6 pavés d'une charte de gris, puis j'ai lu les valeurs correspondantes à chaque -g dans PS
J'ai fait ressortir les différences par rapport à -g 9 qui me semble bien représenter la moy. Elles sont assez évidentes pour accepter qq imprécisions

Merci pour la précision concernant -F et -y, j'utilise maintenant cette dernière option avec -L quand nécessaire

[polohc]

 [at]  jdc

Je me suis lancé avec -N :
les actions sur la chromaticité - [at]  et sur l'exposition -Z semblent fonctionner normalement, par contre pour celle sur les basses lumières -[ les valeurs de c > ou = 2 ne modifient rien et c=1 inverse progressivement le Noir avec le Blanc
Par contre j'ai constaté que pour cette action sur les BL on peut utiliser des valeurs < 1 pour le paramètre a pour assombrir les ombres

[jdc]

 [at] polohc

Tu as tout à fait raison, mon algorithme est "faux" ou du moins insuffisant. La retouche est simple...
D'ici demain, je mettrais à jour mon site pour remédier à ce bug et ajouter des fonctionnalités.

[polohc]

 [at]  jdc

C'était pour voir si je suivais ! 

Plus sérieusement, je vais voir maintenant ce que donne l'action sur le contraste de ta v. 1.76

[polohc]

je vais voir maintenant ce que donne l'action sur le contraste de ta v. 1.76

Essayée avec plusieurs valeurs, -% ne semble pas fonctionner.
Mais je me gourd peut-être qq part, ma ligne de commande du test :

C:\Users\polo>dcrawggt87 -v -w +M -H 2 -o 4 -I 1 -q 3 -l 2 8 -C 0.9995 0.9998 -g 7 -N 2 1 3 - [at]  1.1 1.1 1.0 -Z 1.2 3 -[ 1.0 30 4 -% 1.4 60 -Y 2 1.0 -4 -T DSC_0416.NEF
Prend en compte matrice couleur du boitier - actif
Chargement de l'image creee par un NIKON D80 depuis DSC_0416.NEF ...
Temps CPU lecture: 1.356
Equilibre canaux verts globalement
et equilibre canaux verts localement
rayon 8 pixels
Temps CPU verts: 1.420
Modification multiplicateurs BdB pour HL
Mise a l'echelle avec noir 0, saturation 4095, et
multiplicateurs 1.000000 0.557734 0.779956 0.557734
Correction aberration chromatique rouge 0.9995 , bleu 0.9998
Interpolation AHD...
blanc 1 0.95046
blanc 2 1.00000
blanc 3 1.08875
Temps CPU Interpolation: 5.491
Combinaison des hautes lumieres...
Temps CPU HL: 0.188
Espace conversion rgb->XYZ->rgb Prophoto
option 3 Precis-affiche- borne rgb espace choisi
Conversion rgb => xyz => Lab => Lch
indication:XYZ<0 zx 0 zy 0 zz 0  XYZ>65535 maxx 0 maxy 0 maxz 0
Temps CPU Lab 1: 12.246
Conversion Lch => Lab => xyz => rgb
depas:i_r Rouge 1 i_g vert 0 i_b bleu 2
minimum rgb calcul 0 maximum rgb calcul 69720
Maximum 'traduit par option' en rgb = 65535 37755 40373 et couleur fausse= rouge

Temps CPU Lab 2: 2.761
Debut conversion RGB
blanc 1 16b hex f351
blanc 2 16b hex 10000
blanc 3 16b hex 116cc
Conversion vers espace couleur Prophoto D65 .
16b utilise gamma variable 2.600
Ajustement contraste TRC 1.000
16b Utilise courbe TRC faible: 1960000
Soit un gamma TRC: 1.59
Modif luminosite et contraste -exposition - Gen. 1.000000 - BL 1.000000
[si INlin<seuil OUTgam=mult*INlin - si INlin>seuil Outgam=INlin(1/gam))*(1+z)-z]
gamma LUT. z= 0.1225
gamma LUT mult= 6.90 , seuil=0.01000
16 b Debut traitement des donnees
16 bits Fin traitement des donnees
Temps CPU RGB: 6.551
Ecriture des donnees dans DSC_0416.tiff ...

[polohc]

Mille excuses jdc, j'ai mal mis à jour ma version dcrawggt87
J'avais cliqué sur les .dll au lieu du .exe

Donc -% fonctionne, mais il me semble que les paramètres a et b sont à choisir avec précaution/limitation car sur mon premier traitement apparait un fort effet de postérisation.

[polohc]

Le problème, avec et sans l'option contraste :

[xiberotar]

j'ai parcouru ce fil avec un certain intérêt car ce matériel me parait intéessant pour les photos cas particulier. Ce qui me fit un peu peur est le fonctionnement en ligne de commande. Pouvez- vous me rafraichir la mémoire sur ce mode e fonctionnement? De plus il semble qu'il existe un didacticiel sur le site "guillermoluiijk. Est-ce le seul? Je n'ai pas non plus saisi la différence avec UFRAW.Merci pour vos réponses

Cordialement

[polohc]

Ce qui me fit un peu peur est le fonctionnement en ligne de commande. Pouvez- vous me rafraichir la mémoire sur ce mode e fonctionnement?

Au début on se croit revenu qq années en AR du temps du DOS, mais avec la pratique et de la méthode ce n'est plus trop contraignant.
Pour être "confortable", il faut ouvrir :
- "invite de commande" (démarrer/exécuter/cmd sous XP)
- WordPad pour sauvegarder les lignes de commande satisfaisantes (qui serviront à retrouver le traitement d'une image et à d'autres images similaires avec copier/coller dans "invite de commande")
- Eventuellement Histogrammar (disponible aussi sur le site de G. Luijk) qui permet de voir en détail l'histogramme de l'image traitée
- le logiciel de retouches d'images (PhotoShop ou autre)

Tout çà ouvert, on passe de l'un à l'autre sans perte de temps et on affine peu à peu les valeurs des divers paramètres

Bien sûr DCRaw est à réserver aux traitement unitaire "aux petits oignons"

De plus il semble qu'il existe un didacticiel sur le site "guillermoluiijk. Est-ce le seul?

Ce n'est pas le seul, mais il est TB.
Il y a aussi celui de Volker Gilbert et sans doute d'autres
Mais le mieux est de se lancer en progressant avec les diverses options indiquées lorsqu'on tape "dcraw" en ligne de commande.

Je n'ai pas non plus saisi la différence avec UFRAW

UFRaw est une version graphique de DCRaw, donc comme toutes les versions graphiques, les options disponibles de DCRaw sont + ou - bridées
Toutefois, une version graphique de DCRaw dénommée PerfectRaw sans concession sur la qualité et les possibilités de dématriçage est en cours de développement par les espagnols Luijk et LLorens

J'ai récemment débuté avec DCRaw et je me suis pris au jeu, c'est très formateur

Depuis qq temps j'ai découvert la version de jdc qui va beaucoup plus loin dans les possibilités de traitement, même si qq fonctions sont encore expérimentales
Avec l'évolution de cette version on a de - en - de retouches à faire dans PS et l'histogramme final reste très propre, voir ici :
http://desmisja.perso.cegetel.net/geraud/photo_calcul.php#dcr