A few n00b observations about darktable 3.4 on Mac

Since my ancient copy of Adobe Lightroom 6.0 is no longer playing nice with macOS Big Sur, and I have been impressed with the discussions I’ve seen from the darktable developers, I decided it was time to switch to darktable for real. I’m still just wading into these waters, so please, if you need to say “RTFM”, feel free.

My background: 40 years as a software developer. 35 years as an advanced amateur in photography, mostly freelance motorsports photography. I learned exposure by shooting slide film, so the transition to digital and its unforgiving clipping characteristics was not a big deal. I have read most of Dan Margulis’s books and understand how to use the principles in them. I have prepared color photos for press (and won awards from the car club community for my work) when a “big” monitor was a 17" CRT at 1024 x 768. I was a diehard Lightroom user from the first public beta until they switched to the subscription model.

First - kudos to all the developers for an astoundingly capable DAM and photo editing application. This is the first Mac app to date which lets me use both of the GPUs in my Mac Pro (trashcan).

Second - I was quite fond of using LR with a 2nd window displaying the image I was working on, full size on my 2nd monitor. I’m happy to find that I can still work that way.

Third - there is a whole lot of control here! If anything, there’s too much control (more about this later). But for sure this isn’t some “Lite” or dumbed-down app.

Fourth - the online (English) manual is a great piece of work, and does a great job of explaining the “why” of some of the pipeline modules. It is a reference manual, though, and needs a quick-start tutorial to go with it. Maybe even a “darktable for LR refugees”. I’m old enough that I prefer to read, rather than watch videos.

User interface observations, nits, and feature requests:

  • PLEASE, add a way to display the pixel values under the cursor! I lived by that with other applications for literally decades. It’s the thing I miss most when using DT. (Again… if I missed a clue about it, drop me a hint.)

  • I find the sliders difficult to use quickly and accurately with a trackpad. Double clicking the slider to activate the keyboard shortcuts causes the slider to be set somewhere before being reverted to its default setting, and that causes the image to get reprocessed and redisplayed. If a better way to activate the keyboard shortcuts for a slide already exists, please tell me! LR activated the key shortcuts for a slider when my mouse merely hovered over it. I would love to see that feature in a future release.

  • I appreciate the flexibility the “eyedropper” controls give by using a region with handles, but I find that awkward when (e.g.) setting white balance. Just let me click once on the neutral/highlight/shadow please! I would prefer a choice between a fixed-size “spot” and a user-defined region. Or just a spot.

  • Scrolling the lighttable view via the trackpad moves in larger increments than I would expect. I have gotten quite accustomed to just a two-finger swipe to scroll by part of a page in many, many Mac apps. Doing that from the top of the lighttable when hundreds of photos are on it usually puts me 2/3 of the way down the list.

  • The handle at the bottom of the filmstrip is impossible to use with the macOS Dock in auto-hide mode. I am not going to disable auto-hide; that would burn up valuable screen real estate.

  • I usually edit with highlight/shadow clipping display turned on. I find that some adjustments don’t reactivate the clipping display, and it has to be cycled off and on to reappear.

  • The sheer number of modules listed in the develop pipeline is overwhelming to this new user. The display-referred and scene-referred presets help, as does the user preset editor, but it’s still a bit overwhelming. I found that when I first set up my own workflow preset, the pipeline display didn’t update immediately to show only the modules in my preset.

  • A suggestion re workflow presets: the “Beginner” workflow still shows too many modules, and puts multiple options for doing the same thing in the pipeline. A true beginner workflow needs to be simpler. Should a beginner really have both filmic rgb and base curve modules available? Pick one or the other. Perhaps offer multiple “Beginner” presets, e.g. one for LR refugees like me. Are there online repositories for user presets?

  • I’m finding filmic rgb to be extremely powerful, but not yet intuitive for me.

  • I noticed Richardson-Lucy deconvolution was available through a Lua export script; could it be made available as a module, or an option in the sharpen module? I was quite impressed when I saw how well it worked in Raw Therapee.

I am willing to contribute a modest amount of my own coding labor into DT, but I’m afraid user interface design is not my strength. I’ve done enough UI implementation and cross-platform coding to appreciate how difficult it is to get everything working seamlessly on one platform, let alone cross-platform.

