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.

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

Re: [darktable-dev] Deconvolution and Python framework

[Tim Rolph]

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

Re: [darktable-dev] Deconvolution and Python framework

[Tobias Ellinghaus]

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

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

Re: [darktable-dev] Deconvolution and Python framework

[François Tissandier]

Hi

Probably a silly idea, but in case this deconvolution is really really
long, wouldn't it be possible to run it separately, and save the result as
a DNG file ? This way it would be done just once, and no need to
recalculate everything each time you want to edit the photo. But maybe it's
impossible to keep the raw data this way, I don't know much about what is
happening behind the scene ;)

In any case, i'm curious to see the result, it looks promising and like a
potential life saver on some shots.

have a nice day, guys !

François

On Fri, Oct 13, 2017 at 4:30 AM, Aurélien PIERRE  wrote:

> Hi Tobias and Johannes !
>
> @ Tobias :
>
> The standard deconvolution has to be computed on the whole picture since
> the iterations stack represents the approximated numeric solution of the
> equation we try to solve with an implicit method, so there is no way to
> just store a bunch of parameters for a later recomputation because we never
> actually know the exact equation (it's like solving a partial differential
> equation). Hence the iterations. As far as I know… (maybe Heiko Bauke''s
> second opinion on this matter could be of use).
>
> The blind/myopic deconvolution performs an additional refinement of the
> blur kernel (hence the 2 additional convolution products) and this part
> doesn't need to be computed on the whole image. The size of the data could
> be set by the user or limited in the software based on the available
> computation power. This is an additional constrain passed to the solver so
> there is always a trade-off anyway (too much data means an over-constrained
> problem, too few is a lack of information). However, here, if the blur
> kernel ends up accurate enough, it *could* be possible in theory to just
> solve the equation in one iteration thus store the blur kernel and re-apply
> it anytime. I still have to play with the algorithm more to understand it
> fully.
>
> I think what need to be understood here by everyone (I don't know
> everyone's background) is R-L deconvolution is not just a regular filter to
> apply on the data, but an equation to solve in a numeric way with an
> accuracy degree roughly related to the number of iterations. There is no
> explicit transfer function known.
>
> @ Johannes :
>
> the non-blind deconvolution runs on 3 threads (1/channel) in 16 s but
> could be tiled (you just need to pad the tiles accordingly with
> low-frequency content to avoid ringing and weird border effects).
>
> 4) that depends on the order of modules. if you want to do it in the
> current sharpen module as an option, it'll come pretty much last. if
> you do it early, dt will transparently cache the output for you and do
> the other computations in darkroom mode on top. that said, i doubt you
> want to implement this for raw/bayer/xtrans images or run it before
> denoising.
>
> 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).
>
> mit herzlichen Grüße ;-)
>
> *Aurélien PIERRE*
> aurelienpierre.com
> --
>
> Le 2017-10-12 à 03:58, Tobias Ellinghaus a écrit :
>
> Am Donnerstag, 12. Oktober 2017, 00:23:42 CEST schrieb Aurélien PIERRE:
>
> Hi !
>
> I understand the performance concerns and I'm working on some trade off.
> But…
>
> [...]
>
>
> 3 - The most computation-demanding operation is convolution product (2
> FFT-convolve by non blind iteration, 4 by blind iteration). The good
> news is we don't need to compute them on the whole picture (it's
> actually bad when you have a large bokeh area) and you can/should mask
> the area of interest and do the computations only on it. It saves a lot
> of time and gives better results on some cases.
>
> How big is the data this step computes? If it's just a few values required to
> process the whole image with afterwards and not changing once it's been
> computed, then we could easily have a button in the module that does the heavy
> lifting once for the image and stores it in its params. Similar to what "color
> mapping" does.
> Provided the rest of the computations that just use the values computed here
> are fast, we don't have to worry too much how long a one-time operation takes.
>
> [...]
>
>
> Thanks for your interest !
>
> *Aurélien PIERRE*aurelienpierre.com  
> 
>
> Tobias
>
> [...]
>
>
>

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

Re: [darktable-dev] Deconvolution and Python framework

[Aurélien PIERRE]

Hi Tobias and Johannes !

@ Tobias :

The standard deconvolution has to be computed on the whole picture since
the iterations stack represents the approximated numeric solution of the
equation we try to solve with an implicit method, so there is no way to
just store a bunch of parameters for a later recomputation because we
never actually know the exact equation (it's like solving a partial
differential equation). Hence the iterations. As far as I know… (maybe
Heiko Bauke''s second opinion on this matter could be of use).

