Reprise du message précédent :
Pour les "experts" de la numérisation du signal
http://www.photo-lovers.org/fsensor.html.fr

Woua l'usine à gaz si trois valeurs d'amplifications... c'est sûr c'est de la science fiction... ce n'est pas faisable !

non mais le RAW ca a plein de defauts : dejas a cause de son poid (rafale anémique, temps d'enregistrement, carte mémoire qui se remplis plus vite) et du PP qu'il faut lui appliquer, j'ai du mal à en tiré quelque chose. Et format proprio en plus. Bref, j'y suis allergique.

ton jpeg spécial aurait exactement les mêmes défauts, puisque le format jpeg actuel ne permet pas de faire ce que tu décris.

a bon, du jpg sans bdb ni renforcement du contraste/neteté, ni corrections des différentes abbération, pas possible ? Pourtant ce ne sont que des retouches appliquer sur l'image par l'APN.
Même si ça sera jamais équivalent à un RAW, on peut toujours s'en approcher le plus possible.

 
le passage raw --> jpeg s'accompagne d'une perte d'informations (c'est aussi pour ca que les raw sont si lourd). Ces informations perdes, tu ne pourra pas les récupérer après coup....les infos permettant de faire la bdb en font partie.    
 

Petite amélioration pour les bridges (ou p'être plus généralement pour les objectifs à la mise au point électronique) :  
 
Quand on fait la mise au point avant... que celle-ci reste sur la même distance lorsqu'on utilise le zoom.
 
 
 
Note : je ne répondrais pas au cd5 et autre carbone si c'est pour encore les entendre sortir que ce n'est pas possible simplement parce qu'ils ont encore lu de travers  

Bha écoute, si t'es pas là pour échanger, je ne peux que t'aider à te passer de nous pendant 15 jours

oui je sais!
mais on peut mettre ces info dans les métadonnées du jpg, c'est ce que je disait. Ces infos serait ensuite lisible par le prog de retouche de photo fourni par le constructeur de notre APN et ca nous permettrait de traiter le jpeg un peut comme un raw au lieu que ce soit l'appareil qui le fasse de façon desctructrice. L'idéal aurait été d'avoir un format jpg 16bits par couches mais je sais pas si ça existe
 
PS: Si j'était assez riche je racheterait une grande marque d'APN et je concevrait des APN parfait pour le grand public  
Je renouvellerait mes appareils tout les 1 ou 2 ans pour leur faire bénéficié des progrès hardware et software mais il n'y aurait aucun bridage commercial à la con l'ors de la mise sur le marché de mes appareils. Ils seront conçus et mises a jours par des passionnés. Je les concevrait avec intelligence et seront donc ergonomiques et performants. Y'a pas mal de chose qu'on peut faire pour améliorer ceux qu'ils nous vendent sans en augmenter significativement leur prix mais j'ai l'impression que les constructeurs se fiches bien de nous
Si un milliardaire philanthrope me lis et ne sais pas quoi faire de son argent => MP

je ne suis pas une lumière en orthographe, mais il y a des limites tout de même.
Je préfèrerais que le milliardaire philanthrope investisse dans l'éducation afin que chacun puisse exposer clairement ses idées.
 
si les infos sont dans les métadonnées, cela n'en diminue pas le poids tout en compliquant leur recherche.
depuis très longtemps, la recherche du format idéal est en cours. Suivant le type d'image, sa complexité et le résultat souhaité, il existe une grande palette de format pour stocker les données.
en règle général, les ingénieurs sont intelligents, pour une majorité passionnés par ce qu'ils font.
l'ergonomie est une notion subjective tout comme la performance.
les constructeurs essayent de proposer au public des appareils qui leurs conviennent tout en faisant des compromis pour qu'ils puissent les vendre. Leur but final étant de faire de l'argent, ce qui n'est possible que si le produit est correct et vendu efficacement.
la concurrence oblige les constructeurs a utiliser les progrès et la recherche pour pouvoir séduire la clientèle par des produits innovants.

aïe aïe aïe aïe aïe si tu veux un JPEG 16 bits, tu fais x2 sur la taille de fichier par rapport au 8 bits, et tu dépasses la taille d'un RAW normal. super l'avancée. même si j'étais milliardaire, j'investirais pas là-dedans.

c'est quoi que t'aimes pas dans le raw?

les infos permettant au logiciel de retouche d'identifier quelle bdb a été utiliser par l'appareil, et le reste, ca doit pas prendre bcp de place quand même.
Et ce jpg sera plus léger qu'un raw car la compression serait destructrice de toute manière.
 

pas mal de limitations commerciales quand même (comme sur les canon J1/V1 la molette qui n'inclu pas les modes PASM alors qu'il y aurait eu la place de les mettre). On pourrait faire mieux. L'ergonomie est penser par des marketeux ou des ingénieurs (je sais pas trop comment ca se passe) qui ne semble pas se rendrent comptent que pour une personne lambda ca pourrait être mieux. Ex d'amélioration: DNG au lieu du RAW. Absence des différentes accentuations desctructrices en compression jpg si on le désire. Moins de pixel (a mon avis il est innutile de dépasser 6MP sur un compact). Et plein d'autre fonctionnalités. Le grand public je l'éduquerait en lui fesant comprendre que certaines choses plus commerciales sont néanmoins néfaste à la qualité du produit au travers des publicités par ex. Avec moi il comprendra qu'il se fait entubé chez les autres constructeur  
 

on peut faire autrement et je pense bien que ca se vendra pas de soucis car le produit sera de meilleurs qualité fonctionnel sans être plus chère et ma boite aura une meilleurs image de marque aupres du public car on ne se fichera pas d'eux et que le patron ne s'enrichira pas.  
 
A chaque fois que j'utilise un APN je lui trouve 10K défauts. Je suis persuadé que mon entreprise fonctionnerait. Moi j'y crois  
 

non mais cest pas uniquement pour ça j'ai plein d'autre idées. Et puis non je ne crois pas que ça fera plus lourd qu'un RAW moi mon apn me sort des jpg de 2Mo et les RAW (enfin DNG) font 18Mo.
 
Et puis y'a le format jpeg XR qui pour une qualité équivalente au jpeg créer un fichier au moins 2x plus léger. Il prend aussi en charge la compression sans pertes (merci prout2000 pour m'avoir fait connaitre ce format).
 

