My main point is not that modules need to somehow have impregnable guard rails that prevent you screwing up your image. It’s that I feel more confident that I “know what I’m doing” (without having any understanding of the underlying math) if I have some idea of what a module’s purpose is within the context of the workflow/pipeline. Exposure is where I go to change, er… exposure, color calibration is where I go to alter white balance and flail around with the channel mixer, color balance rgb is mostly colour grading, etc.
Neither am I saying there should be only one way to achieve some effect but rather it would be ideal if there was a straightforward pathway for non-tinkerers to get what they want done and feel confident that what they’re doing makes sense.
It’s like in a car, you have the brake and you have a handbrake. They will both probably stop the car one way or another but it’s also quite clear to the driver in which circumstances they should be used for best effect.
anything outside the 0…1 range will be clipped on display or export to e.g. jpeg (as those media just can’t handle values outside 0…1)
“display-referred” modules expect their input to be in that 0…1 range, and may or may not deal badly with values outside that range; e.g. a tone-curve is not defined outside 0…1 input, so the module can clip, or extrapolate, or…
Then there’s an issue with the colour spaces used (check Aurélien Pierre’s article about Lab with the examples he shows).
Finally, let’s not forget that for years images were only edited in display-referred workflows, and that it worked!
True but also because there’s not a third brake that’s somehow integrated into the controls for the windshield wipers and another that depends on what radio station you’re tuned into.
Personally, I’ve never really understood the concept of scene-refered or display-refered workflow. Having no knowledge of the underlying mathematics, I rely more on my eyes and my feeling. For me, one doesn’t preclude the other, I simply use the linear modules before Sigmoid and then the “display” modules .
To return to the subject of the post, I really like the current “Color Zones” module, which I combine with the “Color Balance RGB” and “color look up table”.
Greetings from Brussels,
Christian
No math needed. In scene referred most of the modules are working on the linear image (from the scene) before the filmic or sigmoid module apply the curve to “map” the image to the actual display (your screen, the printer).
Working in linear space does get better results as the algorithms are not handling pixels in area that have already been “compressed”. The S curve do compress the shadows & highlights (more pixels are mapped to less space). Hope this is clear
Such far-fetched analogies are usually broken.
Even in a car, controls may interact. If you step on the brake (or on the accelerator) and try to abruptly change the direction at the same time, you may exceed the friction the tyres can provide, even though separately they would not have caused you to lose the grip.
That is perfectly fine.
The original display-referred workflow had the following legacy module order:
Note that base curve comes rather early, and is applied in the camera’s colour space (it’s before input color profile). That makes its affect dependent on the camera’s colour space. Also note that sharpen comes after base curve, so its input will not be linear light, but a tone-compressed version.
Simply by changing the module order to v3.0 RAW, the base curve module gets moved to the end, just before output color profile. This means that sharpen can now work on linear light, and the base curve itself is applied in the working space (Rec2020) – so the same curve will provide the same result for all cameras.
I was going to say that I think the legacy one would be the standard definition of display referred and now DT sort of has a hybrid with the change to the basecurve location…
I get your point. But… I sometimes use the handbrake for steering too…
(sorry, couldn’t resist adding that)
Edit: And going even further off topic, I hate the way more and more modern cars come with an electronic push-button parking brake instead of a real handbrake. Completely destroys the utility of a brake that works on only the rear wheels.
I guess this kind of thing is why I like darktable - lets you control whatever you want regardless if the makers thought you wanted to or not!
Thanks for your reply, it’s an excellent summary that explains it all in a few words ;-).
I just wanted to say that I didn’t understand the concept from a marketing and communication point of view.
I propose to gather my ideas and submit them to you for discussion in a new post so as not to pollute this one.
You’re right, the order of the modules has been very well improved, and I rarely change it except for my black and white (monochrome) treatments.
I wonder if the next step isn’t to take the best of both worlds. I currently have the “auto apply pixel workflow defaults” set to none.
Thank you for the information, I’ve read this article and watched all Aurélien’s videos, in my opinion, they are very (too) technical and photography like any other art remains very subjective For example, he advises against the velvia module and I use it in my basic workflow (style) ?
It’s clear and it’s a very good explanation to why a color equalizer that is placed earlier in the pipeline is preferred.
I did play more with color zones yesterday and I was reminded of why I don’t use it (more). The s-curve applied by sigmoid before color zones gives me minimal headroom for changes without things starting to look crap.
Brightness adjustments (by hue) is of course extremely sensitive. sigmoid darkens shadows by a lot. Increasing brightness in hues that are present in shadow areas will try to lighten them again. It’s rather self explanatory why first making them considerably darker (with sigmoid) and then making them lighter again (with color zones) is a bad idea.
This was an attempt at trying to explain things as simple and easy as @Pascal_Obry did.
I think that the need for a module of this kind is understood, it is just that the discussion in #12082 went in the direction of overgeneralizing this module, which would in fact have made it redundant (as suggested, if you need super-flexible fine control then you are better of with color calibration/color balance rgb and a mask).
It would be great to see it revived. @flannelhead kept improving on it for a while.
The potential of a tool like the color equalizer lies beyond local hue shifts. I always shift a range of colors by hue. This is to create a shared boundary (or “look”) between a series of images. I use the LUT 3D module for this now, but making adjustments of the look would mean firing up something to edit the LUT (like 3D LUT Creator) and exporting a new LUT for use in darktable. Not really feasible.
I think the color equalizer (or a similar conecpt) would be an excellent companion for powerful grading that the very limited “4 ways” tab of the colors balance rgb module does not offer. Without tedious parametric masks (in multiple instances) color balance rgb selects ranges by luminosity. What we need for grading, creating looks or better simulations of film is a hue-centric tool.
I was looking forward to a scene-referred version of colour zones, but I could be persuaded by this argument above by @flannelhead. Maybe that module just needs a little TLC to avoid the blotching that some people are complaining about. I personally don’t have many problems with it other than it can be hard to get a precise hue because of its interface. And having 3 separate tabs is not always as user-friendly as other approaches.
I also see the argument for a more “familiar” colour adjustment module (e.g. the classic HSL sliders found in most other image editors) at some point in the pipeline. If I’m not mistaken, color lookup table is based on LAB, and I’m wondering how difficult it could be to convert this to RGB, which would make it more like HSL adjustments found in other editors. Instead of the green-magenta and blue-yellow offsets, it could just have a single hue slider. In my opinion, the rest of the interface works really well. You can either select a colour swatch or replace one from a sample in your image. Then there are the HSL sliders all below without the need to switch tabs.
Would an RGB version of colour lookup table be feasible and fulfill what colour EQ was going to do?
And then colour zones can remain a display-referred option for later in the pipeline…
Darktable isn’t a commercial product, so it doesn’t need a marketing strategy, which could be a hindrance to development. On the other hand, a bridge between developers and users could help develop communication and website content. I’m willing to give my free time to the Darktable project, but my English is more than perfectible (thanks Deepl), I’m French-speaking and my second language is Dutch.
This forum is already a good communication channel.
Greetings from Brussels,
Christian
.
