I’m using the current official darktable version 4.6.1
Since December I’m struggling with the issue that in lighttable, when expanding the thubnails using the shortcut w (so that the pic is shown on full screen) the preview is extremly pixelated.
I’ve tried to change several parameters in darktablerc to solve that issue, but I could not manage to solve the issue… Even deleting darktablerc did not help…
The only way it worked was to completely delete the folder ./config/darktable
Unfortunately that is not an option I would like to take as I have a lot of pictures in my database…
Is there a solution to this problem? I did find some threads in this forum pointing to the same issue for older dt versions but unfortunately those were of no help for my current problem
I do experience the same thing with dt 4.6.1/Ubuntu 22.04 but after a few second, while maintaining w pressed, the picture is not pixelated anymore. (OpenCL off)
Is it possible that the embedded jpegs are used while dt prepares previews from the raw?
Just a guess, I know some Sony embedded jpegs are limited to 1080p, so too small for a large or HD screen. But @manu’s observation seems to point in that direction.
The initial preview thumbnail is calculated from the embedded JPEG. On many camera, this is very low resolution. Depending on your settings, the full-screen view shows a darktable render. So this checks out.
I’m using darktable since many years and my database has more than 170000 pics.
Only recently I changed to the new version. I’m pretty sure that this issue came with dt 4.6. With the upde to 4.6.1 this problem remains.
But I did not change any settings for dt 4.6. Maybe I missed something? Do I have to adapt some settings?
I would try to check edit history of some problematic image. Maybe first reset it to default and if it fixes it, check one by one which module causes the problem.
Impossible to say which settings are best for your situations, as you don’t give any information about raw formats/camera brands or computer specs.
Personally, I’ve set the first two (“use raw file instead…” and “high quality…”) to “always”, and “generate thumbnails in background” to “never”. But then, I have a reasonably powerful system… (though by no means a high end system). I do know that my embedded thumbnails are about 1000 px high (which is 1/4 of the raw size), and my screen is 1080 pix high.
To be more precise, here’s my setting regarding thumbnails:
It’s always been like that, apart “enable disk backend for full preview cache”, because of the huge space it takes on the SSD. So, I moved the cache on a second disk for the test.
Now, when I run the following command, I get immediate full preview as kindly proposed by @pehar.
The second thing that puzzle me is that for photos which ID is before 82000 (see before), when I press w it takes a while and then, the full preview shows something very different from the thumbnail, which is I guess the embedded JPEG. Since, “use raw file instead of embedded JPEG from size” is set to “never”, I don’t understand the difference in display…
One more thing, processing > prefer performance over quality is off, as it’s always been.
Last but not least maybe, I could reproduce @wiegemalt issue, i.e. for some photos pressing w showed a pixelated full preview and nothing else, ever. While usually I get a “working…” on the preview until it’s displayed unpixelated.
I thought what that setting was generating the thumbnails in the background, even when the raw is not visible on the lighttable, so once you scroll, it’s immediately available.
4.6.0 release notes:
New functionality has been added to automatically generate thumbnails in the background while the user is inactive in the lighttable view.
I am on v4.7 and can not replicate the problem on a windows 11 machine. When I switch an image to full size it takes a second or two to generate a quality preview on my 4K screen.