Forum Chasseur d'Images - www.chassimages.com

Dernière nouvelle toute fraîche, je viens de tester ce dématriceur (brièvement) sous Vista pro 64, et il marche parfaitement; ce n'était pas le cas il y une heure...Merci à JDC...Je dois maintenant en tester toutes les fonctionnalités...Lit parfaitement les raw Olympus, sortant même la "vraie" résolution du capteur 4/3, soit : 3720X2800, ainsi que je l'avais constaté avec Photomatix...C'est toujours ça de gagné...A quand un "gui", monsieur JDC...? (bien que j'adore la ligne de commandes MS Dos, cela rappelle le bon vieux temps...!).

DPP pour Canon : simple rapie et efficace

Je ne cherche pas à me prendre la tête et il comporte tous les outils nécessaires. Puis bascule vers ToShop en 16bits (Tiff).

J'ai mis à jour mon site avec 2 exécutables Windows de Dcraw :
* un compilé dans l'environnement Cygwin qui fonctionne sous Vista (y compris la version Vista pro 64 bits) - merci Patounet9 d'avoir procédé aux essais
* un compilé avec Djgpp qui fonctionne avec XP, etc.

Ces 2 exécutables donnent des TIFF aussi bien en 8 bits qu'en 16 bits (préférer cette option).

J'ai apporté des compléments sous formes d'autres options pour les "gamma variables 16 bits", (en plus du gamma=1 linéaire et des gamma standard 2,2, 1,8, etc.). Ces possibilités permettent de voir les importantes variations de formes des histogrammes notamment dans les basses lumières.

De plus lors de l'exécution, on peut lire à l'écran les phases successives de travail, si bien sûr les options correspondantes sont activées :
* charger image
* équilibrage des canaux verts
* débruitage
* fixation du noir et de la saturation
* BdB avec ses multiplicateurs de canaux
* aberration chromatique
* interpolation
* détermination des points blancs
* début conversion RGB
* Espace colorimétrique de sortie
* choix du type de gamma
* choix de type de courbe TRC
* Prise en compte luminosité et contraste (exposition)
* recalcul des coefficients gamma variables
* traitement des données
* écriture du fichier TIFF

Un traitement 16 bits se déroule entre 7 et 20 secondes selon la machine et les options et produit un TIFF d'environ 60M°.
:)

Je déterre ce post que j'avais loupé juste pour signaler que UFRaw permet d'accéder à pratiquement toute les fonctionnalités de dcraw avec une interface graphique qui commence à être potable (manque encore le zoom 100% notamment) et quelques petits bonus.

moi je n'ai pas compris le sens de ton message
je n'ai pas eu besoin de ce topick pour découvrir dcraw/ufraw

je connais depuis fort longtemps et autant je n'ai pas accroché avant, autant maintenant je suis bluffé par certains cotés du logiciel

j'ai même fait de la pub en étant bluffé à haut iso en comparant le D3 sous NX et DCraw

ce n'est pas la première fois que je venterais des mérites de dcraw/ufraw

néamoins, ton message est ambigu et y a rien de concret, ça ressemble à du spam

dcraw n'est pas parfait, le réducteur de bruit, on pourrait dire qu'il est pourri face au standard actuel
ca manque vraiment de netteté face à NX pour le nefs
dcraw via gimp, la gestion des couleurs est certe superbe sur le poste de l'utilisateur mais ça c'est secondaire, ce qui compte c'est qu'on voit partout pareil

hors y a aucune gestion de profil couleur

si je fais une capture d'écran de ce que je vois chez moi écran calibré, tout le monde partage mon avis comme quoi ça pootre

mais si je poste direct le fichier avec ou sans profil attribué ensuite sous photoshop CS 3

il ne voit pas pareil que ma capture d'écran donc inutilisable à moins d'aimer la loterie

chez moi écran calibré avec une sonde monaco optix XR

alors si les autres ne voit pas pareil uniquement avec gimp/UFRAW aucun intérêt

nb : je parle de la version mac

J'ai juste fait cet ajout rapidement (sûrement trop rapidement vu ton intervention) car en parcourant ce post, UFRaw n'était pas cité et il y avait plusieurs interventions du genre "ouais ... dcraw ... c'est quoi ce truc préhistorique en ligne de commande".

Que tu connaisse UFRaw c'est bien, mais apparement ce n'est pas le cas de tout le monde. D'ailleurs quand je dis que je n'utilise que cela, en général on me regarde de travers avec un air légèrement moqueur  ;)

Sinon je ne comprend vraiment pas ton histoire de profil. Dans UFRaw tu peux à la fois attribuer un profil pour l'affichage et un profil pour la sauvegarde de ton fichier.
De toute façon au final, il faut toujours faire une conversion en sRVB pour échange ou affichage web, sinon c'est prendre des risques en effet.

Grâce à jdc (merci à lui  ;)) j'ai vraiment découvert DCRaw et ses énormes possibilités + ou - bridées dans les derawtiseurs graphiques (même ceux basés sur DCRaw, dont UFRaw) :D
Maintenant lorsque j'ai une photo difficile à traiter (notamment à grande dynamique) j'utilise DCRawggt ou DCRawg qui ont des fonctions de gestion des HL brûlées et gamma intéressantes.
Un article intéressant fait par un spécialiste de ce soft, ici :
http://www.guillermoluijk.com/article/gamma/index.htm (http://www.guillermoluijk.com/article/gamma/index.htm)
Le lien pour télécharger DCRawg se trouve dans l'avant-dernière ligne de cet l'article.
DCRawggt qui est une version complétée par jdc va encore plus loin (AMA trop loin pour un débutant) dans la gestion du gamma et du contraste

La réduction de bruit est loin d'être pourrie, elle fonctionne très bien (paramètre -n 100 et rarement besoin de +) en conservant tous les fins détails.
De plus, avec le paramètre -m 2 j'ai rarement vu de dématriçage aussi propre (vérifié sur mire de définition progressive) :)
Le manque de netteté par rapport à un NEF développé avec NX est évidente puisque DCRaw n'en apporte aucune ! C'est du domaine du post-traitement car DCRaw se veut uniquement un derawtiseur. Il faut évidemment lui faire suivre un logiciel de retouche (Tons foncés / Tons clairs de PS est alors très efficace)

Le profil de couleur est paramétrable (par -o) avec entre autre sRGB, adobeRGB, prophoto
Par contre à l'ouverture dans PhotoShop il faut ignorer le profil et l'attribuer après car PS devant un 16 bits linéaire, applique d'entrée une correction gamma (ce qui ferait une double correction)
Ensuite l'image peut être vue sur d'autres écrans correctement calibrés, j'ai vérifié.

Mais tout çà est bien expliqué dans l'article et le didacticiel de G. Luijk ;)

CitationPar contre à l'ouverture dans PhotoShop il faut ignorer le profil et l'attribuer après car PS devant un 16 bits linéaire, applique d'entrée une correction gamma (ce qui ferait une double correction)

J'ai oublié de préciser que c'est dans le cas ou on paramètre le gamma dans DCRawg avec -g, sinon on ouvre le fichier normalement avec PS

Réponse : Capture One. De loin.

Dcraw ? !

Logiciel tres interressant car gratuit, mais ... c'est un jouet inutile pour un professionnel.

Le meilleur logiciel est Capture One. Et les facilités des logiciels à interface sont à des années lumières des bricolages des nostalgiques de Dos et autres lignes de commandes. J'en ai fait 25 ans, le plaisir s'est estompé ;)

Il est inexact de dire que Dcraw ou un autre serait juste en colorimétrie sans profil ( sic), quand ce sont les profils internes de chaque machine qui décident du gamut apn. Ou alors on relance le débat qu'une projection sur CIERGB ( car proche spectre filtres rgb - et spectre humain en synthese additive ) est presque parfaite ? Ok dans ce cas, le coller dans un autre logiciel, C1 par exemple ;) Il est inexact de dire que les lumières sont plus ou moins récupérables, quand l'information d'origine est la même, et les possibilités de récupération aussi infinies que les habiletés de chaque graphiste. Il est inexact de dire que les profils peuvent être mis en interne, uniquement dans ce logiciel, quand C1 le permet ( le bug sur C4 est résolu ). Il est inexact de définir D50, quand la balance n'existe pas avant le transfert. Et pour information les apn sont calés en usine en D65 Jacques, la dynamique maximale se situerait dans cette tc, dans la réalité. Ceci dit on s'en moque des tc. Quel que soit le calcul, c'est le format de sortie qui sera interessant.

A ce titre les travaux de Jdc sur les espaces sont très interressants, KPR et Photogamut très bons.

Bref un tres bon logiciel, basique, qui a l'avantage d'éviter les gommages habiles des constructeur quand ils proposent une sauce " maison " ( dPP et NX ), mais qui est possible aussi dans C1 ( oter potard de chrominance et luminance, qui sont activés par défaut ). Les courbes sont éminement plus maniables dans les logiciels à interface, du fait simple de leur interactivité directe. Et la totalité des outils visibles en interactivité, c'est d'une importance capitale pour l'artiste, le graphiste, le créateur. DCRaw est l'inverse de la créativité. C'est comme réduire ses photos à du jpg, sans la sensation de création en direct.

ps : Le linéraire n'est pas une panacée, c'est la base de l'information du codage d'un apn. Là encore difficile de faire une apologie sans dire que les autres ... font la mm chose. Certes avec des précourbes, mm dans leurs "linéraires" un tantinet fallacieux, mais ce n'a que peu d'importance.

Je suis bien heureux que d'aucuns s'amusent avec ces jouets, bien écrits, et bravo à Jacques pour sa persistance à faire du code C+, mais je crains que cela soit une joie intérieure, plus qu'utile.

Sauf sa gratuité.

+1...Après les avoir tous testés (les derawtiseurs), je travaille uniquement avec C1 (Oly 510)...Je sors mes tiffs avec leur profil générique E 510 et le garde jusqu'à l'imprimante...J 'obtiens ainsi des couleurs parfaitement naturelles...
Dcraw n'est pas utilisable comme outil "de tous les jours"...C'est un jouet pour passionnés, très intéressant; notez qu'il fourni les raw complet 4/3 en taille, soit : 3720x2800 (400000 pixels de mieux que le standard)...

+2  ;)
perso je n'utilise dcraw que lorsque je veux faire un truc très spécifique qui en général n'a pas grand chose à voir avec la photo (faire un "dark" ou regarder finement la dynamique du capteur).

Il faut par contre souligner le boulot de dingue de Dave Coffin avec dcraw qui sert de base à pas mal de gros soft commerciaux (ceux d'Adobe en tête). C'est quand même assez fou que ces grosses boites attendent qu'un mec tout seul dans son coin travaille la prise en charge des nouveaux appareils avant de mettre à jour leur code !!
A noter d'ailleurs que dcraw n'est pas un soft open-source, mais est complètement libre et gratuit, ce qui permet aux éditeurs de soft commerciaux de l'utiliser sans scrupules (et même sans que l'auteur ne le sache).

Sinon j'avais essayé Capture One il y a longtemps et c'est en effet un super soft (juste un peu lent à l'époque). J'ai d'ailleurs utilisé pendant longtemps le profil C1 de mon D5D dans UFRaw avant d'utiliser celui de BibblePro qui est aussi très bon (peut être un peu plus flatteur).

-1 :)

CitationLogiciel tres interressant car gratuit, mais ... c'est un jouet inutile pour un professionnel.

Bien d'accord, DCRaw n'est pas le logiciel à utiliser par un professionnel qui fait de la production d'images, C1 v4 (et d'autres pour ne pas être sectaire) est nettement mieux adapté.
L'intérêt de DCRaw ne peut pas être réduit à sa gratuité mais dans la Q de son dématriçage, très propre et avec très peu d'artefacts comme je l'ai vérifié lorsqu'on utilise les bons paramètres.

CitationEt les facilités des logiciels à interface sont à des années lumières des bricolages des nostalgiques de Dos et autres lignes de commandes. J'en ai fait 25 ans, le plaisir s'est estompé

Pourquoi traiter les utilisateurs de DCRaw "de nostalgiques du DOS" ? ;D
Moi aussi, j'en ai fait pendant longtemps -trop longtemps !- et çà ne m'a pas traumatisé :)
Donc, je n'ai pas d'a priori à tester un soft basé sur ce principe et à l'adopter s'il m'apporte un + dans certains cas. Une ligne de commande utilisée avec copier/coller et quelques ajustements de paramètres, c'est aussi très rapide. ;)

CitationIl est inexact de dire que les profils peuvent être mis en interne

DCRaw utilise le profil APN (option -p) et au choix tous les profils courants en sortie (option -o)
DCRawg sort aussi en ProPhoto D65

CitationIl est inexact de dire que les lumières sont plus ou moins récupérables, quand l'information d'origine est la même

L'information d'origine utilisée par les derawtiseurs est évidemment la même mais elle n'est pas exploitée de la même façon.
Je suis dans l'attente d'un derawtiseur qui sorte autant de détails corrects dans les HL que DCRaw avec son option -H 2
Un fil a traité ce sujet et je n'ai rien vu de d'intéressant du côté des derawtiseurs "graphiques", c'est DCRaw qui s'en sortait le mieux car ses images brutes rendaient le maximum de détails dans le ciel alors qu'elles devaient encore passer par un post-traitement pour accentuation, Tons foncés/Tonsclairs, courbes, etc..., voir ce fil :

