I noticed some black boxes in DT. I have only seen it in 4.2.1
Has anybody seen something like this?
Lightroom view below
Resulting image in Geeqie
But it is not consistent (when working on the image) it is affected by the zoom. Consistently wrong on export however.
Linux Pop!_OS 22.04 LTS
NVIDIA Corporation TU106M [GeForce RTX 2070 Mobile / Max-Q Refresh]
AMD® Ryzen 9 3900 12-core processor × 24
Can you deactivate hardware acceleration?
The nVidia driver version would also be useful. Plus a raw and the sidecar. Optimally, a Github bug report.
Would be good to test master before opening a Github bug report. There’s some bugs that had been fixed, and some about black “boxes”. can’t be sure it’s related to this one though.
@vbs : I can test on the current master branch, but will need the raw + XMP.
Works well without open CL
These are my default settings
I don’t think I can test master - I can spin VM but it may not access open CL (and this appears to be the key)
But here is RAW +XMP.
If I am to copy the complete stack to a another image - it may not manifest the issue.
20220828_174137_0942_01.CR2.xmp (15.6 KB)
20220828_174137_0942.CR2 (25.6 MB)
Sun Apr 16 11:10:43 2023
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.89.02 Driver Version: 525.89.02 CUDA Version: 12.0 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 NVIDIA GeForce ... Off | 00000000:07:00.0 On | N/A |
| N/A 56C P5 16W / 115W | 1348MiB / 8192MiB | 20% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| 0 N/A N/A 3273 G /usr/lib/xorg/Xorg 584MiB |
| 0 N/A N/A 3406 G /usr/bin/gnome-shell 180MiB |
| 0 N/A N/A 50322 G ...b/thunderbird/thunderbird 201MiB |
| 0 N/A N/A 225576 G firefox 196MiB |
| 0 N/A N/A 234360 C /usr/bin/darktable 98MiB |
+-----------------------------------------------------------------------------+
If somebody has a chance to test master? I can open github if needed.
Maybe something related to the work of this item?
Fix possible bad pinned memory transfer on OpenCL
Change your opencl tuning to none… I found a few issues going back I think with my 3060Ti but also this was the fastest mode in my case , ie using none… for tuning
I just noticed that you provided the sidecar and file… @kofa can you check… on my machine on windows disabling one of the diffuse and sharpen instances seems to correct it…so the issue could be tied to this and an interaction with some other module??
What I can tell you is that if you want to use color balance rgb for brilliance manipulation, then according to Aurélien Pierre, the author of the module:
However, with or without performing those changes, I do not see any black boxes either in the editor or in the exported files. I’m on NVidia 470.
This is what I just noticed…one instance dropped global brilliance like 90 some percent… changing that seems to fix things on my end… And that module with that brilliance setting impact calculations made by diffuse and sharpen it would seem…
With the xmp as provided I get a box in the upper left preview which is persistent and when I zoom scroll I get this black box briefly on the main display…
Disabling the CB module instance 3 or altering the brilliance settings removes the behaviour during scrolling but the black box remains in the navigation preview…
I can enable this CB instance back on and then disable diffuse and sharpen and both disappear.
So this to me is similar to what was happening in that thread earlier with the black regions in the image and it was due to very large adjustments using the brilliance slider in that case as well. As noted by @Kofa it was suggested to keep it under 22% or so as after that there was an exponential change in pixel value…
Enable it and then disable one of the diffuse module instances…
So the large adjustment to brilliance combined with diffuse and sharpen seems to be the source of things in this case as best it seems to me…
I changed the white fulcrum and it appears to help. Thank you!
This also helps.
I was not aware of restrictions within the module and just went by what my eyes perceived. But there are other ways to work around it. Besides - my extreme adjustment did not contribute that much visually.
Thank you all!
I think you right… that is a lovely image… even a minimal edit produces a nice result… it must have been lovely to stand there and look at that wonderful scenery…
20220828_174137_0942_01.CR2.xmp (9.7 KB)
The issue came up here but in the reverse with someone boosting brilliance too much…
I think this contains the comments that @Kofa was talking about…
