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

Reply via email to