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 <http://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 <http://aurelienpierre.com>
> Tobias
>
> [...]

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to