The blind/myopic deconvolution performs an additional refinement of the
blur kernel (hence the 2 additional convolution products) and this part
doesn't need to be computed on the whole image. The size of the data
could be set by the user or limited in the software based on the
available computation power. This is an additional constrain passed to
the solver so there is always a trade-off anyway (too much data means an
over-constrained problem, too few is a lack of information). However,
here, if the blur kernel ends up accurate enough, it *could* be possible
in theory to just solve the equation in one iteration thus store the
blur kernel and re-apply it anytime. I still have to play with the
algorithm more to understand it fully.

I think what need to be understood here by everyone (I don't know
everyone's background) is R-L deconvolution is not just a regular filter
to apply on the data, but an equation to solve in a numeric way with an
accuracy degree roughly related to the number of iterations. There is no
explicit transfer function known.

@ Johannes :

the non-blind deconvolution runs on 3 threads (1/channel) in 16 s but
could be tiled (you just need to pad the tiles accordingly with
low-frequency content to avoid ringing and weird border effects).

> 4) that depends on the order of modules. if you want to do it in the
> current sharpen module as an option, it'll come pretty much last. if
> you do it early, dt will transparently cache the output for you and do
> the other computations in darkroom mode on top. that said, i doubt you
> want to implement this for raw/bayer/xtrans images or run it before
> denoising.
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).

mit herzlichen Grüße ;-)

*Aurélien PIERRE*
aurelienpierre.com 



Le 2017-10-12 à 03:58, Tobias Ellinghaus a écrit :
> Am Donnerstag, 12. Oktober 2017, 00:23:42 CEST schrieb Aurélien PIERRE:
>> Hi !
>>
>> I understand the performance concerns and I'm working on some trade off.
>> But…
> [...]
>
>> 3 - The most computation-demanding operation is convolution product (2
>> FFT-convolve by non blind iteration, 4 by blind iteration). The good
>> news is we don't need to compute them on the whole picture (it's
>> actually bad when you have a large bokeh area) and you can/should mask
>> the area of interest and do the computations only on it. It saves a lot
>> of time and gives better results on some cases.
> How big is the data this step computes? If it's just a few values required to 
> process the whole image with afterwards and not changing once it's been 
> computed, then we could easily have a button in the module that does the 
> heavy 
> lifting once for the image and stores it in its params. Similar to what 
> "color 
> mapping" does.
> Provided the rest of the computations that just use the values computed here 
> are fast, we don't have to worry too much how long a one-time operation takes.
>
> [...]
>
>> Thanks for your interest !
>>
>> *Aurélien PIERRE*
>> aurelienpierre.com 
> Tobias
>
> [...]



signature.asc
Description: OpenPGP digital signature

Re: [darktable-dev] Deconvolution and Python framework

[Tobias Ellinghaus]

Am Donnerstag, 12. Oktober 2017, 00:23:42 CEST schrieb Aurélien PIERRE:
> Hi !
> 
> I understand the performance concerns and I'm working on some trade off.
> But…

[...]

> 3 - The most computation-demanding operation is convolution product (2
> FFT-convolve by non blind iteration, 4 by blind iteration). The good
> news is we don't need to compute them on the whole picture (it's
> actually bad when you have a large bokeh area) and you can/should mask
> the area of interest and do the computations only on it. It saves a lot
> of time and gives better results on some cases.

How big is the data this step computes? If it's just a few values required to 
process the whole image with afterwards and not changing once it's been 
computed, then we could easily have a button in the module that does the heavy 
lifting once for the image and stores it in its params. Similar to what "color 
mapping" does.
Provided the rest of the computations that just use the values computed here 
are fast, we don't have to worry too much how long a one-time operation takes.

[...]

> Thanks for your interest !
> 
> *Aurélien PIERRE*
> aurelienpierre.com 

Tobias

[...]

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

Re: [darktable-dev] Deconvolution and Python framework

[johannes hanika]

hi,

1) 16s in single-thread python sounds like it would be possible to do
< 100ms in a programming language.

4) that depends on the order of modules. if you want to do it in the
current sharpen module as an option, it'll come pretty much last. if
you do it early, dt will transparently cache the output for you and do
the other computations in darkroom mode on top. that said, i doubt you
want to implement this for raw/bayer/xtrans images or run it before
denoising.

5) indeed this imagej plugin has interesting code, albeit java (but
GPLv3, too). the results look great and it even has a spatially
varying psf version. the test cases on this web page seem to be more
in the 256^2 range of problem size, so the speed issue will need
investigation. i suppose opencl may help here.

