Darktable UI Work

[paperdigits (Mica)]

@martinus

The film processing jargon and the photography jargon are not the same

I just make images. The tools have changed, but the end goal hasn’t. Of course, I was a Zone System enjoyer when I was shooting film, so technicality is all good for me. Try to master the process so I can have full creative expression.

[Toast]

@thumper

If users are expected to have “no intuition” about a module meant to be used to do relatively basic operations on their images, perhaps it would be better to add a layer of abstraction that could be intuited.

I’d disagree that what the diffusion module is doing could count as relatively basic, the rest I agree with. If an abstraction could be found that managed the complexity without meaningfully reducing the power of the module, that would be great. Until we find that abstraction the module as it currently is is still worth including because it’s so useful.

@thumper

I do not agree with this. No matter what, users who dedicate themselves to using the module beyond just presets will build a mental model of what each control does. This mental model will be based on what effect each control has, not in understanding how the math works. Doing this proactively is not that hard.

If you can find names that match what’s going on and which don’t mask complexity, great. I was arguing that you shouldn’t force a friendly sounding but wrong name. If you have alternatives that are accurate and more human then of course we should use them. That’s pretty much the point I was making.

@thumper

I don’t see how the above is not better than the current control names. I din’t remove a single control, and none of the underlying terms were necessary to keep.

By all means suggest them as an improvement. I don’t know the details well enough to judge the examples you’ve given, but plenty here could and I support the attempt.

@thumper

What do we use to define “accurate”? Accurate as in what it does? Or how it does it? If we pick the latter, we would’nt call it “exposure”, we would call it “uniform pixel luminance adjustment” .

Diffuse or Sharpen leans heavily into “Accuracy in how it works”, instead of “Accuracy in what it does”, and the latter is really the only thing users need or want. Not all users are developers or scientists, and the module is obviously supposed to do something useful for users, so the controls should reflect the things users want to do, rather than obscure parameters used within the engine of the module.

I am not saying the module should be dumbed down. But we have the ability to abstract, and we should use it in situations like this.

That’s a very good question. My aim is to avoid oversimplifications which sow confusion. It’s easier to be told what’s actually happening under the hood and have to learn some details than to be told a pretty lie and have to waste hours reverse engineering what your software is actually doing in order to get the correct results. Commercial software is full of magic sliders which work wonders and save you hours on 9/10 images, but which have edge cases that will drive you up the wall with no indication of why.

Edit: s/petty/pretty

[Toast]

@Qor

Adams’s later Photography Series published in the early 1980s (and written with the assistance of Robert Baker) also proved more comprehensible to the average photographer.

I picked these up recently. Hopefully I’ll get time to read them before too long.

[thumper]

@Toast

@thumper

If users are expected to have “no intuition” about a module meant to be used to do relatively basic operations on their images, perhaps it would be better to add a layer of abstraction that could be intuited.

I’d disagree that what the diffusion module is doing could count as relatively basic, the rest I agree with. If an abstraction could be found that managed the complexity without meaningfully reducing the power of the module, that would be great. Until we find that abstraction the module as it currently is is still worth including because it’s so useful.

To clarify, I am using “basic operations” to refer to the common adjustments people generally perform in image editing, not operations that are trivial in their implementation.
I did not say that DorS is a basic module, but the effects it is supposed to achieve are basic in the context I am using. It is one of the most recommended modules for sharpening, which is among the fundamental adjustments done in image editing. I have also seen it suggested/used for denoising, dehaze, local contrast, etc.
These are all pretty fundamental adjustments common to many/most RAW developement softwares. In other softwares they are usually presented as single slider controls while still having great effectiveness. I am not saying that DorS should have controls removed, but claiming that no good abstraction exists is not a reasonable stance.

@Toast

Until we find that abstraction the module as it currently is is still worth including because it’s so useful.

Of course. I never said we should remove it.

@Toast

@thumper

I do not agree with this. No matter what, users who dedicate themselves to using the module beyond just presets will build a mental model of what each control does. This mental model will be based on what effect each control has, not in understanding how the math works. Doing this proactively is not that hard.

If you can find names that match what’s going on and which don’t mask complexity, great. I was arguing that you shouldn’t force a friendly sounding but wrong name. If you have alternatives that are accurate and more human then of course we should use them. That’s pretty much the point I was making.

I think the suggestions I already made are plenty accurate and only mask complexity when that complexity is unnecessary. Maybe my suggested names only give users an accurate effect description for ~80% of use cases (I think it is higher than that but whatever), but most of the current names give accurate effect descriptions for 0% of use cases. “1st order speed” does not tell a user anything, in any situation, unless they already understand the math behind the module.