Citationhttp://www.chassimages.com/forum/index.php/topic,15132.80.html

CitationLes courbes sont éminement plus maniables dans les logiciels à interface

Oui aussi, après dématriçage DCRaw, l'application d'une courbe se fait aussi en "graphique" dans un logiciel de retouche (PS ou autre)

CitationDCRaw est l'inverse de la créativité. C'est comme réduire ses photos à du jpg, sans la sensation de création en direct.

Tu oublie que DCRaw est seulement un outil de dématriçage, la créativité se fait ensuite dans PS (ou autre) en TIFF 16 bits, pas en JPEG

Citationmais je crains que cela soit une joie intérieure, plus qu'utile

Je ne sais pas pour jdc, mais moi je sors des images impossibles avec les logiciels classiques et réputés et c'est çà ma satisfaction :D

Bref Olivier-P, je te le dis amicalement : j'ai le sentiment que ton "ras le bol" du DOS t'a dissuadé de tester DCRaw et donc que tu le connais mal ;)

Citation de: stingray le Août 20, 2008, 09:56:29
C'est quand même assez fou que ces grosses boites attendent qu'un mec tout seul dans son coin travaille la prise en charge des nouveaux appareils avant de mettre à jour leur code !!
A noter d'ailleurs que dcraw n'est pas un soft open-source, mais est complètement libre et gratuit, ce qui permet aux éditeurs de soft commerciaux de l'utiliser sans scrupules (et même sans que l'auteur ne le sache).

NB de ce qu'en dit   [at] .59b5191d]le père Schewe (http://www.adobeforums.com/webx?128%20%5Bat), c'est pour une question très américaine de propriété intellectuelle au sujet de l'accès à des formats propriétaires et plus ou moins encryptés...
Edit : je l'avais déjà mis dans mon 2e message, je devioens gâteux, je radote... désolé.

Ca n'enlève effectivement rien au mérite de David Coffin!
Nicolas, qui s'accroche fermement à son baril de LR2, trop accro à l'ergonomie...

Citation de: polohc le Août 20, 2008, 11:03:41
L'information d'origine utilisée par les derawtiseurs est évidemment la même mais elle n'est pas exploitée de la même façon.
Je suis dans l'attente d'un derawtiseur qui sorte autant de détails corrects dans les HL que DCRaw avec son option -H 2
Un fil a traité ce sujet et je n'ai rien vu de d'intéressant du côté des derawtiseurs "graphiques"

Ben si, avec UFRaw on doit pouvoir faire pareil, le raw d'origine n'est plus accessible, sinon j'aurai bien joué  ;)

Citation de: Nikojorj le Août 20, 2008, 11:07:41
NB de ce qu'en dit   [at] .59b5191d]le père Schewe (http://www.adobeforums.com/webx?128%20%5Bat), c'est pour une question très américaine de propriété intellectuelle au sujet de l'accès à des formats propriétaires et plus ou moins encryptés...

Oui en gros Dave fait le reverse-engineering pas trop légal, pond un code qu'il met à dispo et Adobe le récupère  ;D

Citation de: Nikojorj le Août 20, 2008, 11:07:41
Nicolas, qui s'accroche fermement à son baril de LR2, trop accro à l'ergonomie...

C'est clair que j'aimerai bien un truc qui n'en fasse que la moitié sous Linux, mais bon on s'en sort quand même. Et puis pour pratiquer les deux systèmes (Windows et Linux) au jour le jour, j'aime encore autant m'embêter un peu plus sur mes photos mais rester sous Linux à la maison.

Je rentre de vacances avec mes petits fils..et je constate avec plaisir que ce fil a été relancé.

Tout d'abord merci à ceux qui ont testé les "additifs" que j'ai apporté à DCRAW.

Certes je ne cache pas qu'une partie du développement en C++ m'apporte une certaine "joie intérieure" (ou plutôt le plaisir d'un défi résolu), mais avant tout c'est la compréhension de ce que fait un logiciel de traitement Raw - sachant que le code de Dcraw n'est quasiment pas commenté.

J'ai appris beaucoup de choses à "lire" le code de D.Coffin, notamment :
* la manière très personnelle qu'il a de traiter la gestion des couleurs en mode basique, c'est à dire sans profil : options de sortie XYZ, Raw, sRGb, Prophoto, etc., où on peut "jouer" sur les courbes TRC et le point blanc
* l'ordre des diverses opérations (étapes)
* le temps passé pour chaque étape.
* etc.

En ce qui concerne  "mes additifs", ils sont de deux types :
* réaliser un vrai traitement 16 bits, dont l'étape la plus consommatrice de ressources machine - et de loin - est la conversion XYZ ==> RGB avec les gamma sous 16 bits (le multiplicateur est 65536 au lieu de 256)
* en s'inspirant de ce qu'a fait Adobe avec Ligthroom - qui utilise les courbes de gamma variable de type sRGB dans un espace de type Prophoto - j'ai rendu possible, même si cela semble un peu complexe, la possibilité de choisir plusieurs gamma variables associés ou non à des rendus TRC personnalisés.

Bref DCRAW avec ou sans mes additifs n'est pas un produit pour faire du "batch", il offre certaines fonctions que d'autres n'offrent pas, et permet de traiter certains cas difficiles. Sa gestion du bruit limitée, sa gestion des couleurs perfectible, l'absence d'accentuation,... et l'interface austère, limitent son champ d'application.

Je pense pouvoir d'ici quelques temps apporter une contribution pour une partie des points ci-dessus.
:)

Salut Jacques, et bonne rentrée ;)

Et bien, tu tombes à pic !
Depuis mon retour de vacances, j'ai perfectionné mon utilisation de DCRaw avec ses divers développements (les tiens et ceux des spécialistes espagnols)

Ma conclusion provisoire : DCRaw est un pur dématriceur de haute Q quand on connait bien ses divers paramètres, parfaitement utilisable pour un traitement à l'unité d'un sujet difficile, il nécessite bien sûr ensuite un soft de traitement 16 bits pour les retouches habituelles classiques.

J'ai par contre découvert une version graphique de DCRaw appelée Perfect Raw, en cours de dévelppement qui promet beaucoup car sa version alpha est déjà largement exploitable (j'ai testé), voir ici : http://www.guillermoluijk.com/software/perfectraw/index.htm (http://www.guillermoluijk.com/software/perfectraw/index.htm)
La philosophie qui a conduit à l'élaboration de ce soft est séduisante : faire que le dématriçage mais le faire à la perfection :D
A suivre

[at]  stingray

Citation... le raw d'origine n'est plus accessible, sinon j'aurai bien joué

Je le remettrai volontiers mais sur Megaupload, çà ne marche plus ;D
Une autre solution ?

Citation de: polohc le Août 20, 2008, 14:33:28
[at]  stingray

Je le remettrai volontiers mais sur Megaupload, çà ne marche plus ;D
Une autre solution ?

http://dl.free.fr/
En général ça marche bien

Merci stingray, le fichier _DSC1254.NEF doit donc être ici :
http://dl.free.fr/jKTofmSEu (http://dl.free.fr/jKTofmSEu)

Bon traitement à tous ceux qui veulent participer, il n'y a rien à gagner :)
Seulement une meilleure connaissance des possibilités des derawtiseurs/retoucheurs à notre disposition
Chacun d'entre nous peut y trouver un intérêt ;)

Je demande seulement que le traitement se limite aux outils courants classiques (Accentuation, D-light, Tons foncés/Tons clairs, niveaux/courbes)
N'utilisez pas de retouche basée sur une sélection ponctuelle qui même si elle conduit à une meilleure image, fausserait le test.

A+

polo

Citation de: polohc le Août 20, 2008, 15:45:23
Bon traitement à tous ceux qui veulent participer, il n'y a rien à gagner :)

Je demande seulement que le traitement se limite aux outils courants classiques (Accentuation, D-light, Tons foncés/Tons clairs, niveaux/courbes)
N'utilisez pas de retouche basée sur une sélection ponctuelle qui même si elle conduit à une meilleure image, fausserait le test.

Mon traitement LR2 ci-dessous (en petit ça suffit non?)
Un peu plat, pour ça qq coups de GradND ou de pinceau ne lui feraient pas de mal, mais je sais c'est injuste pour les autres programmes de traitement... ;D

LR2 & NX2.. sans u-points et autres dégradés... ;D

UFRaw de base, juste un coup dans Gimp pour redimensionnement :

(http://chris.stingray.free.fr/tmp/Polo_V1.jpg)

Sinon il y a moyen évidemment de faire un peu plus pêchu avec des masques, bien sur moins naturel :

(http://chris.stingray.free.fr/tmp/Polo_V2.jpg)

Fait vite fait sur l'écran du boulot ... faudra que je vérifie ça sur mon écran  :D

C'est marrant, sur l'essai avec NX, on voit clairement le problème de dénaturation des ombres sur le mur de la maison. Un vrai caricature ce NX  ;D

Pour le résultat c'est LR donc cela ressemble au traitement qu'a présenté Nikojorj

Citation de: patrickrosuel le Août 20, 2008, 17:41:07
C'est marrant, sur l'essai avec NX, on voit clairement le problème de dénaturation des ombres sur le mur de la maison. Un vrai caricature ce NX  ;D

Bof, je trouve qu'il s'en tire pas trop mal, a ces niveaux de rattrapage et sans possibilités de retouches locale, tous les softs cafouillent (ciel qui vire au vert dans LR par ex), et puis la version NX est aussi plus froide en bdb / LR  ...

Citation de: patrickrosuel le Août 20, 2008, 17:41:07
C'est marrant, sur l'essai avec NX, on voit clairement le problème de dénaturation des ombres sur le mur de la maison.

Ca, ce n'est pas simplement le problème de la courbe tordue?
Si on rajoute du contraste qq part, il faut en enlever ailleurs...

NB j'avais cru comprendre que l'enjeu principal était de récupérer un ciel potable, sans trop enterrer les BL, mais si besoin je diois pouvoir sortir plus clair... Boh allez j'aime bien l'ambiance sombre des nuages bien noirs.

De toute façon, si c'est le ciel qui est visé, je trouve que c'est stingray avec UFRaw qui s'en tire le mieu pour l'instant . ;)

PS KOWA, quand au vert dans le ciel avec LR je cherche, je cherche je cherche ...............mais pour l'instant ma pipette ne me trouve strictement aucune trace de vert. Ce doit être ton écran.

Citation de: patrickrosuel le Août 20, 2008, 17:59:51
De toute façon, si c'est le ciel qui est visé, je trouve que c'est stingray avec UFRaw qui s'en tire le mieu pour l'instant . ;)

PS KOWA, quand au vert dans le ciel avec LR je cherche, je cherche je cherche ...............mais pour l'instant ma pipette ne me trouve strictement aucune trace de vert. Ce doit être ton écran.

OK pas vert mais cyan.. cela ne change rien il y a une dérive désagréable dans la recup du ciel (et avec mes réglages de bdb) ceci dit, elle est présente aussi dans NX et C1

Citation de: patrickrosuel le Août 20, 2008, 17:41:07
C'est marrant, sur l'essai avec NX, on voit clairement le problème de dénaturation des ombres sur le mur de la maison. Un vrai caricature ce NX  ;D

Pour le résultat c'est LR donc cela ressemble au traitement qu'a présenté Nikojorj

Sans vouloir porter ombrage à l'auteur de cette photo -- magnifiquement exposée ! , en raw c'est comme on peut. Affaire de goût, si je puis dire. Je ne vois pas en quoi NX en particulier dénaturerait les ombres de la maison sur ce genre de cliché ? Surtout avec la possibilité unique, mais l'interdiction ici, de se servir des points de contrôle pour s'abaisser au niveau des autres.
Ci-joint NEF en respectant donc les règles. Avec la grisouille des nuages et la dénaturation des bleus du ciel. Enfin quoi... sans conviction... ma pétouille quand même, histoire de participer.

Bon de retour à la maison ... c'est décidé je ne m'amuse plus a faire des retouche sur cet écran au boulot  ;D

Bon alors sur ce fichier ce qui me semble le mieux à faire :

- Dans UFRaw faire un développement en récupérant les HL tout en remontant les ombres :