cheers,
 jo


On Thu, Oct 12, 2017 at 5:23 PM, Aurélien PIERRE
 wrote:
> Hi !
>
> I understand the performance concerns and I'm working on some trade off.
> But…
>
> 1 - Non-blind Richardson-Lucy deconvolution by gradient descent with Total
> Variation regularization (probably not the algorithm used in Gimp since it's
> relatively recent) gives very good results in 25 iterations, thus 16 s on my
> 2 Mpx test picture with a Python script (on an i7 Ivy bridge laptop).
>
> 2 - Myopic deconvolution (the sort of "blind" deconvolution where you give a
> good-enough initial guess of the blur profile) converges faster than the
> blind one,
>
> 3 - The most computation-demanding operation is convolution product (2
> FFT-convolve by non blind iteration, 4 by blind iteration). The good news is
> we don't need to compute them on the whole picture (it's actually bad when
> you have a large bokeh area) and you can/should mask the area of interest
> and do the computations only on it. It saves a lot of time and gives better
> results on some cases.
>
> 4 - It should be possible to deconvolve the RAW pic first, cache it, then
> apply the further edits on the cached picture (similar to the HDR workflow).
>
> 5 - Piccur uses a myopic deconvolution (from what I have understood), and
> seems to offer rather decent time/quality ratio. Also, ImageJ has a similar
> open-source plugin (http://imagej.net/Parallel_Iterative_Deconvolution)
> which code could be of interest.
>
> Thanks for your interest !
>
> Aurélien PIERRE
> aurelienpierre.com
>
> 
>
> Le 2017-10-11 à 14:59, Heiko Bauke a écrit :
>
> 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
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Deconvolution and Python framework

[Aurélien PIERRE]

Hi !

I understand the performance concerns and I'm working on some trade off.
But…

1 - Non-blind Richardson-Lucy deconvolution by gradient descent with
Total Variation regularization (probably not the algorithm used in Gimp
since it's relatively recent) gives very good results in 25 iterations,
thus 16 s on my 2 Mpx test picture with a Python script (on an i7 Ivy
bridge laptop).

2 - Myopic deconvolution (the sort of "blind" deconvolution where you
give a good-enough initial guess of the blur profile) converges faster
than the blind one,

3 - The most computation-demanding operation is convolution product (2
FFT-convolve by non blind iteration, 4 by blind iteration). The good
news is we don't need to compute them on the whole picture (it's
actually bad when you have a large bokeh area) and you can/should mask
the area of interest and do the computations only on it. It saves a lot
of time and gives better results on some cases.

4 - It should be possible to deconvolve the RAW pic first, cache it,
then apply the further edits on the cached picture (similar to the HDR
workflow).

5 - Piccur uses a myopic deconvolution (from what I have understood),
and seems to offer rather decent time/quality ratio. Also, ImageJ has a
similar open-source plugin
(http://imagej.net/Parallel_Iterative_Deconvolution) which code could be
of interest.

Thanks for your interest !

*Aurélien PIERRE*
aurelienpierre.com 



Le 2017-10-11 à 14:59, Heiko Bauke a écrit :
> 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

Re: [darktable-dev] Deconvolution and Python framework

[Heiko Bauke]

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

--
-- Number Crunch Blog @ https://www.numbercrunch.de
--  Cluster Computing @ http://www.clustercomputing.de
--   Professional @ https://www.mpi-hd.mpg.de/personalhomes/bauke
--  Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Deconvolution and Python framework

[Martin Marmsoler]

Gimp use python as scripting language. It might be easier to port for Gimp?

Am 11.10.2017 17:55 schrieb "Jean-Luc Coulon (f5ibh)" <
jean.luc.cou...@gmail.com>:

> > but those "challenges" would only affect a small sub-set of dt users
> *every* "challenge affect only a small subset of dt users…
> Only base curve, demosaicing, light-contrast-saturation affect everybody ;)
>
> 2017-10-11 17:34 GMT+02:00 Patrick Shanahan :
>
>> * Jørn Villesen Christensen  [10-11-17 11:25]:
>> > On 2017-10-11 15:35, Pete Hall wrote:
>> > >Just an opinion from a devoted user... It might be a very useful tool
>> for
>> > >me. I shoot a lot of sporting events. It's common for me to find a
>> great
>> > >shot ruined because at the critical moment, the camera focused on the
>> > >wrong player, or on the goal keeper's net. Even if it can't be made
>> > >efficient for the normal workflow, it could still be a very useful
>> tool,
>> > >at least for me.
>> >
>> > Same for me - I think that would be an awesome feature, although I am
>> kind
>> > of sceptical that it will be the magical bullet for you, Pete ;-)
>> >
>> > But nonetheless, I hope that it will be possible to fit this
>> functionality
>> > into the workflow of Darktable - although I do see the challenges with
>> the
>> > time requirements.
>>
>> but those "challenges" would only affect a small sub-set of dt users, the
>> same as those working low-light and/or high-noise images.  and you can
>> prioritize usage, work those modules last to minimize delays.
>>
>> --
>> (paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
>> http://en.opensuse.orgopenSUSE Community Member
>> facebook/ptilopteri
>> Registered Linux User #207535@
>> http://linuxcounter.net
>> Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet
>> freenode
>> 
>> ___
>> darktable developer mailing list
>> to unsubscribe send a mail to darktable-dev+unsubscribe@list
>> s.darktable.org
>>
>>
>
> ___
> 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

[Jean-Luc Coulon (f5ibh)]

> but those "challenges" would only affect a small sub-set of dt users
*every* "challenge affect only a small subset of dt users…
Only base curve, demosaicing, light-contrast-saturation affect everybody ;)

