Hallojsa, @obe!
Sorry, I am not skilled enough to give any advice 
However, the PS article gives some ideas (thank you, @RTaubold)
on how to fix the problem – but I would rather have a solution
which would warn in advance, so to speak. Det ville være skidegodt, Egon!
Med venlig hilsen,
Claes fra Lund, Sverige
Usually I try dehaze with HSL lightness blending mode. Sometime it produce better result. But a bit “dirty” look
Hi’ @Benja1972
Thank you very much for your excellent advice. When I use the HSV Lightness blending mode the export and preview are much closer.
Hi’ Claes
You get me wrong.
I think it’s a bug that the preview is very different from the export. This should never be the case. Do you agree? If yes, what steps can I take to get this problem fixed?
Hallojsa!
If you think it is a bug, then you file a bug report:
Does this bug report sound similar to what you have found?
https://redmine.darktable.org/issues/12290
Mvh
Claes
But the haze removal effect is almost lost. You may as well just turn the strength down.
This bug report offers an explanation:
https://redmine.darktable.org/issues/11921#change-34541
Not sure I’m convinced…
hi,
the explanation makes perfect sense. RT had the same problem, which I solved by using a fixed size image (independent of the current zoom level) to estimate the ambient light. (in fact, now that I mention it, I don’t remember whether I back ported this in the official version, I have to double check – though this is not relevant here…).
bottom line, I think using a downsampled image to estimate the ambient light would be a way to fix this, assuming this is feasible in darktable
From this explanation I’d expect to get a decent preview at 100%… which I don’t.
Is 100% considering the whole image or what is rendered?
just read the code, the ambient light estimation is different between preview and export – if I read it correctly, that is…
100% is 1:1 preview so it’s just what fits on the screen.
I’m currently trying to test with a small crop so that I can preview the whole image at 100% but so far I’m getting an ever increasing range of random tangents… But I’ve still got a few more things to try.
That sounds like a very promising lead
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?
