Visual aid to scene and display referred workflow.

[difrkaguilar (Franklin Aguilar Matos)]

The new scene-based workflow is excellent. It is true that it requires more time to learn and that it leads to changes in the way of editing that many have ingrained for years, either in darktable or inherited from other development programs.

What would be useful for the user, in addition to the excellent help of the program and the tutorials that several users and developers have created, would be a better organization in the management of the modules belonging to each workflow.

If users want to know if a module is scene-based or display-based, they should hover the mouse pointer over the module name and then the tooltip with the information is displayed.

If a user selects blend mode on a module, they should also make sure to select scene-referred or display-referred in the list of blend modes (this is also confusing, because if in the darktable configuration window the scene-based workflow is selected as the default and this selection would transform the workflow, there would be no need to display this blend mode selection).

For a new user it is a bit confusing to know which module is scene based and which is display based as many modules are repeated in one workflow and another indistinctly.

Blue modules are scene-referred but are present in the display-referred workflow.
Magenta modules are display-referred workflow but are present in the scene-referred workflow.

Added to this is that when you go to the manage presets window… the modules tend to confuse, since for example: the display-referred workflow contains some modules that belong to the scene-referred workflow. (This can only be changed by duplicating the preset and adjusting it as desired). The same goes for the scene-referred workflow, which in turn contains modules that belong to the display-referred workflow.

It is understandable that there are modules that can be contained in one or another workflow, such as: crop, rotate and perspective, exposure, color calibration, color balance rgb, retouch and tone equalizer among others, since many modules such as: color calibration and tone equalizer are the replacement of modules that have been deprecated as the manual makes clear.

https://docs.darktable.org/usermanual/development/en/module-reference/processing-modules/tone-equalizer/

tone equalizer

Dodge and burn while preserving local contrast.

When used together with filmic rgb, this module replaces the need for other tone-mapping modules such as the base curve, shadows and highlights, tone curve and zone system (deprecated) modules. It works in linear RGB space and uses a user-defined mask to guide the dodging and burning adjustments, helping to preserve local contrast within the image.

But in that case it would be better if the user has some kind of visual aid to know to which workflow each module belongs. (e.g. with some color). Maybe this option could be enabled or not in the darkroom tab in the darktable configuration window and so it would not be annoying for advanced users who know the program better.

This is just an idea, I know many of you have better ideas on ways to organize workflows in a way that is more user friendly. So, other ideas are welcome.

[MStraeten (MartinSt)]

please define your criteria for being ‚user friendly‘

Comparing darktable to a whole bunch of other professional, not just consumer oriented software (enterprise software, engineering tools, …) it’s extraordinary user friendly. At least with the new shortcut capabilities.

In my opinion a user usually doesn’t need pay too much attention if a module is display or scene referred if they use the modules that gives them the expected result. If that’s a display referred module even within a scene referred setup - it’s fine.

Raw processing is about getting the expected results, not in getting an award for most consistent use of scene or display referred tools

[rvietor]

There are preset module selections for the different workflows. So if you select a display-referred workflow, expect display-referred modules and vice-versa. I’d expect any exceptions to be there for a good reason and at a position in the pixelpipe where they won’t cause problems in normal use.

That already removes for me any need to visually mark the display-referred modules (and cluttering the interface).

And as @MStraeten pointed out, usually there’s no need to know if a module is scene- or display-referred.

You can of course make your own module layout. If someone does that, it’s up to them to ensure the combination of modules they use makes sense, and they know how and when to use them.
You can also modify the pipeline order. Again, if you do that, it’s up to you to be sure the order makes sense (hint: manual).
In both of these, I still see no need to clutter the interface for everyone else.

Note: Something similar (or identical?) was proposed already…

[difrkaguilar (Franklin Aguilar Matos)]

@MStraeten

please define your criteria for being ‚user friendly‘

Any visual aid is always good to learn which module belongs to which workflow and thus achieve a better understanding of the application as well as a better handling of the application.

@MStraeten

Comparing darktable to a whole bunch of other professional, not just consumer oriented software (enterprise software, engineering tools, …) it’s extraordinary user friendly.

I am not comparing the program to any other professional application or not. I particularly love the program and all that can be done with it, every day I find new ways to reach good results. This new scene based workflow helps me to better understand all that can be achieved from a RAW image and the presets are valuable especially for working with batches of images. But that’s not to say that the program is “extraordinarily user friendly.”

