Re: [darktable-dev] Deconvolution and Python framework

[Aurélien PIERRE]

Hi !

The algorithm I have implemented so far is
http://www.cvg.unibe.ch/dperrone/tvdb/index.html which cites the article
you mention in its references.

However, I don't like the way your article plays because the algorithm
adds a bilateral filter to avoid ringing at the last step which is kind
of a cheat.

Currently, I'm working on a 2015 paper from the same authors which seems
to give state-of-art results :
http://www.cvg.unibe.ch/dperrone/logtv/index.html. It's basically a
refinement over the previous one (using log of Total Variation instead
of Total Variation as a regularization).

*Aurélien PIERRE*
aurelienpierre.com 



Le 2017-10-14 à 13:34, Tim Rolph a écrit :
> Hi All, have any of you guys seen this work? Sounds promising.
>
> http://appsrv.cse.cuhk.edu.hk/~leojia/projects/motion_deblurring/index.html
>
> Tim.
>
> On Wednesday, 11 October 2017 20:59:59 BST Heiko Bauke wrote:
>> Hi,
>>
>> Am 11.10.2017 um 19:11 schrieb Martin Marmsoler:
>>> Gimp use python as scripting language. It might be easier to port for
>>> Gimp?
>> by the way: there is a Richardson Lucy sharpening filter in G'MIC.  (As
>> far as I understand this is a non-blind deconvolution algorithm.)
>>
>>
>>  Heiko
>
> ___
> darktable developer mailing list
> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
>



signature.asc
Description: OpenPGP digital signature

Re: [darktable-dev] Deconvolution and Python framework

[Aurélien PIERRE]

Hi,

this technic aims at solving all kinds of blurs (static and motion
blurs). The most challenging configuration is when the blur is not
uniform along the image. I fear that applying geometric corrections
before deblurring could modify the spatial distribution of the blur in
the corners and lead to some inconsistencies in the solution.

However, I'm working on a masked implementation which would take only a
relevant portion (512×512 px) of the image as an input for performance
purposes, so at the end, the order of applyance of the modules might not
make a difference.

*Aurélien PIERRE*
aurelienpierre.com 



Le 2017-10-14 à 10:54, Tobias Ellinghaus a écrit :
> Am Donnerstag, 12. Oktober 2017, 22:30:51 CEST schrieb Aurélien PIERRE:
>
> [...]
>
>> I believe that it should be applied right after denoising since this is
>> low-level signal processing. Also a Total Variation and a Wiener filter
>> denoising methods should be added to the modules for better results with
>> the deconvolution (Total Variation is litteraly a gradient computation
>> plus 3 lines of code similar to the Unsharp Mask equation ; I'm not
>> familiar with Wiener filters, althouh they come often in the litterature
>> as a RL pre-processor).
> Wouldn't it be better to have it after lens distortion? If it's meant to fix 
> camera shake then having lens distortion in the way seems like a bad idea.
>
>> mit herzlichen Grüße ;-)
> :)
>
>> *Aurélien PIERRE*
>> aurelienpierre.com 
> Tobias


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org