If you’re not seeing this in exported images, I’d say the problem lies somewhere in the pipeline to display. The internal image has to be scaled, cropped, and converted to the display profile before it is splatted on the screen, so there are a few places where this sort of thing might occur.
The blocks are rather big, so it’s possibly something isolated to tiling, with respect to the left display boundary, a single-channel NaN thing, black clipping thing, or somesort…
A Heisenbug would change behaviour depending on e.g. running under a debugger, no? Maybe there’s some overlap between the categories. ‘A bug that disappears or alters its behavior when one attempts to probe or isolate it.’
Makes perfect sense. Do you see any way to test or isolate any of those possibilities? With the caveat that my programming skills are limited and out of date.
I may have found a reproducible situation on Windows 10 where the Crop and Rotate module is the culprit. It has other issues as well. I’ll make a screencast in a moment.
I have no clue how to describe the effects exactly and what I would write in a darktable bug report, but there is more wrong with the crop and rotate module than just reproducibly creating border artifacts. Please take a look here:
For clarification: 3.5.0+2439~g9aefc3ceb-dirty on Windows 10, self-compiled in MSYS2. OpenCL is active. AMD Ryzen 3700X, 32 GB RAM and nVidia GeForce RTX 2070 Super.
The artifacts look very similar to what I’ve experienced, although mine pop up without the crop and rotate module activated.
In my case, the happen while zooming in or out. I wonder if the processes are related from a display pipeline perspective. I’ll try it with the C&R module later.
Later…
@Thanatomanic and @hannoschwalm, I had a chance to look at the screen cast more carefully and it the border artifacts look exactly like mine, however I tend to see them while zooming and can’t replicate them using the crop module (I’m not seeing any of the other issues from the screen cast either).
My question once again is if there is a connection between zooming the display and cropping that provides some additional clue that we’ve been searching for?
I tried and failed to reproduce the black/coloured rectangles, on Linux with darktable 3.5.0+2436~g61b928872, using both shots (the bird and the rabbit). Lens correction was not enabled, but even if I turn it on (after updating the lensfun DB), the lens is not found (lensfun 0.3.2-6). OpenCL on/off did not change anything.
Hi, i am reading all this with great interest as “if there is a genuine bug - we want it!” Just some comments:
There have been a number of bugs due to wrong numbers processed in the pipeline (NaNs) resulting in black areas (this is the cairo library rendering the display content). Some of these bugs were related to not-fixed module maths and a compiler switch option to -O3 for release. So these bugs might only be observed with release builds - not with debug as that uses -O2
I looked at the video and was somewhat surprised about the visuals while using the crop&rotate module. You should always see a more colorful part inside the cropping region and paler parts surrounding.
This is just wrong and looks like a redrawing issue i can’t explain right now - also i have never seen such. Maybe a building problem with your cairo/gtk libraries but i really don`t know.
“Artefacts” while zooming in & out or selecting another region via the preview (top left) again are something different. dt show an approximated bad quality image and gives the “working” hint. After finishing processing the output of the pipeline is shown with good quality. So the greenish parts at the borders shouldn’t be there
I can confirm what @hannoschwalm mentioned. I just compiled my version with -O3 and now I notice the colored / black rectangles, too, but only while darktable is still processing the image. After processing is finished the view is adjusted and the artifacts are no longer visible.
