Logiciel de dématricage : nouvelle version

jdc · Octobre 07, 2009, 13:41:00

La version à jour des dernières modifications de Dave Coffin est à jour sur mon site: http://desmisja.perso.cegetel.net/geraud/photo_calcul.php#dcr

Ce logiciel pour l'instant en ligne de commande intègre de nombreuses fonctionnalités complémentaires absentes dans la version de base :
* interpolations très performantes notamment pour le traitement en haut ISO

* traitement du bruit avec des processus (au moins ?) au niveau des meilleurs (DxO, NX2, C1...)

* accentuation en mode Lab

* filtres pour réduire les artefacts d'interpolation ou de débruitage

* traitement performant des images à forte dynamique (HL et BL)

* gamma adaptés à plusieurs situations (LUT)

* profils "input" d'étalonnage opérationnels

* corrections du contraste, de la saturation, des niveaux,...

* etc.
Bien sûr vous aurez reconnu Dcraw, dans la version que j'ai développée pour Windows et que j'appelle dcraw_98...Le code en C++ est disponible sauf celui pour lequel une confidentialité m'a été demandée (interpolations RGE, JDDFD, AFD; débruitage,...)

Un tutoriel en cours de réalisation peut vous aider à tester ce produit. http://jacques.desmis.perso.neuf.fr/manuel.html

Si vous n'êtes pas rebuté par la ligne de commande (c'est beaucoup plus simple qu'on peut le croire a priori), vous pouvez l'essayer sur des images de D700, D3x, A900, 5DII, D3000, D300S,...bref la quasi totalité des boîtiers...

Essayez sur des images à 25600 ISO pour le D700 ou à 6400 ISO pour le D3X ou le A900.

Perfectraw (avec interface graphique en cours de développement) doit en reprendre de nombreuses fonctionnalités.

chewan · Octobre 07, 2009, 23:59:40

Bon, c'est bien de partager ces efforts, mais...

Franchement, c'est surement un bon logiciel pour faire des recherches, des test, etc

Mais pour un usage dans l'optique d'un photographe, c'est juste imbuvable et je suis poli.

C'est très bien les logiciels en lignes de commande, mais ils faut que le travail soit bien fait et simple, même si il faut chainer plusieurs logiciels les uns après les autres, mais dans ce cas le nombre d'option est juste proche du ridicule, je cite une des phrase du sites:

"Du fait que le nombre de commandes dépasse le nombre de caractères disponibles (A..Z, a..z, 0..9) sans faire usage des caractères dont le code est supérieur à 128...J'ai "arrangé" une solution acceptable."

Soit plus de 60 options... Quand on arrive à plus de 60 options on devrait se remettre sérieusement en question.

Proposer un logiciel en ligne de commande avec plus de 60 options, ce qui doit être pas loin voire même supérieure au nombre de paramètre de développement de LR qui lui dispose d'un feedback visuel... Amusant comme concept, c'est un gag ?

Désolé si le ton est rude mais je sais que des fois en dév. on s'écarte du droit chemin, et il me semble que c'est clairement le cas.

Franchement je ne comprend pas la cible, les scientifique font du traitement d'image sous Matlab, Labview, etc
Les ingénieurs utilisent ou développent leurs propres outils voire utilisent les mêmes outils que les scientifiques.
Les photographes devraient utiliser des outils comme LR, Aperture, etc

Donc je me pose la question suivante: Quel est le public visé ?

chewan · Octobre 08, 2009, 00:20:32

Et juste pour conclure à propos de certain commentaires mis en ligne sur ton site, oui l'interface console c'est pratique pour certain traitements.

Mais pour le graphisme, curieusement, les écrans graphiques sont plus adaptés...

Et ne pas le reconnaitre en 2009, c'est très très fort.

Il faut se tenir au courants, les machines actuelles permettent des traitements quasiment en temps réel qui duraient des heures en 1975.

Je veut dire en 2009, proposer une fenêtre avec une liste des fichiers à traiter, des liste d'options à cocher, une fenêtre avant/après, avec les outils logiciels actuels que ce soit en C#, en Cocoa sous mac, voire même en GTK c'est l'affaire de quelques heures.