(http://chris.stingray.free.fr/tmp/Polo_V3.jpg)

- Ensuite reprise dans Gimp pour densifier le ciel (un calque), quelques petites retouches de couleurs et voila :

(http://chris.stingray.free.fr/tmp/Polo_V4.jpg)

Et ben, les vacances sont finies !
Je quitte 4h mon PC et je retrouve 8 interprétations de mon fichier :D
Merci à tous de votre contribution.

Quelques constantes se dégagent :
- Difficulté pour sortir un ciel chargé et une façade et du feuillage pas trop enterrés
- LR2 et NX2 mettent du Cyan qui n'existait pas dans le ciel
- NX2 malgré peu de détails récupérés dans le ciel rend des transitions brutales
- UFRaw s'en tire bien mais avec recours aux calques :( (n'est-il pas possible de jouer avec l'outil courbe UFRaw ?)

Ma version DCRawg complétée par tons foncés/tons clairs et courbe dans CS2 :

Citation de: polohc le Août 20, 2008, 20:24:29

- UFRaw s'en tire bien mais avec recours aux calques :( (n'est-il pas possible de jouer avec l'outil courbe UFRaw ?)

Disons que comme l'a dis Nikojorj tu ne peux pas à la fois avoir un ciel dense et contrasté et une façade qui ne soit pas enterrée (ou alors tu n'as plus de contraste sur la façade).
Sur ce type d'image, il n'y a pas vraiment de solutions, un masque de contraste peux aider un peu mais c'est quand même difficilement rattrapable.

UFRaw est effectivement impressionnant dans la recup des HL, en travaillant l'image, NX2 ne s'en tire pas trop mal tout de même

edit: le passage en srvb est un peu violent...a retravailler

Citation de: polohc le Août 20, 2008, 20:24:29
Et ben, les vacances sont finies !
Je quitte 4h mon PC et je retrouve 8 interprétations de mon fichier :D
Merci à tous de votre contribution.

Quelques constantes se dégagent :
- Difficulté pour sortir un ciel chargé et une façade et du feuillage pas trop enterrés
- LR2 et NX2 mettent du Cyan qui n'existait pas dans le ciel
- NX2 malgré peu de détails récupérés dans le ciel rend des transitions brutales
- UFRaw s'en tire bien mais avec recours aux calques :( (n'est-il pas possible de jouer avec l'outil courbe UFRaw ?)

Ma version DCRawg complétée par tons foncés/tons clairs et courbe dans CS2 :

Ce qui se dégage surtout, c'est qu'il n'y rien de bon et rien de tirable. De là en tirer des conclusions sur les logiciels... c'est quand même bisuter les pixels.

Citation de: cagire le Août 20, 2008, 21:15:39
Ce qui se dégage surtout, c'est qu'il n'y rien de bon et rien de tirable. De là en tirer des conclusions sur les logiciels... c'est quand même bisuter les pixels.

Je ne vois pas trop le rapport. Des photos bien exposé j'en ai plein ma poubelle, j'ai aussi sur mon mur un grand tirage d'un portrait de ma fille avec une grosse zone cramée en arrière plan.
D'une manière générale ce n'est pas parce qu'un photo est techniquement réussie qu'elle est "tirable", non ?

Je pensais en particulier à cette photo et pas à des photos personnelles avec des blancs cramés comme nous en avons tous.
Sur cette photo je ne vois rien de récupérable ni de récupéré dans le ciel sinon du grisouillis, donc pour moi ce point n'est pas un critère. Par ailleurs l'effet courbe ou D-L ce fait un peu trop sentir à mon goût à la limite partie claire et partie sombre. Et, par ailleurs aussi, un dématriceur ne s'estime que dans la mesure où l'on le maîtrise.
C'était plutôt cela le sens de ma précédente remarque. Evidemment, ensuite l'on fait ce que l'on veut et l'on tire les photos que l'on aime, qui ne sont pas toujours techniquement, j'en conviens, les plus parfaites.

Mais sous couvert d'estimer la qualité de tel ou tel logiciel, en fait on avance des appréciations personnelles comme des axiomes gravés dans le marbre en oubliant un peu vite que chacun fait comme il veut ou comme il peut. Ce qui est autre chose.

Il ne faudrait quand même pas prendre, ce qui n'est qu'un divertissement, comme une donnée technique dont dépendrait la qualité ou les vertus d'un logiciel de développement.

Citation de: cagire le Août 20, 2008, 22:12:51Mais sous couvert d'estimer la qualité de tel ou tel logiciel, en fait on avance des appréciations personnelles comme des axiomes gravés dans le marbre en oubliant un peu vite que chacun fait comme il veut ou comme il peut. Ce qui est autre chose.

Pour moi, ce qui compte le plus avec un logiciel de RAW, c'est ce qu'on arrive à faire avec, personnellement...
Au départ il y a des tas de bons softs, certains certainement "objectivement" meilleurs que d'autres.

Mais bon, je prends un exemple perso, avec Capture One, qui je pense est quand même qualitativement très bon, perso je n'arrive pas à un résultat qui me plait...
Alors qu'avec Bibble, ou Lightroom, qui sont deux softs peut-être moins bons sur certains plans (et notamment sur le dématriçage pur, même si je n'ai pas fait spécialement de tests avec LR2), j'arrive à faire à peu près ce que je veux.
Et finalement c'est ça le plus important.

Au final, la qualité du dématriçage... ben si le rendu global que j'arrive à avoir avec la photo ne me plait pas, je m'en tape.

Entièrement d'accord avec vous deux !!
L'important c'est "de se sentir bien" avec le soft.
C'est très personnel, en général fortement lié à un apprentissage qui s'est bien passé ou non (genre t'es de mauvais poil quand tu test le soft et tu ne reviens jamais dessus) et au final, ce qui compte, c'est ce que l'on en fait.
D'un autre coté, voir ce qu'un autre est capable de faire avec tel ou tel soft peut permettre de se remettre en question (tiens si je re-essayais ce soft que j'avais effacé le jour ou j'étais de mauvais poil !!) et même de progresser avec son outil.

Citation de: cagire le Août 20, 2008, 22:12:51
Je pensais en particulier à cette photo et pas à des photos personnelles avec des blancs cramés comme nous en avons tous.
Sur cette photo je ne vois rien de récupérable ni de récupéré dans le ciel sinon du grisouillis, donc pour moi ce point n'est pas un critère. Par ailleurs l'effet courbe ou D-L ce fait un peu trop sentir à mon goût à la limite partie claire et partie sombre. Et, par ailleurs aussi, un dématriceur ne s'estime que dans la mesure où l'on le maîtrise.
C'était plutôt cela le sens de ma précédente remarque. Evidemment, ensuite l'on fait ce que l'on veut et l'on tire les photos que l'on aime, qui ne sont pas toujours techniquement, j'en conviens, les plus parfaites.

Mais sous couvert d'estimer la qualité de tel ou tel logiciel, en fait on avance des appréciations personnelles comme des axiomes gravés dans le marbre en oubliant un peu vite que chacun fait comme il veut ou comme il peut. Ce qui est autre chose.

Il ne faudrait quand même pas prendre, ce qui n'est qu'un divertissement, comme une donnée technique dont dépendrait la qualité ou les vertus d'un logiciel de développement.

CitationDisons que comme l'a dis Nikojorj tu ne peux pas à la fois avoir un ciel dense et contrasté et une façade qui ne soit pas enterrée (ou alors tu n'as plus de contraste sur la façade).

Avec DCRaw + CS2 je pense avoir un bon compromis des deux :)

CitationSur cette photo je ne vois rien de récupérable ni de récupéré dans le ciel sinon du grisouillis

Tu vois du grisouillis dans le ciel sur ma version DCRaw ?

Citationl'effet courbe ou D-L ce fait un peu trop sentir à mon goût à la limite partie claire et partie sombre

Oui, c'est un choix réglable avec le paramètre rayon des tons clairs qui pourrait être plus élevé ou à 0

Citationun dématriceur ne s'estime que dans la mesure où l'on le maîtrise

???

CitationMais sous couvert d'estimer la qualité de tel ou tel logiciel, en fait on avance des appréciations personnelles...

Chacun peut donner ses appréciations, un tel test est fait pour çà  ;)

CitationIl ne faudrait quand même pas prendre, ce qui n'est qu'un divertissement, comme une donnée technique dont dépendrait la qualité ou les vertus d'un logiciel de développement

Qui a dit çà ? Ces premières constations ne donnent que quelques éléments d'appréciation.
Il se trouve que j'ai commencé avec cette photo car elle avait déjà donné du fil à retordre et que la récup des HL cramées est pour moi qui fait beaucoup de paysage, un critère très important.
C'est le seul intérêt de cette photo que je n'ai évidemment exploitée que pour des tests.

Alors, maintenant si vous avez d'autres "cas d'école" pour évaluer d'autres critères...

Bien d'accord avec les deux derniers posts (Zaphod et stinray) et notamment

CitationD'un autre coté, voir ce qu'un autre est capable de faire avec tel ou tel soft peut permettre de se remettre en question

Citation de: Zaphod le Août 20, 2008, 22:23:26
Pour moi, ce qui compte le plus avec un logiciel de RAW, c'est ce qu'on arrive à faire avec, personnellement...
Au départ il y a des tas de bons softs, certains certainement "objectivement" meilleurs que d'autres.

Mais bon, je prends un exemple perso, avec Capture One, qui je pense est quand même qualitativement très bon, perso je n'arrive pas à un résultat qui me plait...
Alors qu'avec Bibble, ou Lightroom, qui sont deux softs peut-être moins bons sur certains plans (et notamment sur le dématriçage pur, même si je n'ai pas fait spécialement de tests avec LR2), j'arrive à faire à peu près ce que je veux.
Et finalement c'est ça le plus important.

Au final, la qualité du dématriçage... ben si le rendu global que j'arrive à avoir avec la photo ne me plait pas, je m'en tape.

Nous sommes d'accord, je ne dis pas autre chose, avec une réserve toutefois la qualité du dématriçage je ne m'en tape pas.

L'important est de parvenir à ses fins. C'est pour cela que je tempère les appréciations portées par un tiers sur des développements effectués avec différents logiciels, qui ne sont que des variantes proposées par d'autres à l'aune de leurs goûts et compétences. L'appréciation ne porte donc que sur les goûts ou les compétences des uns ou des autres et non sur les logiciels dont il est question.
Peut-être me suis-je mal exprimé et que maintenant c'est plus clair et moins ambigüe ?

Nous sommes peu ou prou tous pareils, nous développons mieux avec tel logiciel plutôt qu'avec tel autre. Dans ce cas, les qualités intrinsèques du logiciel ne sont pas remises en cause.

Il se fait tard, bonne nuit.

Citation de: cagire le Août 20, 2008, 22:52:16
Nous sommes d'accord, je ne dis pas autre chose, avec une réserve toutefois la qualité du dématriçage je ne m'en tape pas.

Je n'ai pas dit que je m'en tapais, mais que ça n'avait d'importance que si j'arrivais à traiter globalement la photo comme je voulais (rendu colorimétrique, apparence globale).
Surtout que les détails visibles à 100% sur un écran de PC ne le sont que rarement au tirage.

A l'inverse, un mauvais dématriçage peut aussi foirer une photo, mais c'est quand même relativement rare.
Perso dans les softs habituels de traitement du RAW je ne pense pas qu'il y en ait de spécialement mauvais.
Tous ceux que j'ai testés (RawImageTask, DPP, Bibble, CaptureOne, DxO, Lightroom, Silkypix) peuvent donner de très bons résultats quand il sont bien utilisés.
(même si certains ont besoin d'un soft de retouche en complément).

Et quand on fait des tirages comparatifs... les différences ne sont pas si sensibles en qualité pure d'image.

C'est dommage que ce test ait pris cette tournure :(
On ne peut pas émettre des avis qui dérange :(
C'est pas en se regardant le nombril qu'on peut avancer :(

polo

Citation de: polohc le Août 20, 2008, 11:03:41
-1 :)
Bien d'accord, DCRaw n'est pas le logiciel à utiliser par un professionnel qui fait de la production d'images, C1 v4 (et d'autres pour ne pas être sectaire) est nettement mieux adapté.
L'intérêt de DCRaw ne peut pas être réduit à sa gratuité mais dans la Q de son dématriçage, très propre et avec très peu d'artefacts comme je l'ai vérifié lorsqu'on utilise les bons paramètres.
Pourquoi traiter les utilisateurs de DCRaw "de nostalgiques du DOS" ? ;D
Moi aussi, j'en ai fait pendant longtemps -trop longtemps !- et çà ne m'a pas traumatisé :)
Donc, je n'ai pas d'a priori à tester un soft basé sur ce principe et à l'adopter s'il m'apporte un + dans certains cas. Une ligne de commande utilisée avec copier/coller et quelques ajustements de paramètres, c'est aussi très rapide. ;)
DCRaw utilise le profil APN (option -p) et au choix tous les profils courants en sortie (option -o)
DCRawg sort aussi en ProPhoto D65
L'information d'origine utilisée par les derawtiseurs est évidemment la même mais elle n'est pas exploitée de la même façon.
Je suis dans l'attente d'un derawtiseur qui sorte autant de détails corrects dans les HL que DCRaw avec son option -H 2Un fil a traité ce sujet et je n'ai rien vu de d'intéressant du côté des derawtiseurs "graphiques", c'est DCRaw qui s'en sortait le mieux car ses images brutes rendaient le maximum de détails dans le ciel alors qu'elles devaient encore passer par un post-traitement pour accentuation, Tons foncés/Tonsclairs, courbes, etc..., voir ce fil : Oui aussi, après dématriçage DCRaw, l'application d'une courbe se fait aussi en "graphique" dans un logiciel de retouche (PS ou autre)
Tu oublie que DCRaw est seulement un outil de dématriçage, la créativité se fait ensuite dans PS (ou autre) en TIFF 16 bits, pas en JPEG
Je ne sais pas pour jdc, mais moi je sors des images impossibles avec les logiciels classiques et réputés et c'est çà ma satisfaction :D

