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

[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" 
> A : darktable-user@lists.darktable.org
> Copie à : 
> 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
> Am 01.02.2018 um 16:46 schrieb Remco Viëtor:
> > 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 "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
> > to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
> >
> >
> 
> 
> darktable user mailing list
> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
> 
>

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

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

[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
Am 01.02.2018 um 16:46 schrieb Remco Viëtor:
> 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 "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
> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
>
>


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

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

[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é



2018-02-01 18:13 GMT-02:00 thokster :

> 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 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
> to unsubscribe send a mail to darktable-user+unsubscribe@lis
> ts.darktable.org
>
>


-- 
André Felipe

https://www.flickr.com/photos/andrefelipecarvalho/


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

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

[thokster]

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 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
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

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

[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.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

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

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

[Remco Viëtor]

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 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

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

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

[Anders Lund]

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 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
> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org





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

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

[Matthew Harrison]

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 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
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

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

[Remco Viëtor]

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 "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
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

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

[KOVÁCS István]

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 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.
>
> > -Sergii.
>
> Tobias
>
> [...]




darktable user mailing list to unsubscribe send a mail to
darktable-user+unsubscr...@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


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

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

[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.

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 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.
>
> > -Sergii.
>
> Tobias
>
> [...]


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

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

[Tobias Ellinghaus]

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 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.

> -Sergii.

Tobias

[...]

signature.asc
Description: This is a digitally signed message part.

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

[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.

On Wed, Jan 31, 2018 at 8:48 AM, Harald  wrote:

> 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
> to unsubscribe send a mail to darktable-user+unsubscribe@
> lists.darktable.org
>
>


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

[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


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