That’s always been my problem with Apple as the household tech troubleshooter. I have never owned one myself, but have needed to troubleshoot occasionally, and Apple won’t let you access the innards easily. But that’s a different issue entirely. The interface being relatively easy to learn to navigate is the applicable bit.
I think Pixls.us is a really good focus group for the usability of Darktable. Although the users here are almost certainly above average in terms of tech literacy as well as patience to learn new tools (so not representative of the mass market), if these users are struggling with a certain aspect of the software, it’s a good indicator that most people will.
I don’t think anyone is arguing to make the Diffuse or Sharpen module “easy” or dumbed down per se. It’s inherently a very complex module. But a change to the interface could make it more usable (let’s forget the word intuitive for now) for the average Darktable user. We know from YouTube views/subscribers and social media followers that the number of Darktable users is probably in the thousands. The dozens or even hundreds active on this forum are maybe not the average user, but they make a good focus group for if something is likely to cause confusion for all other users.
The proposition is to keep the actual interface as an “advanced interface” and to add an additional tab named “simple interface”.
The simple tab is not able to recreate all the cases the advanced tab can do, but it is sufficient for a lot of simple cases.
The “Optimisation” choice would be the selection of the “purpose” (watercolor, local contrast, sharpening, in-painting, …). It could be placed higher in the tab.
Then, you choose between “sharpen” or “diffuse”. The “Force” slider is something like Speed * Iterations and the “increase time” would reduce speed in favor of the iterations (keeping Speed * Iterations constant).
The problem with DoS is not that it’s unintuitive. All new things are. The problem is that it’s complicated.
There are a large number of sliders, and the sliders all interact with one another. It’s not like the tone equalizer or filmic, where each slider does one thing in a fairly well-differentiated manner. Instead, each slider is modulated by at least three other sliders. The first order laplacian is modulated by its anisotropy and by the effect size and the number of iterations. This intertwinedness, or complication (from “complected”, aka “braided”) is what makes DoS hard to learn.
Perhaps this is merely a question of factorization: perhaps Diffuse and Sharpen does too many things at once. There’s a heuristic in programming that says that any function with an “and” in the name, should be split into two separate functions. Perhaps it would make sense to separate the sharpening/local contrast/clarity from the soften/bloom/blur side of things. And perhaps we could multiply the sliders for several effect sizes instead of having the additional size slider (sort of like the wavelet scales in retouch). Perhaps we could then find useful labels for the sliders. At least in the UI. The background algorithms could stay the same. Sort of like how the primaries module is an easier-to-grasp version of the RGB panels in color calibration.
…but I’m just thinking out loud here, I don’t actually have solutions. Nor, regrettably, time to try and implement a few.
Yes, that’s why it will not be implemented
However, this particular proposition does not need to understand the math behind the module, as it was designed as a simple cover for the advanced tab, not a real new interface altering the algorithme. It’s more like a “preset” selector… but yeah the presets already exist.
I’ll let you know when I can use the word “anisotropy” in a sentence. If it requires maths then probably never. But that doesn’t mean I won’t ever get to have some practical ability with these sliders: I hope to. And when I can, I’ll be able to say, “Hey, it’s intuitive!”
That’s why the module is called “Diffuse or Sharpen”
Joking apart, the two (diffuse and sharpen) are actually opposite sides of the coin:
Diffusion blurs edges, if you reverse the effect (*), you end up sharpening those same edges.
And all the seemingly different effects in the presets are variations on this theme, applied at different scales.
Diffusion processes are quite important in chemistry, geology and biology, and therefore well studied and reasonably well understood (they can explain things like distribution of polluants, stripes on a tiger or spots on a panther or jaguar). That does not mean they are simple to calculate, as you deal with differential equations, with no analytical solutions (special cases exempted).
Here a few other wrinkles are added by working on two wavelet scales, allowing “reverse diffusion”, and use of existing edges. But that mostly influences setting up the PDE system, not so much the way the PDE calculations are done. So separating out some of the posibilities into separate modules may make the system easier to use for an inexperienced user, but you’ll pay for it by longer calculation times, more changes of artifacts (try pushing the iteration count too high), and probably limiting the possible uses.
(* : impossible in real life, see 2nd law of thermodynamics)
The concept is not all that complicated:
Isotropic diffusion means that the speed of diffusion is the same in all directions. Anisotropic means it’s not. And the higher the anisotropy, the more difference you have between directions (usually perpendicular directions, as we tend to prefer perpendicular reference frames: xy, xyz, length-height-depth).
In this case, the module uses as directions the gradient (perpendicular to the edge) and the isophotes (parallel to edges). Keep in mind that we are working on small units (pixel level or a bit larger), so noise provides edges!
What I’m still not quite seeing is how you could get diffusion along the isophotes (but that’s perhaps because I look at it too much as “physical” diffusion).
I think it is a premature to conclude this without seeing the math in question first.
A lot of DT users have some understanding of multivariate calculus and even PDEs, at least as a notation. They could then contribute by explaining it intuitively to others (I would definitely do this).
Without the math, we are treating this as an experimental black box problem: here is this great module, no one really knows what it does, so we tweak the sliders until something interesting happens.
There’s a reason for the module’s name: “diffuse”(*) or sharpen. That’s the main process used here. The difficulty in understanding what’s going on comes from the other bits of math mixed in: wavelets, gaussian blurs, anisotropy, etc., and how all those bits interact. I can more or less see the use of the wavelets and the anisotropy, the rest is still too opaque.
So far, I’ve felt no need to understand the details of (solving) the PDE:
basically, it calculates the advancement of the described process over time, so it calculates the model set up earlier; and it’s the setup of that exact model that’s I find tricky to understand.
(*: I have no idea how much at ease people here are with “physical” diffusion processes, and the math behind them.)
My mental model for the module is that anisotropy just parametrizes the diffusion process, wavelets are an implementation detail, and there is no gaussian blur per se, it is done by the process. (My mental model is probably wrong ).
Thanks to all for continuing explanations. Every little helps. After reading the last few posts, I’m back to scratching my head over the term “speed!” Speed is to do with movement: our images are static.
I don’t think photographers should have to be mathematicians. But I do realise that maths is what makes all this image processing work, just as it is at the core of, say, music.
My maths is at the level of basic arithmetic and a smattering of geometry. I’ve used trigonometry in basic small-boat navigation. I don’t even have a concept of what calculus is. Just for the record: I’m not trying to restrict the conversation in any way. I’ll just take from it what I can manage today.
(Haha… I was thrown out of maths class: “no point in you doing the course, let alone the exam.” But I still worked with computers, systems management. A friend was incredulous at my career change. I told him, the machine does the sums, not me.)
Think of particles moving at random. You drop some paint in water: the particles move randomly, and diffuse. Soon enough, the little drop will become a diffused little cloud with no sharp boundaries.
The module simulates this. To blur, it ‘diffuses light’; to sharpen, it ‘reverses time’ (‘moves the particles backward’), like watching a video of that little cloud of colour condensing back into a well-defined paint droplet.
In hot water, particles move faster: you get larger diffusion in a given time.
The ‘iteration’ is your ‘time’, the ‘speed’ is the ‘water temperature’; the sign of the speed is watching the video forwards or backwards (positive speed: diffusion, blurring; negative speed: sharpening).
I fully agree with this, but I still think it’s an interface problem. Take the Contrast EQ module for example. When you move a node up to add contrast, it’s one action but several parameters are being adjusted all at once. First of all, the node choice represents a point on the wavelet scale (equivalent of central radius in DoS), how much you push up is affecting the amount of contrast added (iterations + speed?), and the width around the node – adjustable using shift+scroll – is affecting the “width” of the effect (radius span in DoS).
To do the same operation In DoS, you need to set multiple sliders, and it’s therefore multiple distinct actions (about 5). With Contrast EQ, it’s basically 1 or 2 actions. I know defaults have essentially been set in Contrast EQ, such as the choice of default widths, node placements, etc, but these defaults really help you get started, and it’s trivial to make adjustments to the effect.
I think the sheer number of sliders in DoS is overwhelming, especially as they all interact with each other and can’t be used in isolation, but I don’t think just reducing the number (as proposed in that Ansel feature request) is enough to help users. I think some visualization tool is sorely needed, and so far my favourite idea is to at least see the various wavelet scales we are working on, either through a mask (like the Retouch module) or a graph (like Contrast EQ, Tone EQ, etc).
Contrast EQ has 6 nodes, roughly translating to Coarse details x2, Medium x2, Fine details x2
Diffuse or Sharpen has a slider from 0 - 512 in pixels.
The lack of delimiters in DoS is immediately disorienting. Knowing (or, even better, visualizing) where the coarse, medium and fine details lie on that slider would be a great start. Especially because the pixels on the DoS slider refer to the full-resolution image, not the zoomed-out image in your preview.
Yes, it’s a complicated module. That’s probably why there are so many presets provided.
But, in order to propose an alternative interface (if that’s even possible without limiting the tool too much), you first have to understand the module. And so far, it looks as if no one here both understands all the sliders (I know I don’t), and has a viable idea for an alternative interface.
So continuing to harp on how complicated the module is, and how there are too many sliders (have you looked at color balance RGB?) is not helping anymore to get to a better interface.
As has been said in other contexts, just because those sliders are there, doesn’t mean you have to use them.
You can use a preset, and then play around with the sliders looking at the effect. Do that often enough, and you can develop a pragmatic understanding of the function of each slider. Also, the tooltips on mouse-over give hints about what the sliders (are supposed to) do.
And, just creating a series of “sub-modules” for e.g. bloom, sharpen, denoise, local contrast only moves the problem from “select a preset and modify” to “select a module and modify”, while adding the false impression that you understand what the tool does. (Do the participants here understand the math behind demosaicing? If not, does that stop you from using the module? Same for highlight correction, color balance RGB, …)
I really hope that this is a correct interpretation of how DoS works (or at least is good enough???). I’ve watched various videos, read around, but this is the first explanation I’ve seen that explains the arcane workings of DoS in terms that my aged, non-mathematical brain can understand and retain for future use.
