Project

General

Profile

Feature #12518

Module group: "only enabled in history stack"

Added by David Schaefer 3 months ago. Updated 3 months ago.

Status:
Incomplete
Priority:
Low
Assignee:
-
Category:
Darkroom
Target version:
-
Start date:
12/31/2018
Due date:
% Done:

20%

Affected Version:
git master branch
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Hi,

it would be nice to be able to hide some modules that are always on. Users may not want to change their default values anyhow. Displaying the modules anyhow removes valuable space and adds unnecessary complexity.

Cheers

History

#1 Updated by David Schaefer 3 months ago

The modules are:
  • raw black/white point
  • demosaic
  • input color profile
  • output color profile

#2 Updated by Roman Lebedev 3 months ago

  • Status changed from New to Closed: invalid

You already can control the modules you want/don't want to see via https://www.darktable.org/usermanual/en/more_modules.html

#3 Updated by David Schaefer 3 months ago

No, sorry, you cannot:

You can not control the above four mentioned modules from appearing in the active modules section. They always appear there because currently all active modules (modules that are in the pixelpipe) are shown in the active modules tab. This definitively makes sense from a technical point of view but please consider users that do not adjust those four modules:

For these users the active modules tab is not a technical list of all used modules but a list of all changed modules. So in this usecase the user is using the show all active modules tab to understand which modules he has changed. Displaying all turned on modules distracts the user from his list of actions and feels more complicated.

Kind regards
Dave

#4 Updated by Roman Lebedev 3 months ago

David Schaefer wrote:

No, sorry, you cannot:

You can not control the above four mentioned modules from appearing in the active modules section.

Ah, "active modules".

They always appear there because currently all active modules (modules that are in the pixelpipe) are shown in the active modules tab. This definitively makes sense from a technical point of view

Having some magical, untouchable, on-by-default, modules is not good.
Thankfully dt avoided that so far, i really hope that never ever changes.

but please consider users that do not adjust those four modules:
For these users the active modules tab is not a technical list of all used modules but a list of all changed modules. So in this usecase the user is using the show all active modules tab to understand which modules he has changed. Displaying all turned on modules distracts the user from his list of actions and feels more complicated.

Kind regards
Dave

#5 Updated by Roman Lebedev 3 months ago

Roman Lebedev wrote:

David Schaefer wrote:

No, sorry, you cannot:

You can not control the above four mentioned modules from appearing in the active modules section.

Ah, "active modules".

They always appear there because currently all active modules (modules that are in the pixelpipe) are shown in the active modules tab. This definitively makes sense from a technical point of view

Having some magical, untouchable, on-by-default, modules is not good.
Thankfully dt avoided that so far, i really hope that never ever changes.

but please consider users that do not adjust those four modules:
For these users the active modules tab is not a technical list of all used modules but a list of all changed modules. So in this usecase the user is using the show all active modules tab to understand which modules he has changed. Displaying all turned on modules distracts the user from his list of actions and feels more complicated.

And FWIW https://www.darktable.org/usermanual/en/module_groups.html
"Active Modules you have activated and are using on the current image."
these modules are activated, and are being used on the current image.
So i really don't see why they shouldn't be shown.

I'm not sure how you'd formulate the criteria as to why those modules should not be shown.
"where module params are different from what the default params would be, should you reset history stack"

Kind regards
Dave

#6 Updated by David Schaefer 3 months ago

Having some magical, untouchable, on-by-default, modules is not good.
Thankfully dt avoided that so far, i really hope that never ever changes.

I agree from a technical point of view and to keep the power of choice at the user. This is one of the reasons people love darktable. I dont agree from a usability point of view. Here the user should have the choice of what he wants to see. Does he want to see all actions performed on the raw image or does he care about the changes he did (see below). I find myself most of the time looking for the usability improving simplicity (this feature request) than the expert knows and controls everything (the current state).

And FWIW https://www.darktable.org/usermanual/en/module_groups.html
"Active Modules you have activated and are using on the current image."

Thanks for finding this, as it makes my request very clear:
When I
1) open a raw image and
2) clear the history and
3) compress the history stack and
4) go to the basic group (or any other)
5) go to the active group

then I expect to see nothing, because as the documentation states only modules should be there that "you have activated and are using on the current image". However, I turned off all modules. So I expect nothing to be there. Instead of an empty active modules list I see

  • output color profile (1)
  • input color profile (1)
  • orientation (2)
  • demosaic (1)
  • highlight recon (2)
  • white balance (2)
  • raw black/white point (1)

These modules are applied to the image. Some of them can be turned off like most of the other modules (they have a 2 in the list above), some of them cannot be turned off (they have a 1 in the list above).

As a user I expect to be able to clear the list.
As a technical expert I know raw processing does not make sense without modules like demosaic.
Anyhow I see this as an inconsistency if darktable forces the user to use some modules and doesnt allow them to be turned off. This inconsistency makes it harder to understand darktable.

(As a user and as a technical expert I may wonder why the modules marked with 2 in the list above appear, but I guess this is a different issue than the one we want to talk about here.)

I'm not sure how you'd formulate the criteria as to why those modules should not be shown.

As shown above it is pretty easy: I expect no module to be shown if I have nothing in the history. I also expect all the modules to be shown that are in the history.

To say it with different words: I am requesting a feature (boolean) that changes the active group to only show active modules from the history. An average user (like me) is not able to benefit from changing the raw black/white point, would change the output color profile on the export module, would very rarely change the demosaicing method and so on.