@MStraeten

At least with the new shortcut capabilities.

The shortcuts have come a long way especially in these latest versions, but the window to assign them is not intuitive at all. (But that’s another topic).

@MStraeten

In my opinion a user usually doesn’t need pay too much attention if a module is display or scene referred if they use the modules that gives them the expected result. If that’s a display referred module even within a scene referred setup - it’s fine.

Here’s part of the problem, first time users, if they watch the tutorials, which tell them to select the scene-based workflow in the configuration window and then see that the modules are intertwined with each other, a question that comes to their mind is: So why define between one workflow or the other if in the end you use one or the other interchangeably?

Of course, for a user who has been using darktable for a long time, this is not contradictory at all.

@MStraeten

Raw processing is about getting the expected results, not in getting an award for most consistent use of scene or display referred tools

… ah, right… then that creates even more confusion in the users, why spend so much effort in learning a workflow if it is scene or display (it is worthless everything that many have explained about the advantages and disadvantages of using one workflow or another) what matters is how the final image will look like… No?

[rvietor]

@difrkaguilar

Here’s part of the problem, first time users, if they watch the tutorials, which tell them to select the scene-based workflow in the configuration window and then see that the modules are intertwined with each other, a question that comes to their mind is: So why define between one workflow or the other if in the end you use one or the other interchangeably?

Where in the scene-referred workflow do you see “that the modules are intertwined with each other”, when using the (predefined) ‘scene-referred workflow’ module layout? Sure, there are display-referred modules in there. But they have specific uses, and are placed after filmic (with one or two exceptions).

@difrkaguilar

… ah, right… then that creates even more confusion in the users, why spend so much effort in learning a workflow if it is scene or display (it is worthless everything that many have explained about the advantages and disadvantages of using one workflow or another) what matters is how the final image will look like… No?

While raw processing is about getting the expected results, that does not mean that you use the available tools in a random way. Within a given workflow you have a set of tools that (are supposed to) work well together, and a different approach to editing.

Using a (display-referred) tone curve tool means that you introduce hard clipping. Not a problem in a display-referred workflow (where any module can clip, so you better control your dynamic range as soon as possible).
Very bad in a scene-referred workflow, where any clipping is supposed to occur only at the transition to display-referred (which you need to, well, display the image), i.e. as late as possible. So instead of a tone curve tool, we use ‘tone equaliser’ (it’s not quite as simple as that, but it will do).

But if in a given situation a display-referred tool makes more sense, you’ll use it even in a scene-referred workflow (and vice versa).

Then again, you can’t expect a new user to learn all the different modules from the start, so you offer them a selection of tools that handle the more common situations. With the current paradigm shift within darktable, that leads to several predefined workflows, each with a limited selection of tools.

Once users get to the point that those tools aren’t sufficient, they can look for a better tool for the job. By then, they also should be able to look up what the potential pitfalls are.

[Leniwiec (Michał)]

I agree - most of the time I get excellent (because desired) results just by using my basecurve but in v3.0 pipeline order.

I’ve set my default workflow to “None” in preferences, I’ve got my set of favourite modules and I’m extremely satisfied with the output images with almost none effort

[herbert-50]

This “user-friendly” would confuse me more than it would help me.

The first difficulty for a new user is not to recognize which modules are scene or display referred, but to understand what the pixelpipe means and how these two workflows differ.

I think there really isn’t a pure scene-referred workflow or a pure display-referred workflow. Both are mixed forms that use scene-referred modules as well as display-referred modules.
For example, the exposure module is scene-referred in both workflows.

The turning point is the filmic RGB module or the basecurve module.
Everything before that is scene-referred and everything after that is display-referred.

I know this isn’t 100% true, but it gives me a good guide.

And the pixelpipe arranges the modules in the right order.

Of course, you can also move the modules, but that’s not recommended if you don’t know what you’re doing. So it is no standard procedure and nothing for beginners.

So I can use the modules I need and feel good about and do not have to care about they are scene-referred or display-referred. Every workflow has a scene-referred and a display-referred part, and the modules are correctly sorted into the pixelpipe.

I understood the default settings for the module layout as suggestions/basis for my own module palette.
The tone equalizer, color balance RGB and color calibration modules are not part of the classic display-referred workflow. That’s correct. But they can be used and they work.