Thanks for clarifying and sharing. Good result based on good principles. 
My problem with his image (that I noticed right away) is that there seems to be something similar to a light leak or fade. There are patches where the tone changes in an odd manner.
If you reread my comments (from 15 days ago by the way) - I surmised that using exposure clipping was potentially causing the haloing (exposure clipping was active in that particular image).
One could argue that the local contrast enhancement operation Pierre used fundamentally violates light-transport consistency. I’ll need to run some tests, but I wouldn’t be surprised that you could cause haloing by abusing it. After all, if you look in darktable source code, “local contrast” is CLAHE, and the original author of the algorithm (Karel Zuiderveld) has stated that CLAHE can cause haloing. Of note, using tone equalizer without that followon step provided extremely unnatural results for me. So it appears that achieving “natural-looking” results requires violating Pierre’s rules somewhere in the pipeline.
I’ve only seen haloing in exposure fusion in three cases:
Clahe is deprecated, the new local contrast is called bilat.c and uses local laplacian on a multi-resolution pyramid as default because, indeed, the bilateral filter is anisotropic and does not behave (especially when used in Lab…). Also, in this particular case, the bilat module is put at the end of the pipe, aka when we don’t care about light transport anymore. Same image without colour balance and local contrast:
Essentially the same, just less crunch.
Everytime I see something bad when the theory says “it should work”, there is indeed a programmer-induced bug.
Probably because your clipping results in slope/curvature discontinuities of your transfer function between layers (which should not be a problem in linear space).
Means broken algo with lucky parameters. There is no excessive EV shift, just EV shifts that makes the flaws of the method pop out.
This is something I don’t get. Bear-of-little-brain here thinks EV should be a straight multiplication. No “pet-tricks”. Am I under-thinking this?
In this case, yes, the EV shift is just a multiplier.
However fusion takes multiple images generated with an EV shift and blends them together, based on a set of calculated weights. What I’ve seen is that if things DO break, they happen when the generated images are “too far” apart. (In the “traditional” enfuse approach, this would be if you set your bracketing steps too far apart.)
I haven’t abused the original enfuse implementation yet to see how it behaves in such situations - maybe this weekend I’ll get some time to poke at it again? Interestingly, Google has been cited as performing their algorithm slightly differently than the darktable fusion approach here - instead of generating 3 or more images and blending them together with weighting, Google is supposedly generating one image with +EV shift, fusing it with the base image, then iteratively doing the same thing a few times (so at all times only two images are being fused with each other, but the “base” image in successive iterations has had its dynamic range compressed with previous fusion steps.
I did find a potential difference between darktable’s blending and enfuse’s that may be a contributor to some of the oddities observed:
In enfuse, the mask weights are normalized (such that the total for of the weights for any given pixel is 1.0) before the gaussian pyramid of masks is generated.
In darktable, this appears to be happening after the GP is generated.
Ah, apologies, I forgot we were talking about blending…
A try with ART. Mainly using the Log encoding tool.DSZ_0619-art-1.jpg.out.arp (9.7 KB) ![DSZ_0619-art-1|690x459]
My 1st few steps with DT 3.
DSZ_0619.NEF.xmp (12.7 KB)I’ve managed to compress everything into display range, but no luck with contrast. My jpg is looking very flat. Also, many areas are out of range and gamut. I’ll have to go through Aurelien’s video a few more times!
DSZ_0619.NEF.xmp (13.8 KB)
DT 3.9
Edit:
It seems to me, from my recent posts, that Chrome doesn’t make the monitor profile compensation correctly. In Chrome i get the images darker then any other software i use.
Any ideas? Anyone can confirm that? 
Does Chrome have any colour management settings that you need to (re)adjust? I don’t know: I use Firefox. What I would say is that your image is indeed on the dark side.
Thanks, i think Chrome settings are ok, but images are darker. It has been happening since I profiled the (ugly} monitor…
Quick RT test using the recent cam 16 with sigmoid local edit. Done on the laptop not workstation so not the best screen…
WB, Cam16 with some chromatic adaptation to make warmer, abstract profile tuning,
DSZ_0619.jpg.out.pp3 (17.8 KB)
The overall image looks fine to me, maybe a bit dark in the darkest shadows. My surmise is that your display profile doesn’t have the right TRC (tone response curve); if you did the profile in a bright ambient light the profiling software might have tried to compensate.
IMHO you did a really nice job pulling the exterior levels toward the interior ones, not at all HDR-ish.
I think that jpg is larger (mb-wise) than the original raw 
Maybe this post (Web browsers color management) or even the whole thread may shed some light?
I.think this is the problem! Accordingly to display Cal, my monitor gamma is about 2.4… Thanks
Thanks @XavAL, i read all the thread; if i understand i would try to reach gamma 2.2 for my monitor to “please” Chrome…
If I’m not wrong, you should profile your display with a sRGB TRC (gamma). That’s not exactly the same as TRC 2.2.
