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

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" > A : darktable-user@lists.darktable.org > Copie à : > Objet : Re: [darktable-user] history stack still containing

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.

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

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:

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

Am 01.02.2018 um 19:25 schrieb 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

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

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

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

On jeudi 1 février 2018 17:55:14 CET Matthew Harrison wrote: > > 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

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

A suggestion: Remove modules that are disabled + reset at compress history stack. Kindly, Anders torsdag den 1. februar 2018 17.55.14 CET skrev Matthew Harrison: > On 1 February 2018 at 15:46, Remco Viëtor wrote: > > The current implementation of "compress history

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

On 1 February 2018 at 15:46, Remco Viëtor wrote: > > 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

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

On jeudi 1 février 2018 15:18:27 CET Matthew Harrison wrote: > 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

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

On 1 Feb 2018 15:19, "Matthew Harrison" wrote: Why would compress history stack do that [keep disabled modules]? On 31 January 2018 at 18:38, Tobias Ellinghaus wrote: > Am Mittwoch, 31. Januar 2018, 19:31:29 CET schrieb Sergii Dymchenko: > > For me having

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

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. On 31 January 2018 at 18:38, Tobias Ellinghaus wrote: > Am Mittwoch, 31. Januar 2018,

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

Am Mittwoch, 31. Januar 2018, 19:31:29 CET schrieb 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

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

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

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

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