Franchement, dites un truc du genre: "Désolé, pas le temps de faire une jolie interface, en plus c'est pas fun à réaliser"
Mais le coup de: "la ligne de commande c'est le top" RHAAAAAAAAA

olivier_aubel · Octobre 08, 2009, 00:49:28

Citation de: chewan le Octobre 07, 2009, 23:59:40
....
Donc je me pose la question suivante: Quel est le public visé ?

Boâ ! quand on a bossé quelques années avec unix en ligne de commande et des trucs comme l'editeur vi, ça fait même pô peur

GLaG · Octobre 08, 2009, 09:18:35

Citation de: chewan le Octobre 07, 2009, 23:59:40
Soit plus de 60 options... Quand on arrive à plus de 60 options on devrait se remettre sérieusement en question.

J'utilise au quotidien ImageMagick (toutes les images de mon site sont passées par lui) -et je suis loin d'être le seul, et je ne suis pas informaticien. Je pense (pas compté..) qu'il propose largement plus de 60 options !

Tu as parfaitement le droit de préférer les outils graphiques (qui je le reconnais volontiers sont plus pratiques pour beaucoup de choses, et que j'utilise largement aussi) mais désolé, il y a un public pour d'autres manières de travailler.

Quand on veut ajuster une image option par option, c'est évident que c'est mieux de voir le résultat immédiatement. Mais pour plein d'usages, en particulier tous les scripts, traitement automatiques, comparaison de l'effet d'une option avec plusieurs valeurs différentes, ... , on peut (je n'ai pas dit on doit) largement préférer ce genre d'outils aux systèmes de scripts de Photoshop ou Gimp...

CitationLes photographes devraient utiliser des outils comme LR, Aperture, etc

Les photographes sont comme les autres : ils devraient utiliser les outils qui leur sont adaptés, même si ce n'est pas le choix de la majorité.
Beaucoup auront de bonnes raisons de préférer Lightroom, c'est certain. Mais quel est l'intérêt de critiquer ceux qui font d'autres choix ??
Je vois au moins 3 raisons ici d'utiliser ce logiciel :
- comprendre et pouvoir améliorer le code (disponible),
- les résultats annoncés comme meilleurs (je ne me prononce pas, je n'ai pas testé),
- l'intégrer dans un environnement de travail (scripts, etc...) où Lightroom ne s'insèrerait pas bien...

Par ailleurs rien n'empêche de mettre une surcouche graphique à un logiciel en ligne de commande : ce n'est juste pas ce qui motive l'auteur du post..

Nikojorj · Octobre 08, 2009, 11:27:58

Citation de: chewan le Octobre 07, 2009, 23:59:40
Proposer un logiciel en ligne de commande avec plus de 60 options, ce qui doit être pas loin voire même supérieure au nombre de paramètre de développement de LR qui lui dispose d'un feedback visuel...

Pour ça, yaka attendre PerfectRaw.
Même si je pense bien conserver LR pour ses capacités inégalées du point de vue flux et ergonomie et malgré quelques défauts, je me dis qu'un soft avec entre autres

Guillermo Luijk dans l'equipe de dev ne peut pas être foncièrement mauvais.
D'ailleurs, y'a des niouzes de la version de ZeroNoise qui pourrait sortir du DNG?

D'ici là, on ne peut qu'encourager le développement de l'outil derrière - et oui, moi aussi je vois plus l'outil à ligne de commande comme un prototype que comme qq chose d'utilisable.

jdc · Octobre 08, 2009, 12:27:26

Effectivement derrière il y a Perfectraw avec des hommes de talent (je ne me classe pas parmi eux...), comme Guillermo Luijk, mais d'autres aussi, comme Emil Martinec (US - allez voir son site!) et Paul Lee (US), Manuel LLorens et Luis Sanz (Esp), Egon (Esp) qui assure le développement graphique, etc.

Pour les photos "normales" (plus de 95%) je me sers de Nikon Capture NX2 qui me va très bien, mais lorsque je veux faire "plus que bien" j'utilise ma version de Dcraw....

Certes ce n'est pas très convivial (c'est un euphémisme!), mais ce qui compte pour moi, c'est le résultat. Je suis d'accord sur le point de vue de Nikojorj comme quoi Dcraw (modifié) est un prototype de fonctions à tester, pour mettre au point Perfectraw...

