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] possible data loss scenario

[Marcello Mamino]

On Thu, Oct 12, 2017 at 11:57 PM, Tobias Ellinghaus  wrote:
> Am Donnerstag, 12. Oktober 2017, 17:24:30 CEST schrieb Marcello Mamino:
>> I can reproduce the bug on Debian stable, under Xfce, master branch
>> just compiled, every setting default. The steps to follow are
>> *exactly* these
>>
>> 1. Open the "export selected" tab
>> 2. Click in the "max size" filed.
>> 3. Slowly move the pointer *downwards*
>> 4. As soon as the pointer reaches the "allow upscaling" label just
>> below, the input field loses focus
>> 5. Hover on a image, press a number, and the star rating changes
>
> We are aware of this and know why it's happening. We are not sure how to
> proceed with this though, as grabbing the focus itself is intended (so you can
> use the arrow keys to change the dropdowns and sliders), but the implication
> is unwanted. So we have to decide what eggs to break and what omelette to
> make. Or something like that. :-)

If I may offer a suggestion, I would say that grabbing the focus
should necessitate a click. Even ignoring Alexander's problem, the
current implementation is broken (at least under Linux+Xorg+Xfce). If
the "max size" field has focus and I press the arrows I can adjust the
number. Then I move the mouse down to "allow upscaling", and the
arrows adjust this setting. Fine, but now I do the opposite action and
move the pointer back to "max size": for no good reason the arrows
keep controlling the "allow upscaling" setting. It must be either
focus-follows-pointer or focus-follows-click, while now it seems to be
a random mix of these.

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

Re: [darktable-dev] possible data loss scenario

[Jonathan Richards]

On 12/10/17 22:57, Tobias Ellinghaus wrote:
> Am Donnerstag, 12. Oktober 2017, 17:24:30 CEST schrieb Marcello Mamino:
>> I can reproduce the bug on Debian stable, under Xfce, master branch
>> just compiled, every setting default. The steps to follow are
>> *exactly* these
>>
>> 1. Open the "export selected" tab
>> 2. Click in the "max size" filed.
>> 3. Slowly move the pointer *downwards*
>> 4. As soon as the pointer reaches the "allow upscaling" label just
>> below, the input field loses focus
>> 5. Hover on a image, press a number, and the star rating changes
Ah, yes.  This behaviour is identical on the KDE build that I reported
above.  I did not move the cursor downward before.
Jonathan
> 
> We are aware of this and know why it's happening. We are not sure how to 
> proceed with this though, as grabbing the focus itself is intended (so you 
> can 
> use the arrow keys to change the dropdowns and sliders), but the implication 
> is unwanted. So we have to decide what eggs to break and what omelette to 
> make. Or something like that. :-)
What about a confirmation dialog before DT changes the star rating on a
large number of selected images?  Or an undo stack that remembers star
ratings and can restore them after a mistaken commit?  Alexander's
original report was about losing many decisions on star rating, after all.

> 
>> I have a second, loosely related problem with number keys and stars. I
>> take this opportunity to ask the devs if it's a bug or a feature.
>> Image X has one star. You click on the star, and the star is removed.
>> This makes sense because there is no other way to remove that star.
>> You hover on image X that has one star, you press 1, and the star is
>> removed. This makes no sense, because if you want to remove the star,
>> you can just press 0. It's also frustrating when you see image X
>> suddenly vanish. Is this by design?
> 
> This used to be by design and was changed in the development version. There 
> is 
> still some minor issue left but we are certain that the upcoming release will 
> be intuitive to use in this regard.
> 
>> Yours,
>> Marcello Mamino.
> 
> Tobias
> 




signature.asc
Description: OpenPGP digital signature

Re: [darktable-dev] Olympus lens name mismatch

[Roman Lebedev]

On Fri, Oct 13, 2017 at 1:47 AM, Felipe Contreras Salinas
 wrote:
