what's so hard about darktable

Software darktable
43

I think I need to explain my pov/need more. I don’t really like trying to get a perfect white balance most of the time. There are two reasons for this:

  1. because I am usually editing whole sets of photos and don’t want to get too consumed with making everything perfect. I already obsess about enough things.
  2. I like approaching digital photo editing similar to how film stocks are used. I design styles or module presets that I can pick through to get the desired look quickly. For this process I also generally like using a static white balance (like 5600k for a standard daylight), to further optimize how fast I can edit.

TLDR: usually, I am not trying to get correct white balance, but a quick “standard white balance” in relation to the generally accepted standards throughout the history of analog photography.

44

Darn… That doesn’t help things :sweat_smile:

45

If you set a fixed temp in your camera, I believe darktable and CC will give the same look if you don’t change anything. I can only see this being an issue with a RAWs from other people?

I have my X-T3 set to a fixed WB (Daylight) and all my shots have:

image
image588×642 32.7 KB

46

There are also a few other issues, esp with the scene referred pipeline where the data passes through stages of dynamic range and colorspace transitions.

The early pipe is raw sensor data, linear unbounded highdynamic range. Then in the middle its demosaiced, color calibrated linear rgb. The later stages are tone mapped and compressed to non-linear display data.

Applying a single mask across modules that bridge the transition from linear HDR data to compressed display space could lead to severe blending artifacts and non-physical color shifts. Maybe with other software that starts out in display space things are easier to manage that way or maybe some don’t even have a fixed processing order??

As already noted, parametric masks calculate pixel inclusion using specific channels (luminance, chromaticity, hue). A parametric mask evaluated at the beginning of a mask container would lose mathematical validity if modules “inside” that container alter the color space, saturation, or tonal distribution.

The same for anything geometric that alters pixel coordinates, aspect ratio, and image dimensions at specific points in the pipeline.

In short, darktable could be described I think as a parametric RAW converter built on a linear buffer pipeline, whereas a “mask-first” workflow would require a node or layer-based compositing engine with branching sub-pipelines.

Currently each DT module receives an incoming pixel buffer, applies its operation, evaluates its own internal mask, blends the output, and hands the modified buffer to the next module.

Mask containers would break this, I think if you want multiple modules inside a mask group this requires splitting the image stream into two branches.

Loosely you would need an unmodified baseline branch and a sub-pipeline branch that executes the grouped modules in sequence, and finally a compositing step at the end of the group that blends branch 1 and branch 2 using the mask. And I guess a means to manage multiple masks.

Branching pipelines with nested mask groups would break the pipe cache model. Tracking sub-tile ROIs across parallel branches, intermediate mask compositing buffers, and GPU OpenCL memory allocations would dramatically decrease processing speeds and increase memory consumption.

In any case I feel like its not just a simple act of reorganization and some modifications to get that model to work, I don’t think, and the modules themselves are designed around the existing pipeline model…

This would be a whole other project and vkdt is one such project making that sort of leap with technical tools “like” or in the spirit of darktable but used in a completely different operational framework to allow for nodes and parallel processing…

But I am also not a programmer so things I see as limitations or operational issues might not be. For context DT could use branching for output to branch output and display but that has been a bridge too far up until now so this seems next level… :slight_smile:

4 Likes
47

Yeah, I already do this usually, but it would be nice to just be able to work in kelvin without the weird cct difference. I’m not saying that the maths behind CC are weird, but just that it seems unnecessary to not have an abstraction layer.

1 Like
48

This is a helpful reference I think anyway…

It explains the concept and shows the isobars… and why trying to match CCT to wb numbers is probable not useful…

The distance from the curve on an isobar is where the invalid error in DT comes from…when you move away from the curve along the isobar the value has less and less meaning so past the coded threshold you get invalid…

3 Likes
49

Well if you want to know why no abstraction you need look no further than the module author’s view of handling wb through the lense of the scene illuminant and his design choices…

Rationale found in this section…

image
image850×661 65.2 KB

1 Like
51

Yes, ok. I think I moved the goal posts. :blush:

52

At the present moment, does the module automatically and correctly guess which part of the tonal range you want to modify? I don’t think so. And if the whole tonal range was covered, wouldn’t be simpler to have (say) a couple of sliders to zoom in the area you actually want to modify?

53

It’s true about everything, though, right?

1 Like
55

Who said that it’s broken, nobody said that it is broken. Other modules are being improved all the time, without being broken.
So the principle doesn’t apply.

Plus, it’s a raw editor, not a software which can potentially bring down thousands of flights at Heathrow.

So if it works quite well (that is “for you”) and this proposal wouldn’t change that, where is the problem?

56

Yeah, I’ve read that. In my opinion this is a case of one person’s sensibilities guiding the UX more than they should.