#7 Updated by Roman Lebedev 3 months ago

  • Subject changed from Hide standard modules to Module group: "only enabled in history stack"
  • Status changed from Closed: invalid to Incomplete
  • % Done changed from 0 to 20

David Schaefer wrote:

Having some magical, untouchable, on-by-default, modules is not good.
Thankfully dt avoided that so far, i really hope that never ever changes.

I agree from a technical point of view and to keep the power of choice at the user. This is one of the reasons people love darktable. I dont agree from a usability point of view. Here the user should have the choice of what he wants to see. Does he want to see all actions performed on the raw image or does he care about the changes he did (see below). I find myself most of the time looking for the usability improving simplicity (this feature request) than the expert knows and controls everything (the current state).

And FWIW https://www.darktable.org/usermanual/en/module_groups.html
"Active Modules you have activated and are using on the current image."

Thanks for finding this, as it makes my request very clear:
When I
1) open a raw image and
2) clear the history and
3) compress the history stack and
4) go to the basic group (or any other)
5) go to the active group

then I expect to see nothing, because as the documentation states only modules should be there that "you have activated and are using on the current image". However, I turned off all modules. So I expect nothing to be there. Instead of an empty active modules list I see

There is an issue. History stack is NOT what the actual processing pipeline will do,
and likewise, the module order in the history stack is NOT the actual order in which modules will be applied.
So if something is not in the history stack, it does not equal to that module not being activated.

  • output color profile (1)
  • input color profile (1)
  • orientation (2)
  • demosaic (1)
  • highlight recon (2)
  • white balance (2)
  • raw black/white point (1)

These modules are applied to the image. Some of them can be turned off like most of the other modules (they have a 2 in the list above), some of them cannot be turned off (they have a 1 in the list above).

As a user I expect to be able to clear the list.
As a technical expert I know raw processing does not make sense without modules like demosaic.
Anyhow I see this as an inconsistency if darktable forces the user to use some modules and doesnt allow them to be turned off. This inconsistency makes it harder to understand darktable.

Have you looked through the usermanual? Did it answer these questions? Perhaps this can be solved by simply extending the docs.

(As a user and as a technical expert I may wonder why the modules marked with 2 in the list above appear, but I guess this is a different issue than the one we want to talk about here.)

Well, why wouldn't they? You will likely want to manually tune the white balance,
may want to re-adjust the image orientation e.g. in case the camera failed to set the correct tag,
and WILL most likely want to change the highlight recovery method from the default.

I'm not sure how you'd formulate the criteria as to why those modules should not be shown.

As shown above it is pretty easy: I expect no module to be shown if I have nothing in the history. I also expect all the modules to be shown that are in the history.

To say it with different words: I am requesting a feature (boolean) that changes the active group to only show active modules from the history. An average user (like me) is not able to benefit from changing the raw black/white point, would change the output color profile on the export module, would very rarely change the demosaicing method and so on.

#8 Updated by David Schaefer 3 months ago

There is an issue. History stack is NOT what the actual processing pipeline will do,
and likewise, the module order in the history stack is NOT the actual order in which modules will be applied.
So if something is not in the history stack, it does not equal to that module not being activated.

I know that the history and the actual processing pipeline are different and I dont say they are.

I think there is a inconsistency between "Having some magical, untouchable, on-by-default, modules is not good" and on the other hand concealing some modules from the history.

  • output color profile (1)
  • input color profile (1)
  • orientation (2)
  • demosaic (1)
  • highlight recon (2)
  • white balance (2)
  • raw black/white point (1)

These modules are applied to the image. Some of them can be turned off like most of the other modules (they have a 2 in the list above), some of them cannot be turned off (they have a 1 in the list above).

As a user I expect to be able to clear the list.
As a technical expert I know raw processing does not make sense without modules like demosaic.
Anyhow I see this as an inconsistency if darktable forces the user to use some modules and doesnt allow them to be turned off. This inconsistency makes it harder to understand darktable.

Have you looked through the usermanual? Did it answer these questions? Perhaps this can be solved by simply extending the docs.

Its not a matter of the documentation and its not a matter of understanding.

My proposition here is that I seldom need to adjust these features because dt makes sensible defaults. I would love to be able to turn on their visibility only if I want to change the defaults.

Even the manual writes for the "raw black/white point" that "Changes to the defaults are normally not required". So why shall I always have to see them if I am happy with dts defaults and will not ever change them? For most people they are like constants. How many times did you change this module? If you need to change it for your camera you probably do it once and create a preset that gets applied to all photos of your camera automatically. There is no need to see it every time in the "active modules" group.

(As a user and as a technical expert I may wonder why the modules marked with 2 in the list above appear, but I guess this is a different issue than the one we want to talk about here.)

Well, why wouldn't they? You will likely want to manually tune the white balance,
may want to re-adjust the image orientation e.g. in case the camera failed to set the correct tag,
and WILL most likely want to change the highlight recovery method from the default.

If you followed steps 1-5 from above you have cleaned the history. The documentation says "The history stack lists every change of state (activate/de-activated) for all modules". If this is true it means that all (2) marked modules from above are automatically turned on.

Wouldnt it be easier to think about the history as the list of actions being performed on the raw image? Instead it looks the history is showing the difference to the default magical, on-by-default, modules. And seriously, following a concept like all modules are turned off by default or all modules that are active are visible in the history is much more easy as to learn which of all modules are special modules because they are active per default.

For your three examples, I dont see any reason why these modules do not belong to the history.

#9 Updated by David Schaefer 3 months ago

Is my request clear now? Is it clear what I think can be improved? What can I do to fix the status incomplete?

Also available in: Atom PDF