2017-10-11 17:34 GMT+02:00 Patrick Shanahan :

> * Jørn Villesen Christensen  [10-11-17 11:25]:
> > On 2017-10-11 15:35, Pete Hall wrote:
> > >Just an opinion from a devoted user... It might be a very useful tool
> for
> > >me. I shoot a lot of sporting events. It's common for me to find a great
> > >shot ruined because at the critical moment, the camera focused on the
> > >wrong player, or on the goal keeper's net. Even if it can't be made
> > >efficient for the normal workflow, it could still be a very useful tool,
> > >at least for me.
> >
> > Same for me - I think that would be an awesome feature, although I am
> kind
> > of sceptical that it will be the magical bullet for you, Pete ;-)
> >
> > But nonetheless, I hope that it will be possible to fit this
> functionality
> > into the workflow of Darktable - although I do see the challenges with
> the
> > time requirements.
>
> but those "challenges" would only affect a small sub-set of dt users, the
> same as those working low-light and/or high-noise images.  and you can
> prioritize usage, work those modules last to minimize delays.
>
> --
> (paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
> http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
> Registered Linux User #207535@ http://linuxcounter.net
> Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode
> 
> ___
> darktable developer mailing list
> to unsubscribe send a mail to darktable-dev+unsubscribe@
> 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

[Patrick Shanahan]

* Jørn Villesen Christensen  [10-11-17 11:25]:
> On 2017-10-11 15:35, Pete Hall wrote:
> >Just an opinion from a devoted user... It might be a very useful tool for
> >me. I shoot a lot of sporting events. It's common for me to find a great
> >shot ruined because at the critical moment, the camera focused on the
> >wrong player, or on the goal keeper's net. Even if it can't be made
> >efficient for the normal workflow, it could still be a very useful tool,
> >at least for me.
> 
> Same for me - I think that would be an awesome feature, although I am kind
> of sceptical that it will be the magical bullet for you, Pete ;-)
> 
> But nonetheless, I hope that it will be possible to fit this functionality
> into the workflow of Darktable - although I do see the challenges with the
> time requirements.

but those "challenges" would only affect a small sub-set of dt users, the
same as those working low-light and/or high-noise images.  and you can
prioritize usage, work those modules last to minimize delays.  

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Registered Linux User #207535@ http://linuxcounter.net
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Deconvolution and Python framework

[Jørn Villesen Christensen]

On 2017-10-11 15:35, Pete Hall wrote:
Just an opinion from a devoted user... It might be a very useful tool 
for me. I shoot a lot of sporting events. It's common for me to find a 
great shot ruined because at the critical moment, the camera focused on 
the wrong player, or on the goal keeper's net. Even if it can't be made 
efficient for the normal workflow, it could still be a very useful tool, 
at least for me.


Same for me - I think that would be an awesome feature, although I am 
kind of sceptical that it will be the magical bullet for you, Pete ;-)


But nonetheless, I hope that it will be possible to fit this 
functionality into the workflow of Darktable - although I do see the 
challenges with the time requirements.


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

Re: [darktable-dev] Deconvolution and Python framework

[Patrick Shanahan]