While I agree that the math behind it is more correct, I think it would be smart to make the UI more like the utterly ubiquitous standard setup of White Balance controls

1 Like
57

But if the “ubiquitous standard” is not that great, why should we perpetuate it? Just because it’s everywhere?

2 Likes
59

Because it’s easier to adjust? It makes a lot of intuitive sense and looks great most of the time.

60

Again, I didn’t say that and nobody said that you should shut up.

But if someone proposes an improvement, an objection of the kind: “this wouldn’t improve my workflow, but not even ruin it, so I oppose it” sounds a bit tone-deaf, as if the opposition was for the sake of it.

61

I would say this discussion always goes this way…and it seems funny to me that we have two options that should suffice. One that works the traditional way that many people seem to like and want and it is available in a traditional wb module.

And an alternate approach using instead of a scalar wb method, is to use a CAT and apply the perceptual math correction to deal with the scene neutral/color mapping to the display.

If you go this route then buy in to using the scene illuminant and doing a perceptual correction using one of the established CAT methods… If you don’t then you just don’t use it??

As I understand it working with temperature sliders in Kelvin (K) does not make physical or mathematical sense for a module performing a Chromatic Adaptation Transform (CAT) because Kelvin is a rigid, one-dimensional representation of light, whereas a CAT operates on full two-dimensional chromaticity coordinates within a specialized human-cone or colorimetric space.

When a color processing module (such as darktable’s color calibration or DaVinci Resolve’s chromatic adaptation OFX) utilizes a CAT like Bradford, CAT02, or CAT16, it discards traditional sensor-level Kelvin assumptions for several key reasons:

  1. CAT operates on exact coordinates, not curves

Kelvin values are tethered strictly to the blackbody radiation curve or daylight models.

Real lighting frequently falls far off this axis (e.g., green fluorescent or purple LED lights) so real world deviations can benefit from the CAT approach.

A CAT scales color channels using the exact ratio between a source white point and a destination white point. It requires absolute coordinates, like (XYZ) or (LMS), making a 1D Kelvin value mathematically insufficient.

  1. The data is generally already normalized

In modern scene-referred pipelines, raw sensor data is usually normalized to a reference white point (like D65) before reaching the CAT module.

Applying a raw Kelvin slider to an already-transformed image space results in values that no longer correspond to the physical light source temperature.

  1. Non-linear relationship to channel gains

You can have issues with unequal spacing where, a change of 500K at a low temperature (e.g., 2500K to 3000K) causes a massive visual color shift, while the same 500K change at a high temperature (e.g., 8000K to 8500K) is barely noticeable.

Chromatic adaptation transforms depend on linear matrix operations. Mapping a highly non-linear scale like Kelvin directly to a linear CAT matrix forces the software to use complex, inaccurate lookup tables rather than clean color science.

So , instead of Kelvin, modern CAT modules are best paired with perceptual hue and chroma sliders or absolute (xy) chromaticity pickers, allowing you to sample and adjust the true color of the scene illuminant regardless of whether it fits a theoretical temperature curve.

My take (n=1 as always) is you buy in and use the module as intended because you believe your photo has an issue that would benefit and or is better served by the CAT approach…( I think @kofa is working on smoothing out a couple of the rough edges) or you stick to what you know and use traditional wb, often technically but I think maybe even more often for many to artistically warm or cool photos…

5 Likes
62

it seems you’re expecting a kind of lightroom as so many who wants to get the fast and easy path to save money.

darktable has all of these modules for a reason - if you need an explanation of the why you need to read a lot of documentation regarding color science, image editing and of course the manual.

darktable target user group aren’t those quite satisfied with a one size fits it all approach - which ist a valid habit and there are plenty of free tools adressing that user group.
darktable is focused on those enthusiasts who needs or want a little bit more, preferring the better tool over the good one.

So you might request simplification - but up to now no one spent the effort to fork an provide that simpler lightroom killer :wink:

4 Likes
63

drove me nuts until i decided that i start every interaction with the module (and also actually finish quite a few of them) by right-clicking the module header and picking either increase or compress contrast preset - that seems to automatically apply the right mask.

64

I honestly feel like it’s slightly derailing from the topic, I think that the title isn’t ideal and brings a lot more controversy than it should.

My goal was only how I think that darktable has a lot of room to grow and a lot of people making their own editors proves that I’m not alone. I listed the reason why for me.

I don’t want darktable to be a lightroom replacement. I would like it to consider features that I think might be able to improve a workflow and I think some others probably agree or disagree which is a good thing

I think that providing the best possible UX for everyone is ideal which most likely diverges from my ideas.

65

I’m not saying we should change the underlying tech in CC module, but wrap it with an abstraction that makes certain things easier (like manually inputting a “kelvin” temp that is actually similar to the kelvin temp shown in any other raw development software).