I’m on Win7 and yes, I’ve had a play with it. Like you, I’ve found the results wrong whatever I try (while keeping the haze removal settings). Various things get the preview closer to the export (eg. demosaic - ppg) but it still isn’t right. I’ve also found exporting jpgs and tifs gives different results.
So no, I can’t find anyway of correctly previewing/predicting the export results for this image. But I’m quite new to darktable so maybe one of the more experienced heads will come up with something.
Thank you for the article.
As I undertand it we must consider two different problems:
Haze removal causes color shifts but you can readily examine these color shifts in the preview. The article describes how to get around this using several layers which is not possible in DT. These color shifts are apparently inevitable using haze removal, especially if you push the sliders to max. I don’t consider this a problem…
The problem is that the export is different than the preview in areas within gamut and out of gamut. This seems to be a bug.
I don’t know if this is the case in the windows version only. So I’m hoping for feed back on this issue from non-windows users of DT.
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!
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?
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
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.
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.