Anyway, thanks for an outstanding open source application. I look forward to being part of the DT community, and I hope a contributor to it as well.

7 Likes

Hi & welcome! Thanks for providing some valuable feedback.

For starters, as far as beginner tutorials go, can you elaborate on what you found lacking in the Basic Workflows? While it is intentionally sparse, following the instuctions there should get you a pretty good image.

Second thing I would say is… Get yourself a traditional mouse with a scroll wheel. I don’t feel like darktable is at all designed for a trackpad. It
works quite nicely with a mouse though.

Thirdly, I like written docs too, but we have some really talented video tutorial makers in the community. Don’t write them off.

Yes, many of the points have already been addressed. Once the “n00b” wears off, you will see that is the case. In terms of dev, please go to GitHub - darktable-org/darktable: darktable is an open source photography workflow application and raw developer, pick up their dev version, examine their issues, pull requests and code. That is where the real work is being done. And get to know its devs: what they interests are and what they are working on.

My impression from reading ‘editing an image: scene-referred workflow’ is that the actual ‘do this’ part is there, and sparse, as you say. However, the same page goes on to mention a bunch of other modules, many of which aren’t really relevant to a first-time user and likely to overwhelm true beginners. I don’t see that as a quick-start tutorial.

One way it could be reorganized:

  • scene-referred workflow - getting started (exposure, filmic rgb, white balance, crop/rotate) - This is what I consider a truly minimal workflow, and where I will spend 95% of my photo editing time.
  • scene-referred workflow - next steps (lens correction, color balance, denoise, sharpen, retouch)
  • scene-referred workflow - difficult images and artistic effects (overview, link to videos)
  • scene-referred workflow - advanced topics (color spaces, etc.) w/ links to learn more

I am willing to write, contribute to, and/or help edit these pages.

The display-referred workflow page looks like the kind of 10000’ (3000m?) overview I would expect on an introductory page, and doesn’t have any real ‘do this, then do this’ instructions. Fair enough, it’s a deprecated workflow.

While writing this reply, I switched to a photo I hadn’t yet touched and selected ‘workflow - beginner’. The attached image shows the default modules that came up. This is the beginner workflow? When I first started up DT 3.4, I found this a little intimidating. Screen Shot 2021-01-10 at 5.13.50 PM

The scene-referred page does not mention the ‘highlight reconstruction’ module at all. The display-referred page mentions it in passing. Yet here it is, enabled by default. Why? At the same time, the ‘exposure’ module is mentioned on both pages, but is not active by default.

So at the very least, there is a disconnect between the introductory manual pages and darktable’s ‘beginner’ defaults. I would be happy to help resolve this disconnect, with documentation and/or presets.

Another annoyance: if I set ‘module order’ to ‘3.0’ in one photo which has never been processed by DT, then switch to another which has also never been processed by DT, ‘module order’ switches to ‘legacy’. This bothers me for several reasons:

  1. If I select ‘3.0’ for one photo, I expect that setting to stick for all the other previously unprocessed photos until I tell it otherwise.

  2. I haven’t found anywhere in the GUI to choose a default module order.

  3. If I look at the darktablerc file, I see:
    plugins/darkroom/ioporder/last_preset=v3.0 (default)
    Is this the default module order switch?

  4. I suspect the reason DT thinks I want the legacy ordering is that I have been trying the various releases for years, and never went back to delete the old database. I guess that makes me a ‘legacy’ user. Is that a likely answer? I should probably delete the DB and report back. I haven’t done any serious editing yet, so the pain will be minimal.

  5. This is release 3.4. 3.2 came out a year ago, and 3.0 a year before that. Since the devs are recommending new users start with 3.0, shouldn’t it be the default?

Your suggestion I get a mouse with a scroll wheel is arrogant, frankly. I mentioned I’ve been a software engineer for 40 years. I gave up on mice for daily use 25 years ago because of RSI. I use a trackpad because it does the least damage to my wrists. You are in no position to tell me what input device to use.

It would have been sufficient to say ‘It works best with a scroll wheel mouse, trackpads aren’t really supported.’ I understand it’s free software and cross-platform, some gaps in input device support are to be expected. I’m willing to put in modest effort to help improve this, though as I said before, UI work isn’t my strength.

