Aurélien Pierre (2019-Jun-13, excerpt):
> There is no image if the white balance has been disabled, just random
> bits for debugging purposes. The input color profile expects
> D50-balanced input, and this one is always on. Same with the highlight
> clipping module, most software have it built in the input profile and
> don't expose it. Disable these 2 and you mess up your whole module stack.
>
> So, again, what is the purpose of disabling these 2 modules, except for
> debugging, and why can they be disabled at all but are still
> auto-applied at opening ?
It might well be a crap idea to do this, but it's possible, so someone
will do it.
I see two possible outcomes to the current situation:
1. Some modules must not be disabled.
Then the possibility to disable them is a bug that must be
resolved.
This will "break" all existing XMPs that disable one of these
modules.
2. All modules can be disabled.
Then they all must be reported to the history stack, and
compression must not modify their topmost recorded state.
This will "break" all existing XMPs that lack a mentioning of
these modules in their stack.
Either way, it's a messy situation that needs to be resolved.
> The stack of exceptions handling in the SQL instructions smells bad.
I agree. My first implementation was just like that.
> Things should stay general.
General would mean: No exception for "white balance" and others.
Later modules should simply refuse to work if no appropriate input is
available (message: “need white-balanced image”). To implement this,
something like the 'type' of an image could be propagated upwards
along the stack of IOPs (is this really not happening right now?).
Just as an oversimplified example, "white balance" might require 'RAW'
and provide 'D50-balanced', while "color profile" would require
'D50-balanced'. This would allow to implement other modules providing
'D50-balanced' without technical debt hindering their adoption later
on.
Regarding the length of this thread, I assume that it will take quite
some time to reach consensus here.
Clearly the current situation (having two different implementations of
"compress history", one more complete but changing images in
pathological cases) is unsatisfactory.
So where do you want to go?
Why I started this: I wanted to learn DTs internal data structures, in
order to implement better snapshots and history. The idea is to
replace the history stack with a rooted DAG, with the RAW at the root,
and all leaves snapshots (but not necessarily all snapshots at
leaves). Current histories would be straight lists. Creating a
snapshot, going back in history, and then doing a different edit,
would create a tree. This would pave the way to (in the future)
create IOPs that use more than one input, including a means to combine
multiple RAWs. This approach would clearly benefit from a 'typing'
system outlined above.
--
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