> The list of lenses of the Lens Correction Module lists the "Olympus M.Zuiko
> Digital ED 60mm f/2.8 Macro" as "Olympus M.Zuiko Digital 60mm f/2.8 Macro"
> (without the ED). This results in that you must select the lens manually,
> because DT says that the lens is not found.
>
> If I understand correctly, DT uses the Lensfun database for lens correction,
> and there the lens is listed with the "ED", so why there is a difference?
Because that is what lensfun says: http://lensfun.sourceforge.net/lenslist/

> Should I report the bug?
To lensfun - yes.
*Maybe* try https://github.com/lensfun/lensfun/issues

> Regards,
> Felipe Contreras
Roman.

> ___
> 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] Olympus lens name mismatch

[Felipe Contreras Salinas]

The list of lenses of the Lens Correction Module lists the "Olympus 
M.Zuiko Digital ED 60mm f/2.8 Macro" as "Olympus M.Zuiko Digital 60mm 
f/2.8 Macro" (without the ED). This results in that you must select the 
lens manually, because DT says that the lens is not found.


If I understand correctly, DT uses the Lensfun database for lens 
correction, and there the lens is listed with the "ED", so why there is 
a difference? Should I report the bug?


Regards,
Felipe Contreras

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

Re: [darktable-dev] possible data loss scenario

[Tobias Ellinghaus]

Am Donnerstag, 12. Oktober 2017, 17:24:30 CEST schrieb Marcello Mamino:
> I can reproduce the bug on Debian stable, under Xfce, master branch
> just compiled, every setting default. The steps to follow are
> *exactly* these
> 
> 1. Open the "export selected" tab
> 2. Click in the "max size" filed.
> 3. Slowly move the pointer *downwards*
> 4. As soon as the pointer reaches the "allow upscaling" label just
> below, the input field loses focus
> 5. Hover on a image, press a number, and the star rating changes

We are aware of this and know why it's happening. We are not sure how to 
proceed with this though, as grabbing the focus itself is intended (so you can 
use the arrow keys to change the dropdowns and sliders), but the implication 
is unwanted. So we have to decide what eggs to break and what omelette to 
make. Or something like that. :-)

> I have a second, loosely related problem with number keys and stars. I
> take this opportunity to ask the devs if it's a bug or a feature.
> Image X has one star. You click on the star, and the star is removed.
> This makes sense because there is no other way to remove that star.
> You hover on image X that has one star, you press 1, and the star is
> removed. This makes no sense, because if you want to remove the star,
> you can just press 0. It's also frustrating when you see image X
> suddenly vanish. Is this by design?

This used to be by design and was changed in the development version. There is 
still some minor issue left but we are certain that the upcoming release will 
be intuitive to use in this regard.

> Yours,
> Marcello Mamino.

Tobias

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

Re: [darktable-dev] possible data loss scenario

[Marcello Mamino]

I can reproduce the bug on Debian stable, under Xfce, master branch
just compiled, every setting default. The steps to follow are
*exactly* these

1. Open the "export selected" tab
2. Click in the "max size" filed.
3. Slowly move the pointer *downwards*
4. As soon as the pointer reaches the "allow upscaling" label just
below, the input field loses focus
5. Hover on a image, press a number, and the star rating changes

I have a second, loosely related problem with number keys and stars. I
take this opportunity to ask the devs if it's a bug or a feature.
Image X has one star. You click on the star, and the star is removed.
This makes sense because there is no other way to remove that star.
You hover on image X that has one star, you press 1, and the star is
removed. This makes no sense, because if you want to remove the star,
you can just press 0. It's also frustrating when you see image X
suddenly vanish. Is this by design?

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

Re: [darktable-dev] Fixing the scroll-bar issue

[Jørn Villesen Christensen]

Hi there,

On 2017-10-12 09:50, Tobias Ellinghaus wrote:

Am Mittwoch, 11. Oktober 2017, 20:04:34 CEST schrieb Rolf Meyerhoff:

DT has actually two scrollbars for the lighttable. One is located at the
outer most right edge and one at the outer most left edge of the main
window.

However, they are not accessible with a mouse because they're overlaid
by the 'side panel open/close click areas' (or whatever they're called).
The side panels have their own scrollbars.


Precisely.


No, they are not "accessible" because they are not scroll bars in the first
place. We just draw some grey rectangles of various shades as an indicators.


Well, they are. At least the one associated with the modules pane. I can 
click and scroll on that one.



It always annoyed me that I could see the scrollbars but I couldn't use
them. It would be great of someone could fix that.


That would be less of a fix than a new feature added. One that I were not
opposed to. But it's definitely more involved than just moving the widget to
another place and wiring up a signal.


I think I will see if I can find time to look at this issue - whether 
the outer one is a scrollbar or not. If the latter, I can perhaps copy 
stuff from the modules pane.


(Looking closely now, I do see a small difference at the top and bottom 
of the two "scrollbars". The modules one have rounded corners, while the 
light table one do not.)


~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

[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] Fixing the scroll-bar issue

[Tobias Ellinghaus]

Am Mittwoch, 11. Oktober 2017, 20:04:34 CEST schrieb Rolf Meyerhoff:
> Hi
> 
> DT has actually two scrollbars for the lighttable. One is located at the
> outer most right edge and one at the outer most left edge of the main
> window.
> 
> However, they are not accessible with a mouse because they're overlaid
> by the 'side panel open/close click areas' (or whatever they're called).
> The side panels have their own scrollbars.

No, they are not "accessible" because they are not scroll bars in the first 
place. We just draw some grey rectangles of various shades as an indicators.

> It always annoyed me that I could see the scrollbars but I couldn't use
> them. It would be great of someone could fix that.

That would be less of a fix than a new feature added. One that I were not 
opposed to. But it's definitely more involved than just moving the widget to 
another place and wiring up a signal.

> Stock Kubuntu 16.4 with current git DT.
> 
> Rolf

Tobias

> Am 11.10.2017 um 19:12 schrieb Roman Lebedev:
> > On Wed, Oct 11, 2017 at 8:04 PM, Jørn Villesen Christensen
> > 
> >  wrote:
> >> Hi there,
> > 
> > Hi.
> > 
> >> I have been using Darktable from time to time and think I will be using
> >> it
> >> more in the future. I have a few ideas of what modules I would like to
> >> see
> >> in Darktable and I thought I might throw in a few hours myself.
> >> 
> >> Short about me: I have been working 7 years now as a software developer
> >> and
> >> architect in a Windows oriented environment. Mostly I have been working
> >> with Delphi, C#, and C++. In my private life I have been running Linux
> >> for ~15 years and done some C++ programming - but without GUI.
> >> In order to get started and to do something useful, I thought I would
> >> look
> >> at a bug that I also find annoying. It is described in these two bug
> >> 
> >> reports:
> >>   https://redmine.darktable.org/issues/10947
> >>   https://redmine.darktable.org/issues/10711
> > 
> > You should have pointed to https://redmine.darktable.org/issues/9439
> > 
> >> My idea was basically to move the scrollbar from the outer position
> >> (where
> >> it is currently) to just next to the film roll. See attached photo.
> > 
> > Which scrollbar? There is a scrollbar for the sidepanels.
> > There is no scrollbar for the lighttable view itself.
> > 
> >> Questions:
> >>  a) Are there already other people working on solving these bugs?
> >>  b) Does my proposed solution seem like a good idea?
> >>  c) Would you have any pointers to me on how to get started (which files
> >>  I
> >> 
> >> should look into or other tips on how *you* would go about solving this).
> >> 
> >> BR
> >> Jørn Christensen
> > 
> > Roman.
> > 
> >> _
> >> __
> >> 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



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