je n'est jamais le même resultat selon le derawtisseur qui ouvre mes RAW (en laissant les réglages par défauts).  
Et aussi, avec le raw je n'arrive jamais a retrouver les même different traitement qui on été appliquer au jpg par l'APN. Pas même bruit ni même piqué que le jpg de l'APN même si j'ouvre le RAW avec le log du constructeur de mon apn et que j'applique des modifications je n'y arrive pas. Soit c'est + piqué mais y'a trop de bruit soit c'est l'inverse, etc. Du coup, je prefere la qualité globale du jpg, un comble car je sais que le jpg est moins bon. (experience faite avec les RAW panasonic)
 
Le DNG, a par le fait qu'il ne soit pas un format proprio, je lui trouve les même défauts (experiences faites avec les DNG crées par le CHDK de mon canon).

cas : fait une photo infra rouge en jpeg et la même en raw.
pour ce style de photo, il faut obligatoirement retraiter pour avoir un résultat agréable à l'oeil.
Si tu le faits avec un jpeg, le résultat sera bruité et mou alors qu'avec un raw, le résultat est nettement meilleur car le traitement utilise les infos de sur-échantillonnage contenues dans le raw. L'information de température et de teinte ne suffit pas à améliorer un jpeg.

Ca ne fonctionne pas comme ça.
Le jpeg ne garde que ce qui est visible par l'oeil humain. c'est le principe de l'algorithme.
Il va détruire les nuances invisible pour la BDB appliquée. Du coup on ne peut plus appliquer proprement une BDB qui les ferait apparaitre.
 

Salut, salut.
 
