I am really surprised about this. We had some problems especially with sony cameras about wrong white-point exif data but those are mostly resolved by now. So if you have a camera with such problems you can either
let devs know about it via github so we can try to fix it in rawspeed or libraw
do some specific presets
What we don’t take into account here is “where in the signal curve does non-linearity start”. Those data might help but except for DNG specs they are mostly hidden in manufacturer specific exif data. Plus that doesn’t tell us how the maths would be.
You are aware of the “clip visualizing button” in HLR? If you suspect that your white point might be wrong it’s very easy to see it here. And changing the clip value here is fine in the vast majority of cases, only very rarely you have to set whitepoint.
If you are interested in this field and would like to start developing in dt, it might be nice to do statistics and visualize the power spectrum in the rawprepare module. But i suspect it won’t help a lot for developing images and might be very cpu hungry to do that in realtime.
Selecting the raw black and white points is pretty simple (if you have to touch that module; and once you have proper values, they are put in a preset).
Otoh, picking the best threshold value in filmic can take some time, also due to interactions with other values. But as the “best” result is also a matter of taste, that will be very hard to reduce to a simple button…
EDIT: as you can see, I’m not at all convinced adding a picker to either “raw black and white point” or “filmic threshold” will solve any problem. But as some seem to think that any button in the interface has to be used, such buttons could actually cause more problems…
Is it really about roll-off? Roll-off suggests a curve-like, pixelwise operation, doesn’t it?
How about simply highlights? (highlight <anything> is probably too long for the GUI.)
An additional problem with the current name, reconstruct, is that it’s a verb, while all other tabs have noun labels.
While we are at it, is the section header highlights clipping really appropriate? It does not clip anything (abruptly).
It’s possibly just a matter of naming things. I reused the terminology from the manual about the “reconstruct” tab:
“This tab provides controls that blend transitions between unclipped and clipped areas within an image and can also help to reconstruct colors from adjacent pixels.”
So my understanding is that it does both a global “rolloff” (which is run independently on each pixel) and reconstruction (which uses adjacent pixels to try and estimate what the scene radiance looked like on the clipped pixels). Admittedly I haven’t dived yet into the code to understand exactly how it’s implemented.
I, myself, don’t. So if that’s a fixed thing for most that’s great.
That’s my main issue. It’s difficult to know that beforehand for a given sensor because that depends entirely on the relationship between the sensor’s spectral sensitivity and the spectrum of the blown highlight I’m trying to correct.
I am. And yes, it’s useful as a debug tool, but ideally it shouldn’t be needed for 90% of the cases so that I can focus on making the image look as I want…
Yes! Another aspect is that it’s very difficult to integrate highlight correction in a preset right now, because of all the interactions. I’m not sure exactly how I’d solve that right now, so my idea of adding a button is perhaps just a band aid…
As long as the name doesn’t suggest that anything is reconstructed where that isn’t the case, I’m fine. At the end of the day, those names are labels to indicate a function. Of course they should have some relation to what the function does, but other than that the exact name isn’t too important.
So something like “highlights” for the tab, and “highlight blending” and “enable highlight blending” for the tab tittle and tick box, resp., would work for me.
I don’t think it does. Highlight Rolloff is just the transition from the surround scene into blown out highlights. Mostly talked about with film photography and videography, but I don’t think there is an implied curve there. I view the term as qualitative, much the same as bokeh.
That is not really a problem. HLR inpaint opposed and the rest falls into place.
I am sorry if that sounds like a brutal answer, but here it goes anyway:
By exposing correctly.
I have just gone through to find settings and readings for my main cameras in relation to my preferred settings in darktable. If I stick to my derived rules, there is nothing to do. Highlight rolloff and dynamic range is now better than anything I have ever used before and that includes tons of film back in the days. Spoiler alert: film is not better, it’s just way more foolproof because the whole technology has been designed to be an integrated workflow.
Old digital stuff looks awesome or meh, depending on how well it matches the current ideal workflow. If you have been a very strict user of ETTR you should be fine.
I often encounter shots which are ETTR except for some light spots, and exposing for those highlight will just drown the rest of the shot in noise. What you say makes me think that perhaps I’ve overlooked something. I’ll try to collect examples, maybe that will show me that in fact there’s no need to modify Darktable to find a correct preset for these kinds of shots.
Well, photography will be a compromise until we get those 50 stops dynamic range 10-4000mm f1.0 lenses with 500 megapixels in a pocketable camera. And even then, someone will find a use-case that is outside of that system.
But one thing is for sure … if you absolutely need those lights, then you gotta capture them. Because there is one thing in digital that is absolute: overexposure has no data to work on. If it’s gone, it’s gone. You can kind of re-invent some of it with software, but that’s it.
On the other hand, if the rolloff is nice, who cares.
And if the shadows block because you need the lights, well, so be it.
Or you need to photograph brackets.
In the end it is a management of expectations and possibilities.
Couldn’t say better All reconstruction in HLR is sort of “best guess”. And we are really good in dt atm. I just go with default for 99% of the images with any problems at all. A few are more tricky. In my experience those with difficult (non-natural) lighting or large parts with smooth gradients into blown out skys. That’s for segmentation
But then we also needs screens with those 50 stops dynamic range…(and what about prints? I don’t see paper get much beyond current dynamic dynamic range)
So. Back from holidays, I was able to look a bit more into my clipping usability issues and found a couple of things.
I did say that I have a camera that didn’t cause problems where I had to change the white point setting, right? Wrong. It does so, sometimes, and it was probably what was driving me mad.
I exhibited a couple of examples since then. This one is for one channel of the RGBG matrix (I think that’s blue, don’t quote me on that, but the clipping point is the same on all channels) that is clearly saturated a good ~15% below the advertised white level:
This completely explains why I had some shots where the clipping mask in the “highlight reconstruction module” was randomly black despite obvious clipping, and I had to tweak the clipping threshold for it to be correct again. I’m not sure what causes this - I could reproduce it reliably at home with ISO100 but not for other ISO values, and I have several existing shots that exhibit a clipping point that’s either much higher than the advertised value or much lower.
I’m assuming Canon does something on the 550D that’s too clever for their own good, but I’m not sure exactly what — and I will probably never know.
My current take after playing a bit is that:
Either Filmic or raw higlight reconstruction should work now that I know that sometimes the white point is off — that makes me much more confident in using these tools.
For complex cases I played with color balance rgb with a mask so that I can give the tint and brightness I want to the clipped areas — I like it : it’s a bit clunky but is much more controllable than filmic.
As some of you fine folk said earlier reconstruction is a last ditch effort for when I messed up when exposing the scene but still want to salvage the shot, but it’s nice to have options!
I think at some point I will revisit adding options to the UI to make these cases easier to navigate, but I need to figure out a nicer way to use existing tools first without cluttering everything!
I came across this post… I think DT usually uses the same value per channel but Canon and maybe others don’t … Might be a bit of this that you are experiencing…
Also they vary it with iso and that might also not be captured by DT … you would have to check a few files…
If what you show in the image are the values for one channel of the raw file, then no, it doesn’t explain anything in what happens in filmic.
The filmic “threshold” value is relative to the filmic white reference as stated in the manual.
Just try with a correctly exposed image (no clipped highlights): your “clipping mask” will change for a given threshold when you change the filmic white reference or the value of the exposure (in the exposure module.
Too much has happened between raw black and white point and filmic to establish such a link as you make.
Otoh, if your “raw black/white points” are off, you should apply a correction in that module, as that’s what the highlight reconstruction module uses to decide what to correct. As black and white points should be fixed for a given camera/ISO combination, presets are your friends here. (even if dt changes the defaults for your case, that isn’t a problem).
@priort : in that excerpt you show, I noticed that the white points vary per channel, but by less than 1%. Is that really enough to bother with setting white points per channel? (black point is different, but dt already has 4 black point values).
For the 550D camera, dt uses the white point value from rawspeed. Rawspeed has a single value for the white point:
<Sensor black="2048" white="15831"/>
But I dont think this is the correct approach/value for low ISO. Other canon cameras with a similar sensor use a different white point when the ISO is low. See, 600D:
In summary, the white point is incorrect and the HR module will yield incorrect processing. Your options:
Submit an Issue or a PR in Rawspeed with the correct white values per ISO. You can likely copy/paste the exact line from the 600D section. After merging, then dt will use the correct value for future users too.
Since dt 4.4, you can now create auto applied presets based on different criteria to most modules. Create a preset in the Raw Black/White Point module that changes the white point value for that camera and that ISO. The 13584 seems correct.
Cool, thanks @g-man and @priort for the links! I was expecting much less guesswork on raw processing for such an old sensor, and I definitely wasn’t aware of the differences between RawTherapee and Darktable/rawspeed. The presets sounds like a doable workaround even if it’s not very user-friendly, so I think I’m going to try and do that.
@rvietor Everything you’re saying is correct — now I understand this a bit better after this thread!
All reconstruction in HLR is sort of “best guess”. And we are really good in dt atm. I just go with default for 99% of the images with any problems at all. A few are more tricky. In my experience those with difficult (non-natural) lighting or large parts with smooth gradients into blown out skys. That’s for segmentation 