Bref Olivier-P, je te le dis amicalement : j'ai le sentiment que ton "ras le bol" du DOS t'a dissuadé de tester DCRaw et donc que tu le connais mal ;)

D'accord avec tes remarques en général, celles de Stingray, et de Jdc himself. C'est un plus pour photos individuellement, pour éviter les " gommages " des logiciels tiers.

Maintenant une note importante sur ce que vous appelez " des récup de hautes lumières". C'est impropre. C'est un algo de tricherie pour tout ramener ce qui est hors course, à un blanc neutre. Autrement en sous exp réelle, ces blancs sont colorés car des canaux ont laché avant d'autres.

Les récups consistent à faire de l'achromatisme avec ce qui approche les 255 (8b).

C'est gentil, c'est utile, cela dépanne, mais c'est littéralement faux. En cela les logiciels qui vous donnent des bleus, de cyans, des rosés, sont ceux qui ne mentent pas. Bien entendu de plus en plus, ce genre d'algo existe ici et là, DCraw le fait, mais C1 en récup HL aussi, et d'autres à venir de plus en plus. Cela finit bien une photo limite, dans le cas où le blanc neutre ( celui de la TC demandée ) est  lisible. Si jamais c'était un sujet logique avec dominante, c'est perdu. Pour des nuages c'est ok. Pour un objet jaune ( lampe tungstène ) c'est infaisable. De toute façon, il faut savoir qu'une partie des messages de luminance est perdu ( un des canaux ou deux, sont explosés ) et les détails moins nombreux. Celui qui aura exposé normalement s'en sortira avec d'autres infos.

Bien entendu on ne va pas pester contre des récupérations qui sauvent une photo non éditables, mais encore une fois, ce n'est pas le but de la photographie de travailler avec des informations perdues. Il vaut mieux refaire les photos, et pousser sa propre exigence plus loin.

Il n'y a rien que C1 ne fasse pas dans ce soft, avec des souplesses à cent lieux des lignes de commande. Et C1 vaut 99e. Je crois que la messe est dite.

Par contre je le redis, pour le fun du codeur C+ ( Bravo Jacques ) , c'est un pur plaisir, surtout s'il commence à jouer avec cela, dans qq mois ou années il laissera ce genre de bébés aux codeurs pros, qui vont évidemment plus loin, et fournissent du clé en main. Ok Dpp et NX sont castrateurs, c'est bien de le voir, de le prouver aussi, c'est une démarche interressante et pédagogue. Mais C1, BibbleRaw ( moins neutre ) sont aussi de cette cuvée. Avec la facilité de l'interface.

Pour le fun c'est ok, et encore bravo à Jdc. Pour la réalité, c'est autre chose. Pour les utilisateurs aussi.

CitationEn cela les logiciels qui vous donnent des bleus, de cyans, des rosés, sont ceux qui ne mentent pas

Oui bon, ils ne mentent pas mais ils ne rattrapent pas une photo d'un sujet à trop grande dynamique pour lequel on doit choisir un compromis entre 1 ou 2 canaux cramés et des ombres bouchées irrattrapables sans dégât car trop bruitées.
Alors, il ne faut pas faire la photo ou la refaire comment quand le sujet n'est plus disponible ?
En paysage on est souvent dans ce cas de figure :(
J'utilise normalement et couramment C1 avec bonheur, mais dans ce cas maintenant c'est DCRaw, en attendant PerfectRaw (peut-être) ;)

CitationDCraw le fait, mais C1 en récup HL aussi

J'ai évidemment essayé, mais la limite est plus vite atteinte avec également une dérive un peu Cyan, certes moins prononcée qu'avec NX ou LR
Ma version _DSC1254_DCRawg.jpg (post 20:24:29) rend bien, je pense, les possibilités de DCRaw dans ce domaine. J'ai fait un tirage du TIFF (pour voir, car je ne pensais pas exploiter cette image quelque peu irréelle) le résultat est très convaincant :)

Pour tester il me faudrait ton Raw, mais je n'ai pas envie de jouer ;)

Les constructeurs ont une logique - elle est défendable - de refuser de mimer des canaux abimés. C'est normal, et Nikon par exemple poussait le bouchon très loin, presque à sacrifier un IL dans n'importe quelle condition. Puis ils ont du se plier à la demande des clients, gratter jusqu'au raisonnable.

Ensuite ... gratter un pouillème de plus ? NX et DPP gardent tt de mm une sécurité. Elle me parait normale.

C1 récupérer moins ou pas moins ? moui c'est jouer sur les mots. Je vois déjà C1 inventer presque 2 IL manquants en informations, avec son système de récupération de canaux saturés, et je vois BibbleRaw en faire autant depuis des années. Il n'y a pas mieux ou pas mieux, il y a autoriser à "inventer". Tous ceux là le font. Il ne peut pas y avoir de hiérarchie, juste des potards de TC à bien caler pour tricher sans que celà se voit trop. Facile sur des nuages, impossibles sur un reflet de statuette en or par exemple et j'en passe.

Il ne faut pas confondre facilité des triches possibles par algo, et traitement des photographies. Les informations n'existent pas. Ce sont des montages. Ensuite à chacun de manier ses outils de graphistes pour arriver à son but.

Ceci dit je ne vois aucun inconvénient que le module de " fabrication de blanc " de DCraw te convienne, je dis simplement ce n'est pas de l'ordre du dévellopement, c'est de la création.

Ce qu'on demande à un Derawtisateur, c'est de bosser tt de mm avec les véritables informations non corrompues non ? dans ce cas aussi Dcraw n'est ni meilleur, ni pire. Son avantage je le répète est d'être brut, sans les manips de masques des constructeurs pour améliorer leur produit ou cacher des misères. Mais cela C1  le fait déjà.

Il y a une seule chose pratiquement supérieure, mais dont l'utilisation dépasse les interressés, c'est la gestion d'un linéaire exact, et d'une primo projection en gamut ( avant le profil perso ) en triplet pur. C1 a déjà une base un peu " trafiquée" en primo projection ( voir no_correction.icc dans le catalogue PhaseOne, le triplet est déjà en fait une LUT , LUT presque sur primaires mais ... ). Mais c'est tellement peu ... et qu'un profil perso corrige ( ou constructeur etc ) que c'est parfaitement invisible, sauf sous cabine D50 justnormlich, et spectro à 3000e ... bref invisible à l'oeil. Pour le linéaire idem, on a pas de soft externe en Bitmap  pour jouer avec un linéaire exact ( sauf IRIS mais pas fait pour cela, sauf des vieux softs de Miranda qui sont obso ) et l'utilité est nulle, complétement nulle. Si ... on peut s'en servir en controle, pour voir si un dématriceur triche trop à potard 0. Utilité dédiée à des tech ... nulle aussi donc.

Olivier c'est un peux plus complexe que cela. J'admet bien sur que "c'est triché" et je ne suis pas de ceux qui vont te dire que l'on va retrouver une information qui a disparu, tu t'en doute.
Par contre lorsque l'information a partiellement disparu (une seule couche cramé), il est possible d'essayer de retrouver quelque chose, ce ne sera bien sur jamais juste et il y a plusieurs façon de faire la chose avec des résultat différents et plus ou moins "bon" suivant les situations.
Le module de dcraw ou ufraw, n'est pas de la "fabrication de blanc" comme tu dis, tu peux aussi récupérer des couleurs (avec plus ou moins de succès), j'ai des exemples de fleurs avec des couches de bleu ou de rouge cramés qu'il faudra que je retrouve.

Sinon j'ai retrouvé ça, couche bleu bien cramé sur le bleu et rouge cramée partout ailleurs.

la photo sous-exp dans ufraw sans récupération (clipping) :

(http://chris.stingray.free.fr/tmp/test_ufraw/Test_recup_CLIP.jpg)

La même avec récupération dans l'espace HSV :

(http://chris.stingray.free.fr/tmp/test_ufraw/Test_recup_HSV.jpg)

Après, on peux toujours discuter de savoir quelle est la bonne interprétation, je suis bien d'accord  ;D

Citation de: Olivier-P le Août 20, 2008, 23:27:52En cela les logiciels qui vous donnent des bleus, de cyans, des rosés, sont ceux qui ne mentent pas.

Je crois aussi qu'il est important de souligner ce point : la récup HL, ça se fait forcément avec une colorimétrie fausse, et dans TOUTES les images ci-dessus où les détails des nuages clairs sont suffisament visibles on voit à pu près la même dérive cyan, plus ou moins planquée par les tonalités et les masques de contraste automatiques.
Dans les 2e versions (à la maison) de stingray, elle est effectivement plus discrète, mais pour moi le bleu de la zone à l'interface ciel/nuage n'est pas un bleu ciel, alors que celui un chouille plus bas vers les nuages en dessous, si.

Merci Olivier pour ces précisions qu'il est tj utile de redonner :)
Bien d'accord, tous les dématriceurs ont leur propre sauce, mais c'est bien de pouvoir ne pas en mettre ou d'en mettre + ou-
Et surtout de savoir ce qu'il fait :) C'est très transparent avec DCRaw, moins avec d'autres :(
AMA DCRaw oblige a mieux connaitre le RAW et ce qu'on en fait

CitationPour tester il me faudrait ton Raw, mais je n'ai pas envie de jouer

Tester n'est pas jouer, puisque le but est de voir sur cet exemple ce que chacun peut en tirer ;)
Il serait intéressant qu'un expert apporte sa contribution concrète...
Mon .NEF est ici :
http://dl.free.fr/jKTofmSEu (http://dl.free.fr/jKTofmSEu)

A+

polo

Citation... dans TOUTES les images ci-dessus où les détails des nuages clairs sont suffisament visibles on voit à pu près la même dérive cyan

Où la vois-tu dans les versions UFRaw (Polo_V1 et V4) et DCRaw (_DSC1254_DCRawg) ?

Citation de: polohc le Août 21, 2008, 10:11:37
Où la vois-tu dans les versions UFRaw (Polo_V1 et V4) et DCRaw (_DSC1254_DCRawg) ?

Au même endroit que les autres, elle est juste un peu plus foncée donc plus discrète... Comme j'ai dit, c'est moins criant que les autres, mais ça me dérange quand même - ça fait partie des masquages à faire à mon goût, désaturer cette zone.

C'est clair que le NEF de Polo est quand même extrême :

(http://chris.stingray.free.fr/tmp/Polo_clip.jpg)

Le ciel est pratiquement complètement cramé sur les trois couches, donc on ne peux pas faire de miracles. La récupération se fait par interpolation avec les zones voisines sans aucune information correcte sur aucune couche, c'est mission impossible.
En plus il y a une relativement forte variation de TC entre l'avant plan, le ciel à gauche et le ciel à droite, donc ça complique encore les choses au niveau de la BdB.
Pour finir il y a un truc bizarre sur l'histogramme du NEF, le canal vert clip plus tôt qu'il ne devrait et le canal bleu fait comme un double clipping  ??? C'est un truc "à la Nikon" ça ?

Non Stingray, seule la couche R est cramée ;)
Les histogrammes des softs sont aussi bridés, va voir ici : http://www.guillermoluijk.com/software/histogrammar/index.htm (http://www.guillermoluijk.com/software/histogrammar/index.htm)

L'histogramme de mon fichier avec au dessus les paramètres DCRaw :

En fait on a tous les deux tord  ;D
Moi j'ai fait l'histo avec une expo à 0 mais en gardant la BdB, donc les coef multiplicateurs remontent les couches rouge et bleu. Et si j'ai bien compris ton histo ce n'est pas l'histo du raw d'entrée mais celui du tiff de sortie après dematricage et récup (-H 1).

D'après ce que je vois, c'est la couche verte qui semble cramée sur tout le ciel avec quelques zones cramés sur les trois couches (c'est d'ailleurs celles qui restent irrécupérables). Il y a en plus ce "double clipping" sur les couches vertes et bleu qui donne l'impression que le bleu est ok alors que c'est juste l'algo de traitement des raw Nikon qui a "crée" ces valeurs (interprétation purement personnelle !!).

CitationEt si j'ai bien compris ton histo ce n'est pas l'histo du raw d'entrée mais celui du tiff de sortie après dematricage et récup (-H 1)

Tu as en partie bien compris : c'est le fichier TIFF, par contre d'après la doc DCRaw les options sont :
-H 0 
    Limite les zones claires à du blanc pur (par défaut).
-H 1
    Laisse les zones claires sans limite (différentes teintes rosées peuvent apparaitre).
-H 2
    Combine les valeurs de pixels limitées et illimitées de façon à obtenir un transition graduelle vers les blancs.
-H 3+
    Reconstruit les zones claires. Les petites valeurs favorisent les blancs, les valeurs importantes favorisent les couleurs. Essayez -H 5 comme un compromis. Si cela n'est pas assez bon utilisez -H 9, supprimez les zones claires non blanches et copiez les dans une image générée avec -H 3.

Ainsi, - H 1 n'effectue aucune modification
Par contre, que fait UFRaw dans l'option que tu as sélectionnée qui restaure dans l'espace HSV !?

Citation de: polohc le Août 21, 2008, 14:21:47
Par contre, que fait UFRaw dans l'option que tu as sélectionnée qui restaure dans l'espace HSV !?

Je ne sais pas trop si ça correspond a une option de dcraw, la restauration LHC d'UFRaw semble correspondre a peut près au -H 2 mais l'autre est peut être un développement propre à UFRaw.

Après réflexion (comme quoi çà sert d'échanger d'une manière constructive :)), je pense que pour voir les canaux écrêtées au delà du niveau 65536 (TIFF 16 bits) il faut utiliser -H O qui coupe à ce niveau du blanc pur ;)
Ce que j'ai fait, l'histo est un zoom vers ce niveau des HL
On peut voir que R est bien écrêté, B dépasse un peu la limite et V ne l'est pas (ce résultat semble plus conforme aux précédentes constatations)
On avance, en attendant que les experts s'en mêle :D