* Pete Hall  [10-11-17 09:37]:
> Just an opinion from a devoted user... It might be a very useful tool
> for me.  I shoot a lot of sporting events.  It's common for me to find a
> great shot ruined because at the critical moment, the camera focused on
> the wrong player, or on the goal keeper's net.  Even if it can't be made
> efficient for the normal workflow, it could still be a very useful tool,
> at least for me.
> 
> On October 11, 2017 3:03:44 AM CDT, Heiko Bauke  wrote:
> >Dear Aurélien,
> >
> >Am 10.10.2017 um 10:25 schrieb Aurélien PIERRE:
> >> Following my work from this Summer, I'm glad to propose my first
> >blind 
> >> deconvolution algorithm, written in Python, based on papers from 
> >> 2011-2014  : https://github.com/aurelienpierre/Image-Cases-Studies
> >> 
> >> TL;DR :
> >> 
> >> Blind deconvolution is a technique used in astronomy and microscopy
> >to 
> >> deblur pictures based on an estimation of the blur "profile" (SPF for
> >
> >> the geeks). This work on motion blur, focus blur, etc. A commercial 
> >> photo software get spectacular results with this technique : 
> >> http://relaunch.piccureplus.com/ (although it's not really blind).
> >> 
> >> My code is a proof of concept which runs now (barely optimized)
> >between 
> >> 50 and 275 s on a 2 Mpx image.
> >> 
> >> I'm still looking for some help to port it in a Darktable module,
> >since 
> >> I'm not a C developper (or at least some doc).
> >
> >I am still rather skeptic regarding the question if a blind 
> >deconvolution algorithm fits into the darktable workflow.  It may be 
> >computationally too demanding.  Nevertheless, this is a very
> >fascinating 
> >topic and I will have a look at your code.  Thanks for your efforts.
> >
> >
> > Heiko
> >
> >
> >-- 
> >-- Number Crunch Blog @ https://www.numbercrunch.de
> >--  Cluster Computing @ http://www.clustercomputing.de
> >--   Professional @ https://www.mpi-hd.mpg.de/personalhomes/bauke
> >--  Social Networking @
> >https://www.researchgate.net/profile/Heiko_Bauke
> >___
> >darktable developer mailing list
> >to unsubscribe send a mail to
> >darktable-dev+unsubscr...@lists.darktable.org
> 
> 
> --
> Pete Hall
> p...@hallcircus.net
> 608-290-0731
> ___
> darktable developer mailing list
> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
> 

I agree with this.  I also shoot a lot of soccer and loose some good shots
because of errant focus.

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Registered Linux User #207535@ http://linuxcounter.net
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Deconvolution and Python framework

[Pete Hall]

Just an opinion from a devoted user... It might be a very useful tool for me. I 
shoot a lot of sporting events. It's common for me to find a great shot ruined 
because at the critical moment, the camera focused on the wrong player, or on 
the goal keeper's net. Even if it can't be made efficient for the normal 
workflow, it could still be a very useful tool, at least for me.

On October 11, 2017 3:03:44 AM CDT, Heiko Bauke  wrote:
>Dear Aurélien,
>
>Am 10.10.2017 um 10:25 schrieb Aurélien PIERRE:
>> Following my work from this Summer, I'm glad to propose my first
>blind 
>> deconvolution algorithm, written in Python, based on papers from 
>> 2011-2014  : https://github.com/aurelienpierre/Image-Cases-Studies
>> 
>> TL;DR :
>> 
>> Blind deconvolution is a technique used in astronomy and microscopy
>to 
>> deblur pictures based on an estimation of the blur "profile" (SPF for
>
>> the geeks). This work on motion blur, focus blur, etc. A commercial 
>> photo software get spectacular results with this technique : 
>> http://relaunch.piccureplus.com/ (although it's not really blind).
>> 
>> My code is a proof of concept which runs now (barely optimized)
>between 
>> 50 and 275 s on a 2 Mpx image.
>> 
>> I'm still looking for some help to port it in a Darktable module,
>since 
>> I'm not a C developper (or at least some doc).
>
>I am still rather skeptic regarding the question if a blind 
>deconvolution algorithm fits into the darktable workflow.  It may be 
>computationally too demanding.  Nevertheless, this is a very
>fascinating 
>topic and I will have a look at your code.  Thanks for your efforts.
>
>
>   Heiko
>
>
>-- 
>-- Number Crunch Blog @ https://www.numbercrunch.de
>--  Cluster Computing @ http://www.clustercomputing.de
>--   Professional @ https://www.mpi-hd.mpg.de/personalhomes/bauke
>--  Social Networking @
>https://www.researchgate.net/profile/Heiko_Bauke
>___
>darktable developer mailing list
>to unsubscribe send a mail to
>darktable-dev+unsubscr...@lists.darktable.org


