Darktable: Mouse wheel turn on new image causes it to pixelate

[chhil]

3.3.0+1440~g44fe67e70 Windows.
Opencl off.

Coppied history then realized I want to edit this fresh. Copy had multiple exposure modules. Compressed history.

Turning mouse wheel on histogram for exposure immediately pixelated.
Notice history has exposure 1, but there is no exposure 1 in modules.

This has happened on a few images now.

[elstoc]

This could be a regression from a refactor. This was a bug that used to happen before I rewrote the multi-instance shortcut stuff. Probably @dterrahe. The problem is that modules don't get removed from darktable when you compress history - they just get their order set to INT_MAX, so you have to be careful not to use those modules when attaching accels to instances.

[dterrahe]

That test in imageop.c is still there
if(mod->so == module && mod->iop_order != INT_MAX)
Does the manipulation of exposure via scrolling of histogram go via accelerators?

[elstoc]

The exposure module proxy used by the histogram is set in connect_key_accels() within exposure.c (which perhaps is no longer being called?).

To reproduce create a duplicate of the exposure module (with all the options in preferences > miscellaneous at their defaults) then select a prior item in the history stack and drag the histogram. The accel works fine.

[dterrahe]

You are correct; connect_key_accels is only called once now, and the connections are stored in a list and restored from there. It is not called for every change of active module.

Looking at it closer, what happens with the proxy.exposure needed to be fixed for multi-instance ordering, because every time connect_key_accels was called another proxy entry was added to the list. So if one kept switching back and forth between two exposure modules, the list would keep growing. Only the first element is ever used. The list is eventually cleaned in gui_cleanup or when the darkroom is left. This made sense when the last added instance of exposure always was the active one, and connect_key_accels was called only once to set it up, but now that they can switch back and forth, maybe we should just set the instance->module of dt_dev_proxy_exposure_t to the currently active exposure module.

@TurboGit I can fix just this regression or clean up the whole proxy list structure, which I don't think works (or can be made to work) correctly with the current setup of multi-instance accelerator priorities.

[TurboGit]

I would go for clean up the proxy if possible to get this right in 3.4. TIA.

[chhil]

I believe this should be reopened.
3.3.0+1520~g26b4e09d4 on Ubuntu 20 run on windows using WSL (windows subsystem for linux).

Compressed edited history stack of image1.
Cleared history of edited image2 by compressing to original.
Copied history (ctrl+c) of image1 from filmstrip.
Pasted history on image2.

There were 2 exposures modules. If I disable exposure1, the image becomes alright.

[elstoc]

Maybe worth raising a new one as this doesn't appear to be directly related to histogram adjustment. Also worth asking if either of these images are ones that were affected by the previous issue?

[chhil]

This image was not affected previously, its a brand new edit.
Created https://github.com/darktable-org/darktable/issues/6868