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
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.
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:
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
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
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
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
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
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
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
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,
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
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
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
14 matches
Mail list logo