Interesting how turning down the RGB levels in white balance provides better highlight recovery than turning down the exposure
Yes, I learned that from dcraw, the grandfather of raw processors.
This should be made more accessible to Darktable users, I think. This is a pretty big feature that is a side effect of an unrelated module.
Thank you for sharing your process, afre!
I second @CriticalConundrum, that rgb levels in the white balance is a nice trick indeed 
I downloaded xmp from @afre. Renamed to afre.RAF.xmp and made a copy of oryginal file to afre.RAF. (yes, I know that RAF file name is inside xmp file)
Open dt with file and history showed about 63 changes… Took a look somewhere in the middle of list and modified something in Equalizer, so I lost all modifications above it. I decided to download xmp file again and overwrite the one I manipulated. I should get exactly what @afre made, but this doesn’t work. I tried restarting dt, removing file and copy freshly downloaded xmp, make a new copy of RAF file and copy xmp file… Each time I open dt with RAF file i don’t see last modifications. 
I looked up xmp file and last few changes are what I remember (from opening first time):
highlights
global tone map
global tone map
global tone map
base curve
But I don’t have them in history (shorten from about 63 to 58 modifications)
Checked this on other computer (without renaming files) and same thing: highlighted line 42, modified sharpening (lost everything in history above line 42), closed dt, download - overwrite xmp file and when I open dt again I have history with 42 lines only.
If somebody can confirm problem, I’ll make a copy of above to redmine.darktable. I have dt 2.4.4 on W10
Sorry @Gobo, I uploaded the .xmp with a long history stack that shows me trying a bunch of stuff. What you should do is press the compress history stack button. Even then, there would be 12 steps remaining. Notice how some of those steps are (off)? They aren’t steps either. In short, concentrate on which tools have been activated here:
Only 5 (actually 4 if you consider global tonemap as one step) are turned on, making it a total of 9 processing steps in the dt stack.
If you want to reread the xmp files, you need to check the option on Preferences for “look for new xmpnon start up” or soemyjing like that.
I thought a lot about this last night, and I think it bears pointing out that white balance and exposure compensation are really in two separate categories of tool. WB is an early and fundamental modification to the raw data, in some processors it’s done before even demosaic. EC is a discretionary tool, usually done in conjunction with some notion of the displayable image. Given that order, it makes good sense to me that WB has more influence on highlight ‘recovery’ because for one, EC is done after WB, so if WB lost highlights, EC is using that handicap as a starting point.
As a set of multipliers, WB by definition will push one channel’s data to the right. With G anchored at 1.0, one of either R or B is a number > 1.0, which will increase the original channel values. If that value happens to be at or near the saturation limit, the WB multiplier will likely push it into oblivion. An especially poignant consideration for ETTR.
So, to avoid losing data to the right in a WB operation, consider this: after the R and B multipliers are determined, transform all three numbers with a multiplier determined by 1.0/highest_multiplier. I think that’ll transform all three in syncronization, and make the highest multiplier equal to 1.0, so then WB won’t be pushing any data higher than it already is. Recover highlights by not losing them in the first place… does this make sense, @afre?
Edit: Ever write something, post it, then read it and realize you were not thinking of all the considerations? So, for my 2nd paragraph above, maybe not so likely as the >1.0 multiplier will be working on lower values relative to G, so not so likely to push them over the top. I should have my coffee before I post… 
1 Like
That is a part of the equation. There are downsides to normalizing the multipliers to <1. (Re)read the RT AMaZE thread and others like it for more insight.
PS Speaking of RT, you may have to dial back certain controls before you can use the recovery tools, so we have new users remarking that recovery isn’t working, etc. I say this to point out that each raw processor may take a different approach.
This time I did a full round of edits and completely forgot about Photoshop.
1 - RT
- Exposure and Dynamic Range Compression to recover both shadows and highlights
- Sharpening and Impulse Noise reduction
- Wavelets (essentially, noise reduction and highlights compression)
2 - Gimp
- Applied chroma/tonality split edit according to Elle Stone tutorial (NOTE: I think this step is not necessary and the same results could be achieved either in RT or DT, but I’m practising the tutorial)
NOTE: The intermediary results from steps 1 and 2 are rather dull and flat. But they carry with them more information from the shadows and highlights (and chroma, from Gimp). The last step below is where I adjust all that information according to my taste.
3 - DT
- Final tone mapping
Here’s the result:
This is a nice result!
1 Like
Thanks, I liked it too, it was fun playing with this photo.
I hope @andrayverysame didn’t give up his migration to foss 
Hope so. The steps you list sound complicated though. 
Remarks
1. Could you please share your pp3, xcf and xmp?
2. By tutorial, I am guessing the autumn one. Note that her tutorials try to be scene-referred. Therefore, doing these steps in 2-GIMP (e.g., after DR compression) defeat this objective.
Agreed. Every time I end my edits I get that impression…
Here they go:
1- _DSF0498.RAF.pp3 (10.5 KB)
2 - Gimp’s xcf is huge (1.4 GB!). Uploading to filenet.bin. When it finishes I put the url here (but it’s nothing more than the steps outlined by Elle on her tutorial, a bit simplified on the Lightness Group)
EDIT: the file is here: https://filebin.net/10vg3nighjreg383
3 - _DSF0498-1.tif.xmp (10.7 KB)
Correct, this one
Why?
Once a workflow is no longer scene-referred, there is no point in doing scene-referred editing.
@afre Just to check my understanding of it.
When you say it’s no longer scene-referred you mean that by doing any kind of tone mapping edit I change the original information about color and light that is inside the raw file, right?
I am not well-versed in scene-referred. And, if you read some of the threads, it is kind of a controversial subject.
It is not about changing things per se because you do that when you calibrate and profile the colours and interpolate the raw pattern, etc. Scene-referred, if I understand correctly, is being as accurate to the scene as possible. In scientific papers, it is referred to as ground-truth. Scene-referred differs from display- or print-referred, etc. Once you do things like compressing the dynamic range, it is no longer scene-referred because the only reason you are doing that is to appease apps that cannot handle HDR or the so-called unbounded values.
1 Like
Even if the first step result was saved in a wider color gamut (REC2020), like I did?
Yes, a wider gamut only lessens out-of-gamut results and does not account for scene integrity or colour deviations. Of course, throughout this thread, I have tried to make things simple. For more info (and debates), see: Unbounded Floating Point Pipelines.
@afre thanks, I’ll digest that thread sooner.
btw, the xcf file is there. I updated the other post where I linked the files.