Et maintenant la version -H 2 qui utilise les valeurs écrêtées par rapport au blanc pur (qui existent bien puisque -H 1 les trouve) pour reconstruire un blanc légèrement grisé en modifiant les valeurs des canaux RVB

Bonjour à tous,

Oui bien entendu, cramer et récup cramer n'est pas impossible avec les canaux restants. Vous avez AUSSI raison. Et ce n'est pas "entièrement" tricher.

Néanmoins nous sommes dans l'invention, l'interprétation comme tu dis.

Ok je vais faire joujou avec ton Nef avec C1 et d'autres ;) Si j'ai le temps.

A ce soir.

CitationOk je vais faire joujou avec ton Nef avec C1 et d'autres  ;) Si j'ai le temps.

J'espère que tu auras le temps :)
Ton traitement de ce fichier nous situera un peu mieux dans ces travaux qui donnent des résultats tj perfectibles  :-\
A + tard

Heu situer non, voir le gout de qq1 ;)

En fait étant une reconstruction, ce que je fais sera un choix perso.

Ici bdb froide, récup effectivement de bcp d'info, il y a suffisemment de canaux encore bons pour jouer.

Avec C1, Netimage ( vite fait ), PSP et deux fonctions de lissage et BDB, deux actions de couleurs par luminance dans PSP toujours ( PSP a des bons outils très rapides ). Qq actions de masque de zone ( pas trop c'est délicat sur zone de grosses luminances ) en désaturation, puis resaturation en corrections de balance comme citées ci haut. 15mn.

Pas eu le temps de fignoler ( zone ciel bleu à bosser avec bcp plus d'attention ), mais c'est vite "acceptable".

www.photus.eu/img/Recup_C1-4.jpg

... je retourne à Pékin ! :)

La fameuse zone morte normallement.

Je viens de mettre à jour sur mon site la version de Dcraw que j'ai appelée Dcrawggt87. C'est une version compilée en environnement "cygwin" qui nécessite de mettre 3 librairies dll dans c:windows/system32 (l'exécutable et les 3 librairies sont dans le zip).
http://desmisja.perso.cegetel.net/geraud/photo_calcul.php (http://desmisja.perso.cegetel.net/geraud/photo_calcul.php)

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

:)

Premiers tests avec ta nouvelle version...
Tu n'as pas chômé depuis ton retour :)
Mes premières remarques, si elles peuvent t'aider à améliorer le produit :

- le paramètre -X [0-5] est utile seulement pour 8 bits ?
- le menu ne sort pas correctement les lettres accentuées
- -o [0-5] et -o <fich> Pourquoi cette même option pour un traitement différent (j'utilise la 1ère) ???
- +M semble sans effet (Nikon D80) serait-il utile seulement avec DSLR Olympus comme j'ai pu le lire ailleurs ?
- -p utilisé avec espace couleur DSLR (NikonD80-Generic.im) renvoi "conversion sans espace couleur"
- -Y et -g mériteraient une explication détaillée, je saisi mal la diff.
- lorsque fichier ouvert dans PS, l'espace est indiqué ProPhoto Dxx

Justement, concernant l'ouverture dans PS il faut bien supprimer le profil incorporer puis ensuite attribuer le profil du traitement DCRawggt87, sinon il y a une double application comme expliqué par G.Luijk

Mon impression globale est que ta version qui devient de + en + performante par les choix possibles et les résultats avant retouches ultimes, devient de + en + complexe à utiliser.
La solution lorsqu'on maitrise les options passera forcément par l'utilisation de lignes de commandes préenregistrées en txt selon le type d'image à traiter.
Toujours est-il que travailler avec est très formateur dans l'utilisation du RAW, on voit mieux ce qui est fait ;)

Les espagnols travaillent sur un DCRaw graphique : PerfectRaw très prometteur (déjà en partie opérationnel comme j'ai pu le constater sur qq traitements).
L'as-tu testé ?

 [at]  Olivier-P,
Merci pour ton travail nocturne  ;)
Ta version de _DSC1274.NEF est intéressante et effectivement plus qu'acceptable.
Elle repose sur ta vision de la scène, toutefois il me semble que le choix de BDB et TC rend globalement un peu trop de Magenta, qu'il y a un peu trop de contraste sur les toits et la végétation (peut-être dû à l'accentuation pour le web)
Par contre le ciel est bien gris et après un travail supplémentaire sur ses parties bleu, ce devrait être bien, toutefois était-il possible d'aller + loin dans la densité du ciel avec C1 + PSP ?
Mais, tu as utilisé des masques de zones... ;) Il semblerait que ce soit incontournable pour arriver à de bons résultats.

Bonjour Polohc

Le paramètre -X ne sert qu'en 8 bits, je l'ai fait au démarrage de mon travail, pour "voir".

C'est vrai que le menu avec les caractères accentués donne des résultats bizarres...mais il suffit que je supprime les accents...

Pour -o [0..5]  et o fichier, la différence c'est que :
* dans le premier cas, la gestion des couleurs est faite directement en inscrivant les données d'en l'entête du fichier, ce qui permet de faire ce que l'on veut..Changer les matrices de conversion XYZ RGB, changer les points blancs, changer les gamma TRC, etc. Ce sont ces points que j'ai modifiés en combinant cela avec les gammas variables (une première partie linéaire, puis une seconde en puissance décroissante, comme le fait Lightroom avec le doux nom de Melissa). Je vais y revenir plus loin.

* la seconde -o fichier.icm utilise LCMS, c'est ce dont se sert G.Luijk dans Perfectraw, mais pour que cela marche en termes de respects des couleurs, il faut associer l'option -p fichier.icm...(avec le même fichier par exemple Prophoto.icm). Sinon les couleurs sont plus que fantaisistes (je l'ai vérifié avec des photos de mire 468 couleurs).

* l'option -p fichier.icm, désactive l'option +M et force la "gestion de couleur interne" en mode "conversion sans espace couleur" (équivalent à -o 0). Ceci sert en théorie pour bâtir des profils colorimètriques d'entrée, mais le bug annoncé plus haut fait que ce n'est pas très opérationnel. Par contre mettre -o fichier.icm derrière fait que l'espace colorimètrique sera bien  fichier.icm

* pour mon D200 l'option +M est opérationnelle : en fait Adobe a fourni à D.Coffin autant de matrices de couleurs que de boîtiers...Le rendu est très bon (voir mes essais comparatif sur mon site entre DCRAW, NX, ACR...). Elle est désactivée si tu utilises l'option -p ou -o fichier.icm. Pour ton D80 voici les valeurs...
{ "NIKON D80", 0, 0,
   { 8629,-2410,-883,-9055,16940,2171,-1490,1363,8520 } },

* Comme j'ai donné la possibilité de modifier le point blanc pour Prophoto et Widegamut (soit D50 ou D65), c'est pourquoi j'ai remplacé Prophoto D50 par Prophoto Dxx. Par défaut c'est D50.

Concernant l'ouverture dans PS, en général il faut laisser le choix "préférer le profil incorporé"...sinon en linéaire pur.

Pour ce qui est des options -g et -Y c'est en partie expliqué sur mon site, mais je ferais un complément. Néanmoins :
* le paramètre -g joue sur la forme de l'histogramme, mais n'agit pas sur les courbes internes dites "TRC" , c'est de mon point de vue le manque qu'il y a dans le travail des espagnols. Dans la version 8 bits D.Coffin prévoit quelque soit l'espace colorimètrique (sRGB, Prophoto...), le même gamma variable (sinon en recompilant) et la même courbe TRC. Dans la version 16 bits, D.Coffin ne prévoit que le linéaire, donc sans gamma et sans TRC...Les deux espagnols qui ont fait un sacré boulot (notamment l'équilibrage des verts et un algorithme de traitement du gamma 16 bits très rapide), n'ajoute pas de "TRC" ce qui a pour résultat des images plates sans contraste, qu'on peut "bricoler" avec des courbes (dans PerfectRaw il se servent a priori de LCMS).
* c'est mon paramètre -Y qui permet d'ajuster à la demande les valeurs TRC. Ce paramètre n'a pas d'incidences notables sur l'histogramme mais joue sur le rendu des couleurs. Dans le cas d'une gestion des couleurs (Adobe, Microsoft, LCMS...) le traitement fait les deux avec (sensiblement) les mêmes valeurs. Dans ce que j'ai prévu, qui ne fonctionne qu'en 16 bits, on peut combiner des valeurs de g avec des valeurs de Y, bien sûr on peut mettre les mêmes. Mais vu les finalités de DCRAW qui est un peu un couteau suisse, cette combinaison permet selon les images :
** d'étendre / réduire les histogrammes
** éclaircir +- les ombres
** ajuster le rendu des couleurs (contraste)
** etc.

L'option -L mérite quelques commentaires. En effet sous 16 bits, l'option -b (clarté - qui est en gros la racine de l'exposition) ne fonctionne pas, et ajuster l'exposition en touchant à l'histogramme peut introduire de gros défaut. C'est le but de -L  dont le premier paramètre qui agit sur l'exposition globale  (sensiblement -L 0.6 = -2IL, -L 1.4 = +2IL) et le second sur les BL, mais comme on agit sur une courbe variable le problème est complexe...

Certes accroître le nombre d'options dont certaines sont complexes (comme -g -Y -L) ne va pas dans le sens "ergonomie" ni facilité...

Je connais PerfectRaw, à ce jour il lui manque encore pas mal de chose, mais bénéficier d'une interface est loin d'être inutile...notamment pour l'aberration chromatique. A suivre avec attention.

  :)

Citation de: polohc le Août 22, 2008, 18:03:57
[at]  Olivier-P,
Merci pour ton travail nocturne  ;)
Ta version de _DSC1274.NEF est intéressante et effectivement plus qu'acceptable.
Elle repose sur ta vision de la scène, toutefois il me semble que le choix de BDB et TC rend globalement un peu trop de Magenta, qu'il y a un peu trop de contraste sur les toits et la végétation (peut-être dû à l'accentuation pour le web)
Par contre le ciel est bien gris et après un travail supplémentaire sur ses parties bleu, ce devrait être bien, toutefois était-il possible d'aller + loin dans la densité du ciel avec C1 + PSP ?
Mais, tu as utilisé des masques de zones... ;) Il semblerait que ce soit incontournable pour arriver à de bons résultats.

Oui c'est un choix, c'est ce que je disais. Magenta ? hum froid tu veux dire ? tu es étalonné ?

Oui pour les masques, aucune photo de ce genre ne se fait sans masques.

Mais il faut surtout souligner un GROS probleme, apparu aussi sur ma photo, et sur les votres. Qui est au sens réaliste du terme, complétement innaceptable, et qui remet en selle certaines de mes reflexions.

Je te laisse, toi ou d'autres, trouver où est le pb.

Cela sera un enseignement pour la suite.

Citation de: jdc le Août 22, 2008, 18:37:04

... / ... sur une courbe variable le problème est complexe...

Certes accroître le nombre d'options dont certaines sont complexes (comme -g -Y -L) ne va pas dans le sens "ergonomie" ni facilité...

Je connais PerfectRaw, à ce jour il lui manque encore pas mal de chose, mais bénéficier d'une interface est loin d'être inutile...notamment pour l'aberration chromatique. A suivre avec attention.

  :)

Euphémismes des années 80 ... :)

Jacques, c'est la base de tout travail artistique, une interface et action en direct pour l'interactivité.

Il est impossible de concevoir quoi que ce soit sans interface dans nos métiers " d'interprétation".

 [at]  jdc,
Merci pour toutes ces précisions :)

Mais :

CitationConcernant l'ouverture dans PS, en général il faut laisser le choix "préférer le profil incorporé"...sinon en linéaire pur

Lorsque "préférer le profil incorporé" est choisi l'image affichée est très pâle :( et les retouches (notamment TF/TC) amènent très difficilement à un bon résultat.
Alors que "supprimer le profil incorporé" donne une image sombre + facile à retoucher.
Pourtant l'histogramme est le même et plus conforme à cette dernière option.
Là, il y a qq chose qui m'échappe et que je pensais avoir compris par l'explication de G. Luijk dans son article "Compensation gamma, DCRaw avec gamma..." : "L'image TIFF résultante aura marqueté le profil correct mais avec gamma 1.0, ce pourquoi le plus simple en l'ouvrant en Photoshop sera simplement d'ignorer totalement le profil marqueté et d'assigner (attribuer) directement le profil dans lequel nous l'avons créée de sorte que l'image soit correctement visualisée."

