[darktable-user] history stack still containing disabled modules after compression - why?

[Harald]

Hi,

I don't understand why the history stack still contains - or generally
should contain - disabled modules after stack compression.

I have seen the procedure for cleaning up deselected modules, but it
seems to me to be very complex, especially for multiple deselected
modules within the same stack.

Unfortunately, I have to disable alternative modules again at a later
stage, due to ongoing module comparisons.

Would a global function in Lighttable for compressing and deleting
disabled history stack module entries for a group of selected photos be
a useful extension for darktable?

Any other idea would help to create my own 'clean' styles ... ?

Thanks and Regards

Haribo M

[Sergii Dymchenko]

For me having disabled modules in history is very useful, because the
modules may have some non-default parameters set, and later I may want to
re-enable them.
For example, I can apply the watermark module, change some colors/position,
export with the watermark.
Later I can disable the watermark module to export for some other purpose.
If I want to export with a watermark again I want it to remember
colors/position I set before, even after stack compression.

-Sergii.

Post by Harald
Hi,
I don't understand why the history stack still contains - or generally
should contain - disabled modules after stack compression.
I have seen the procedure for cleaning up deselected modules, but it
seems to me to be very complex, especially for multiple deselected
modules within the same stack.
Unfortunately, I have to disable alternative modules again at a later
stage, due to ongoing module comparisons.
Would a global function in Lighttable for compressing and deleting
disabled history stack module entries for a group of selected photos be
a useful extension for darktable?
Any other idea would help to create my own 'clean' styles ... ?
Thanks and Regards
Haribo M
____________________________________________________________
________________
darktable user mailing list
lists.darktable.org

[Tobias Ellinghaus]

Post by Sergii Dymchenko
For me having disabled modules in history is very useful, because the
modules may have some non-default parameters set, and later I may want to
re-enable them.
For example, I can apply the watermark module, change some colors/position,
export with the watermark.
Later I can disable the watermark module to export for some other purpose.
If I want to export with a watermark again I want it to remember
colors/position I set before, even after stack compression.

There is an even more important reason to keep disabled modules: When turning
off any of the default modules, like sharpen or (for raw files) the basecurve
you need that entry in the history stack. Removing it will turn the module
back on.

Post by Sergii Dymchenko
-Sergii.

Tobias

[...]

[Matthew Harrison]

Why would compress history stack do that? It shouldn't be too hard to
check if a module is in the default list and leave disabled copies of those
when cleaning up whilst removing the others.

Post by Sergii Dymchenko

Post by Sergii Dymchenko
For me having disabled modules in history is very useful, because the
modules may have some non-default parameters set, and later I may want to
re-enable them.
For example, I can apply the watermark module, change some

colors/position,

Post by Sergii Dymchenko
export with the watermark.
Later I can disable the watermark module to export for some other

purpose.

Post by Sergii Dymchenko
If I want to export with a watermark again I want it to remember
colors/position I set before, even after stack compression.

There is an even more important reason to keep disabled modules: When turning
off any of the default modules, like sharpen or (for raw files) the basecurve
you need that entry in the history stack. Removing it will turn the module
back on.

Post by Sergii Dymchenko
-Sergii.

Tobias
[...]

[KOVÁCS István]

On 1 Feb 2018 15:19, "Matthew Harrison" <***@gmail.com> wrote:

Why would compress history stack do that [keep disabled modules]?

Post by Sergii Dymchenko

Post by Sergii Dymchenko
For me having disabled modules in history is very useful, because the
modules may have some non-default parameters set, and later I may want to
re-enable them.
For example, I can apply the watermark module, change some

colors/position,

Post by Sergii Dymchenko
export with the watermark.
Later I can disable the watermark module to export for some other

purpose.

Post by Sergii Dymchenko
If I want to export with a watermark again I want it to remember
colors/position I set before, even after stack compression.

There is an even more important reason to keep disabled modules: When turning
off any of the default modules, like sharpen or (for raw files) the basecurve
you need that entry in the history stack. Removing it will turn the module
back on.

Post by Sergii Dymchenko
-Sergii.

Tobias
[...]

____________________________________________________________________________
darktable user mailing list to unsubscribe send a mail to
darktable-user+***@lists.darktable.org


Suppose you edit a bunch of files, and make use of some plugin (e.g. some
version of denoising) in all of them.
Then, while processing one file, you realise that denoising module X works
better in your case than denoising module Y, which you used previously. So
you disable Y, enable X, and clean up (compress) your history. If disabling
Y were removed, you wouldn't be able to copy and paste "disabled Y, enabled
X" in append mode to your other images, or save this as a style. One could
argue that you could, after compressing your history, re-enable and then
disable Y so its removal is again (a 'copy-pasteable') part of your stack.

Kofa

[Remco Viëtor]

