Re: [darktable-dev] Deconvolution and Python framework

[Aurélien PIERRE]

I understand your point and all I can offer for now are intuitions to be
confirmed by experiments. But… :

 1. the lens distorsion profiles provided by lensfun are user-produced
and my bet is they are not 100 % accurate, which could do more harm
than good,
 2. to some extend, the deconvolution takes care of lens distortion too

*Aurélien PIERRE*
aurelienpierre.com 



Le 2017-10-16 à 06:21, Tobias Ellinghaus a écrit :
> Am Sonntag, 15. Oktober 2017, 14:51:47 CEST schrieb 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.
> But that's exactly what we want. When dealing with motion then the lens 
> distortion has to be removed to have a uniform blur, otherwise the blur would 
> be curved along the lens distortion. Or am I missing something here?
>
>> 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


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

Re: [darktable-dev] Deconvolution and Python framework

[johannes hanika]

On Mon, Oct 16, 2017 at 11:21 PM, Tobias Ellinghaus  wrote:
> Am Sonntag, 15. Oktober 2017, 14:51:47 CEST schrieb 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.
>
> But that's exactly what we want. When dealing with motion then the lens
> distortion has to be removed to have a uniform blur, otherwise the blur would
> be curved along the lens distortion. Or am I missing something here?

but if you rotate the camera around "z" (or whatever axis goes inside
the screen) you'd need a non-uniform blur kernel anyways. and these
methods seem to support spatially varying deconvolution. so i think we
should be good either way.

-j.


>> 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
>
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Deconvolution and Python framework

[Tobias Ellinghaus]

Am Sonntag, 15. Oktober 2017, 14:51:47 CEST schrieb 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.

But that's exactly what we want. When dealing with motion then the lens 
distortion has to be removed to have a uniform blur, otherwise the blur would 
be curved along the lens distortion. Or am I missing something here?

> 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



signature.asc
Description: This is a digitally signed message part.