Le restant de ton message je vais tenter de l'assimiler, après une pose repas bien méritée ;)

[at]  Olivier-P,
Mon écran est étalonné (Optix XR + Monaco Optix Pro) et mes impressions sur Epson R1800 avec mes profils Spyder3Print sont fidèles...
Mais la faible dérive M de ton fichier est peut-être due à ma vision de la scène.

Quant au GROS pb, à part un irréalisme dû à la dynamique excessive que j'essaye de réduire comme sur une image HDR en voulant voir jusqu'où on peut aller, je ne vois pas :( pour l'instant, mais... je vais relire tes réflexions ;)

Fort de ces derniers évènements, j'ai refais un jpg avec qq options DCRawggt87 (jointes à l'attention de Jacques, Olivier ne regarde pas ;)) et un travail sur saturation/désaturation après TF/TC :
:

M...e, en affichage web, elle est trop désaturée ;D j'ai oublié de la mettre en sRGB ;D

Polohc

Si l'image est claire, c'est probablement parce que la modification gamma faite par G.Luijk et M.LLorens ne prend pas en compte le paramètre TRC.

Fait un essai avec le même NEF. en 16 bits

1) gamma = 1, image sombre. On peut la rendre correcte en "bricolant" les courbes, etc.

2) gamma de type sRGB (à ne pas confondre avec l'espace colorimètrique), c'est à dire variable - début de courbe linéaire, puis gamma 2,4 qui varie linéairement. L'histogramme s'est élargi, mais l'image manque de contraste, est pâle, blanchâtre...

3) comme précédemment, mais en ajoutant le paramètre TRC..et là l'image devient correcte...

(Bien sûr j'ai choisi gamma de type sRGB car c'est celui qu'ont choisi les 2 espagnols -comme Ligthroom, mais tu peux choisr autre chose...).

Citation de: stingray le Août 20, 2008, 09:56:29
A noter d'ailleurs que dcraw n'est pas un soft open-source, mais est complètement libre et gratuit, ce qui permet aux éditeurs de soft commerciaux de l'utiliser sans scrupules (et même sans que l'auteur ne le sache).

Tss tss! dcraw est pleinement un soft open source encore plus qu'un soft sous GPL par exemple. Pour les softs commerciaux il semble que Dave Coffin vende des licences (voir point d de l'entête du fichier).

Citation de: cptcv le Août 22, 2008, 21:46:27
Tss tss! dcraw est pleinement un soft open source encore plus qu'un soft sous GPL par exemple. Pour les softs commerciaux il semble que Dave Coffin vende des licences (voir point d de l'entête du fichier).

Tu as raison, en fait je faisais référence à une licence de type GPL.
Par contre l'entête est nouveau il me semble. Les premières versions n'avait pas du tout ce type de licence, il en est d'ailleurs question dans le point c de l'entête.

Citation de: polohc le Août 22, 2008, 20:30:19
[at]  Olivier-P,
Mon écran est étalonné (Optix XR + Monaco Optix Pro) et mes impressions sur Epson R1800 avec mes profils Spyder3Print sont fidèles...
Mais la faible dérive M de ton fichier est peut-être due à ma vision de la scène.

Quant au GROS pb, à part un irréalisme dû à la dynamique excessive que j'essaye de réduire comme sur une image HDR en voulant voir jusqu'où on peut aller, je ne vois pas :( pour l'instant, mais... je vais relire tes réflexions ;)

Fort de ces derniers évènements, j'ai refais un jpg avec qq options DCRawggt87 (jointes à l'attention de Jacques, Olivier ne regarde pas ;)) et un travail sur saturation/désaturation après TF/TC :
:

Ok tu as vu la scène, dans ce cas il aurait fallu que je "jaunisse" un peu.

Ok je ne regarde pas, mais apparemment tu évites un peu le piège sans le savoir, c'est bien :) Allez c'était facile, les parties qui manquent sont bleues certainement en grande partie puisqu'on voit du vert cassant le bleu. La facilité des logiciels ( et plus encore quand on agit vite sur masque ) est de désaturer. Ainsi les ruptures de chroma n'existe plus.

"Dans la vie", ce genre de photos ... c'est éviction hélas.

Citation... en ajoutant le paramètre TRC..et là l'image devient correcte...

Oui jdc, c'est çà, merci :D

Effectivement, avec un peu d'habitude :
- les paramètres de g modifient la luminosité où on veut
- ceux de Y modifient le contraste aussi où on veut
- ceux de L étendent + ou - l'histogramme

Un peu de "Tons foncés/Tons clairs" et de "Saturation + ou -" selon besoin et le tour est joué

Maintenant je rêve d'un PerfectRaw qui intègrerait tous ces paramètres sous forme de curseurs :)
Tu devrais collaborer avec les Espagnols... ;)

 [at]  Olivier-P,

Oui la TC était sans doute un peu + jaune

Citation... apparemment tu évites un peu le piège sans le savoir, c'est bien  :) Allez c'était facile, les parties qui manquent sont bleues certainement en grande partie puisqu'on voit du vert cassant le bleu. La facilité des logiciels ( et plus encore quand on agit vite sur masque ) est de désaturer. Ainsi les ruptures de chroma n'existe plus.

La description de ton traitement m'avait mis sur la voie ;)

Citation"Dans la vie", ce genre de photos ... c'est éviction hélas.

Oui, mais elle a bien servi comme "cas d'école", j'en ai qq unes avec d'autres pb, sans autre intérêt que de servir de matière à test.
Les logiciels évoluent tellement vite qu'il est bon d'en vérifier les perfs lorsqu'une version majeure sort, quand on est passionné et qu'on a le temps...

Oui tu as raison, toujours utile d'aller voir les "limites".

Bonnes photos à tous et bon code à Jdc ;)

Citation de: polohc le Août 22, 2008, 23:36:08
Maintenant je rêve d'un PerfectRaw qui intègrerait tous ces paramètres sous forme de curseurs :)

Hé hé cela se nomme "Capture One 4", "Bibble", et autres DPP ou NX ... sauf qq commandes qui manquent dans les moins chers. Par exemple la correction de chroma dans C1/4 ( le logiciel non pro) absente.

Sinon tous ces logs font la mm chose, souvent mieux. Forcément mieux quand on connait leurs implications diverses, certains pour le MF, d'autres pour des constructeurs seuls. Vraiment si un a une tare visible ( bdb auto dans Nx par exemple sous tungstene ou illuminants divers ), un autre potard du mm log en vient à bout ( corrections tres poussées de couleurs de balance ).

Le code de Coffin est déjà utilisé dans ces logs. Depuis des années. Et avec potards.
Comme celui de ... zut oublié le nom ... dans RIT de Canon ( jpg intégrés aussi ) est pris chez un dev externe.

Avec potards saperlipopette ! :)

Citation de: stingray le Août 20, 2008, 20:16:54

- Dans UFRaw faire un développement en récupérant les HL tout en remontant les ombres :

(http://chris.stingray.free.fr/tmp/Polo_V3.jpg)

- Ensuite reprise dans Gimp pour densifier le ciel (un calque), quelques petites retouches de couleurs et voila :

(http://chris.stingray.free.fr/tmp/Polo_V4.jpg)

Faudra que tu m'expliques comment tu as fait, parce que je n'arrive pas à ton résultat...

Citation de: cptcv le Août 23, 2008, 02:27:43
Faudra que tu m'expliques comment tu as fait, parce que je n'arrive pas à ton résultat...

Alors, dev un peu différent mais pas de gros changements.
réglages ufraw :
Expo : -1EV, restauration HSV
BdB : Temp 5247, vert 1.081
Profil d'entrée : nikond.icm pris ici (http://digikam3rdparty.free.fr/ICCPROFILES/CameraProfiles/BBP.4.9.5/)
Saturation : 1.2 + légère courbe en S
Et le plus chiant à faire c'est la courbe ci dessous (modification du gamma) :
(http://chris.stingray.free.fr/tmp/ufraw_polo.jpg)

On peut voir le fichier en entier, pour voir les détails sur les nuages ? :)

On peut tirer un A5 ou un A3 ?

Avec la méthode de C1, achromie, on perd la couleur car les zones cramées sont remplies par du gris (presque tous font cela ), avec ta photo, le bleu apparait à la place du vert ( c'est la chromie normale si on baisse l'expo de cette photo ) mais dans quel état en détail ?

Le fichier en entier est  ici  (http://chris.stingray.free.fr/tmp/Polo_Tot.jpg).

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

Sur cette  version  (http://chris.stingray.free.fr/tmp/Polo_Tot1.jpg), le ciel a été densifié dans UFRaw directement, les dérives sont plus faibles.

Bien Stingray tes versions avec UFRaw ;)
Dans ta 2ème version tu densifie avec courbe, en jouant sur saturation ?
Beaucoup de détails sont récupérés dans le ciel, mais es-tu au maxi (seulement pour savoir si la limite est atteinte) ?

En ce qui concerne les dérives de couleurs dans le ciel, on peut résumer :
Deux groupes se distinguent :
- les dématriceurs basés sur la récup. -H 2 DCRaw (Highlight recovery 2 pour PerfectRaw et HSV pour UFRaw) avec une grande possibilité de densification du ciel et qui en rendent bien le bleu mais avec des parties haute et basse un peu magenta
- les dématriceurs commerciaux (LR, C1, NX, DXO) avec un peu moins de possibilité de densification et qui rendent une partie centrale cyan mais avec très peu de magenta en haut et en bas

Citation de: stingray le Août 23, 2008, 20:20:53
Le fichier en entier est  ici  (http://chris.stingray.free.fr/tmp/Polo_Tot.jpg).

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.

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

CitationAie 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

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

Citation de: polohc le Août 24, 2008, 09:53:33
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.

Citation de: polohc le Août 24, 2008, 09:53:33
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.

Citation de: stingray le Août 24, 2008, 15:50:30
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.

Citation de: stingray le Août 24, 2008, 15:50:30

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.

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.

:)

 [at]  jdc,

Je trouve très intéressant le réglage de l'expo dans ta version DCRaw :D
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 :D

 [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

:)

CitationD'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 ;)

CitationAs-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 :D
C'est formateur et la Q du traitement donne envie de continuer :D

A+

jdc,

CitationRemplace : -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 ?

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.

:)

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

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

:)

 [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 :)

 [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

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

:)

 [at]  jdc

C'était pour voir si je suivais !  :D

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

Citationje 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 : ;)

CitationC:\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 ...

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.

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

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

CitationCe 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" ;)

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

CitationJe 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 (http://desmisja.perso.cegetel.net/geraud/photo_calcul.php#dcr)

Merci pour tes réponses si rapides . on va essayer de s'y lancer dans quelques temps.

Cordialement

J'ai mis à jour mon site avec la version 1.78 Dcrawggt87 :

* le 'bug' de l'option "-[" est résolu, cela amène une action différente des paramètres  (en termes de niveau d'incidence) par rapport à la première version. Cette option qui concerne les basses lumières possède 3 paramètres :
  ** le premier accroit ou baisse le niveau de luminance (L) aux environs des valeurs L proches de zéro (niveau de base). On peut théoriquement entrer n'importe quelle valeur entre 0,1 et 10 ou plus...Mais attention aux artefacts et au bruit. Il est donc plus "raisonnable" de limiter son amplitude de 0,5 à 3. Les valeurs inférieures à 1 vont assombrir les BL et celles supérieures à 1 les éclaircir, dans le rapport donné par la valeur de base. Ainsi pour L=1 avec un accroissement de 3 la nouvelle valeur sera L=3 et avec une réduction de 0,6 la valeur L résultante sera à L=0,6

  ** le second correspond au seuil limite d'action exprimé en valeurs L. Au dessus de cette valeur, le système n'a plus d'effet. Toute valeur comprise entre 1 et 99 est théoriquement bonne. En pratique, en fonction de l'histogramme, on pourra ajuster l'action au besoin. Des valeurs comprises vers 40 à 60 sont réalistes. Entrer 100 amènera à reprendre l'ensemble de l'histogramme, avec une action décroissante de 0 (action maximale) à  100 ..plus d'action.

** le troisième correspond à la profondeur de la courbe. Entrer 0 amène une courbe linéaire. On peut théoriquement entrer n'importe quelle valeur entre 0 et 10 ou plus. Plus le chiffre sera élevé plus l'action sera ciblée proche des valeurs de L=0. Par exemple, si on choisit un seuil à L=50, une amplification de base de 2,5 les choix du paramètre profondeur ne changeront pas les valeurs d'amplification à L=0 (2,5) et L=50 (1). Par contre, si je choisis une valeur intermédiaire, par exemple L=25, si profondeur=0, l'amplification sera à L=25 de 1,75 (linéaire), si profondeur = 0,5 l'amplification devient 1,53, si profondeur =3 l'amplification devient 1,31 et si profondeur=10 l'amplification devient 1,04