Post by Matthew Harrison
Why would compress history stack do that? It shouldn't be too hard to
check if a module is in the default list and leave disabled copies of those
when cleaning up whilst removing the others.

The current implementation of "compress history stack" has one important
propery: it does /nothing/ that influences your edit session, it only removes
modules that cannot have an effect. Removing modules that are turned off breaks
that.

Use case: you want to use e.g. equaliser or profiled denoise, perhaps with some
parametric or user mask. Good, no problem, just a bit time consuming to set up
to your liking. Then you want to convert to black and white, or play with some
colour changes.
Both equaliser and profiled denoise are quite slow (imply a lot of
calculation). So while you want to play with the conversions, it can be nice
to turn those two off.
But after playing with colour conversions, you can end up with a lot of unused
modules in the history,

So please leave modules that are just turned off in the stack on compressing.
Perhaps add an option to remove all unused modules (unused == unreachable or
turned off).

Remco

[Matthew Harrison]

Post by Remco Viëtor
The current implementation of "compress history stack" has one important
propery: it does /nothing/ that influences your edit session, it only removes
modules that cannot have an effect. Removing modules that are turned off breaks
that.
Use case: you want to use e.g. equaliser or profiled denoise, perhaps with some
parametric or user mask. Good, no problem, just a bit time consuming to set up
to your liking. Then you want to convert to black and white, or play with some
colour changes.
Both equaliser and profiled denoise are quite slow (imply a lot of
calculation). So while you want to play with the conversions, it can be nice
to turn those two off.
But after playing with colour conversions, you can end up with a lot of unused
modules in the history,
So please leave modules that are just turned off in the stack on compressing.
Perhaps add an option to remove all unused modules (unused == unreachable or
turned off).
Remco

I sometimes have multiple versions of the same module with useful
intermediate steps in my history, much the same as your example. Compress
history stack would remove them, so I can't accept your central premise.

[Anders Lund]

A suggestion: Remove modules that are disabled + reset at compress history
stack.

Kindly,
Anders

Post by Matthew Harrison

Post by Remco Viëtor
The current implementation of "compress history stack" has one important
propery: it does /nothing/ that influences your edit session, it only removes
modules that cannot have an effect. Removing modules that are turned off breaks
that.
Use case: you want to use e.g. equaliser or profiled denoise, perhaps with some
parametric or user mask. Good, no problem, just a bit time consuming to set up
to your liking. Then you want to convert to black and white, or play with some
colour changes.
Both equaliser and profiled denoise are quite slow (imply a lot of
calculation). So while you want to play with the conversions, it can be nice
to turn those two off.
But after playing with colour conversions, you can end up with a lot of unused
modules in the history,
So please leave modules that are just turned off in the stack on compressing.
Perhaps add an option to remove all unused modules (unused == unreachable or
turned off).
Remco

I sometimes have multiple versions of the same module with useful
intermediate steps in my history, much the same as your example. Compress
history stack would remove them, so I can't accept your central premise.
____________________________________________________________________________
darktable user mailing list

[Remco Viëtor]

Post by Matthew Harrison
I sometimes have multiple versions of the same module with useful
intermediate steps in my history, much the same as your example. Compress
history stack would remove them, so I can't accept your central premise.

Well, no, my example was about having a module that you wanted *temporarily*
disabled, typically to speed up processing during the rest of the editing.
Most often, it would only be present once in the history stack, and you most
certainly would want to keep the edits done after those modules.
But yes, I phrased that premise badly.

The idea was *not* to go back to an earlier stage in the editing process, but
to re-add the time-consuming modules after further edits, while keeping
anything done since the disabling of those modules.

So actually, there are two use cases here:
1- use the history stack to go back to a previous state of your image, /
discarding/ all later edits, comparible to the 'undo' history in many other
programs. (the use you refer to above)
2- use the history stack to temporarily disable modules, while keeping any
settings for later re-activation (the use I described in my previous post),
and /keeping/ all subsequent editing steps.

At the moment, "compress history stack" cleans out the stack for the 1st use-
case, making the 'undo' impossible, while keeping the disabled modules for the
2nd case above.

Remco

[Pascal Obry]

Another scenario as to why the disabled modules should not be removed.

You hesitate between two ways of removing noise (profil denoise, or
non-local means). One is disabled but you've tweaked the other quite a
bit on the image and *may want* to enable it and disable the other.
This is a common scenario for me. So I do not want the compress history
stack to remove the disabled modules.

[thokster]

Post by Pascal Obry
Another scenario as to why the disabled modules should not be removed.
You hesitate between two ways of removing noise (profil denoise, or
non-local means). One is disabled but you've tweaked the other quite a
bit on the image and *may want* to enable it and disable the other.
This is a common scenario for me. So I do not want the compress history
stack to remove the disabled modules.

