-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
better initialisation of history stack #5414
Conversation
when clearing the history stack or loading a new image - any module which is forced on and cannot be switched off appears first in the history stack - any module that is on by default but can be switched off appears next in the history stack - finally any modules that are enabled by presets or as a result of a preference setting (workflow or sharpen) are added the final set of modules can be disabled and removed from the history stack but, as previously the first two sets will be automatically re-added if they are removed also fixes bug where higlight reconstruction was not present in the history stack Resolves darktable-org#5396
For some reason the flip module appears last in the stack and I can't figure out why. By no means is this a showstopper though because this PR fixes all of the issues in 5396 so IMO it's still better than master even if not 100% consistent. |
Thinking on this again, the exposure autosetting really has to be managed via a preset, to ensure that subsequent instances don't also start with the same defaults. A second instance of exposure should never need the +1EV or exposure bias compensation. Filmicrgb default settings cannot be managed with a preset as it needs to set parameters based on exposure data from the image. |
ensures that the scene-referred defaults are only applied to the first instance of exposure
For the flip module it is special cased in different part of the code. For example in dt_image_get_orientation (common/images.c). Maybe that's why it behave differently. |
I don't think it's an issue now I've moved everything else to presets. Also related to the second issue, I don't really understand what the code in database.c is designed to do. Maybe that has something to do with the basecurve auto-apply issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not tested yet but sounds correct to me.
Let me know if you agree about the preset.
Yes I agree - I did think about that when I did it. I've pushed that change |
I'm still not convinced that any of the modules that may be switched off should be auto-enabled via the module->default_enabled flag due to the problems I've mentioned in my issue (namely that if one can disable the module one should also be able to remove it from the stack) but given how close we are to feature freeze I didn't think it was worth opening that can of worms yet. IMO that flag should really be limited to just those modules that are fully mandatory. |
Agreed on both counts ! |
Perhaps I'll raise another FR to discuss for 3.4 |
Would be perfect ! |
Thanks for working on this. Better initialization indeed. |
FR as discussed is #5434. |
when clearing the history stack or loading a new image
the final set of modules can be disabled and removed from the history stack but, as previously, the first two sets will be automatically re-added if they are removed
also fixes bug where highlight reconstruction was not present in the history stack
finally changes the scene-referred exposure defaults to a preset to ensure that they only apply to the first module instance and can be easily reapplied if necessary (by choosing the preset)
Resolves #5396, #5416