Skip to content
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

base modules (enabled by default) not saved in history #2910

Closed
aurelienpierre opened this issue Sep 4, 2019 · 4 comments
Closed

base modules (enabled by default) not saved in history #2910

aurelienpierre opened this issue Sep 4, 2019 · 4 comments

Comments

@aurelienpierre
Copy link
Member

aurelienpierre commented Sep 4, 2019

The modules colorin, colorout, and possibly demosaic and others don't write an entry in history (either XMP sidecars or database) if user has not changed the default parameters. This is a problem since modules can be reordered in pipe, because it leads to undefined behaviours:

  • if the default params of said modules are changed in a future version, they will be used in place of the former and will result in history breaking,
  • when copy-pasting history between images, the pipe order can be randomly changed (see tone equalizer #1904 (comment)),
  • if the default pipe order is changed in a future version, these untracked modules will be automatically moved in the pipe accordingly to the new default, with no warning to users (see Fix pipe order #2905 (comment)),
  • history compression needs fiddling around these special cases of modules being there in processing but not tracked in history,
  • the current default pipe order is already not consistent with the legacy one (exposure moved after colorin for example), whereas no explicit rule is changing it.

Proposed solution for darktable 2.6 to 3.0 migration:

  1. browse the database and force-commit untracked modules to history,
  2. associate untracked modules with their pipe position in 2.6
  3. update default pipe order for new edits
  4. force base modules to write an entry from now on
@aurelienpierre
Copy link
Member Author

Copy-paste of @parafin from IRC (for later reference):

it seems that all modules enabled by default which are present in the history stack got there using preset system while missing ones just have default_enabled flag set to 1. I think they can be added to the history in function dt_dev_read_history_ext from src/develop/develop.c file. add some kind of loop near the end of the function to find enabled but not present in the history modules

@parafin
Copy link
Member

parafin commented Oct 17, 2019

I think this one is already fixed?

@jenshannoschwalm
Copy link
Collaborator

Yes. Turbogit committed

@TurboGit
Copy link
Member

Yes, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants