Le meilleur dématriceur ?

[Cytochrome]

Intéressante discussion. Juste un commentaire: pour ceux qui veulent dcraw dans une interface il y a PWP4 (Picture Windows Pro V4 de Jonathan Sachs (http://dl-c.com/content/view/14/28/).

Bien sur on perd la ligne de commande mais on gagne l'intégration dans un éditeur d'images qui sous une interface viellotte cache des trèsors (je ne suis pas le seul à le penser ). Pour environ 60€ cela fait un ensemble performant. Et avec un très bon forum (http://www.dl-c.com/cgi-bin/discus/discus.cgi)

Francis

[jdc]

Je ne connaissais pas Picture Windows !

Toujours est-il que les résultats obtenus par Dcraw ou ses dérivés, rivalisent largement en qualité avec ce qui se fait de mieux sur le marché. De mon point de vue, Dcraw en lignes de commande ou avec interface) est à réserver au cas délicats et/ou lorsqu'on souhaite de très bons résultats. Il y a certes encore à progresser dans les traitements de base, c'est ce à quoi s'attaquent les espagnols (interpolation AFD, bruit, etc.) et ce que j'essaie d'apporter.

J'ai levé une partie des limitations des "points de contrôle" en autorisant 9 "points ou zones" ou fenêtres. Il "suffit" dans la ligne de commande dans l'option création de fenêtre (ou de zone) d'entrer un autre chiffre que 1 par exemple :
* -] 1 20 20 500 500 249 va permettre à l'intérieur de ctte zone d'image de changer colorimétrie, BL, etc., à condition d'entrer dans ces commandes le numéro de zone, ici 1
* -] 2 100 2000 300 300 149 va créer une zone 2
* -] 3 3000 2000 60 60 1 va créer une zone 3
etc.

[at] Polohc
Qu'entends-tu par perte de contraste dans la commande de traitement des BL? A partir du moment où on accroit la luminance des BL, naturellemnt le contraste baisse .

[polohc]

[at] Polohc
Qu'entends-tu par perte de contraste dans la commande de traitement des BL? A partir du moment où on accroit la luminance des BL, naturellemnt le contraste baisse .