The only way non-scientist users can understand the current controls is by building mental models to use as an abstraction. For example, when I see “1st order speed”, I subconsciously think something like “Sharpen<->Blur for Large Shapes”. This mental model is created and solidified through interaction with the module and observation of the effect.

I think there are enough intelligent people in this community that we could come up with good abstractions for almost any situation. Part of the problem with DorS, is that the names are way more technical than even other complex modules like AgX. So the gap feels impossible to cross to get to good abstracted control names.

@Toast

By all means suggest them as an improvement. I don’t know the details well enough to judge the examples you’ve given, but plenty here could and I support the attempt.

I should create a dedicated topic so that the conversation can be more clear, and then maybe the more technical people can help me refine it if they deem it worthy.

@Toast

@thumper

What do we use to define “accurate”? Accurate as in what it does? Or how it does it? If we pick the latter, we would’nt call it “exposure”, we would call it “uniform pixel luminance adjustment” .

Diffuse or Sharpen leans heavily into “Accuracy in how it works”, instead of “Accuracy in what it does”, and the latter is really the only thing users need or want. Not all users are developers or scientists, and the module is obviously supposed to do something useful for users, so the controls should reflect the things users want to do, rather than obscure parameters used within the engine of the module.

I am not saying the module should be dumbed down. But we have the ability to abstract, and we should use it in situations like this.

That’s a very good question. My aim is to avoid oversimplifications which sow confusion. It’s easier to be told what’s actually happening under the hood and have to learn some details than to be told a petty lie and have to waste hours reverse engineering what your software is actually doing in order to get the correct results. Commercial software is full of magic sliders which work wonders and save you hours on 9/10 images, but which have edge cases that will drive you up the wall with no indication of why.

I agree with this. As a ex-user of Lightroom, there were abstractions/obfuscations Adobe made that definitely don’t help (like not making it clear what the order of operation is). However, I was almost always able to get results I liked in Lightroom and learned the software in very little time. So there are tradeoffs. This is what makes UX design, especially in FOSS, hard. Every choice of “to abstract or not to abstract” is exposed to users, and their opinion is split much of the time.

[Qor (Chris)]

Another topic related to darktable UI work. I think we can all agree that shortcuts make using darktable much easier and, above all, faster.

However, the hurdle is always our learning process.

One solution for this is the following overview.

The advantages are obvious at a glance, but especially at the beginning, you have to keep checking what each key is for.
You can print out the list or display it on a second monitor.

But how about being able to see the shortcuts directly in darktable?

[GregDunn]

I just wanted to drop in here and offer a couple of comments. I’m really happy to see people working on refining the dt UI - especially any changes that speed up the use of the application. Because I’m reluctant to make sweeping changes myself, my CSS changes on my personal copy have been limited to improvements in UI contrast and distinguishing modules/control states. These are all very positive things to me.

I do caution against unnecessary use of color on the UI. To me, the UI and the image being edited need to remain visually distinct; and my color perception is affected by other colors being on the same screen as the image I’m working on. (Cf. the recommended grey background for the image area to prevent color biasing) I like the fact that the dt UI tends to use b/w or grey tones and uses shading or contrast to delineate the controls and modules. I have seen some truly hideous UI implementations (usually on Windows apps) which are splashed with color and varying font sizes/typefaces, making it into a visual jumble which the eye can’t quickly penetrate. dt has maintained a very visually consistent UI by adhering to monochrome with appropriate shading and I appreciate that a lot.

I’m not saying that judicious use of color is bad, but I encourage using it for vital and singular purposes and avoiding a rainbow of colors just because it’s possible. Carry on, and I eagerly anticipate checking out some of the ideas mooted here.

[thumper]

@GregDunn

I do caution against unnecessary use of color on the UI. To me, the UI and the image being edited need to remain visually distinct; and my color perception is affected by other colors being on the same screen as the image I’m working on.

After using darktable for some time, I also really appreciate the grey scale ui. Hopefully, I will have some css that I feel like is genuinely good enough to share in the near future.

[thumper]

Ok,
Life has been busy, and I got sidetracked with the DorS rework…

I wanted to go ahead and make this css available for anyone who is interested. Just copy and paste into your custom css window in the general setting page.

Main Changes

