It is sublime for the blue skies, but awful for the cyan clouds and building highlights. View those at 100%. I don’t know if RT has a sat/luma curve that allows you to just desaturate the cyan out of those clouds? If not, then I would wish to export two different versions, and combine them together with masks.
Aurelien’s demonstration looks to strike a balance between the two. Nicer blending, cloud (highlight) colour, and no blue tree fringing, at the expense of some blue sky.
It all about your expectations: filmic tries to bringt the information captured by the sensor - or more precise in the linear pixelpipe - in a range that can be displayed. It isn’t intended to add information that wasn’t available.
So this is a different approach and far away from correcting bad colors. If you want to do this, you have to do it yourself earlier in the pipe using the appropriate modules.
Don’t expect filmic to be magic
Overall impression after playing with it yesterday evening and this morning: Very nice and it is an overall improvement compared to the previous version, which wasn’t bad to begin with.
A lot has been said already in the above replies, so I’m not going to repeat those.
I am going to mention the extreme luminance saturation slider: The de-/resaturation handling is much, much better in this version.
One, minor, interface related “issue”: Shouldn’t the reconstruction and look tab change places?
scene and look are the 2 that will be used most. The reconstruction one occasionally and the other 2, once set (be it for specifics via presets), will not be used at all or too often. The tab order should reflect that in my opinion.
The tabs are organized in the order they should be used, given the order in which operations are applied. The logic is not in the most used first, less used last (except for the options). It’s easier to bypass one less used tab and go to the next, than to remember which comes when, if you don’t know the underlying code.
Actually, doing magic using this method should be possible by making the reconstruction process iterative, so we propagate the gradients from near to near at each iteration for each wavelet detail scale. However, if we go this way, you can kiss your realtime preview rendering goodbye.
Would I neeed to turn off the Highlight reconstruction module when I want to use this?
Since Filmic is quite late in the pipeline, a few modules would not benefit from the recovered highlights. In particular, how well does this work in terms of denoising?
If you want to recover some texture, yes. But for those hardcore cases where a large area is blown, and there is no hope, and/or highlights are made magenta, you may keep the highlight reconstruction in clipping mode to help filmic. But be aware you will not get the details back.
Actually, it’s the inverse: you want to reconstruct a denoised image, otherwise you might end up copying the noise and chromatic aberrations from one channel onto the others. Clipped pixels are not data, so it’s dangerous more than anything to let earlier modules play with these parts. They should ideally be discarded entirely by early processing steps.
Today’s version adds an extra step of reconstruction (in tab “options” → “enable high quality reconstruction”). It’s basically a second wavelet reconstruction but over ratios (RGB / norm), that helps a bit more with magenta highlights and fringes. Highlights should be whiter with a softer transition. However, it adds a 10% performance penalty.
OpenCL is disabled on the filmic v4 experimental branch, since I don’t have written the OpenCL kernels yet, so everything goes by the CPU for now. I’m waiting for more CPU feedback in case the algo needs tweaking, before starting the OpenCL duplicate.
OK, but I think / I feel that filmic 4 (w/o open cl) is slower (GUI or image preview is less responsive) than filmic 3 (w/o open cl) (or maybe the compilation options make the code less optimized ?)
EDIT: the loop that is supposed to count the number of clipped pixels and bypass the reconstruction if there are non always throw something, so the wavelets decomposition happens even if no pixel is clipped. That’s what is heavy. I’m investigating that.
Great work. I did not test as I am on Windows and really don’t want to mess about trying to get it to compile but it is great to see the darktable highlight reconstruction being worked on. The magenta issue is one reason I just moved away from the tool.
Does this wavlet reconstruction method try to rebuild natural color of the area similar to color propagation? In so that colors are retained until you hit the pure white clip?
One of the biggest issues I noticed in a lot of commercial raw processors is the ignorance of the color gradient into the clipped area causing everything to get muddy.
It is a shame that this adjustment could not just be rolled into the highlight reconstruction module but I understand why it can’t be. The two different workflows linear RGB vs non linear make a bit of a module mess thankfully you can customize what is shown.