Avec ces 3 paramètres on réalise à peu près ce que l'on veut sur les basses lumières, avec une remarque d'importance, il n'est pas nécessaire d'agir sur la saturation  car contrairement à d'autres logiciels j'agis en Lch sur le canal L, donc sans incidences sur la saturation et la teinte. Il suffit d'examiner une image avec Dcraw plus l'action que j'aie ajouté et par exemple Capture NX pour voir que dans le second cas les valeurs a et b de Lab sont changées...

J'ai ajouté 2 autres fonctions (dont une a été testé par Polohc) :
  * le contraste -% a b : 'a' accroissement (ou réduction) du contraste, 'b' seuil d'action en valeurs L - entrer par exemple une valeur de seuil de 80, va amener une variation continue du contraste entre L=20 et L=80, et de 0 à 20 et de 80 à 100 une réduction progressive de ce contraste
    ** attention toutefois, l'inconvénient de travailler en 'aveugle' avec Dcraw amène des contraintes...et attention aux valeurs de 'a' qui dès 1,1 va amener un accroissement important du contraste. Par exemple pour L=80 la nouvelle valeur devient avec a=1,1 L=83...et avec 1,4 L=92...

* des rendus spécifiques (comme le font Capture NX, DxO, etc.) - option -J a. J'ai activé 3 possibilités a=2 paysage, a=3 portrait, a=4 standard. Ces 3 rendus agissent simulatnément et de manière différenciée sur les chromaticités (ternes, pastels, saturés), le contraste et l'exposition.

:)
               

Comme évoqué dans mon post de 17:26:55, l'option -% ne me parait guère utilisable en l'état car même avec a = 1.1 on retrouve des zones posterisées,
Le détail de traitement dcrawggt87 et un crop de l'image résultante :

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.0 1.0 1.0 -Z 1.15 3 -[ 1.0 30 4 -% 1.1 75 -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.342
Equilibre canaux verts globalement
et equilibre canaux verts localement
rayon 8 pixels
Temps CPU verts: 1.419
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.522
Combinaison des hautes lumieres...
Temps CPU HL: 0.203
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.558
Conversion Lch => Lab => xyz => rgb
depas:i_r Rouge 0 i_g vert 0 i_b bleu 0
minimum rgb calcul 0 maximum rgb calcul 0
Temps CPU Lab 2: 2.621
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.443
Ecriture des donnees dans DSC_0416.tiff ...

 [at] polohc...
Encore une fois tu avais raison..J'ai regardé "à la loupe" mes algorithmes de modification du contraste - je l'avais déjà fait suite à ta première intervention mais je n'avais pas vu...l'erreur - que je viens de voir. Il y avait une discontinuité aux environs de la partie basse du seuil. Si tu réglais celui-ci par exemple à 70 avec un contraste de 1.1, une discontinuité apparaissait entre 27 et 30...C'est maintenant corrigé et j'ai modifié en conséquence mon site.

Bien sûr tout ceci est expérimental, le code n'est pas optimisé, et son "placement" - c'est à dire la manière dont il s'intègre dans le processus de traitement - non plus.

Merci pour tes essais qui font progresser le sch..ic.

:)

J'ai repris le code de Dcraw de Dave Coffin (version 8.88 du 15/09/2008) qui traite de nouveaux boîtiers dont les récents Nikon D90 et Sony A900.

J'ai intégré mes modifications et mis l'exécutable windows sur mon site.

La liste des appareils supportés se trouve en bas de la page d'accueil du site de D.Coffin http://www.cybercom.net/~dcoffin/dcraw/ (http://www.cybercom.net/~dcoffin/dcraw/)

:)

CitationMerci pour tes essais qui font progresser le sch..ic.

[at] jdc
A mon tour de te dire merci pour l'évolution intéressante et rapide (peut-être trop ! ;)) du sch..ic
Je me suis pris au jeu d'utiliser ta version DCRawggt, on veux tj voir ce qu'apporte la dernière nouveauté et bien souvent c'est une bonne surprise et un peu moins de retouche à faire dans PS et lorsqu'on y applique encore une courbe c'est tout en nuance :D
J'obtiens des résultats jamais atteints sur des images difficiles, notamment en respect des transitions/nuances, des détails et de la colorimétrie :)
Je pense que lorsque ton produit sera plus abouti (à ton gout), il serait intéressant pour le rendre + accessible de faire un didacticiel/workflow

A+, je vais tester tes dernières MAJ

Epaté Jacques par ton boulot, ton application.

Hélas comme je le disais cela attirera 0.01% des utilisateurs.

Aurais tu la force et la patience de te mettre à faire du Visual Basic ou autres dev, pour nous proposer de l'interface ? ce serait absolument passionnant d'avoir un dev qui exauserait ensuite nos idées que les constructeurs oublient, ou qui ne sont que l'une chez l'un et l'autre chez un autre ?

Chiche ?

 [at] Olivier-P

Merci pour tes appréciations.
Parmi les finalités de mon travail:
* la première est de "comprendre" :  comprendre comment fonctionne un logiciel de traitement raw et comme Dcraw est quasi le seul à ouvrir son code, c'est lui que j'ai choisi. Le code de D.Coffin n'est quasi pas commenté et quelque peu touffu (il dit lui même qu'il est 'huggly'). Néanmoins avec le temps on arrive à voir les phases de :
  ** a) lecture du fichier (CR2, NEF,...et les boîtiers associés)
  ** b) traitement de la matrice de Bayer (ou équivalent)
  Ces deux premiers stades ont été repris par de nombreux logiciels du marché.
  ** c) balance des blancs, traitement des HL et choix du mode d'interpolation et éventuel traitement du bruit.
  ** d) puis conversion en RGB avec choix de l'espace colorimétrique (et ceci sans gestion des couleurs au sens application de profils...)
  ** e) élaboration du fichier TIFF
  ** f) écriture

et comprendre où on peut ou non apporter des améliorations.
Les "améliorations" que j'aie choisies sont dans le domaine que je pense commencer à maîtriser, la colorimétrie.
Un groupe d'espagnols travaille sur d'autres aspects comme une interpolation de très haut niveau (AFD) qui a priori semble plus efficace que VNG ou AHD en termes de définition et moins productrice de bruit, ainsi que d'autres aspects qu'il serait fastidieux de commenter..(équilibrage des canaux verts, gamma, etc.)

* la seconde finalité est de permettre aux quelques utilisateurs qui ne sont pas rebutés par la ligne de commande, eux aussi de comprendre ce que fait chaque réglage...C'est très pédagogique.

Le code de D.Coffin est écrit en C Ansi ce qui lui assure une portabilité sur tous les systèmes...L'inconvénient de ce code touche en particulier à la gestion de la mémoire qui n'est pas optimisée - si on veut faire une interface graphique.

L'interface graphique de DCRAW (il en existe 2 autres sur le marché, mais peu performantes) est en cours de développement par une équipe d'espagnols (dont Guillermo Luijk, Manuel LLorens, et d'autres qui apparaissent avec leur pseudo). Elle s'appelle PerfectRaw, une version provisoire est dispo , la version 1.0 devrait sortir prochainement. M.LLorens m'a proposé d'intégrer leur équipe.
Mais il ne s'agit pas de réinventer la roue et de proposer un nième produit comme NX ou LR, mais bien de garder l'esprit de Dcraw avec une interface graphique - qui permet de voir en direct ou en léger différé de quelques secondes ce que l'on fait - mais en proposant pour chaque fonction le "meilleur" de ce qui se fait. Donc en sortie ce ne sera pas un produit pour faire des batch...et il restera sommaire.

Juste pour monter le travail d'un des membres - G.Luijk - qui a sorti le logiciel "Histogrammar" qui lit les fichiers TIFF en 16 bits et affiche les histogrammes dans la plage 0 - 65535 en permettant les zooms...remarquable.

http://www.guillermoluijk.com/software/histogrammar/index.htm (http://www.guillermoluijk.com/software/histogrammar/index.htm).

:)

J'ai introduit dans le code de Dcraw, la possibilité de modifier les basses lumières..
Les lignes de commande sont certes rébarbatives...mais les possibilités sont importantes. Plutôt que de parler chiffres, j'ai réalisé un petit graphique qui montre les possibilité de l'option "-[".

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 : dans l'exemple, 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é. Si on entre protection = 10 ou plus, la courbe est très creuse et n'agira quasiment que sur les très basses lumières.

* protection (pour éviter la montée du bruit dans les très basses lumières): 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 et autre caractéristique, en agissant sur les composantes Lch, en modifiant L on ne modifie pas la saturation. Bien sûr rien n'interdit par ailleurs de modifier la chromaticité!

Essayez !
:)

 [at] Olivier-P

CitationHélas comme je le disais cela attirera 0.01% des utilisateurs.

Dois-je être content de savoir que je fais partie de ce 0,01%  ???
Pour me "justifier" je dirais que je suis passionné par le traitement d'images, mais que je n'y connaissais pas grand chose (remarquez l'imparfait ;))

L'utilisation de dcraw avec les options implémentées par jdc est un formidable outil pédagogique associé à Histogrammar, lorsqu'on a un peu de temps à y consacrer.
De plus, je suis plutôt perfectionniste, à mon âge j'ai gardé ce défaut sur les sujets qui me passionnent.

Mais je serai heureux si PerfectRaw respecte son CDC et nous offre un excellent dématriceur qui fera que çà mais TB ;)

[at] jdc

Ton graph expliquant l'utilisation de la modif des BL est le bienvenu, je n'ai pas à ce jour continué les tests avec

Par contre, j'ai poursuivi avec les modif expo -Z et contraste -%, elles semblent bien fonctionner et permettent d'étirer l'histo comme on veut, avec l'option gamma -g on arrive déjà à d'excellents résultats :D

Mon doute vient de l'utilisation de la modif de chromaticité qui fonctionne sur les tons ternes mais en boostant trop les J, par contre sur les tons pastels et a fortiori sur les saturés, elle n'apporte rien de visible sur les .NEF que j'ai voulu modifiés pour éviter d'avoir après traitement des verts (herbage) trop saturés.
Ce fait ne viendrait-il pas que cette modif est appliquée sur un fichier brut en linéaire ?

Je me demande aussi pourquoi et dans quel cas modifier l'affichage avec le gamma TRC -Y

polo

Pas de jugement de valeur Polo ;) l'important c'est de se faire plaisir.

Jacques c'est interressant, par contre pour le pro, il faut de la production, c'est pour cela que l'interface est utile, et de plus le jugument d'un artiste est comparative avec la simultanéité, du visuel. Donc ce serait un pas important. Oui ce serait idéal que tu joingnes une équipe existante, ce projet est captivant.

N'oublies pas de nous en parler.

 [at] polohc

L'action sur la chromaticité agit sur la composante "C" de Lch. En fait c=racine(a*a + b*b) ou a et b sont les valeurs Lab.

Tout d'abord bien sûr les modifications que j'opère se font avant application du gamma et avant la conversion vers l'espace colorimétrique de travail.

La valeur de la chromaticité peut donc varier de 0 (gris parfait) à 128*1.414= 181. J'ai arbitrairement fixé 3 seuils (que j'ai calculé à partir des saturations RGB) :
* C < 20 tons ternes
* C < 60 tons pastels
* C > 60 tons saturés.
Que fait ma routine...:
a) en première étape, avec l'option -N, elle calcule les valeurs XYZ et LCh de chaque pixel de l'image avant transformation. Dans Dcraw (comme d'ailleurs Ufraw) la matrice de transformation choisie pour ce calcul est celle de sRGB (elle sert notamment dans DCraw pour l'interpolation AHD), mais je propose d'autres choix comme Prophoto, Don RGB, etc. Cet esapce de calcul est théoriquement sans importance puisqu'on fait deux fois le même calcul à l'endroit puis à l'envers..mais j'y reviendrais.

b) en seconde étape, on applique les transformations que l'on souhaite (contraste, chromaticité, basses lumières, etc.) en agissant sur les valeurs L C ou H ou les 3 réunies. Par exemple si on entre - [at]  1 1.3 1.4, les tons inférieurs à C=20 resteront identqiues, ceux entre 20 et 60 seront multipliés par 1.3 et ceux supéreius à 60 par 1.4

c) puis je reconvertis en rgb via la matrice inverse de l'option -N

d) et enfin intervient la conversion RGB avec l'espace de travil chois et le gamma choisi;

Qu'est-ce qui peut se passer ? En fait c'est à la fois très simple et complexe.

Si les modifications apportées à Lch font que les nouvelles valeurs entrent dans l'espace de travail choisi, on verra apparaître les changements soit à l'œil car les couleurs sont (encore) dans l'espace d'affichage de l'écran qui est sensiblement sRGB, soit à la pipette avec CS en examinant les valeurs Lab...lorsque les valeurs dépassent sRGB et sont inférieures à l'espace de travail choisi.

