They are encoded in log, if you really want to see that as an encoding, with a middle grey value (output) targeting the correct grey value of the output space (46% if you set gamma 2.2). Out of filmic, the RGB data are ready for display. But we can’t bypass the output color profile in darktable, which applies the ICC profile gamma/OETF no matter what, because it expects a linear pipe, so double-up.
The correct way to do it would be to convert from Lab to output RGB before filmic, apply the tone mapping in this space, ditch the in-module gamma workaround, copy the filmic output directly to the JPEG/pixbuf and tag the file with the gamma corresponding to the grey mapping. But darktable’s pipe doesn’t allow that now. So, the current option is a trade-off until clean-up arise. Last week, the modification allowing a full RGB pipeline in darktable (along with modules re-ordering) has been merged in master, so I will finally be able to do that properly.
Your fix is a good looking option, but does not preserve hues and defeats the original purpose.
It does no such thing. I don’t know where you get this idea, but it’s dead wrong.
We get a log transfer function.
We get a double up: the middle grey gets pushed to 72%.
That’s actually the opposite that happens. Filmic’s output is already display ready, but I can’t send anything to display directly, so I have to fake a linear output.