A propos...j'ai ajouté une commande de plus...

Patounet9 · Octobre 08, 2009, 13:16:31

Citation de: chewan le Octobre 07, 2009, 23:59:40
Donc je me pose la question suivante: Quel est le public visé ?

Ce sont les amateurs passionnés qui aiment sortir des sentiers battus et s'amuser intelligemment avec les technologies modernes...!

Moi, dans le temps, j'adorais modifier une souce de bios ou un utilitaire Msdos en asm86 (ex: le Print de Msdos adapté à la 1ère Jet d'encres au monde, la Diablo...!)...Par contre, le langage C ...je n'ai jamais accroché...!

Dommage, Jdc, que le code du Foveon soit fermé...Du coup, on a droit au "langage unique" concernant sa colorimétrie...très pointue...!

chewan · Octobre 08, 2009, 20:03:23

Bon cela à l'air sympa comme logiciel perfectRaw, par contre mon niveau d'espagnol étant plus que limité, je ne comprend pas vraiment ou est localisé le projet, les sources, etc

Un lien serait plus qu'apprécié!

Nikojorj · Octobre 08, 2009, 21:15:36

http://luminous-landscape.com/forum/index.php?showtopic=28791 par exemple en anglais?
http://www.ojodigital.com/foro/perfectraw-perfectblend/ c'est de l'espagnol mais même en y comprenant rien on trouve les liens qui vont bien pour télécharger la bête.

jdc · Octobre 09, 2009, 08:44:46

Merci Nikojorj pur ces deux liens.

