Indeed VERY strange. Also with Peter’s XMP I see the blurred region.
I will explore further tomorrow …,
Thx for looking so far for today 
2 Likes
@DerMartin - could you share your pertinent shot settings? I have an R7 and haven’t seen these issues, but I could try your configuration and see if I can replicate the problem. Normally I would just go by the embedded EXIF data, but I’m not sure if that would report your CRAW settings
I have it… 4.3 +255
left of the 2 the fine color noise is missing in a blotch…
Also in the background…
Left of the arm left of my mouse pointer…
I’m on win11 with Nvidia graphics…
Seems like with or without opencl
Hi Todd,
thank you for confirming. I already started questioning myself
So what I try later today might be to get back to 4.2 and check if in my environment something changes …
okay…
So I just tested things —
And with the v4.2.0-2 installed from manjaro repository the issue is NOT there.
But compiling my own recent version 4.2.0+107~g640324d71c from git → the blurred regions appear.
No idea where to look, but for me this clearly is some sort of regression.
Any recommendations how to proceed here?
Cheers, Martin
You could try a git bisect to find the commit that introduced the error.
1 Like
Hi,
I fear I am not git-Wizzard enough to use bisect to nail down the commit.
Am actually glad, that I at least manage to compile myself copying the default steps.
But would be interesting to hear if someone else can confirm the “4.2 is fine” and “4.2.x has issues” finding…
Edit:
What I see is, that 2 weeks ago there was a merge respective to the reöeased version of libraw 21.0 (LibRaw update by kmilos · Pull Request #13030 · darktable-org/darktable · GitHub) while before as I understood a beta version was leveraged? Perhaps this brought the issues I experience?
And yes, the blurred regions also appear in exported JPG
It seems to work ok on master for me (and on Windows) - it does look blurry while I’m zooming/panning, but it eventually redraws fine… So it could be some graphics driver interaction on your particular OS/gtk/X/Wayland…
Do you have this in the exported image or just in the darktable window?
I don’t think so, I just tested unprocessed_raw from LibRaw 0.21.1 stable release (Windows/MSYS2):
Edit: Also attaching an XMP that turns everything possible off and sets demosaic to passthrough: 20230121-173420_R7MA6341.CR3.xmp (4.8 KB)
I finally had a change to take look at the file, and I haven’t seen the issue:
I’m running the 4.2.0 release on a Windows 11 system, AMD Ryzen 5 5600X 6-Core Processor, 3701 Mhz, 6 Core(s), 12 Logical Processor(s) and an NVIDIA GeForce RTX 3060 with 16GB RAM
Okay.
Looking at the pull request regarding libraw, I figured out, that by editing DefineOptions.cmake with
option(DONT_USE_INTERNAL_LIBRAW “If possible, use system instead of intree copy of LibRaw” ON)
I can use my system-provided LibRaw. (0.21.1-1)
And guess what? With this the effect is gone.
As soon as I compile with the intree-version, I see the blurbs !
It is mosaiced after all, I wrongly assumed it is somehow similar to old sRaw…
1 Like
I have just built 4.2.0+108~gd318993ca on Windows w/ intree LibRaw, and don’t see any import problems using that minimalistic XMP.
Hi,
just checked again building darktable 4.2.0+108~gd318993cab:
intree LibRaw = blobs
system LibRaw = all is fine
No glue where to search further. But as said, option “system LibRaw” here works fine.
1 Like
Hi,
just to add a data point, I tried with current master
4.3.0+338~g1051a2c8b7
Also here same behaviour:
intree LibRaw = blobs
system LibRaw = all is fine