Yes, this is the number one thing I want to know about. So far it seems to just make things worse by default, but its probable I just don’t understand it, and an explanation will clear things up.
If your camera white balance was not accurate when you took the shot, then image quality might be second-best in certain modules. I think this change was good in terms of basic objective - better image quality - but it is poorly implemented and Darktable deserves better. There’s a discussion I had about this with developer Hanno - it goes round the houses a bit! - Introduce as-shot to later D65 workflow (improved highlights) by jenshannoschwalm · Pull Request #15602 · darktable-org/darktable · GitHub
How so?
For photos with no blown pixels, I see no difference (left: ‘as shot to reference’, right: ‘camera reference’ (like 4.6)):
However, here is a shot I intentionally overexposed, and then used segmentation-based highlight reconstruction (filmic etc. are disabled to avoid desaturation of highlights, making the effect more clearly visible).
Left: ‘camera reference’, right: ‘as shot to reference’. Notice the magenta tint on the left, contrasted with the more greenish/yellowish (but I think in some sense ‘whiter’) on the right.
1 Like
Kofa, you didn’t mention your camera white balance. If you set it well then one should get good results with A.S.T.R. with the modules that depend on a good WB - highlights, denoise and a few others I think. But if the cam WB was inaccurate, these modules will suffer apparently. In your second example, neither side look good to me!
Sure, neither are ‘the real thing’, since HL reconstruction is just ‘guessing’ what was there.
reconstruct in LCh would normally produce grey tones (it tries to recover some luminance detail, but not colour_). However, its grey R=G=B are then colourised when WB is set to camera reference:
But not by as shot to reference:
Kofa, I’m doubting this is the case, based on a bit of an experiment just now. I’ve taken an image with an overexposed area, windows, and used only White Balance, Highlight R. and Exposure. I’ve set recon. in LCh and reduced exposure so the area is not burnt out on my screen. As I change Temperature from low to high, the colour responds, going from blue to yellow-orange. So regarding the different sample readings, this is perhaps nothing to do with ASTR processing, and simply down to the differing white balances - (6501,1) vs. (5329, 1.011). It seems to me Highlight R. largely preserves the incoming temp and tint.
If I read this correctly, it should deliver monochrome (which I interpreted to mean grey) output – see the part in italics.
reconstruct in LCh
Analyse each pixel with at least one clipped channel and attempt to correct the clipped pixel (in LCh color space) using the values of the other (3 for Bayer or 8 for X-Trans) pixels in the affected sensor block. The reconstructed highlights will still be monochrome, but brighter and with more detail than with “clip highlights”. This method works fairly well with a high-contrast base curve, which renders highlights desaturated. As with clip highlights this method is a good option for naturally desaturated objects.
(darktable 4.6 user manual - highlight reconstruction)
1 Like
It seems to be altered by tint, at least at extreme values. Neutral at T = 1921 K, tint 0.316:
Still neutral at tint 0.995:
If I keep increasing the tint value, it turns blue:
Tint: 1.207
Tint: 1.966
However, it does not seem to be influenced by temperature.
1901 K (the lowest value darktable would accept):
3000K:
20000 K:
At 5500 K (so daylight-ish), tint does not seem to affect the ‘reconstructed’ highlight, only at extreme values.
5500 K, tint: 0.425:
5500K, tint: 1
Same, with increased exposure:
Tint at 1.73 (above this, the highlights get coloured again):
Tint: 2
Kofa, when I said the colour was responsive to temperature, it was using the attached raw and xmp. Changing the temp changes the colour, so the highlight recovery is not changing hue, and hence I’m thinking your previous example is more due to simply having different temps than anything special about ASTR. But I might be missing the point! And none of this affects my concern about this change to DT.
_5D_05167.CR2.xmp (52.4 KB)
_5D_05167.CR2 (53.8 MB)
I tried to read and understand your issue, but I don’t get it. Is it because it impacts your workflow because you use UniWB? With uniWB, your “as shot” are purposely incorrect to the captured scene, so this default (camera reference + as shot) might not be ideal. But I think it is still ideal for most users since most of the time, my camera WB is pretty close.
If you don’t like it, or think it’s “bad”, then just turn it off
Oh they made this into a new thread. I hope the emphasis of my post was not so much on the ‘worse’ part as I may have been conflating something unrelated, but the seeking explanation part. Thanks for the contributions.
Uni White Balance is not the problem - I will work around that by simply remembering to set Camera Reference or manually set a white balance.
My problem with this change is that it is illogical and half-baked.
This is the main problem: The change improves image quality by using As Shot coefficients where they are appropriate, and D65 coefficients later in the pipe where they are appropriate. So far so good (though you won’t necessarily benefit if your camera WB is off). BUT if you take the trouble to white balance the image yourself, in the WB module, then you will not benefit fully from this change. Now you will be using the WB coefficients later in the pipe instead of D65, which if I understand correctly is wrong for scene-referred processing and the “modern modules”.
The ideal processing is only deployed for “As Shot to Reference”. Not for “User Defined” or the image area option.
I think a much better solution would have been to always use D65 later in the pipe, and always use the output of the WB module for the modules that benefit from those coefficients. And this would have avoided a new option in the WB module.
Maybe some more background information such a type of camera and file plus a sample image would be helpful here. In my experience this default as shot option is a positive improvement to the workflow, but depends upon good in camera white balance.
How about doing the white balance in the color calibration module?
1 Like
How would that help the first part of this workflow if the as shot WB is bad…
It seems to me that using as-shot only is in there as most of the time it will be a good choice. So then you now use that WB for some modules and then the D65 Cat kicks in later now in the pipeline. On the off chance you have a bad as-shot white balance it would seem that you have to abandon that workflow and go to using legacy and use just the corrected wb alone or switch to using reference values…
Other than protecting users from themselves is there a reason that you could not correct the wb yourself and still use the new processing workflow to access the improved method??
To add to Todd’s above…
Yes I could use the CC module, in which case I’d probably set Camera Ref in the WB module. This means I have no chance of benefiting from the ASTR image improvements.
I could white balance in WB and still use CC for e.g. gamut considerations, but now I’m not using D65 where I ought to be.
This change is actually quite limited in value - the beneficiaries are just those who take photos with a correct white balance setting. I wonder how many people this is. Sometimes you have to be quick and WB is the last thing I’d be trying to sort out. Or a cloud suddenly covers the sun. The only time I pay attention to a proper camera WB is when I want to use the SOOC jpegs. I tried to get a handle on numbers by downloading XMPs from play raws but they all come up User Modified. I think this is because I didn’t load them onto their true parent raw file.
Like 99%+ of users? I mean, most camera’s auto-WB is closer to being correct than the D65 reference.
1 Like
I didn’t think it was that reliable! Can you back that up with a study or something?