Exposure Fusion and Intel Neo drivers

[Entropy512 (Andy Dodd)]

@anon41087856

@Entropy512

Increasing the time I spend for a large number of images which I’ve exposed to preserve highlights from <20 seconds per image for a rough first pass to >10 minutes for something I’m happy with.

The new module I’m working on (remember, that was the topic of this thread) makes a dodging and burning mask from a guided filter in 50 ms. Every other method will ruin colours in unpredictible ways.

OK, I played with it. I can’t be certain whether I like the results from it or a fixed enfuse workflow better yet. It’s still significantly more effort (adjusting 5-6 sliders, vs flipping a switch and twiddling one slider). In terms of potential theoretical visual improvements vs. effort required, I’m not a fan so far.

@Entropy512

Then why does the module exist in darktable?

Because of 10 years of legacy to stay compatible with. You don’t have to use every single module in the soft. It will go out for darktable 3.x branch if we decide to break up compatibility with the 2.x branch (which would be sane, I guess).

I’ve been using the enfuse approach for years, I’ve been very happy with its results as much as you may hate aspects of the algorithm. It happens to have been “baked in” to the basecurve module, for better or for worse.

@Entropy512

So the darktable team added a feature inspired by another program, specifically cited the program/algorithm, made a blog post about it - but failed to properly implement the algorithm in such a way that it’s impossible to get visual results even remotely resembling the algorithm claimed to be their inspiration.

You don’t get, don’t you ? Working gamma encoded stuff (aka display-referred) is what Photoshop, Lightroom and all the legacy image-processing stack is doing. Guess what ? It sucks at HDR ! Why ? Because it breaks light transport models, so it messes up colours and produces halos while blending. So, instead of patching rotten algos from another era, let’s embrace the future and get a chance to do things properly, in scene-referred space, with linear operators, where 18% or 50% are just regular luminances.

Because, yes, I have spotted halos in https://mericam.github.io/papers/exposure_fusion_reduced.pdf (p.6), and I told you they would happen even before looking at the paper (sure, they hide them to some extent by working on a multiscale pyramid, but that doesn’t make it right). Get your theory right, then unroll the algo, not the other way around.

I’m not seeing haloing there. Unless you’re talking about the low-frequency artifacts they explicitly state for that particular image as being a known (rare) corner case.

The only time I’ve seen haloing with an exposure fusion algorithm derived from enfuse is with the current state of darktable master (with one example given in an image posted above). Guess what? That was the one which was entirely processed in linear space.

@anon41087856

Why is darktable now taking 4x as long for my workflow?

Self compiled or packaged dt ?

Self compiled - for months I assumed it was a mistake on my part, but the reality was that it was the result of going from a release prior to Neo being blacklisted to one afterwards.

Same thing will happen to any user who updates from an older prepackaged version of DT to one after the blacklist. All they’ll see as a user is - darktable is now significantly slower, at least on mobile Kaby Lake CPU/GPU combinations such as the i5-7200U and the Neo driver packaged with Ubuntu 19.04.

Disable the blacklist - boom, major performance increase. Users shouldn’t have to dig into darktablerc to make it perform well.

@ggbutcher

I’m not a dt dev or user, but I’ve been here long enough to know that if you have a cogent patch to dt, it will be considered. You’re sparring with a person who has demonstrated just that in his efforts to re-orient dt, and others’ thinking, toward a linear processing pipeline. A lot of the thinking behind that has occurred in threads on this forum; you’ve jumped into that context with a few specific assertions without a real understanding that context. That goes for the module performance, and very likely for the OpenCL consideration.

One thing that needs to happen is that this thread should be teased apart into its separate topics.

OK, I need to head out to enjoy today’s nice weather, but it sounds like that’s a good idea. Either a mod can split posts regarding enfuse to a different thread, or I’ll start a new thread when I get back.