• Full Restyle on the module group buttons to make their behavior clearer (They are filter toggles, not tabs).
• Added Panel Borders to improve visual separation.
• Improved visual distinction between on/off modules without adding color.
• Restyled tabs within modules to make them more obvious tabs and improve aesthetics.
• Removed the horizontal lines underneath each control section header in favor of extra padding above section titles.
• A lot of small tweaks like improving the visual distinction between disabled and enabled actions in the history panel.

@define-color bauhaus_bg shade(@plugin_bg_color,0.75);
@define-color bauhaus_fill shade(@plugin_label_color,0.95);
@define-color modern_border_color mix(@bg_color, #000, 0.15);
@define-color inactive_toggle_bg mix(@collapsible_bg_color, @fg_color, 0.15);
@define-color active_toggle_bg mix(@collapsible_bg_color, @fg_color, 0);
@define-color inactive_toggle_color mix(@modern_border_color, #000, 0.75);
@define-color active_toggle_color mix(@fg_color, #FFF, 0.75);

#navigation-module{
  background-color: @bg_color;
  border: 1px solid @modern_border_color;
  margin: 0px;
  padding: 0px;
}

#left .dt_module_btn.dt_history_switch {
  color: @active_toggle_color; 
}

#left .dt_module_btn.dt_history_switch_off {
  color: @inactive_toggle_color; 
}

#modules-tabs{
  background-color: @bg_color;
  border: 1px solid @modern_border_color;
  margin: 0px;
  padding: 0px;
}

#modules-tabs .toggle.dt_module_btn{
  border-width: 1px;
  border-style: solid;
  border-color: @modern_border_color;
  border-radius: 12px;
  margin: 1px;
  background-color: @inactive_toggle_bg;
  color: @inactive_toggle_color;
}

#modules-tabs .toggle.dt_module_btn:checked,
#modules-tabs .toggle.dt_module_btn:active{
  background-color: @active_toggle_bg;
  color: @active_toggle_color;
  border-radius: 4px;
}

#modules-tabs .toggle.dt_module_btn:hover {
  background-color: mix(@active_toggle_bg, @inactive_toggle_bg, 0.5);
  color: mix(@fg_color, @modern_border_color, 0.5);
  border-radius: 8px;
}

#modules-tabs .search{
  background-color: @modern_border_color;
  border: none;
  padding: 4px;
  margin: 0px;
}

/* Adding border around panels */
#bottom {
  margin: 0px;
  border: 1px solid @modern_border_color;
}

#top-hinter {
  margin: 0px;
  border: 1px solid @modern_border_color;
}

#plugins_vbox_left{
  margin: 0px;
  border: 1px solid @modern_border_color;
}

#plugins_vbox_right{
  margin: 0px;
  border: 1px solid @modern_border_color;
}

#header-toolbar {
margin: 0px;
  border: 1px solid @modern_border_color;
}

#footer-toolbar {
margin: 0px;
  border: 1px solid @modern_border_color;
}

/* MODULE HEADERS*/
#module-header{
  margin: 0px;
  padding-right: 2px;
  padding-left: 2px;
  padding-top: 4px;
  padding-bottom: 4px;
  border: 1px solid @modern_border_color;
  /*border-top: 1px solid @bg_color;*/
  border-radius: 0px;
}

#module-header > button:first-child {
  border-width: 1px;
  border-style: solid;
  border-color: @modern_border_color;
  border-radius: 6px;
  color: @inactive_toggle_color;
  background-color: @inactive_toggle_bg; 
}

#module-header > button:first-child:checked {
  color: @active_toggle_color;
  background-color: @active_toggle_bg;
  border-radius: 2px;
}

#left #module-header > button:first-child ~ * {
  color: @fg_color;
}

#module-header #lib-panel-label {
  color: @fg_color;
}

#right #module-header > button:first-child ~ * {
  color: mix(@bg_color, @fg_color, 0.5);
}

#right #module-header > button:first-child:checked ~ * {
  color: @fg_color;
}

#right #module-header .toggle.dt_module_btn ~ * #iop-panel-label {
  color: mix(@bg_color, @fg_color, 0.5);
}

#right #module-header .toggle.dt_module_btn:checked ~ * #iop-panel-label {
  color: @fg_color;
}

/* MODULE CONTENT*/
#blending-wrapper .frame.dt_plugin_ui_main{
  margin: 0px;
  padding-top: 0px;
  padding-right: 4px;
  padding-left: 4px;
  padding-bottom: 8px;
}

.dt_section_label:not(#blending-box){
  color: shade(@fg_color, 0.9);
  margin-top: 12px;
  margin-bottom: 0px;
  padding: 0px;
  border-style: none;
}