--
Pete Hall
p...@hallcircus.net
608-290-0731
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Deconvolution and Python framework

[Heiko Bauke]

Dear Aurélien,

Am 10.10.2017 um 10:25 schrieb Aurélien PIERRE:
Following my work from this Summer, I'm glad to propose my first blind 
deconvolution algorithm, written in Python, based on papers from 
2011-2014  : https://github.com/aurelienpierre/Image-Cases-Studies


TL;DR :

Blind deconvolution is a technique used in astronomy and microscopy to 
deblur pictures based on an estimation of the blur "profile" (SPF for 
the geeks). This work on motion blur, focus blur, etc. A commercial 
photo software get spectacular results with this technique : 
http://relaunch.piccureplus.com/ (although it's not really blind).


My code is a proof of concept which runs now (barely optimized) between 
50 and 275 s on a 2 Mpx image.


I'm still looking for some help to port it in a Darktable module, since 
I'm not a C developper (or at least some doc).


I am still rather skeptic regarding the question if a blind 
deconvolution algorithm fits into the darktable workflow.  It may be 
computationally too demanding.  Nevertheless, this is a very fascinating 
topic and I will have a look at your code.  Thanks for your efforts.



Heiko


--
-- Number Crunch Blog @ https://www.numbercrunch.de
--  Cluster Computing @ http://www.clustercomputing.de
--   Professional @ https://www.mpi-hd.mpg.de/personalhomes/bauke
--  Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Deconvolution and Python framework

[Maurizio Paglia]

Aurélien, this is really interesting.
I saw some output of Piccure+ and (if REAL and not otherwise handled) they
are really interesting!
I hope someone can help you with the porting.

Maurizio

2017-10-10 10:25 GMT+02:00 Aurélien PIERRE :

> Hi !
>
> Following my work from this Summer, I'm glad to propose my first blind
> deconvolution algorithm, written in Python, based on papers from 2011-2014
> : https://github.com/aurelienpierre/Image-Cases-Studies
>
> TL;DR :
>
> Blind deconvolution is a technique used in astronomy and microscopy to
> deblur pictures based on an estimation of the blur "profile" (SPF for the
> geeks). This work on motion blur, focus blur, etc. A commercial photo
> software get spectacular results with this technique :
> http://relaunch.piccureplus.com/ (although it's not really blind).
>
> My code is a proof of concept which runs now (barely optimized) between 50
> and 275 s on a 2 Mpx image.
>
> I'm still looking for some help to port it in a Darktable module, since
> I'm not a C developper (or at least some doc).
>
> Thanks !
>
> *Aurélien PIERRE*
> aurelienpierre.com
> --
>
> Le 2017-05-04 à 04:03, Coding Dave a écrit :
>
> I can only speak for myself but I find it very interesting.
>
> Am 04.05.2017 03:32 schrieb "Aurélien PIERRE"  >:
>
>> Hi,
>>
>> I got critics so I made it better ;-) My Richardson-Lucy implementation
>> now allows to set a mask. This mask is intended to specify the zone where
>> the focus is supposed to be, and thus compute the deconvolution matrix
>> estimation only there. This matrix is then used to deconvolute the whole
>> picture. I got faaar better results regarding the general
>> smudginess/sharpness ratio : https://github.com/aurelienpie
>> rre/Image-Cases-Studies/commit/bfaf6930abd873e568ee12f90427dad0206d6de6
>>
>> I don't know how much the community is interested in my experiments
>> though or if it's relevant here, so just tell me if I spam.
>>
>> Have a nice day,
>>
>> *Aurélien PIERRE*
>> aurelienpierre.com
>> --
>>
>> Le 2017-05-03 à 04:42, Aurélien PIERRE a écrit :
>>
>> Hi,
>>
>> being a Darktable user since 2010 (0.9 if I recall), a photographer for
>> many years and an almost engineer, I have looked for a long time to get
>> involved into DT development. I know 10 programming languages but I'm still
>> a newbie in C…
>>
>> Following my last email on adaptative deconvolution, I started a Python
>> framework to experiment on image processing algorithms. The Github repos is
>> here : https://github.com/aurelienpierre/Image-Cases-Studies
>>
>> I already have 3 case studies, with algorithms and before/after pictures :
>>
>>- Unsharp masking with bilateral filter in LAB space
>>- Defringing with bilateral filter in LAB space
>>- Focus correction/restoration with Richardson-Lucy deconvolution in
>>RGB and LAB spaces.
>>
>> I'm trying to keep my code as clean as possible to make it easy to
>> understand and possible to translate into C and (hopefully) into Darktable
>> modules. The framework is packaged with a Python setup file and optimized
>> with Cython and parallel computing.
>>
>> I will continue to experiment on deconvolution but any comment, code
>> review, scientific article, or contribution is welcome.
>> Have a nice day,
>> --
>>
>> *Aurélien PIERRE*
>> aurelienpierre.com
>> --
>>
>>
>> ___
>> 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
>>
>
> ___
> 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
>

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

