Playing around with the new version I stumbled over the following effect: In images with a high dynamic range it looks as if the rendering output differs depending on the chosen zoom level.
Zoomed in a lot more structure can be seen while in the “fit in”-view these areas seem to be partially blown out. These details are also lost when exporting to JPG or TIF and viewed 100%.
Yes : local filters (blurs, interpolations, sharpenings, local contrast, etc.) are scale-dependent since we have an integer number of pixels. Whenever you are zoomed at 15% or 33% or any non-integer zoom level, we scale the blur size too but there are rounding errors (we can’t compute a blur over 14.568 pixels…) and the blur intensity cannot always be scaled according to zoom level.
Thanks for the explanation, Aurelien. Maybe a solution could be to split the image in smaller tiles and do some “high-quality” output when time is not such an issue (i.e. exporting).
Darktable also suffers from this defect: http://www.ericbrasseur.org/gamma.html?i=2
So basically you can’t trust the rendering at any zoomlevel below 100%. Might also be an issue here.
I’ve never experienced this issue with real world photo, for example I’ve got problem with rawtherapee and v4 ICC profile, my viewer don’t supports that kind of profile and it render the image darker than it should be.
Also linear downscaling has more stronger ringing artifacts, sure it’s not the best choice for every photo.
I have. Here is the RT issue including a RAW file:
I have some more examples, many show a similar pattern: bright (small) leaves against dark background. In these examples it IMO is quite extreme. I played with other files (exported to gimp and compared the scaled down versions and while the difference isn’t as pronounced it will be visible.
edit:
“Also linear downscaling has more stronger ringing artifacts, sure it’s not the best choice for every photo.”
According to the link it’s upscaling, which in a RAW editor hopefully isn’t expected to be done on a daily basis. (RT has a checkbox “allow upscaling” to (I think) prevet unintentional upscaling when entering too big numbers).
thanks for yor proposal. Exporting with “high quality resampling” definitely takes longer, but unfortunately doesn´t solve this problem.
I found the following workaround: Switch on the highlight clipping indicator (Luminance or any RGB) and, while in “fit to screen”-view, carefully adjust details in local contrast just below the edge of clipping, set highlights to 0% and shadows to 100%. Then use a second instance and do the same … and so on until you reach your desired amount of contrast.
Not very elegant, but works.
To enhance contrast in clouds even more use the soften module with multiply blend-mode.
Well, then you are testing a RAW processor with a JPEG image… do the maths. The gamma of the uint8 file encoding gets reverted higher in the pipe, so the early interpolation deals with gamma-encoded shit, since the pipe is designed for linear RAW…
