para...@paraf.in (2019-Jun-10, excerpt):
> I think we still have default-on modules not recorded in history
> stack (highlight reconstruction and white balance), so removing all
> “off” steps might modify the image.
Hmmm. So if I understand you correctly, the problem is that removing
all unused modules would be a problem for some "special" modules which
are not recorded on the stack but are on by default, and have then
been disabled by the user. I observe this with "white balance":
* disable "white balance"
* compress history stack with removing unused modules
* => white balance is automagically enabled again, changing the
image.
Correct? I do not see any other problem.
I could easily work around that by simply changing the query to
something like (yes, ugly)
DELETE FROM main.history
WHERE imgid = ?1
AND enabled == 0
AND module != <you need to tell me>
AND module != <you need to tell me>
AND module != <you need to tell me>
AND module != <you need to tell me>
But that would add technological debt in order to get around a funny
design choice (or: Why are these modules not recorded on the stack?)
> Best approach would be to record all applied iops to history, but
> it’s a little tricky due to backwards compatibility
I agree.
Basically I see the question as this: Are these modules special (then
I must work around them, or they must not have the ability to be
disabled) or they are not (then they must be recorded to the history).
For the backwards compatibility: I have not checked, but I hope that
there is versioning informaton in the XMPs. If so, new stacks should
have white balance added, and old stacks could be recognised and
migrated by adding the default white balance to their stacks.
--
http://stefan-klinger.de o/X
I prefer receiving plain text messages, not exceeding 32kB. /\/
\
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