#collapse-block .dt_section_label {
  margin: 0px;
  padding: 0px;
  color: @fg_color;
}

#bauhaus-slider {
  padding-top: 4px;
  padding-bottom: 4px;
  padding-left: 4px;
  padding-right: 4px;
}

#collapse-block {
  border: 1px solid @modern_border_color;
  margin: 0px;
  padding: 0px;
}


#blending-tabs tab,
#iop-tabs tab,
notebook tab {       
  border-top: 1px solid @modern_border_color;
  border-right: 1px solid @modern_border_color;
  border-left: 1px solid @modern_border_color;
  border-bottom: 1px solid @collapsible_bg_color;
  border-radius: 2px 2px 0 0;
}

#blending-tabs tab:checked,
#iop-tabs tab:checked,
notebook tab:checked {            
  border-top: none;
  border-right: 1px solid @collapsible_bg_color;
  border-left: 1px solid @collapsible_bg_color;
  border-bottom: none;
  border-radius: 2px 2px 0 0;
}

notebook tab label {
  border-bottom: none;
}

notebook header {
  margin-left: 0px;
  margin-right: 0px;
}

Please provide feedback if you are willing. Thanks!

[leonidas111]

It looks good, I like the contrast. Can’t wait to test it in a real editing session! Thanks @thumper !

[ElectricIgloo (Randy)]

@Terry

For me the big issue was identifying modules were switched on. I previously installed a theme that had green for activated modules and that meets my needs very well.

This is my biggest UI beef with darktable, if you could call it a beef. I use the darktable-icons-highcontrast theme with a bit of custom CSS to make module on/off button state clearer.

@define-color active_module_icon_fg rgb(255, 255, 255);
@define-color active_glow rgba(100,100,100, 0.30);
@define-color inactive_fg rgba(255,255,255, 0.25);

/* Default (unchecked): darker */
#right #module-header > button:first-child,
#right #basics-header-box > button:first-child {
  color: @inactive_fg;
  box-shadow: none;
}

/* Checked: brighter + glow */
#right #module-header > button:first-child:checked,
#right #basics-header-box > button:first-child:checked {
  color: @active_module_icon_fg;
  /*
     Uncomment the following if you want to add a glow to each of
     the buttons
  */
  /*
  box-shadow:
    0 0 0 1px rgba(255, 255, 255, 0.35),
    0 0 2px 3px @active_glow;
  */
}

I think this one modest change makes a huge difference in seeing at a glance which modules are on or off.

@Masterpiga

Scroll wheels are used for scrolling views. They can be used to do other things, but if in any given context a scroll wheel can scroll the view or do something else, then the default should be to scroll the view, because this is what any user without prior knowledge would assume that it will do. Note that the interface does not tell you that “scroll wheels behave differently here”, so the only way to know what the scroll wheel will do is to know it already.

I agree that the default scroll wheel behavior defies expectations. Last year, I wrote about both this and the CSS changes in an article aimed at guiding newer users through setting up the darktable interface to make it easier to use.

I don’t set it to scroll the view because I already have the muscle memory of curling my left pinky to hit Ctrl+Alt when I want to scroll the module list. I don’t think that a new user should need to develop that particular muscle memory, though.

[Pascal_Obry]

@ElectricIgloo

I use the darktable-icons-highcontrast theme with a bit of custom CSS to make module on/off button state clearer.

The on/off button contrast has already been changed in current master.

[Qor (Chris)]

If you want to go one step further to see modules on/off:

Pro Themes

If the contrast is not sufficient for you, I can adjust it for you.

[GregDunn]

This looks very much like my custom CSS for the module appearances! Great minds, as they say…

[siamak]

This is what i did with mine. Active module labels color thanks to additional css variables by @Masterpiga are also different color same as the active icon.

[Qor (Chris)]

I just noticed that there are three opacity settings. However, I could only find the setting in the Mask Manager in the manual.

[paperdigits (Mica)]

@Qor

I just noticed that there are three opacity settings. However, I could only find the setting in the Mask Manager in the manual

Top right is here: darktable user manual - blend modes

and the opacity is defined ‘per-pixel’ by a combination of the mask and global opacity parameter. An opacity of 0% outputs an image that is identical to the input image of the module.

And I assume the left and bottom right are the same mask opacity, covered here: darktable user manual - mask refinement & additional controls

Its also mentioned in the Mask Manager section, but not explained: darktable user manual - mask manager