Oui, bien sûr, mais les effets de cette commande obligent à revenir sur exposition et/ou contraste pour recaler le noir, puis souvent à revoir de nouveau les réglages des BL -[
C'est une procédure itérative qui m'a un peu dissuadé mais sans doute qu'avec la pratique...

[jdc]

J'ai refait une mise à jour de ma version de Dcraw. pas de changements majeurs... sinon des bugs en moins dans les "zones de contrôle" . J'ai porté le nombre possible de zones à entrer en lignes de commande à 50... ce qui est superflu, mais ne gêne pas. La modification du code permet maintenant d'offrir la possibité d'un nombre quasi illimité de zones (limité par la mémoire), j'ai essayé avec 10000000.. cela fonctionne. Cette approche offre la perspective des micro-retouches de l'image en mode rgb (via Lch Lab), micro-contraste, etc.

[at] Polhoc

J'ai vérifié les caractéristiques de l'option -[ (traiter les BL) par rapport à la même image vis-à-vis  de Capture NX et AC après avoir adapté l'exposition pour obtenir sensiblemnt les mêmes conditions de départ.

J'ai pris la mire JDC-Rouli de 468 couleurs comme étalon de travail.

Si on entre les réglages -[ 0 2 95 1 0.5    on obtient sensiblement (les écarts sont faibles et dus aux variations de colorimétrie) les mêmes résultats que avec NX - Dlighting qualité 50 avec amplificateur de saturation à 50 et ACR avec lumière appoint à 50

Rappel : -[ = traitement des BL ; 0 toute l'image ; 2 amplification de base ; 95 seuil limite d'application en valeur L; 1 forme de la courbe (ici logarithmique de degré 1); 0.5 seuil en valeur L de protection des BL.
Le réglage -[ 0 3 95 1 0.5 donne lui sensiblement l'équivalent de NX Dlighting 100 et ACR lumière 100. A noter toutefois que ma version protège totalement la saturation et la colorimétrie.

Ceci montre d'une part que les algorithmes utilisés par ACR et NX sont proches, avec dans les 2 cas une protection des très basses lumières pour éviter le bruit, puis une courbe logarithmique de degré 1 (le quatrième coefficient de -[).

Bien sûr dans le cas de Dcraw on peut changer si on le souhaite et en fonction des images le seuil limite (ici 95) et la courbe en augmentant le quatrième coefficient.

[jdc]

La version de Dcraw présente sur mon site (version 2.11) après quelques déboires de mise au point (il n'est pas simple de combiner du code avec les lignes de commande) possède une nouvelle fonctionnalité.

A partir de la conversion en valeurs Lab/Lch (au lieu de travailler en rgb...ou encore en RGB), j'ai élaboré un algorithme qui sur le principe à l'origine est une zone de contrôle (Nikon Capture NX appelle cela un point de contrôle, avec certes plus de fonctionnalités ... et de commodités grâce à l'interface) qui par adaptation devait servir à l'accentuation. Cet algorithme original, différent des "sharpen" habituels reprend 6 paramètres :
* a: qui active la fonction et détermine le "nombre de passes" (nombre de fois que sera exécutée l'action)
* b: "force", traduit le niveau d'action sur les delta de luminance
* c: "rayon" ou plutôt le 1/2 côté d'un carré de pixels
* d: "progressivité", qui du centre de chaque zone vers les bords réduit l'action du système
* e: "niveau de luminance" maxi (et 100-L mini)  au delà duquel, l'action décroît
* f: "recouvrement", permet de multiplier au delà du nombre théorique, le nombre de zones par recouvrement, un coefficient de 3 va tripler dans la largeur et la hauteur le nombre de zones avec à chaque fois calcul en tenant compte des cellules adjacentes recouvertes.
Par exemple sur un capteur de 3900*2600 pixels (environ 10 millions de pixels), avec un rayon de 4 pixels, il y a environ 160000 zones; mettre un coefficient de recouvrement de 3 va porter ce chiffre à 1440000 zones.

Selon les réglages, on peut faire de l'accentuation ou accroître le contraste local. Actuellement les algorithmes sont assez simples et ne font que appel à la luminance en conservant les valeurs C et H.

Bien sûr tout ceci est expérimental, probablement buggé...et à améliorer de manière importante.

Pour les allergiques à la ligne de commande, j'ai mis une petite procédure (notamment un fichier .bat), qui permet de faire ... sans entrer dans les écrans noirs...Bien sûr il faut adapter le .bat à son cas (sa machine) et au traitement des fichiers souhaités.

[polohc]

 [at] jdc

Séduisante ta fonction "micro-contraste / accentuation"
Elle fonctionne parfaitement dans les zones des tons moyens
Mais, dans celles de transition tons sombres / tons clairs il se produit du "carrelage" sombre / clair

Résultat obtenu avec cette LC :
C:\Users\polo>dcrawggt88 -v -w +M -H 2 -o 4 -I 1 -q 3 -l 2 8 -m 8 -C 0.9995 0.9998 -g 0 -Y 0 1.0 -N 2 1 3 -U 0 3 0 -Z 0 1.17 52 -% 0 1.26 80 - [at]  0 1.1 1.0 1.0  -£ 2 25 5 4 80 4 -4 -T DSC_0416.NEF

Un test avec e = 60 au lieu de 80 ne règle pas ce pb

Crop d'une zone concernée :

[jdc]

 [at] polohc


      J'ai eu pas mal de soucis avec l'algorithme "micro-contraste"..les résultats étant parfois extravagants...

      Bref, il y avait une erreur dans le code...revue, mais cela n'empêche pas que la fonction "micro-contraste" soit capricieuse;

      j'ai mis sur mon site, un compromis (actuel) qui fonctionne correctement (a priori) pour l'accentuation, et qui donne quelque chose d'acceptable pour le micro-contraste. Pour cela la variable 'f' ne peut prendre que 3 valeurs , 1) 2*rayon = valeur par défaut (accentuation), 2) inférieure à 2*rayon, qui va amener un effet "micro-contraste" mais avec des risques de mosaïque de l'image, 3) supérieur qui diminue les effets;

      J'ai également revu l'enchaînement des "micro-contrastes"  multiples qui se fait plus rapidement.


      A surveiller... et améliorer...

[polohc]

j'ai mis sur mon site, un compromis (actuel) qui fonctionne correctement (a priori) pour l'accentuation...

C'est bien 2*c qu'il faut utiliser pour l'accentuation ?
Si oui, il y a tj du "carrelage" bien qu'atténué

Les meilleurs résultats (qui se rapprochent de ce que j'obtiens avec PKS) sont avec -£ 2 50 1 0 85 2 (b pourrait même être > 50)
le "carrelage" est bien plus petit et le rendu dans les TM est très naturel

Une fois au point cette option devrait donner d'excellents résultats

PS : J'ai retesté l'option sur les BL et me suis rendu compte que mon pb vient dans les faibles valeurs de seuil < 20
je pense que comme çà se passe dans une zone très réduite, près du noir (visuellement très sensible) les paramètres "profondeur" et "protection" sont à choisir soigneusement

[jdc]

 [at] polohc

Pour l'accentuation, tu as fait le "bon" choix pour les paramètres "rayon" et "progressivité". En effet, le choix (arbitraire) que j'ai fait de prendre comme rayon, le 1/2 côté du carré de pixels - alors que sur les logiciels du commerce on parle en 0,x pixels..(je ne sais pas comment on fait pour couper un pixel en 2 ou en 4...J'aurais pu faire un autre choix, au lieu d'un carré de 4 pixels minimum (matrice de Bayer), prendre un pixel central...).Bref, c'est mon choix, mon algorithme, qui je pense est très différent des autres...

Donc, oui c'est un bon choix car si avec 1 pixel de rayon tu mets un pixels de progressivité..on obtient rien...

Je n'ai pas renoncé à améliorer l'algorithme...

A propos, c'est quoi PKS ?

[polohc]

Je n'ai pas renoncé à améliorer l'algorithme...

J'espère bien car il produit déjà des résultats intéressants

A propos, c'est quoi PKS ?

C'est PhotoKit Sharpener, le plug-in PS d'accentuation de Bruce Fraser dont la méthode est expliquée dans son bouquin "Netteté et accentuation avec Photoshop CS2"

[jdc]

 

J'ai revu le processus "micro-contraste et "accentuation" en changeant la variable 'f' de fonction. Celle-ci n'opère plus dans la même passe, ce qui amenait des artefacts, mais lorsqu'on active une ou des passes supplémentaires. Ceci rend indépendants les calculs et permet d'entrer n'importe quelle valeur.
   

En faisant cela, si on entre par exemple f=1 (f par défaut est à zéro), on décale la deuxième passe de 1 pixel vers le bas et de 1 pixel à droite... ou du nombre de pixels choisis. Après essais aussi bien en "micro-contraste" que "accentuation" , la valeur du rayon semble la plus appropriée.

[polohc]

 [at] jdc

Mes premières constatations :
Il apparait que pour éviter l'aspect carrelage sur les zones de transition BL / HL il faille ne pas utiliser nb passes >2 et rayon >1
et dans ce cas l'effet d'accentuation est trop limité, même avec de fortes valeurs de "force"
Par contre l'accentuation sur les TM est bien rendue avec des valeurs plus élevées
N'y aurait-il pas une protection plus efficace via le seuil limite d'action à mettre sur les zones incriminées ?

[jdc]

Conscient des limites évoquées...au delà d'un rayon de 1 pixel ...on a du carrelage... j'ai revu l'algorithme...

Dans l'option -£ , la zone de calcul correspond à la zone d'influence. C'est à dire que si je fais un calcul sur 4 pixels (matrice de Bayer), les modifications de luminance (puisque je travaille en mode Lab Lch) se font sur les 4 pixels...Cette manière provoque des artefacts au delà d'un rayon de 1. Je m'en sors au rayon de 1 en faisant 2 passes décalées de 1 pixel.

J'ai ajouté une option provisoire -µ  (pour simplifier le code et pouvoir faire des essais).
Ici la zone de calcul et la zone d'influence sont différentes.
De plus j'ai agrandi la zone en passant à une cellule de 5x5 pixels soit un rayon de 2 ou 2,5 pixels (si on coupe les pixels en 2!). Ce qui de mon point de vue est largement suffisant pour accentuer...car au delà on approche de la caricature. Dans ce cas il n'y a que 2 pixels sur les 25 qui sont concernés par les changements dus aux calculs: le pixel central de la zone et le pixel en haut à gauche de la cellule 5x5.

L'option actuelle est -µ a b c d   (non documentée dans la ligne de commande et non protégée des erreurs de saisie...!)
* a : active la fonction a=1
* b: nombre de passes 1 ou 2 recommandé
* c: force de 0 à 50...attention c'est très sensible, des valeurs de 5 -10 - 15 ou 20 me semblent correctes, mais bien sûr on peut entrer 60..
* d = seuil limite d'action - en valeurs L, des valeurs entre 60 et 85 donnent de bons résultats.. on peut entrer plus.. jusque 90

[polohc]

 [at] jdc

J'ai testé ta nouvelle fonction -µ sur une mire de dégradés de luminance imprimée avec les points jet d'encre visibles dans les tons moyens
Je l'ai photographiée pour avoir un NEF à traiter
J'ai 4 crops : sans accent., avec accent. PKS, avec accent. -µ 1 2 15 60 et -µ 1 2 15 85

L'effet carrelage est maintenant bien maitrisé (équivalent à PKS) mais les micro-détails (points de JE) sont perdus dans les ombres et les HL (le contraste est trop accentué) et flous dans les TM

La valeur de seuil n'apporte que peu ou pas de changement visibles

Les 4 crops :

[polohc]

suite :

[jdc]

 [at] polohc

Je suis impressionné par tes tests pointus..ce qui permet de progresser.

J'espère - j'ai plusieurs pistes - en fonction des graphiques que tu joins, pouvoir notablement améliorer le machin....Au moins 3 paramètres sur lesquels on peut jouer (en programmation).

Mais, car il y a un mais, je n'ai pas les moyens de reproduire chez moi ce genre de tests..donc je travaille doublement à l'aveugle (d'abord ligne de commande..mais là cela ne gêne pas et ensuite impression de ce type..). Donc j'agis sur des fonctions que je crée sans trop savoir leurs incidences.

[jdc]

Le défaut mis en évidence, n'était pas du à l'accentuation, mais à une variable globale de passage de paramètres de la ligne de commande qui restait activée. Si du contraste a été mis pour l'image - indépendamment de l'accentuation - celui-ci était appliqué 2 fois.

La version actuelle est la même mais sans ce bug.