BTW are pen tablets supported?

As for video vs. written word, I just find I absorb information more quickly and thoroughly in text form. No disrespect meant to the video folks, it’s a personal preference. I may not be representative of the intended user base.

Please take these observations in the spirit in which I intend them. I am willing to put in some effort to help improve darktable. These are just the sharp edges and corners I’m running over as I learn the new workflow.

1 Like

Thanks. I’ve been aware of the Github repo for some years now. I have had mixed success trying to build DT from source on a Mac in the past. It’s a rather complex build process and didn’t seem well documented the last time I tried it. Something else I could work on, I guess.

You need to develop thicker skin. Feedback is fine but you need to give it freely without being offended by the response. Again, the best way to be welcomed by a community is to contribute.

That should be your priority. There are several Mac users. @Carmelo_DrRaw is one of them. He might find the time to help you if you get stuck. Once you figure it out, fill in what the documentation is missing. :wink:

@afre I don’t see where he has really taken offense? Maybe I’m reading it wrong.

(begin meta)

Ahem. Now you’re telling me what to do.

Thicker skin? I’ve been around arrogant people my entire career. (If I had a nickel for every “hot shit” dev with a broken user interface I’ve worked with, I could retire already.) I used to be even more arrogant myself, until it bit me in the ass. It still slips out now and then. In my experience, a little humility goes a long way.

I’m OK with “it’s not set up for that, it’s best if you use X”. Tell me “Get an X” and I hear “because everyone should do it our way.”

Get the distinction? The first is an honest assessment of the state of the software; it is what it is. The second is a command, and suggests the speaker isn’t interested in my needs. Even “You might want to get an X instead” is better than that; it’s a suggestion, not a command.

This is why I (try to) say “Here’s one idea” instead of “You should do it my way.” “Here’s what I observed” instead of “This product sucks, it doesn’t do what I want.” (I confess I probably let a little of the latter get through.)

That’s also why I’m saying “I found this didn’t address my needs, and I’m willing to work to make it better”.

(end meta)

Anyway… enough meta. Thanks for the link to the doc repo. I’ll go see what I can take on in the near term. And I did not mean to ruffle feathers here, but if I did, I’ll do better next time.

1 Like

Offended? Not really. Irritated? I confess I’m a bit cranky this week. Something about seeing a coup nearly succeed.

To some of your points:

  • there is a global color picker on the left side of the screen that can be used to display pixel values in RGB, Lab/Lch or HSL
  • the auto-hiding dock issue is easy to fix – use a keyboard shortcut. Hold down the ‘H’ key to get some help, and you’ll see what keystrokes you can use to hide/unhide the bottom panel.
  • your remarks about the display-referred workflow section are fair – I spent minimal time on that, exactly because it is a deprecated workflow. If someone else wants to spend time improviing that section, contributions will be welcomed.
  • the build instructions for Mac seem fine to me. They are a little complicated because they show how to build a binary then will still run on previous versions of macOS. If you only want to build for your current Mac, then it is more straightforward, and you don’t need to worry about the patching etc.
1 Like

Thank you for the hints Matt.

I haven’t tried building from source in a couple of years, so things may have improved since then.

I have Macs of a few vintages around here to test on. I think I will try to get the “simple” build done first, then graduate to the backwards-compatible build.

It was in response to your comment to @paperdigits here:

I have the opposite problem as you do. Track pads are my second worst enemy. First is the track point. My whole arm will stop working accompanied by multiple types chronic pain. Mice are a little better but I have to be selective.

If you don’t like the scroll wheel, one solution is to right click. When you do that, a cursor appears and you get to key in a value.

I believe MIDI controllers are also supported, if you have such a device.

RSI is no fun, in whatever form. I (literally) feel your pain.

My problems started before mice developed scroll wheels. The mouse itself is the problem for me.

This turned out to be the case. Starting from a clean database, I can confirm that the default module order is 3.0.

That’s fair @afre, I hadn’t read that far, my appoligies.

+1000 regarding scrolling. The same is true for the magic mouse, it is unusable in lightable view. It seems likely that it is some problem with inertial scrolling. Far above my ability to fix