Mais comme le dit fort justement Olivier-P, on arrive très vite en agissant sur le contraste et surtout sur la saturation (ou la chromaticité) à dépasser l'espace de travail - même Prophoto. D'où l'option que je propose -N 2 1 1 ou -N 2 1 5, etc. qui permettent de voir ou cela déborde... et on y arrive très vite surtout vers les rouges, orangés, par exemple des fleurs. Bien sûr je n'ai pas de remède à cela...sinon les options d'affichage et de traitement des valeurs 'out' que je propose.

Quand à l'option -Y elle permet de faire varier le gamma interne TRC. En général il vaut mieux choisir une valeur identique à celle du gamma de base. Mais et c'est un peu la vocation de Dcraw, il peut être utile de séparer ces 2 réglages. Le gamma de base va étendre l'histogramme avec une forme variable surtout dans les BL selon le choix du gamma...et le gamma TRC va rendre des tons plus ou moins sombres ou clairs..Il n'y a pas de réponse standard, sinon au cas par cas.

:)

Merci jdc pour cette explication :D

Je comprend bien maintenant pourquoi on peux avoir ces modif visibles ou non à l'écran,
mais le seuil de 60 n'est-il pas un peu élevé ? ou peut-être les essais que j'ai effectués sur qq photos (principalement des paysages aux couleurs pas très saturées) ne sont pas représentatifs.

Des paramètres mal choisis pour -Y m'ont conduit à mal corriger des images, en ProPhoto je reste donc tj avec -Y 0 1.0, sinon à l'ouverture dans PS je choisi "sans gestion des couleurs", ensuite j'attribue le profil du traitement DCRaw.

Sinon, je confirme que c'est un réel + de corriger en mode LCH, pour notamment éviter la montée de la saturation sur des zones délicates comme les verts de la végétation :D

[at] Olivier

Bien d'accord, un amateur qui souhaite obtenir la Q max d'une image n'a pas les mêmes besoins qu'un pro qui doit concilier Q/coût ;)
Toutefois, je ne suis pas maso, si PerfectRaw m'apporte en mode graphique l'équivalent in fine de DCRawggt, je l'adopterai avec satisfaction :D

Bonjour Polohc

Suite à tes remarques, j'ai essayé les options - [at]  sur ma mire 468 couleurs qui a des couleurs dans sRGB, dans AdobeRGB, dans WideGamut et Prophoto

Quelques essais :
* en activant uniquement  les teintes ternes - [at]  1.2 1.0 1.0, une couleur par exemple L=29 a=7 b=10 devient L=29 a=8 b=12  (rapport de 1.2 sur a et b)
* sur les pastels - [at]  1.0 1.2 1.0 la couleur L=31 a=5 b=-61 devient L=31 a=10 b=-75 (couleur qui est hors AdobeRGB)
* sur les saturées - [at]  1.0 1.0 1.2, la couleur L=56 a=45 b=38 devient L=56 a=55 b=43

Je vais "étudier" l'affaire et réexaminer le rapport entre saturation (qui est une notion RGB) et chromaticité (qui est une notion Lab Lch) et voir si il ne faut pas modifier quelque chose...car la chromaticité (c'est pour cela quelle a été conçue) est par nature indépendante de l'espace colorimétrique...et la saturation non...

:)

J'ai modifié l'algorithme de l'option - [at]  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 milli-secondes 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...

Sur l'exemple ci-dessus, le nouvel algorithme ne change rien aux couleurs 1 et 3, mais modifie le traitement de la 2... qui devient saturée..et donc le coefficient sur pastel ne joue pas (dans ce cas bien sûr) et les valeurs restent inchangées L=31 a=5 b=-61. Par contre cette valeur sera changée si on agit sur le coefficient saturé.

:)

 [at] jdc

TB ton automatisme de sélection et de traitement des tons 8)
Je suis "réconcilié" avec cette action :)
Son effet qui peut rester subtil respecte bien les zones de transition.

Oui, je faisais une mauvaise association entre saturation et chromaticité,
vérifié depuis dans PS avec TSL et Lab :)

Merci, je progresse...

 [at] polohc

C'est bien d'avoir un "testeur"...car seul on omet des choses.

En fait l'algorithme est faussement juste...comme d'ailleurs beaucoup de choses (la plupart des sciences dites exactes) que les personnes croient exactes..et qui ne le sont pas.

Bref je pars de la saturation 'rgb', c'est à dire celle de l'image qui vient juste d'être interpolée et qui a eu sa balance des blancs.

Je fais 3 paquets (c'est arbitraire, car j'aurais pu en faire 2 - pastel et saturé - ou 4 ou plus...). Pour un pixel donné je prend ses valeurs rgb, calcule la saturation rgb. Et en fonction des limites de chaque paquet, j'applique le coefficient correspondant que tu entres pour chaque paquet. Si le produit de ce coefficient par la saturation est inférieur à 1, la chromaticité prend en compte totalement le coefficient, sinon celui-ci est réduit pour limiter à 1 la saturation.

Néanmoins c'est un peu faux, car la loi saturation est quasi linéaire en rgb. Saturation = (max(rgb) - min(rgb)/max(rgb) alors que le lien chromaticité => RGB n'est pas linéaire, il fait intervenir une cubique et une multiplication matricielle... Bref, à un poil près cela marche sinon lorsqu'on est 'out' (mais là on s'en moque) ou aux limites de 'out'..avec de petits écarts (par rapport à la demande).

On peut encore améliorer le machin, si c'est nécessaire...en pondérant l'action selon la teinte, mais là en lignes de commande cela va devenir complexe (comme saisie).
;)

CitationOn peut encore améliorer le machin, si c'est nécessaire...en pondérant l'action selon la teinte, mais là en lignes de commande cela va devenir complexe (comme saisie).

A voir à l'usage, mais les possibilités globales de ta version DCRaw sont déjà très complètes :D
Les interventions en post-traitement/retouche se sont bien réduites et on ne peut pas se passer d'une accentuation (à la B. Fraser en ce qui me concerne), d'une courbe de contraste localisé en live dans PS (ou autre) et in fine, le type d'utilisateur de DCRaw veut imprimer l'image

Et on peut se poser la Q :
Pourquoi DCRaw n'est que si peu utilisé ?
Si c'est parce que son traitement ne va pas assez loin, ta version ...ggt.. comble cette lacune.
Si c'est parce que son utilisation en LC est rebutante, ta version ...ggt.. ne comble pas cette lacune.

AMA, DCRaw restera destiné à un public restreint d'amateurs avertis, curieux et puristes ;)
Reste que si une demande se faisait sentir un tuto/workflow pourrait être concocté.

polo

Pour rebondir Jacques, tu peux offrir un épreuvage avec taquet pour le hors gamut ? pour chaque espace evidemment.

 [at] Olivier-P

Je ne sais pas ce que tu appelles "taquets", mais actuellement, l'option que je propose permet avant conversion RGB, donc juste après avoir interpolé. Nous sommes donc en (rgb), ce qui se trouve sur le capteur, mais avec une balance des blancs et une interpolation (de son choix).

A ce stade je propose une conversion rgb ==> XYZ =>Lab => Lch et réciproquement qui vise 3 choses:
1) faire des calculs sur exposition, contraste, saturation, basses lumières..hautes lumières
2) visualiser à l'écran dans un espace de calcul de son choix (un parmi 7..qui peut être différent de l'espace de travail. Je peux en mettre plus du moment qu'ils sont matriciels), les "débordements" de gamut...bien sûr avec les limites des écrans
3) offrir 3 possibilités de traitement des valeurs rgb recalculées (après contraste, saturation, etc.):
     a) clipping (en français 'borner') aux limites du gamut;
     b) laisser faire les calculs ..et là on a un peu n'importe quoi (c'est ce qui sert à voir à l'écran), car on essaie de faire entrer dans l'intervalle (0..65535 : un 'ushort') des valeurs négatives et/ou supérieures à 65535 (des réels);
     c) remettre les valeurs initiales avant calcul .

Cela répond-il a ta question ?
:)

J'ai apporté une modification à ma version de Dcraw.

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 d'autre part, agir sur la fenêtre secondaire (par exemple 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 que 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 - [at]  1.1 1.3 1.2 qui agissait sur la chromaticité devient  [at]  0 1.1 1.3 1.2 pour une action sur l'image entière et  [at]  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 petite 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é.

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.

:)

Salut jdc

L'évolution de ta version DCRaw est spectaculaire, je l'utilise depuis qq temps et mes TIFF ne se sont jamais aussi bien "portés" :D

Par contre, je pense que pour l'instant je vais me cantonner aux modifs sur l'image globale qui me conviennent bien en LCH, seule la modif sur les BL est difficile à paramétrer pour ne pas dégrader le contraste dans cette zone.

A mon gout par facilité, je préfère exécuter les retouches localisées dans PS (puisque le passage dans un logiciel de retouche reste indispensable) avec par ex.des calques de réglages courbe + dégradé en mode luminosité

:)

Citation de: jdc le Septembre 30, 2008, 07:41:30
[at] Olivier-P

Je ne sais pas ce que tu appelles "taquets", mais actuellement, l'option que je propose permet avant conversion RGB, donc juste après avoir interpolé. Nous sommes donc en (rgb), ce qui se trouve sur le capteur, mais avec une balance des blancs et une interpolation (de son choix).

A ce stade je propose une conversion rgb ==> XYZ =>Lab => Lch et réciproquement qui vise 3 choses:
1) faire des calculs sur exposition, contraste, saturation, basses lumières..hautes lumières
2) visualiser à l'écran dans un espace de calcul de son choix (un parmi 7..qui peut être différent de l'espace de travail. Je peux en mettre plus du moment qu'ils sont matriciels), les "débordements" de gamut...bien sûr avec les limites des écrans
3) offrir 3 possibilités de traitement des valeurs rgb recalculées (après contraste, saturation, etc.):
     a) clipping (en français 'borner') aux limites du gamut;
     b) laisser faire les calculs ..et là on a un peu n'importe quoi (c'est ce qui sert à voir à l'écran), car on essaie de faire entrer dans l'intervalle (0..65535 : un 'ushort') des valeurs négatives et/ou supérieures à 65535 (des réels);
     c) remettre les valeurs initiales avant calcul .

Cela répond-il a ta question ?
:)

Oui tb, clipping ;)
7 espaces, cré vin dieux tu t'es surpassé. Blagues à part bravo.

Mets toi à VB6, sincérement cela me fait envie que tu passes en visuel. Car je t'avoue qu'il met totalement impossible dans les flux de travaux actuels de repasser en lignes  de commande. Ni aucun des pros actuels. Et pourtant j'en viens de ce monde de tableaux noirs ;)

Citation de: Olivier-P le Octobre 06, 2008, 01:10:35
Oui tb, clipping ;)
7 espaces, cré vin dieux tu t'es surpassé. Blagues à part bravo.

Mets toi à VB6, sincérement cela me fait envie que tu passes en visuel. Car je t'avoue qu'il met totalement impossible dans les flux de travaux actuels de repasser en lignes  de commande. Ni aucun des pros actuels. Et pourtant j'en viens de ce monde de tableaux noirs ;)

Peut-être que jdc s'il intègre - ou à intégré - l'équipe de développement de PerfectRaw pourra faire passer tout son concept de traitement des RAW dans ce logiciel graphique qui est dans cette philosophie ;) :D

C'est bien la philosophie de Dcraw et PerfectRaw...
[at] Olivier-P. Quitte à faire du développement graphique autant choisir Visual C que Visual Basic...mais ici on entre dans un autre domaine, celui de l'interface graphique.

On peut décomposer un logiciel raw en 4 grandes fonctionnalités :
* a) traiter l'image qui est sur le capteur (lire, interpoler, balance des blancs, colorimétrie,...) et souvent accentuation, bruit,...
* b) post traiter cette image (retoucher, calques, ...mais aussi accentuation, bruit.. qui peuvent selon la philosophie se trouver ici, on travaille alors en RGB.
* c) assurer des traitements en série (batchs, vignettes...)
* d) traiter rapidement
* e) avoir une interface conviviale et performante.

Le travail que j'ai réalisé s'inscrit dans a)

Celui de Perfectraw dans a) d) et e)...Mais jusqu'où ira-t-elle pour e) ???. Cela consomme beaucoup de puissance et génère des incompatibilités.

Par exemple Dcraw.exe est un programme d'environ 400K°, Capture NX (sans les bibliothèques .NET, environ 15M°), les compléments de Dcraw que j'ai ajouté font environ 30K°.

Quand je parle d'incompatibilités cela tient au matériel et au système d'exploitation. Par exemple DCRAW est écrit en C ANSI ce qui lui confère une portabilité quasi absolue.
Si on utilise des bibliothèques pour "accélérer" type OpenGLon devient tributaire du matériel (carte graphique).
Si on utilise des .NET ou GTk (moins performant) on devient tributaire du système d'exploitation...
:)

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

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 .

:)

Citation de: jdc le Octobre 06, 2008, 12:18:00

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

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

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

 [at] jdc

Séduisante ta fonction "micro-contraste / accentuation" :D
Elle fonctionne parfaitement dans les zones des tons moyens :D
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 :

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

:)

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

:)

:)

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

:)

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

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

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

:)

 

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.

 [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 ? ;)

:)

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

:)

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

suite :

:)

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

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.

:)