J'écris par rapport à un sujet entamé dans le topic News&Spéculation à propos d'une nouvelle fonctionnalité proposé par Adobe. Le défloutage (c'est pas très jolie en français) à partir d'une image unique ou "blind deblurring". Les résultats montrés dans la publi de GBo sont assez impressionnant. Ils partent de quelques chose de vraiment très flou pour obtenir un résultat bien net avec de petits artefacts. Mais du coup plusieurs questions me viennent. Le flou a t'il besoin d'être vraiment important pour que le calcul du kernel soit réalisable ? Qu'est ce que ça donnerait sur une image pas très piqué à cause d'un léger flou ?
Et autre question, sur une image où la PDC n'est pas infinie, ce qui n'est pas très rare en photo, qu'est ce que cela donne ? L'algo va nous bouffer notre bokeh   .  
 
Quelqu'un à t'il déjà codé quelque chose dans le genre ?

Y'a des applis déjà dispo, les algos ne sont pas forcément identiques ( ) mais s'en approchent, comme pour Unshake en java (utilisable sur toute plateforme): http://www.zen147963.zen.co.uk/Unshake/Download.html

Ah merci, intéressant. J'ai aussi trouvé l'exécutable pour la publi Hong-Kongaise. Il faut que je teste tout ça pour me répondre à mes questions tout seul.  

Ah cool, merci, j'avais pas vu qu'il y avait un programme dispo :

Single-image Deblurring (Motion PSF Estimation)
http://www.cse.cuhk.edu.hk/~leojia [...] urring.htm
Cela correspond au papier suivant (téléchargement lent):
http://www.cse.cuhk.edu.hk/~leojia [...] raph08.pdf
Page d'entrée : http://www.cse.cuhk.edu.hk/~leojia [...] index.html (il y a aussi un jeu de transparents ppt)

Pour essayer le programme j'ai pris une image floue (flou de bougé) de wikipedia (cf. les cartouches) :
http://en.wikipedia.org/wiki/Motion_blur
Après crop et sauvegarde en exampleBlurImage.png, je lui ai appliqué la moulinette de Hong Kong (ce n'est pas ce que vous croyez messieurs ) en tapant ceci dans un fichier.bat :

37x21 c'est la taille en pixels du "kernel", c'est à dire de l'imagette qui va contenir l'estimation du mouvement de l'appareil. Je n'ai pas trouvé mieux comme taille, et ça se gourre parfois complètement avec certaines tailles.

Et voilà le travail :

Bon. C'est vrai que les artefacts sont moindres que sur l'algo montré en exemple sur wikipedia :
http://upload.wikimedia.org/wikipe [...] ing%29.png
Je ne sais pas pourquoi ça me sort en noir et blanc par contre ?

On constate aussi que le flou de bougé de l'image des cartouches est sûrement artificiel puisque le kernel trouvé (qui marche) montre une belle ligne droite d'un niveau de gris constant, donc un mouvement rectiligne et uniforme comme on dit (cf. l'imagette avec le trait blanc sur noir).
Faudra essayer avec du vrai flou de bougé plus compliqué.

cdlt,
GBo

Re-
Tu pourrais aussi essayer Topaz InFocus, il y a un "free trial" dispo :
http://www.topazlabs.com/infocus/
http://www.topazlabs.com/blog/topa [...] echnology/
C'est le même genre de technique a priori (par déconvolution) et ça s'applique aussi au léger flou de mise au point d'après les exemples montrés, alors que le travail de l'université de HK + Adobe a l'air plus spécialisé sur le (gros) flou de bougé.

Edit : à voir aussi Focus Magic ? :
http://www.focusmagic.com/
 Example 1 - Slightly Blurred Image

Source: http://www.focusmagic.com/examplefocusing.htm

cdlt,
GBo

NB : je ne connais pas ces soft, je ne sais pas si ça marche bien

Pas encore pris le temps de tester.
 
En tout cas sur l'essai que tu as fait, c'est déjà plutôt performant et c'est très intéressant quele programme fournisse également le noyau.
J'ai bien envie de mieux comprendre la publi précédente. Ils ont l'air de masquer les zones constantes lors de l'évaluation du noyau mais j'ai peur que ce masque créé de façon automatique puisse être pris à défaut.
 
Après je ne sait pas si ca  correspond vraiment à l'algo présenté par Adobe. Ils auraient plutôt tendance à breveter les algos qu'il utilisent dans les applis commercials plutôt que de les publier sans protection, non ?

Si tu parles de l'image en noir et blanc appelée Ω, c'est juste pour supprimer les artefacts d'après la publication : "We compute Ω containing all pixels shown in white to suppress ringing". Tous les exemples montrent un flou de bougé d'appareil, lequel affecte toute l'image; si tu pensais à un un flou de bougé partiel, par exemple celui d'une personne qui marche devant un appareil sur pied en temps de pose un peu trop lente, c'est encore plus compliqué que ce à quoi ils s'attaquent.

Re-
J'ai essayé sur des images réelles pour vérifier que la moulinette deblur.exe de l'université de HK ne marche pas QUE sur des flous de bougé synthétiques, ou à partir d'images de test montrées par Adobe, pour lesquelles ça marche très bien* - ou trop bien, car après avoir triché sur au moins une image lors de leur démo publique**, on peut commencer à se poser des questions sur les autres...

Après plusieurs essais infructeux (deblur.exe trouvait des kernels complètement erronés, et je n'ai pas bien compris pourquoi) voici donc mon premier essai réussi de défloutage sur une image réelle (faite ce matin, dès l'aube, à l'heure où blanchit la campagne, je tremblerai) :

- En haut, un crop de ma photo, resizée à 800x400 px pour limiter les temps de calculs, c'est la pire image d'une série volontairement prise à vitesse trop lente (1/30e à main levée) pour la focale de 150mm utilisée sans stabilisation sur un reflex APS-C.
- Au milieu, une vue à 400% du kernel de 33x33 px trouvé en lançant deblur IMG_1608c.png  IMG_1608cOUT.png  33 33
Le kernel est la forme exacte du flou de bougé trouvé par l'algo, et le niveau de gris représente le temps (plus c'est clair, plus l'appareil est resté longtemps à cette position et vice-versa).
- En bas, le résultat de la moulinette robust_deconv.exe IMG_1608c.png IMG_1608c_kernel.png IMG_1608cOut.png 1 0.01 100
Page d'explication sur robust_deconv.exe : http://www.cse.cuhk.edu.hk/~leojia [...] lution.htm
Note : les 3 fichiers (respectivement l'entrée IMG_1608c.png, les sorties IMG_1608c_kernel.png et IMG_1608cOut.png) sont dispos sous forme de PNG là : http://gbotet.perso.sfr.fr/deblur/

Conclusion provisoire, ça défloute pas mal, mais pas sur toutes les photos, et quand ça marche il reste des artefacts très moches. Notez bien que ce n'est pas du soft d'Adobe dont je parle, mais de celui de l'Université de HK (auquel un chercheur d'Adobe a participé), et je ne sais pas si Adobe fera mieux s'ils sortent un jour un plug-in pour photoshop.

cdlt,
GBo

(*) http://forum.hardware.fr/hfr/Photo [...] m#t4410020
(**) http://forum.hardware.fr/hfr/Photo [...] m#t4413066

J'ai essayé aussi pour un léger flou de bougé :

http://gbotet.perso.sfr.fr/deblur/IMG_1607ccFlat.jpg

En bas, résultat de la déconvolution avec :
robust_deconv.exe IMG_1607cc.png IMG_1607ccc_kernel.png IMG_1607ccOut.png 1 0.05 1 basé sur le kernel trouvé sur une portion de l'image (pour minimiser les temps de calculs) avec :
deblur IMG_1607ccc.png  IMG_1607cccOUT.png  17 17

=> sur cette image ça marche, mais avec des artefacts (ex. la cime des arbres, barreau de certaines fenêtres...), et ni plus ni moins qu'avec du sharpen à outrance sur photoshop (essayé et comparé avec un unsharp mask de rayon 0.8 pixel et intensité à 320 %, ça revient au même ).

cdlt,
GBo

C'est quand même prometteur
 
ça pourrait être intégré un jour directement dans l'appareil

A toutes fins utiles, toujours sur le site de l'université de HK il y a une moulinette plus récente (2010) : robust_deblur.exe.
Elle converge beaucoup plus rapidement (deblur.exe rame vraiment même sur de petites images dès que la taille de kernel dépasse qques centaines de px) et elle est adaptée aux flous de bougé de grande amplitude (mais toujours un seul kernel par image, c'est à dire que pour de bons résultats, le mouvement de flou doit être identique en tout point de l'image).

Voici le lien de l'executable :
Robust Motion Deblurring
http://www.cse.cuhk.edu.hk/~leojia [...] urring.htm
Cela correspond au papier technique linké dans cette page d'entrée :
http://www.cse.cuhk.edu.hk/~leojia [...] st_deblur/

Sur mon exemple plus haut, ça a convergé en effet très vite, et le résultat présente moins d'artefacts :

cdlt,
GBo

Adobe publie de nouvelles images defloutées par leur plug-in expérimental :
http://prodesigntools.com/photosho [...] hotos.html
Il faut passer la souris sur une image pour voir le résultat.
Voir aussi : http://juew.org/deblurFamousPhoto.html
Après le floutage de gueule de leur show, il insistent cette fois sur le caractère authentique du flou de ces images
cdlt,
GBo

ca donne des ciels texturés assez bizarre

C'est vachement intéressant tout ça, j'adore. Dans mon université, il y a des choses intéressantes faites en traitement d'image, mais pas aussi poussées, en tout cas pas aussi adapté à la photo.

ok  
mais je pense qu'il vaut quand même mieux pas de bdb qu'une trop mauvaise faite par l'appareil et qui va enlever des couleurs.
 
et sinon du jpg brut de capteur permettra aussi d'augmenter la cadence de la rafale. Au choix ensuite d'appliquer ou non les corrections en PP avec le logiciel du constructeur.  
 
Psk ce qui limite notement la vitesse des rafales infini c'est le traitement entre chaque photo je pense. Sauf pour les rafales au nbr de clichés limités (genre 10fps sur 1s) ou là le traitement doit se faire apres que toute les photos aient été prisent.
Parce que mes rafales (infini) sont plus lente quand j'augmente les ISO surement parce que le réducteur de bruit a + de boulot, c'est dommage, surtout que tout les traitement appliquer aux photos ne me conviennent pas donc c'est un ralentissement innutile
 
 
 
Sinon, j'ai testé quelque programme déflouteur.
Focus Magic 3.02a
Astra Image Pro 3.0.5.51
Tria Image Processing V2.7.01
 
il ny'a que le premier qui fonctionne chez moi, les autres sembles être bugés et de ce fait sont inutilisables chez moi
 
Donc celui qui fonctionne bah il ne fait pas tout automatiquement (notement sens du flou qu'il faut lui indiqué ) et en plus la taille de la zone ou s'effectue le traitement provisoir est trop petite c'est assez relou on vois pas assez d'image.
Et le résultat est assez mauvait sur ma photo (flou de bouger), je pense qu'il n'est pas assez performant.
 
Vous en connaissez d'autre (simple et éfficase si possible) ?  
 
Il n'y a pas un topic unique pour parler de ce genre de programme ? C'est interessant ces déflouteur si ça peut nous permettre de prendre des photos avec une sensibilité moindre sans craindre le floue, ça pourrait être super utile surtout avec un compact

Et ceux mis à dispo par l'université de HK ? pas assez cher mon fils ?    

Pour moi ces algos valent le coup pour tenter de récupérer tant bien que mal (i.e. en acceptant les artefacts si ça marche), des images de contenu précieux et non reproductible : légal/policier, historique, sentimental  - une vieille photo d'enfance avec l'étiquette "ratée/non facturée" de la FNAC   ... De là à faire exprès de faire flou à la PDV parce qu'on a la flemme de sortir le pied en espérant des miracles ensuite, ça n'arrivera pas AMHA : il y a trop d'inconnues mathématiques dans les algos de type "blind" (= pas de connaissance à priori du flou, ni du bruit) comme ceux de HK et d'Adobe (du coup ça ne converge pas toujours sur le bon flou, voire pas souvent), et trop de restrictions pour obtenir un résultat à peine acceptable (ex: déjà il faut un flou de bougé absolument identique pour tous les pixels de l'image, ce qui n'est pas vrai dans tous les cas).
 
--
 
Ceci dit Microsoft par exemple planche sur la réduction du nombre d'inconnues en équipant des appareils de capteurs inertiels, pour être moins "blind" ensuite lors du traitement:
Image Deblurring using Inertial Measurement Sensors
http://research.microsoft.com/en-u [...] eblurring/

 
--
 
Une autre piste est d'insérer dans l'appareil une exposition "codée" dans le temps !  
Coded Exposure Photography: Motion Deblurring using Fluttered Shutter
http://web.media.mit.edu/~raskar/deblur/

 
Edit : cette méthode cible davantage le flou de bougé d'un sujet que le flou de bougé du à l'appareil
 
cdlt,
GBo

pas des miracles mais si c'est mieux que d'avoir trop de bruit c'est toujours ça. Mais meme pour un leger floue, le défloutage n'est pas assurer ? Ca depend du sens du floue ?
Il faudrait qu'a chaque prise de vue à haut ISO que les apn fassent un double a ISO inferieur de nos photos comme ça dans 10 ans on pourra les déflouter efficasement  
Il faudrait aussi que ces doubles soit incorporés dans le même jpg comme ça on se fera pas iéch avec des doubles jpg à gerer.
 

Robust Motion Deblurring ?
je comprend pas comment il fonctionne. Une fenetre DOS s'ouvre un cour instant et se referme
 
S'il se controle en ligne de commande, non merci

Dans le répertoire qui contient robust_deblur.exe et la photo image.png à déflouter, créer un fichier texte run.bat qui contient :
robust_deblur image.png imageOut.png 33 33 2.2

=> 33x33 pixels c'est la taille du kernel de flou (celle que j'ai utilisé pour l'exemple ci-dessus). La taille du flou est facilement observable sous toshop, mesurer combien de pixels pour un carré qui contient entièrement le flou + une bonne marge.
=> 2.2 c'est le gamma (toujours mettre 2.2).
Puis double cliquer sur run.bat avec le mulot. Le résultat apparait au bout d'un certain temps dans imageOut.png (et pour les curieux, le kernel trouvé est dans image_kernel.png).

C'est d'un compliqué !

Ok je fait comme tu a dit !
 
mon floue fait 8pixel donc dans le fichier .bat j'ai mis ça:
robust_deblur image.png imageOut.png 8 8 2.2
 
Bon c'est vraiment pas intuitif. Je vait devoir marquer comment on fait quelque part parce que j'arriverait jamais a me rappeler ! Mais le resultat est nul, ma photo n'a pas été modifier. Mon floue ne doit pas lui convenir parce que ca marche bien avec ta photo IMG_1608c.png et avec 33 33
 
Avec ma photo et 08 08 ca marche pas non plus. Avec 33 33 ca marche mais c'est super moche

Tu peux l'envoyer (via un lien) à Jue W., le chercheur d'Adobe qui teste son soft sur des exemples réels :
http://juew.org/deblurFamousPhoto.html

Moi je l'ai fait avant-hier et voilà que ma photo se retrouve sur son site   :
http://juew.org/deblurFamousPhoto2.html#building

Sinon tu me l'envoies ou tu l'affiches ici et je te dirai peut-être pourquoi ça marche pas ?

le resultat est assez spectaculaire sur ta photo je comprend qu'il l'ai prise
 
sinon voila ma mienne (c'est un crop d'une 12MP que j'ai faite juste pour testé les programme déflouteur)  

Ca marche pas très bien non plus chez moi, pourtant le flou de bougé a l'air homogène (le mouvement de haut en bas - ou de bas en haut ? - de l'appareil a l'air à peu près identique partout).
Le souci est peut-être qu'il s'agit d'un crop à 100% justement (mieux vaut redimensionner l'image complète, en 800 pixels de large par exemple). Et ça m'a l'air un peu bruité (ces algos ont horreur du bruit car c'est une inconnue de plus dans l'équation).
Une autre hypothèse qui met l'algo en difficulté est qu'il y a une majorité de feuillage assez peu contrasté dans ce crop, donc la signature exacte du flou est dure à extraire (ce qui est vrai aussi à l'oeil, tu remarqueras).
Ah, et j'espère qu'il n'y avait que du flou de bougé -cas- n'est-ce-pas ? car s'il y a en plus du flou d'objectif (mauvaise MAP, faible PdC, aberrations aux bords) les chances de bon résultat avec ces algos (spécialisés dans le défloutage de bougé d'appareil) avoisinent 0.

voici la photo d'origine

 
je l'ai recadrer un peut et redim en 800 de large. Le bruit n'était plus visible et j'ai recompter le nbrs de pixel que fesait le floue.  
 
resultat : médiocre.
 
Ma photo est trop difficile pour lui on dirait  
C'est peut être les feuillages qui foutes leurs merde... Ce serait peut être bien de pouvoir lui dire ou mesurer le floue dans l'image...

Faudrait aussi que tu comprennes un peu les contraintes techniques  

Ta photo comporte de nombreux plans différents et doit en plus comprendre un flou d'objectif.

Sans compter que la réduction ne doit absolument pas être fait n'importe comment. La correction gamma n'est pas du tout un paramètre anodin et si la réduction n'en tient pas compte, ça foira inévitablement la déconvolution.

Bon et ca reste un programme à visé recherche. Ils sont déjà bien sympa de le mettre en ligne.

Pour intégrer ca a leur suite commercial, Adobe a probablement du robustifier la chose. Ou alors ils ne l'auraient pas annoncer en grande pompe de cette façon.

Edit: Toujours pas testé sur mes images ... /poil à la main proof. En même temps je m'occupe déjà pas de mes photos non flou

T'as foiré une déconvolution à cause du paramètre de gamma dans robust_deblur.exe ?
Et je ne sais pas ce que tu entends par "pas être fait n'importe comment" pour la "réduction", mais j'ai utilisé la réduction de taille de Photoshop (Image Size => bicubic tout bête bien connu) sur mon exemple qui marche.

Voilà une bonne remarque inédite (celle que j'ai mise en gras).