Not to throw gas on the fire but it seems to me that some of this is already done.
In Lighttable, when you wish to copy the history from one image to another, there are some modules missing (input and output) and also, the "off" modules aren't included in the possible modules to copy over. On Thu, Jun 13, 2019 at 5:30 AM <dt-l...@stefan-klinger.de> wrote: > 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 > > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
