Well yes, that’s the point. I was thinking that you’d expect the out of gamut colours to change as they’re moved to the output colour space. But you wouldn’t expect the dramatic changes seen in other areas of the image. I’m specifically looking at the lighter patches in the distance.
Anyway, even bringing the whole image back into gamut doesn’t solve the issue.
However, changing the basecurve (are you using nikon like alternate?) to nikon like seems to get close. View at 100%.
Hi’ @Marctwo
I get the impression that you have done a test on your own system. If so, what platform do you use and what did your test show?
When I change the base curve from “Nikon like alternate” to “Nikon like” then the preview and the exported image change like they should and the preview is now closer to the export especially when you look at the sky in 100%. The result is closer but there are still a lot of differences also in areas within gamut. Don’t you agree?
It’s essential that the preview looks as the exported image. If not, why should you spend time using editing software to fine tune your photos?
Is this a “real” problem only occurring on the windows platform and using haze removal? And what steps can be taken to properly document and fix the problem?
Let me add to @obe’s questions:
What would be a good way to spot this
problem/behaviour already in the preview
(i.e. before export)?
Some kind of soft proofing?
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.
I don’t use darktable, but GIMP’s de-haze does the same thing with color shifts. And it’s not limited to GIMP. I found the following Photoshop article that addresses this issue: A Quick Cure For Dehaze Color Shifts With Photoshop - John Paul Caponigro
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.
Hello Claes
Look at this feed back:
What to do now?
Olaf fra Copenhagen, Denmark
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