Re: [darktable-dev] Deconvolution and Python framework

[Aurélien PIERRE]

Hi !

Following my work from this Summer, I'm glad to propose my first blind
deconvolution algorithm, written in Python, based on papers from
2011-2014  : https://github.com/aurelienpierre/Image-Cases-Studies

TL;DR :

Blind deconvolution is a technique used in astronomy and microscopy to
deblur pictures based on an estimation of the blur "profile" (SPF for
the geeks). This work on motion blur, focus blur, etc. A commercial
photo software get spectacular results with this technique :
http://relaunch.piccureplus.com/ (although it's not really blind).

My code is a proof of concept which runs now (barely optimized) between
50 and 275 s on a 2 Mpx image.

I'm still looking for some help to port it in a Darktable module, since
I'm not a C developper (or at least some doc). 

Thanks !

*Aurélien PIERRE*
aurelienpierre.com 



Le 2017-05-04 à 04:03, Coding Dave a écrit :
> I can only speak for myself but I find it very interesting. 
>
> Am 04.05.2017 03:32 schrieb "Aurélien PIERRE"
> >:
>
> Hi,
>
> I got critics so I made it better ;-) My Richardson-Lucy
> implementation now allows to set a mask. This mask is intended to
> specify the zone where the focus is supposed to be, and thus
> compute the deconvolution matrix estimation only there. This
> matrix is then used to deconvolute the whole picture. I got faaar
> better results regarding the general smudginess/sharpness ratio :
> 
> https://github.com/aurelienpierre/Image-Cases-Studies/commit/bfaf6930abd873e568ee12f90427dad0206d6de6
> 
> 
>
> I don't know how much the community is interested in my
> experiments though or if it's relevant here, so just tell me if I
> spam.
>
> Have a nice day,
>
> *Aurélien PIERRE*
> aurelienpierre.com 
>
> 
>
> Le 2017-05-03 à 04:42, Aurélien PIERRE a écrit :
>>
>> Hi,
>>
>> being a Darktable user since 2010 (0.9 if I recall), a
>> photographer for many years and an almost engineer, I have looked
>> for a long time to get involved into DT development. I know 10
>> programming languages but I'm still a newbie in C…
>>
>> Following my last email on adaptative deconvolution, I started a
>> Python framework to experiment on image processing algorithms.
>> The Github repos is here :
>> https://github.com/aurelienpierre/Image-Cases-Studies
>> 
>>
>> I already have 3 case studies, with algorithms and before/after
>> pictures :
>>
>>   * Unsharp masking with bilateral filter in LAB space
>>   * Defringing with bilateral filter in LAB space
>>   * Focus correction/restoration with Richardson-Lucy
>> deconvolution in RGB and LAB spaces.
>>
>> I'm trying to keep my code as clean as possible to make it easy
>> to understand and possible to translate into C and (hopefully)
>> into Darktable modules. The framework is packaged with a Python
>> setup file and optimized with Cython and parallel computing.
>>
>> I will continue to experiment on deconvolution but any comment,
>> code review, scientific article, or contribution is welcome.
>>
>> Have a nice day,
>> -- 
>>
>> *Aurélien PIERRE*
>> aurelienpierre.com 
>>
>> 
>>
>>
>> 
>> ___
>> 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
> 
>
>
> ___
> 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

[Coding Dave]

I can only speak for myself but I find it very interesting.

Am 04.05.2017 03:32 schrieb "Aurélien PIERRE" :

