just a side note: it is stated in the “official documentation” that the zoomed out preview is wrong, but I just noticed that the zoomed out preview is correct if opencl is off (however, the module is terribly slow without opencl). So in theory, this could be fixable, couldn’t it?
Either we use different versions of the manual, or we read it differently…
This is what I get from the official documentation for 3.8:
While this module is designed to be scale-invariant, its output can only be guaranteed at 100% zoom and high quality or full-size export.
I read that as “zoomed-out output might be wrong”, not “is wrong”. It may also depend on how your openCL is set up (i.e. which pipes use openCL), and how you use the module.
There have been a number of threads here one I think related to noise in the preview vs output and it has been my experience that your final output will match 100 percent view but not what you see on the screen at other zoom levels due to scaling. For me a typical zoom would be about 25 percent to give me a full screen preview. To get an exported image that matches what that looks like I have found I need to set scaling to 0.25 when exporting. This may be due setting I have but I don’t have any that are set to degrade things for performance. I am not sure what the best scaling aligo to use is. I think I went to bicubic over lanzcos
Many filters in darktable apply on regions of 5×5 pixels around each pixel. A 5×5 pixel filter, downscaled by 2, gives a 3×3 filter. If you downscale by more than that, then it becomes a 1×1 filter, aka not a filter anymore, but the original image, so nothing happens.
There is a trick in diffuse or sharpen to keep applying a 5×5 filter even heavily downscaled, by adjusting the coefficients in the filter, but it’s still an approximation and only works for large effects (presets like dehaze or local contrast, where the radius span is roughly at least 256 px).
But the blunt truth is downscaled previews will always be wrong compared to the full-size rendition, and that has to do with the fact that we can’t split pixels in fractions. Only is some situations, we can use tricks to make the downscaled output perceptually close-enough to the full-resolution.
Now, if you see a perceptual difference between CPU and GPU output, that’s a bug.
3 Likes
Ok, I found a workaround that kind of works for me: I simply deleted diffuse.cl, which disables opencl for this module. It more or less works for me, because I have a fast CPU. I think I can live well with this workaround.
I don’t think there is a difference between the final exported image or 100% zoomed in preview with or without opencl if the settings are the same. But there is definitely a difference when zoomed out.
Would this not likely be true for many modules…
Some discussion occurred here and in the linked topic embedded that I mentioned…
So that means that there are some combinations of modules where it is impossible to get an exact view of the result:
- for most modules the display isn’t exact except when zooming in to 100%; but
- “raw chromatic abberations” is bypassed (i.e. inactive) at 100% zoom…
That said, I have no idea how important that is in practice…
You are right, the preview is not correct either when opencl is off, it just seems to be somewhat more correct than with opencl, it depends on the settings. But there is definitely a difference here between opencl on and off.
I was going to suggest that it would be more correct if there was a demosaicing method for the zoomed out mode that is in between bilinear and rcd in terms of sharpness/contrast, but now I am not sure. On my my screen, the preview usually looks clearer and sharper than the exported image.