+1

[André Felipe Carvalho]

I agree with this scenario: Should not remove disabled module in history
stack when compressing it.

But.... I would like to be able to remove any module I want in the history
stack (right-click on it and choosing delete, for instance).
I've filed a request on redmine about it:
https://redmine.darktable.org/issues/11269#change-30820

Best regards,
André

Post by Harald

Post by Pascal Obry
Another scenario as to why the disabled modules should not be removed.
You hesitate between two ways of removing noise (profil denoise, or
non-local means). One is disabled but you've tweaked the other quite a
bit on the image and *may want* to enable it and disable the other.
This is a common scenario for me. So I do not want the compress history
stack to remove the disabled modules.
+1

____________________________________________________________
________________
darktable user mailing list
ts.darktable.org

[Harald]

I do think I am talking about a 3. type of use cases...

There are for sure many reasons or use cases why not to remove a
disabled module during the photo processing work flow.

My point is, that at a final step, at the end of the work flow, all the
selections and decisions have been made already. Then and only then I do
want to do the final compress and clean.

At that point in time a remove of unused or disabled modules would be
very helpful.

Only this clean stack might be the basis for a new style or used for
copying further.

Not arrived yet at this final step, in between or during the work flow,
there is no need for removing the entries for disabled modules...

... and at that time no need to compress the history stack but at the
end of the process.

Haribo M

Post by Remco Viëtor

Post by Matthew Harrison
Why would compress history stack do that? It shouldn't be too hard to
check if a module is in the default list and leave disabled copies of those
when cleaning up whilst removing the others.

The current implementation of "compress history stack" has one important
propery: it does /nothing/ that influences your edit session, it only removes
modules that cannot have an effect. Removing modules that are turned off breaks
that.
Use case: you want to use e.g. equaliser or profiled denoise, perhaps with some
parametric or user mask. Good, no problem, just a bit time consuming to set up
to your liking. Then you want to convert to black and white, or play with some
colour changes.
Both equaliser and profiled denoise are quite slow (imply a lot of
calculation). So while you want to play with the conversions, it can be nice
to turn those two off.
But after playing with colour conversions, you can end up with a lot of unused
modules in the history,
So please leave modules that are just turned off in the stack on compressing.
Perhaps add an option to remove all unused modules (unused == unreachable or
turned off).
Remco
____________________________________________________________________________
darktable user mailing list

[Jean-Luc CECCOLI]

Hello,

 

Don't know if I really understood the problem... anyway...

When I want to remove an instance of a module form the history, for example the Exposure, I add a deactivated version of it on the top of the history.

So, I have Exposure activated somewhere in the middle of the stack, and the same deactivated at the top.

I select the top or the stack, compress the history, which removes the activated instance and lets the deactivated one still on the top.

Then, I select the module straight under the deactivated one, compress the history and... I'm happy.

DT doesn't work nor look the same as other photo processing softwares, that's why it is DT - enjoy !

 

Regards,

 

J.-Luc

 

 

 

 

Message du 02/02/18 14:32
De : "Harald"
Objet : Re: [darktable-user] history stack still containing disabled modules after compression - why?
I do think I am talking about a 3. type of use cases...
There are for sure many reasons or use cases why not to remove a
disabled module during the photo processing work flow.
My point is, that at a final step, at the end of the work flow, all the
selections and decisions have been made already. Then and only then I do
want to do the final compress and clean.
At that point in time a remove of unused or disabled modules would be
very helpful.
Only this clean stack might be the basis for a new style or used for
copying further.
Not arrived yet at this final step, in between or during the work flow,
there is no need for removing the entries for disabled modules...
... and at that time no need to compress the history stack but at the
end of the process.
Haribo M

Post by Remco Viëtor

Post by Matthew Harrison
Why would compress history stack do that? It shouldn't be too hard to
check if a module is in the default list and leave disabled copies of those
when cleaning up whilst removing the others.

The current implementation of "compress history stack" has one important
propery: it does /nothing/ that influences your edit session, it only removes
modules that cannot have an effect. Removing modules that are turned off breaks
that.
Use case: you want to use e.g. equaliser or profiled denoise, perhaps with some
parametric or user mask. Good, no problem, just a bit time consuming to set up
to your liking. Then you want to convert to black and white, or play with some
colour changes.
Both equaliser and profiled denoise are quite slow (imply a lot of
calculation). So while you want to play with the conversions, it can be nice
to turn those two off.
But after playing with colour conversions, you can end up with a lot of unused
modules in the history,
So please leave modules that are just turned off in the stack on compressing.
Perhaps add an option to remove all unused modules (unused == unreachable or
turned off).
Remco
____________________________________________________________________________
darktable user mailing list

____________________________________________________________________________
darktable user mailing list