This preview vs output issue is not a new problem. The G’MIC plugin is known for such unreliability because it relies on the pixels that are sent via GIMP and then rendered. That is the basis for my question. Even if the zoom level isn’t manipulated, one has to be sure that the rendered image, if that is what the code is querying, is the same image that the processing would be working on to produce the output, with the correct colour management (and conversions and theories) I might add.
I am not convinced by the PS article. Dehaze inherently changes the colours. It is something that I have accepted since dehaze became a thing long ago. Ideally, the changes are corrective. However, the affect of haze is difficult to estimate well, so it is inevitable that there will be some uneven colour shifting and brightness distortions. I guess this is where GANs and other machine learning techniques come in.
The explanation from the previous bug report I linked to essentially says that the effect relies on the neighboring pixels. So if you’re viewing at 100 percent then the neighboring pixels are the same for viewing and export.
Of course, there may be a residual effect missing from the pixels out of view but I wouldn’t expect that residue to be strong enough to have such a dramatic impact. But that’s why I want to try it on a crop so that can be ruled out.
Hi’ everyone
A comment from a user point of view:
It’s important that the preview and the export are identical or very close so you are able to judge the result of your editing.
This turns out to be a challenge in many situations also and maybe especially when working with haze removal.
In RT many tools are marked with a “warning” (1:1) indicating that the editing result is only reliable viewed at 100%. The 1:1 view seems always to be correct.
In DT you get no warning and even the 1:1 view is not correct in the dehaze example in question.
No 1:1 warning is appended to the RT Haze removal tool and the result is excellent in both normal and 1:1 view!
Can the method described by @agriggio be adapted to the Dynamic Range Compression tool or other RT tools? That would be awesome!
I don’t know if the behaviour of the DT Haze removal tool can be classified as being in error but improvements will be certainly appreciated!
Below you will find screen shots of RT Haze removal in normal view. Sliders are set to max. (not pretty) but the views are very, very close!
hi,
if you have evidence of (significant) mismatches
between preview and output, please open proper bug reports. it’s hard to fix something when you don’t know it’s broken…
Hi’
Since there is no 1:1 warning stated on the haze removal tool it seems to me that the method used to construct the preview in haze removal is superior to methods used in other tools where a 1:1 warning is present. Maybe the method could be used in other tools so the 1:1 warning is no longer needed?
If you are looking for an example of the RT preview being different from the export you could look at the following (I don’t know if the code has been changed since the problem was posted or if the problem qualifies to be “significant”):
Output much darker than shown in editor docs
#4630 opened on Jun 21 2018 by olhof
Shouldn’t we move the RT related part of the discussion to a new thread in RT subforum instead of hijacking this thread?