Re: [darktable-dev] possible data loss scenario

[Alexander Rabtchevich]

Hello

David Houlder wrote:


So here's an idea: make all fields and widgets except for sliders 
require explicit focus (mouse click or tab key), on the grounds that 
sliders can be inadvertently changed by click-to-focus in a way that 
other controls cannot. In the case where a slider was not explicitly 
focused, it only has focus while the pointer is hovering over it, and 
focus returns to whatever had it before the slider when the pointer 
leaves the slider. In other words, hover on a  slider temporarily 
steals the focus.


The idea is sound. *Any* unintended keyboard action *is* data loss. The 
scenario could be different, but it can lead even to physical removing 
of a photo. Why not? Assign it 0 rating or click Del to remove unneeded 
digit or a letter in a control. And the confirmation dialog to Del key 
may be passed through automatically. And latter remove the 
*accidentally* assigned image physically.


As I understand, the desired action to be click-less is mouse scrolling 
over a control. Why should it hook keyboard actions?



With respect,
Alexander Rabtchevich
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

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

[David Houlder]

On 13/10/17 08: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

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'm of the opinion that the focus-follows-mouse behaviour isn't always 
helpful, and leads to errors of the type we're discussing here. 
Information display on hover is good (e.g. tooltips and the image info 
panel), but for many things that involve a state change, I think it's 
preferable to require an explicit focus shift (mouse click or tab key) 
first.


For instance, I have accidentally changed the rating on an image in the 
darkroom view due to confusion between the current image in the 
filmstrip (the centered and highlighted thumbnail), and the focused 
thumbnail - the one that the mouse is hovering over - which can easily 
be any random image.


Another downside of the current focus logic can be demonstrated by 
hovering over a text field without clicking (say, the "max size" field 
in the export panel) and tapping the up or down arrow key - it changes 
the setting of the last dropdown that the mouse happened to fly over on 
its way to the text field (in dt 2.2.5, Xubuntu 16.04).


However, I can see some downsides to requiring an explicit focus shift 
in all cases.


The main one I can think of is shifting focus to a slider without 
changing it in the process. The current behaviour allows you to hover 
over a slider and crank it up or down a little with the arrow keys or 
scroll wheel. Using  a click to focus would inadvertently alter its 
setting in many cases.


So here's an idea: make all fields and widgets except for sliders 
require explicit focus (mouse click or tab key), on the grounds that 
sliders can be inadvertently changed by click-to-focus in a way that 
other controls cannot. In the case where a slider was not explicitly 
focused, it only has focus while the pointer is hovering over it, and 
focus returns to whatever had it before the slider when the pointer 
leaves the slider. In other words, hover on a  slider temporarily steals 
the focus.


cheers
David



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