I’d like to use a pen to paint brightness and darkness into my images.
I know I can create an Exposure instance with a positive exposure change, and apply a drawn mask, but this workflow is a bit cumbersome, and not particularly painterly.
I can also export to the Gimp or Krita, but I’d like to stay within Darktable if possible.
Is there a good way of dodging and burning in Darktable that I’m missing?
Unfortunately not. You can Ctrl+click on the brush mask to draw multiple strokes (without having to go back and repeatedly reselect the tool) and keep the opacity fairly low but I agree it’s not the best workflow.
That’s not what I want. As I said, I want to paint light and darkness, not a parametric control like the tone equalizer.
The tone EQ is great for raising shadows and lowering highlights, but it is not built for accentuating details, or highlighting important parts of the image. The latter is what I want, much like the dodge and burn layer in Photoshop.
That will certainly help a bit. Thank you!
I think you are better off using a different program for that kind of work, as darktable just isn’t designed for it.
The advantage of doing it in darktable is that you can do the dodging and burning in the linear part of the pipeline. Currently Krita is the closest thing to a useable alternative for this but I’m not sure (based on @anon41087856’s investigations) whether it’s quite up to the job.
I experimented a bit with Darktable, and noticed it got very slow if I added too many (say, a dozen or so) dodge strokes. You can kind of work around this a bit by adding Exposure modules to the very end of the pipeline (makes them draw faster) and adding a new Exposure module every few strokes.
But honestly, that’s not a workable solution for complex edits. Exporting to the Gimp works well, though, so that’s what I’m doing at the moment.
This is not perhaps what you are looking for, but you can set darktable to translate the pen pressure into mask opacity. The harder you press, the less opacity… See the settings. Then for many modules if you ctrl-click (I think) on the pen tool, the tool stays active. I e you can continue to draw.
Otherwise, darktable’s UI is optimised for a workflow where one hand is on the mouse, and the other on the keyboard.
Thank you! Although I had discovered that already, it is very useful indeed!
(It seems that Darktable sometimes adds some super-giant radii, though, which I then have to clean up afterwards. Probably a bug.)
Krita appears to be a single-threaded and non-vectorized app, plus it relies on Qt C++ slang deep inside, it seems they get away with it because painters use at most 4K resolution mattes, but it’s really a pain for 16 to 52 Mpx files × couples of layers. It’s just way too slow and the pixel processing got butchered with techs suited for a word processor, not a realtime imaging app.
I seriously doubt it is single threaded, although it is probably not optimized for high thread counts.
I also doubt that using QT/C++ is the problem. The architecture was probably not designed for higher pixel counts.
I put Krita down on its knees by painting blur on a 36 Mpx layer with a Xeon. It hanged on for 10 minutes at 15-18% CPU with no response. Internal code shows use of QVec (Qt) for pixel storage. No trace of SSE headers, vectors or intrinsics, no OpenMP, no BLAS, no nothing.
It is not designed for pixels at all. There is no excuse. Pixels = 4×1 vectors, something that Intel Pentium knew how to handle efficiently with 32 bits accuracy back in 2004. If you don’t plan on doing SSE, might as well code in Python and save the trouble to compile.
Which proves nothing. I get that the software has a problem which you showed with your test, but you are doing diagnostics with almost no information. A quick search on their wiki suggest that they use GitHub - VcDevel/Vc: SIMD Vector Classes for C++
Reading through the interleaved C++ classes and high-level interfaces up to the pixel code is information. I don’t care about outdated wiki.
LOL. Calling an high-level lib is not the only requirement to enable SIMD, if the compiler can’t make sense out of your data structure, alignment and dependency graph, developer’s mistakes won’t magically be solved. That blurring thing uses several levels of methods nesting with internal branching at each level. It’s a treasure hunt to find the original pixel loop, which is actually a generic pixel iterator method in a worker class, so forget about optimizations based on data layout and access within the loop. That kind of stuff should be inlined in the convolution code for proper unrolling, not called from a generic API.
I use regularly Gimp2.10.20 with 100px 32bits images, with more than 10 layers without lags, freezes, or crash, on a Ryzen7 & 9
If Darktable had a Raster brush for masking with some edge detection like Lightroom has, most of our problems would be solved.
I use brush a lot in Lightroom, it just enables you to do your edits locally and focus on details. Darktable on the other hand focuses on global editing.
You can do some things with parametric masking but that often takes 2h to adjust the mask.
I often wish that I could just paint a mask in Darktable instead of fiddling with parameters and vectors.
Gimp doesn’t do scene-referred painting, which is mandatory if you want feathered brushes with blended strokes and proper alpha blending. Also its workflow is made for hobbyists with too much spare time. It’s an End-Of-Life project as far as I’m concerned, too much legacy and hard-coded assumptions to make it evolve properly to modern design.