Holy highlights recovery!
IMO, I think the light reflection spots were probably apparent in real life. Yes, they are blown, but with a little highlight recovery, I don’t think they ruin the photo.
1 Like
Sure i agree with you. The point is in an ettr perspective they should be preserved or not?
Imho… depends 
In this case you could lower the exposure by 1/3 or 2/3 without problems, but in other situations the choice is more critical.
Dark table also often grabs the wrong raw white point which will affect HLR correction and raw overexposure readings so it’s best to confirm DT is getting that right… I’m not at a PC so I can’t check but it’s worth checking
1 Like
I’m getting a weird result with this raw, using 4.2 flatpak, Ubuntu 20.04. Is anyone else getting this?
With a few basic settings, ok -
Now switch on highlight rec. using LCh - !!!
With inpaint opposed -
Any ideas?!
Actually exifs reads MaxWhite15360, i’ve measured 15871 from a testchart white patch but the result it’s the same.
Basically don’t use any of the old methods. They are not exactly compatible with scene referred editing… Based on what they assume 50% is and how they address clipped channels based on a definition of white from the legacy wb. AP demonstrated it nicely in a video but also at a time when the only option was to use filmic HLR combined with Laplacian… Watching from about min 23-30 he explain the issue and so taking that into account and then substitute one of the new methods for GLHLR and it should generally be a better less artifact prone result esp if you use the modern WB workflow
LCh has been reliable forever for me!
One thing though, the image is quite out of sRGB gamut right from the start. And is it not odd that most of the image is in the top 1 or 2% of the chromaticity range? -
As it comes in its not that bad… not much is out of gamut from the working space which would be what cant be mapped down to srgb by the output profile… DT has a issue with the display profile… changing the histogram display and working to all be the same show the true out of gamut…
Ignore the tone of the comments but it seems AP has decided to tackle this issue in Ansel as he is back to coding there after a big break he is getting very active again…
Shown as full incase the partitioned option displayed by saturation only is not clear…
Setting all to sRGB websafe gives me this horror show -
and Adobe RGB compatible gives
Your last screen grab is rather dark? - is it useful?
This is all rather complicated, I think I’ll bail out!
So here is the deal the display profile comes in before the histogram profile. My screen is dark because I set the display profile just for the gamut check to linear rec2020 … I think for darktable the srgb profile will work also because it is unbounded… But to remove this possibiltiy at all you set working, display, and histogram to linear rec 2020… now when you check the overexposure set to full gamut you can see what in the pipeline is gamut clipped… When you select the gamut clipping tool that uses what you have set for softproofing… if its srgb then what it shows is all the gamut that won’t fit in the space…but this is handled by color management and mapped…otherwise if you worry about this then you might as well set it to srgb for everything and that would not make sense… So in a way the gamut warning shows you what will have to be mapped and the overexposure gamut will show you what cannot be accurately mapped to your desired output… I hope that makes sense…
EDIT
So in my mind and I could be wrong but set-up as described above with your softproof profile matching your export or output and your histogram profile matching your working profile and then confirming that your display profile is well behaved by checking what impact changing it to linear rec2020 has… it should be none if it is then that display profile distorts true gamut readings… So then from this diagram A would be rec2020 and B would be SRGB. The gamut warning tool would show the areas shown here as out of gamut and needing to be mapped as well as any area’s beyond that and the overexpose gamut would show you any data clipped outside of the A color space ie rec2020 and so not able to be correctly mapped by the colorspace conversion during export… for sure others here are far more knowledgeable than I but this is how I understand it to work and I think AP has decided to remove the histogram profile in his fork and try to tackle this issue so the display profile cannot be an issue ever…
It’s a Sony file with 4.2, that gets it from the maker notes, so it’s alright.
Still, in highlight-problematic files I often do a double-check anyway (to find magenta areas of blown parts, and if they are neatly indicated as clipped).
1 Like
It is worth checking for sure. One recent playraw had 16000 or more and the exif was like 12500 or something for specular… I think it was a Canon file… loose recollection but a big difference in how all the math would work that relies on the raw white point…
I like your “shadowy” look… 
