General means every module should behave the same and avoid the burden of having to manage them locally and separately, and forget later that some of them need special care because *there is no dev documentation to write that on *(that's what happened with the lighttable button).
Now, some modules need to be always enabled because a raw photograph is not an image without them. What remains to decide is the scope of these modules : are we only speaking of basic "codecs" modules (demosaicing, input & output colour profiles), or are we integrating less basic ones although very much needed ? The fact that highlights reconstruction and white balance have been moved from the "always on" to the "off upon user request but still on by default" bin with no further handing/checking is a mistake, and possibly bad design until someone is able to tell me what the use case for having them disabled is. Because, without them, your clipped highlights are magenta, your input color profile is useless and your whole image is possibly green or else, so why anyone would like to have that ? Infrared photographers ? These 2 modules need to be synchronized with the default behaviour handled by the SQL queries, instead of having the SQL queries patch every possible combination of "user on/off" + "default on/off" + "good/bad assumptions if no data". Because the list of modules is ever growing, that will soon be a nightmare (already is). Otherwise, having an "enabled by default if not actively disabled by user" IOP state means all disabled modules will need to stay in the history no matter what, because it's a fallacy to think that the ones maintaining modules will think of updating well-hidden sub-functionnalities like that when they rework the pixelpipe. Especially in the absence of a documentation. Le 13/06/2019 à 14:56, Julian Rickards a écrit : > 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 > <mailto: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 > <mailto:darktable-dev%2bunsubscr...@lists.darktable.org> > > > ___________________________________________________________________________ > 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
