Le meilleur dématriceur ?

[xiberotar]

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

Cordialement

[jdc]

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.


               

[polohc]

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

[jdc]

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

[jdc]

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/

[polohc]

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

[Olivier-P]

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 ?

[jdc]

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

[jdc]

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 !

[polohc]

 [at] Olivier-P

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

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

[Olivier-P]

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.

[jdc]

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

[polohc]

Merci jdc pour cette explication

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

[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

[jdc]

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

[jdc]

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

[polohc]

 [at] jdc

TB ton automatisme de sélection et de traitement des tons
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...

[jdc]

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

[polohc]

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

A voir à l'usage, mais les possibilités globales de ta version DCRaw sont déjà très complètes
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

[Olivier-P]

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

[jdc]

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

[jdc]

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.

[polohc]

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"

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é

[Olivier-P]

[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

[polohc]

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

[jdc]

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