Quelques commentaires :
Initialement la version de Perfectraw (jusqu'à la 0.65) était une interface graphique qui devait s'appliquer à dcraw (modifié) sous forme d'une DLL écrite en C ANSI. Il est apparu que nombre de traitements en cours nécessitent des puissances de calcul importantes et des occupations mémoire très importante , je prends pour exemples :
* interpolation AMaZE en cours de développement par Emil Martinec et Paul Lee
* interpolation JDDFD de Luis Sanz
* median notamment pour réduire de bruit de chrominance
* gamma (je me sers d'une LUT sur 18 bits)
* etc.

Deux pistes se sont avérées prometteuses (en dehors de l'optimisation des processeurs déjà présente dans ma version de dcraw) :
* se servir de la carte graphique et écrire le programme en OpenGL, c'est ce qui est à la charge principale de Egon (Esp) avec la volonté de sortir une application fonctionnant sous la quasi totalité des plateformes (Windows 32 et 64, Mac, Linux,...). La version actuelle 0.70 en est le prototype.
* travailler sur la parallélisation des processus, en particulier l'interpolation. (Je dois avouer avoir essayé, mais les gains obtenus par moi même sont faibles voir nuls.., mais mon code est prêt pour mettre en place cette programmation). C'est notamment le travail de Paul Lee

De plus quitte à franchir le pas..il est nécessaire de rendre l'application plus "attrayante" d'où l'écriture en autre chose que ANSI C...et ceci éloigne de plus en plus de la version de base de Dave Coffin (ma version de dcraw est compatible C++).

Toutes ces modifications ont amené du retard, mais permettent en parallèle de tester, les processus de base (interpolation, bruit, gamma, etc.)

jdc · Octobre 09, 2009, 12:45:29

Je joins 2 crops à 100% de D3X à 6400 ISO.

Il y a d'autres 'crops', exemples sur le tutoriel de mon site.

jdc · Octobre 09, 2009, 16:16:53

et deux autres, toujours D3x à 6400 ISO

polohc · Octobre 10, 2009, 23:00:34

Salut jdc

Non, je ne retomberais pas dans le défi que je m'étais lancé il y a qq mois : utiliser DCRaw V.jdc !

Ce fut très formateur et "jouissif"

mais "bouffeur" de temps

Maintenant j'utilise couramment LR (ou DxO) et... DCRaw original pour les X3F>DNG de mon DP1 avec l'option -D pour trouver le niveau de saturation du Foveon car il est extrêmement variable selon la dynamique de la photo (de près de 4000 à + de 12000 dans HistoGrammar), puis je fais un fichier TIFF avec DCRaw et l'option -S et la valeur adaptée et enfin un traitement qui se trouve très réduit dans LR
Là, je rejoins Patounet9 sur la colorimétrie du Foveon que je trouve problématique mais uniquement dans les R lumineux

Mais je me suis un peu pris au jeu, j'ai téléchargé le fichier D3X à 6400ISO et l'ai soumis à un traitement LR :
Le bruit L est globalement moins visible que sur tes fichiers mais il parait moins régulier, par contre il semble que le bruit C n'ai pas complètement disparu avec LR
Une zone (ci-dessous) reste délicate à rendre, qu'en est-il avec DCRaw V.jdc ?

cptcv · Octobre 11, 2009, 12:50:27

Citation de: jdc le Octobre 09, 2009, 08:44:46
De plus quitte à franchir le pas..il est nécessaire de rendre l'application plus "attrayante" d'où l'écriture en autre chose que ANSI C[...]

tsss tsss. Y a plein d'applications attrayantes écrites en C ANSI...

Sinon j'ai voulu voir ce que donnait perfectraw 0.7alpha sous Linux => plantage lors du chargement d'un NEF ...

Patounet9 · Octobre 12, 2009, 15:11:57

Du nouveau dans la 0.7...l'affichage du gui semble parfait (box au bon endroit etc...)...
Par contre il ne supporte toujours pas les X3f (Foveon)...il les ouvre mais affiche du "garbage"...
Les Orf (Olympus) s'affichent bien, mais...le soft semble "ramer", pédaler sur le DD, temps de réponse horribles...Mauvaise utilisation de la ram..? (8 gg chez moi!)...Bouton save inactif...? Sous Vista 64 pro...A suivre...
Comme il était à prévoir...: la version gui va apporter plus de retours, Jdc...la version "ligne de commandes" est, amha, appelée à disparaître...!?

jdc · Octobre 24, 2009, 07:16:21

[at] polohc

J'ai été absent pendant une quinzaine de jours...

Je poste une image sensiblement de la même zone. Pour faire des vraies comparaisons, il faudrait travailler sur les TIF et s'assurer que l'exposition, contraste, etc. sont identiques. Pour cela je me sers de la Colorchecker 24 qui est sur le cliché...

Débruiter une image n'est pas un exercice simple. Cela passe d'abord (une fois la prise de vue faite bien sûr) par le choix de l'interpolation. Je suis assez surpris que ce sujet ne fasse pas partie des thèmes souvent abordés, car c'est "LE" point du traitement raw qui est le plus fondamental. C'est l'interpolation qui apporte les détails, joue sur le microcontraste, élimine les artefacts divers (moiré, aliasing, fausses couleurs...), et respecte les couleurs et apporte plus ou moins de bruit à celui déjà présent sur l'image....

Certains produits, pour limiter le bruit "ajouté" diminuent le contraste (cela nécessite souvent d'accentuer ou de mettre un filtre passe-haut, pour palier ce manque qui accentuent les défauts...) ou baissent la saturation....

L'interpolation est donc le point fondamental, qui minimisera le bruit ajouté, donnera des images contrastées, saturées, nettes...et sans artefacts.

Le bruit de luminance se caractérise par des taches blanches brillantes et noires, selon les algorithmes utilisés, le traitement préservera ou non la texture (voir par exemple les détails du "tissus blanc" sous le bol..) et diminuera ou non les contrastes. Certains produits utilisent des filtres Gaussiens (ou un median) qui rendent un aspect video, en lissant...

Le bruit de chrominance se caractérise par des taches colorées disgracieuses, il est plus complexe à retirer que le précédent, et plus couteux en temps...Un traitement incomplet se traduira, par des pixels ou zones de pixels colorés, voire un affaiblissement de la saturation, voire un virage de certaines teintes, et voire aussi des artefacts.

Mais les processus interagissent l'un sur l'autre, car lorsqu'on agit sur la luminance, il faut être sûr que l'algorithme n'intervient pas indirectement sur la chrominance (et réciproquement). Pour cela il faut s'assurer que les calculs de luminance et chrominance sont "propres", en théorie le calcul de la luminance devrait être "pur" et n'avoir aucune composante de couleur, ce qui en RGB est un vrai défi.

Ensuite il y a des choix : garder plus ou moins de texture (détails), lisser plus ou moins (pour ma part je ne lisse pas), laisser ou non un peu de bruit de chrominance, accentuer ou non, accroitre ou réduire la luminosité, le contraste et la saturation,...

polohc · Octobre 24, 2009, 17:16:38

Citation de: jdc le Octobre 24, 2009, 07:16:21
[at] polohc

J'ai été absent pendant une quinzaine de jours...

Je poste une image sensiblement de la même zone. Pour faire des vraies comparaisons, il faudrait travailler sur les TIF et s'assurer que l'exposition, contraste, etc. sont identiques. Pour cela je me sers de la Colorchecker 24 qui est sur le cliché...

Débruiter une image n'est pas un exercice simple. Cela passe d'abord (une fois la prise de vue faite bien sûr) par le choix de l'interpolation. Je suis assez surpris que ce sujet ne fasse pas partie des thèmes souvent abordés, car c'est "LE" point du traitement raw qui est le plus fondamental. C'est l'interpolation qui apporte les détails, joue sur le microcontraste, élimine les artefacts divers (moiré, aliasing, fausses couleurs...), et respecte les couleurs et apporte plus ou moins de bruit à celui déjà présent sur l'image....

Certains produits, pour limiter le bruit "ajouté" diminuent le contraste (cela nécessite souvent d'accentuer ou de mettre un filtre passe-haut, pour palier ce manque qui accentuent les défauts...) ou baissent la saturation....

L'interpolation est donc le point fondamental, qui minimisera le bruit ajouté, donnera des images contrastées, saturées, nettes...et sans artefacts.

Le bruit de luminance se caractérise par des taches blanches brillantes et noires, selon les algorithmes utilisés, le traitement préservera ou non la texture (voir par exemple les détails du "tissus blanc" sous le bol..) et diminuera ou non les contrastes. Certains produits utilisent des filtres Gaussiens (ou un median) qui rendent un aspect video, en lissant...

Le bruit de chrominance se caractérise par des taches colorées disgracieuses, il est plus complexe à retirer que le précédent, et plus couteux en temps...Un traitement incomplet se traduira, par des pixels ou zones de pixels colorés, voire un affaiblissement de la saturation, voire un virage de certaines teintes, et voire aussi des artefacts.

Mais les processus interagissent l'un sur l'autre, car lorsqu'on agit sur la luminance, il faut être sûr que l'algorithme n'intervient pas indirectement sur la chrominance (et réciproquement). Pour cela il faut s'assurer que les calculs de luminance et chrominance sont "propres", en théorie le calcul de la luminance devrait être "pur" et n'avoir aucune composante de couleur, ce qui en RGB est un vrai défi.

Ensuite il y a des choix : garder plus ou moins de texture (détails), lisser plus ou moins (pour ma part je ne lisse pas), laisser ou non un peu de bruit de chrominance, accentuer ou non, accroitre ou réduire la luminosité, le contraste et la saturation,...

Les fins détails apparaissent mieux préservés, le bruit chroma a pratiquement disparu, ta version DCRaw a encore bien progressé mais nécessite une bonne période d'adaptation et une certaine dose de persévérance...

Actuellement je travaille des X3F de DP1 et je suis dubitatif devant le traitement destructeur fait par le débruitage de SPP et de LR,
un essai sur un X3F de SD14 avec DCRaw et les options -v -D -6 retraité avec TSL donne un excellent compromis fins détails/bruit. Le capteur Foveon a un rendu exceptionnel de ce point de vue

Mais DCRaw ne traite pas les X3F du DP1

Seul Silkypix V. beta Foveon s'approche de ce résultat.