Erroneous output with multiple instances of colorzones module in style

[cstaahl]

When applying styles with multiple instances of the module colorzone the result is mosaic-like. Similar to the image posted in https://github.com/darktable-org/darktable/issues/7477 I used this style: style_test.zip

The console output is: [dt_ioppr_check_iop_order] history module not used but enabled!! colorzones 2(2147483647) image 6646 dt_dev_read_history_no_image end) cannot get iop-order for colorzones instance 1

Resetting the module order as described in https://github.com/darktable-org/darktable/issues/6207 does not solve the problem.

Darktable version: 3.4.1

[Nilvus]

Could you precise if that is in previous edited images or new imported ones (in 3.4.0 or 3.4.1)? You also forget to precise which OS you use, if you have OpenCL or not (and if yes, which graphic card used).

Could you test on a clone without history. Just clone an image, remove development in development module in right panel of lighttable view? We have had similar demosaic issues with an older release of darktable (before 3.2.1 as I remember) and the issue is fixed. But as the issue was the fact that history recorded in database/xmp was corrupted when having multiple instances, the only way is to clone and copy history to create a good one. Then remove the corrupted one. I have just tested your style on my side, and I can't reproduce your issue (on master). Many all mosaic-like issue with multiple instances we've seen here were due to that old bug, fixed since some months but resulting to use the clone/copy then remove corrupted one, to fix. A quite annoying bug unfortunately. Waiting for your feedback or precision.

[Nilvus]

To complete, see #7655

[cstaahl]

I'm using the following OS: Ubuntu 20.04.1 OpenCL: yes (switching it off does not make a difference) Graphics card: GeForce GTX 1660 Ti

The issue arises on images imported on 3.4.1 and is very similar to what is described in https://github.com/darktable-org/darktable/issues/7655. Cloning the image did not fix the issue.

With your feedback I experimented some more and found out that is dependent on how you apply the style: With "mode: overwrite" the result on an untouched image is garbled and with "mode: append" it works fine. If you apply with "mode: overwrite" once, then discard the history stack in lighttable and re-apply with "mode: append" the result is still garbled. The only way I was able to "fix" the image was to select "original" and compress the history stack in darkroom or remove image from the collection, delete the .xmp file and re-import.

[sobrus]

I'm having the same issue when applying two instances of profiled denoiser. Again, image output is similar to https://github.com/darktable-org/darktable/issues/7655. Images from both my cameras are affected (Panasonic LX-5 and Fuji X-T30). I've removed all XMP files, dropped history, imported newly taken images, even deleted my darktable config entirely and started with "fresh" one, new photo and new style.

I've also tried to update to newest available version (3.4.1-2) from unstable Manjaro and Arch repo (along with newest libavif library). Problem still persists. Please don't close bug reports as fixed in 3.2 because something is apparently wrong. There are no problems until applying multiple module instances.

I'm unable to tell when the problems started to show, as I've upgraded my machine a month ago. I think it did run well before on my old E5450 Xeon with same RX570, same Manjaro system and same orca driver. My Lenovo X230 laptop is currently also affected though.

Steps to reproduce:

• load any image
• enable profiled denoise and duplicate/create new instance (default settings will do) - everything works perfectly up to this point even though two instances are in use
• create style from this image (just two denoise modules)
• drop file history
• apply the style again
• file corrupted in preview, in edit window and in output jpg.

OS: Manjaro x64 CPU: Ryzen 5950x, i5-3360M (laptop) GPU: Radeon RX570, Intel HD4600 (laptop) OpenCL: yes (Orca driver), Disabling OpenCL does not help, no OpenCL support on Ivy Bridge laptop.

edit: Following text is visible in standard output when the problem occurs:

cannot get iop-order for denoiseprofile instance 1
[dt_ioppr_check_iop_order] history module not used but enabled!! denoiseprofile NL(2147483647) image 19064 (dt_dev_read_history_no_image end)
blockdenom vanishes 

I know this was already talked about in #6207 but this is for new edit, Darktable 3.4.1, there was no version 3.2.x ever installed on this machine and I'm even unable to downgrade to it due to dependencies.

edit2: I've checked last successfully developed photos and they were made using DT 3.2.1. I've installed git version of 3.5.0 and the problem seems to be fixed. So only 3.4.x version is affected.

[CSymes]

I'm also experiencing this, however I'm just copying edit history across photos, rather than using styles. Using the copy- or paste-parts function and excluding all but the original instance of the Colour Zones module bypasses the issue. I just reimaged this machine, so it has only ever had 3.4.1.1 installed, and these were images I just took today so they didn't have any past history on them either.

OS: Windows 10 20H2 CPU: Ryzen 1600 GPU: GTX 1070 Ti OpenCL: Enabled

[sobrus]

I can confirm that copying and pasting a history containing multiple instances also caused the issue, even though the original (history source) image worked fine (had multiple instances done manually). Fortunately I haven't noticed the issue ever since I've upgraded to 3.5 series, so I guess it must have been already fixed somewhere. I hope that Windows version will be fixed as well.

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[johnny-bit]

I think it's duplicate of #7477 (fixed in current master) or duplicate of #8547 (also fixed in current master) and similar (fixed in current master).

Unfortunately the fix didn't make it to 3.4 branch, but will be part of 3.6 release comming in just 2 weeks :)

So - while I can reproduce the issue on 3.4, i can't do it on current master which means the issue is fixed so closing :)