> Hi,
>
> I got critics so I made it better ;-) My Richardson-Lucy implementation
> now allows to set a mask. This mask is intended to specify the zone where
> the focus is supposed to be, and thus compute the deconvolution matrix
> estimation only there. This matrix is then used to deconvolute the whole
> picture. I got faaar better results regarding the general
> smudginess/sharpness ratio : https://github.com/
> aurelienpierre/Image-Cases-Studies/commit/bfaf6930abd873e568ee12f90427da
> d0206d6de6
>
> I don't know how much the community is interested in my experiments though
> or if it's relevant here, so just tell me if I spam.
>
> Have a nice day,
>
> *Aurélien PIERRE*
> aurelienpierre.com
> --
>
> Le 2017-05-03 à 04:42, Aurélien PIERRE a écrit :
>
> Hi,
>
> being a Darktable user since 2010 (0.9 if I recall), a photographer for
> many years and an almost engineer, I have looked for a long time to get
> involved into DT development. I know 10 programming languages but I'm still
> a newbie in C…
>
> Following my last email on adaptative deconvolution, I started a Python
> framework to experiment on image processing algorithms. The Github repos is
> here : https://github.com/aurelienpierre/Image-Cases-Studies
>
> I already have 3 case studies, with algorithms and before/after pictures :
>
>- Unsharp masking with bilateral filter in LAB space
>- Defringing with bilateral filter in LAB space
>- Focus correction/restoration with Richardson-Lucy deconvolution in
>RGB and LAB spaces.
>
> I'm trying to keep my code as clean as possible to make it easy to
> understand and possible to translate into C and (hopefully) into Darktable
> modules. The framework is packaged with a Python setup file and optimized
> with Cython and parallel computing.
>
> I will continue to experiment on deconvolution but any comment, code
> review, scientific article, or contribution is welcome.
> Have a nice day,
> --
>
> *Aurélien PIERRE*
> aurelienpierre.com
> --
>
>
> ___
> 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
>

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

Re: [darktable-dev] Deconvolution and Python framework

[Aurélien PIERRE]

Hi,

I got critics so I made it better ;-) My Richardson-Lucy implementation
now allows to set a mask. This mask is intended to specify the zone
where the focus is supposed to be, and thus compute the deconvolution
matrix estimation only there. This matrix is then used to deconvolute
the whole picture. I got faaar better results regarding the general
smudginess/sharpness ratio :
https://github.com/aurelienpierre/Image-Cases-Studies/commit/bfaf6930abd873e568ee12f90427dad0206d6de6

I don't know how much the community is interested in my experiments
though or if it's relevant here, so just tell me if I spam.

Have a nice day,

*Aurélien PIERRE*
aurelienpierre.com 



Le 2017-05-03 à 04:42, Aurélien PIERRE a écrit :
>
> Hi,
>
> being a Darktable user since 2010 (0.9 if I recall), a photographer
> for many years and an almost engineer, I have looked for a long time
> to get involved into DT development. I know 10 programming languages
> but I'm still a newbie in C…
>
> Following my last email on adaptative deconvolution, I started a
> Python framework to experiment on image processing algorithms. The
> Github repos is here :
> https://github.com/aurelienpierre/Image-Cases-Studies
>
> I already have 3 case studies, with algorithms and before/after pictures :
>
>   * Unsharp masking with bilateral filter in LAB space
>   * Defringing with bilateral filter in LAB space
>   * Focus correction/restoration with Richardson-Lucy deconvolution in
> RGB and LAB spaces.
>
> I'm trying to keep my code as clean as possible to make it easy to
> understand and possible to translate into C and (hopefully) into
> Darktable modules. The framework is packaged with a Python setup file
> and optimized with Cython and parallel computing.
>
> I will continue to experiment on deconvolution but any comment, code
> review, scientific article, or contribution is welcome.
>
> Have a nice day,
> -- 
>
> *Aurélien PIERRE*
> aurelienpierre.com 
>
> 
>
>
> ___
> 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

[darktable-dev] Deconvolution and Python framework

[Aurélien PIERRE]

Hi,

being a Darktable user since 2010 (0.9 if I recall), a photographer for
many years and an almost engineer, I have looked for a long time to get
involved into DT development. I know 10 programming languages but I'm
still a newbie in C…

Following my last email on adaptative deconvolution, I started a Python
framework to experiment on image processing algorithms. The Github repos
is here : https://github.com/aurelienpierre/Image-Cases-Studies

I already have 3 case studies, with algorithms and before/after pictures :

  * Unsharp masking with bilateral filter in LAB space
  * Defringing with bilateral filter in LAB space
  * Focus correction/restoration with Richardson-Lucy deconvolution in
RGB and LAB spaces.

I'm trying to keep my code as clean as possible to make it easy to
understand and possible to translate into C and (hopefully) into
Darktable modules. The framework is packaged with a Python setup file
and optimized with Cython and parallel computing.

I will continue to experiment on deconvolution but any comment, code
review, scientific article, or contribution is welcome.

Have a nice day,
-- 

*Aurélien PIERRE*
aurelienpierre.com 




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