I would normally agree with this, but enfuse is a special case here. It’s unique in that it’s about the only “multiple LDR in, tonemapped LDR out, no intermediary” solution out there. Enfuse actually often performs poorly (sometimes EXTREMELY poorly) with tiff input, especially “typical” TIFFs. (“typical” being 16-bit linearly encoded). Feed 16-bit linear TIFFs to enfuse and you wind up with the same problem darktable’s built-in fusion has.
Enfuse is usually the very last step in the workflow, so your concerns about 8-bit JPEGs being unsuitable to further editing do not apply - there is no further editing. Anyone doing further editing should not be using enfuse, they should be doing something like feeding multiple bracketed RAWs to hdrmerge. If they REALLY need to be generating an editing-suitable HDR intermediate from multiple LDR inputs, enfuse is not the tool - LuminanceHDR or an alternative implementation of Debevec’s or Robertson’s algorithm is needed. (Warning: OpenCV’s robertson implementation is vastly inferior to LuminanceHDR’s in most scenarios in my experience, even “easy” scenarios like performing response recovery on a simple smooth gradient which should be the easiest thing for a response recovery algorithm to handle…)
Looking at the one example provided by the OP:
Exposure weight of 0 is not suitable for this use case. The only scenario where you would ever want to consider an exposure weight of 0 is when doing focus stacking. (In which case, you only want contrast weight and nothing else). In fact, looking at the command provided, that command is only suitable for focus stacking.
The “highlights” input may still have been too overexposed, potentially due to the RAW itself being overexposed (clipped highlights).
I’ll try and dig up my Christmas tree example, but the workflow was:
Feed bracketed shots with hdrmerge to generate an float32 HDR DNG for input to RawTherapee (note: when I dig up my example, there will be artifacts from this, I’m working on trying to fix those bugs in hdrmerge, there are documented open issues relevant to the failure. In fact you reminded me that I need to see if filebin is accepting new submissions again so I can upload example raw sequences that trigger the bugs…)
Perform color/etc processing in rawtherapee
Generate a sequence of exposure-shifted outputs using a “typical” tone curve from RT - at this point 8-bit sRGB JPEG is fine unless the desired final output is a wider gamut.
95%+ of the time, RawTherapee’s “dynamic range compression” tool is more than sufficient. (It probably would in this particular shot). In those where it doesn’t (so far, in my experience, colored LED lighting that you WANT to have its color preserved) - Feed those exposure-shifted JPEGs to enfuse - so far the defaults usually are fine for me, sometimes I’ll bump up saturation weight but Christmas tree lights are an atypical use case here. In general if there’s a contrast issue (highlights pulled down too much, shadows pulled up too much), I adjust the inputs to enfuse before I’ll adjust the weights. For example, if the highlights are too dim, I’ll remove the most negative-shifted-exposure-compensation (dimmest) JPEG from the enfuse input. Note that in my initial adventures with exposure fusion, I considered saturation weight to be unneccessary/pointless but I was wrong - since most tone curve implementations will boost saturation in the high-contrast midtones, saturation weight is relevant.
I’ll try and take a crack at the OP’s original raw image tonight.