Thanks a lot for all your replies and edits, I learned a lot.
So I will use ‘preserve chrominance = no’ as default, and finetune with ‘white relative exposure’ and ‘highlight reconstruction’ when using max RGB.
But I still have no clue why there is such a difference between legacy-wb and color calibration.
What does ‘wrong WP’ mean? How can I ‘use the canon values’?
You could if you find them better just create an auto preset for that camera and set it to apply to all images… you set it in the first module in the pipeline…raw black/white point…
Edit. As for the blue. I bet it has to do with the combination of the norm and the maybe some gamut mapping done by the CC module that the WB module doesn’t do. That is the only thing I can think of but again I only scanned the code and I glaze over pretty quickly 
Or maybe try luminance rather than no… one or the other
I’m stull trying to decide personally if its worth the trouble. If I need to mask things and deal with some crazy lighting then I will use it but might just stick to the good old legacy and avoid extra steps…
thanks again, always learning something new…
WP is White Point. That is, the maximum meaningful value a pixel can have (in the raw file, which is basically a stream of (here 14-bit) integers. The exact value depends on the sensor, and is provided in the EXIF data (in your case, 14800 and 15300).
I’m not sure why there are two white point values, unless the lower one gives the upper limit of the linear response, and the higher gives the actual sensor saturation. (if pixels are between the two values, they have meaninful data, but colours can be off).
In the case of this file there is a linearity value given at 10000… I had the same question…perhaps the lower one is a value reliable for “white” or where all channels are not yet clipped and specular is the highest “measureable” value on the sensor but not necessarly guaranteed not to be clipped say on one channel…?? No idea
but remember white point values often depend on ISO for Canon cameras.
Outside my pay grade…then I guess you just have to do lots of experiments and compare the file data with what happens in DT… This would however create a further deviation if DT uses a fixed WP in all cases and doesn’t account for this??
@priort , DT already takes ISO into account I believe, at least in my experience. I just checked a few shots from my 6D and the raw black white module is showing sensible values. You don’t have to do lots of experiments in any case, RT’s camconst.json file (text) has all the values if anyone wants to compare with DT.
I am sure there are config files to provide the values…in the end I am just checking the meta data against what gets used by the software…
In the RT file there are a ton of entries…
Eg. Canon D6
{ // Quality A, some missing scaling factors are safely guessed - samples by sfink16 & RawConvert at RT forums
“make_model”: “Canon EOS 6D”,
“dcraw_matrix”: [ 7034,-804,-1014,-4420,12564,2058,-851,1994,5758 ],
“ranges”: {
“white”: [
{ “iso”: [ 50, 100, 125, 200, 250, 400, 500, 800, 1000, 1600, 2000, 3200 ], “levels”: 15180 }, // typical 15283
{ “iso”: [ 4000, 6400, 8000, 12800 ], “levels”: 15100 }, // typical 15283
{ “iso”: [ 16000, 25600 ], “levels”: 14900 }, // typical 15283
{ “iso”: [ 160, 320, 640, 1250, 2500 ], “levels”: 13100 }, // typical 13225
{ “iso”: [ 5000, 10000 ], “levels”: 13000 }, // typical 13225
{ “iso”: [ 20000 ], “levels”: 12800 }, // typical 13225
{ “iso”: [ 51200, 102400 ], “levels”: 15900 } // typical 16383
],
“white_max”: 16383,
“aperture_scaling”: [
// no scale factors known for f/1.0 (had no lenses to test with), but the
// ISO 160-320… 12650 white levels maxes out at “white_max” for f/1.2 and below anyway.
{ “aperture”: 1.2, “scale_factor”: 1.130 }, // from histogramm 1 gap in every 7 levels
{ “aperture”: 1.4, “scale_factor”: 1.090 }, // histogram 3 gaps in every 32 levels
{ “aperture”: 1.6, “scale_factor”: 1.060 }, // 16213/15283
{ “aperture”: 1.8, “scale_factor”: 1.040 }, // 16004/15283
{ “aperture”: 2.0, “scale_factor”: 1.030 }, // 15800/15283
{ “aperture”: 2.2, “scale_factor”: 1.020 }, // guessed
{ “aperture”: 2.5, “scale_factor”: 1.015 }, // 15541/15283
{ “aperture”: 2.8, “scale_factor”: 1.010 }, // 15437/15283
{ “aperture”: 3.2, “scale_factor”: 1.005 }, // 15361/15283
{ “aperture”: 3.5, “scale_factor”: 1.000 } // no sample
Then for some Nikon cameras a single value but then it says set to x to be safe…who decided??
Not debating any of the values, in the end my gold std though would be what is defined in the file against what gets used and then deciding if it really was different enough to make a difference…
Sorry for resurrecting an old thread…
I was curious about this issue and I did some tests.
To me, the difference between CC and legacy WB when coming to magenta highlights is entirely due to the highlight reconstruction module being activated or not.
If I disable HLR, I get magenta highlights with both methods.
Which makes sense, HLR is meant to fix exactly that problem, but it can only do it if WB is used in legacy mode. If you choose the modern workflow, then WB is set to camera reference, HLR cannot fix the magenta artifacts and you have to deal with those in filmic reconstruction instead.
Nope sorry…I don’t think that is accurate and its easy to demonstrate…
Legacy wB
I think it’s a bit more complex than that:
HLR will do its reconstruction *based on the coefficients in the WB module" as that’s all it has available.
Those coefficients vary with the illuminant, in @priort 's example:
legacy : 5651 K, coeff(R) = 2.312, coeff(B)=1.545
modern: 6502 K, coeff(R) = 2.382, coeff(B)=1.389
As expected a small difference in coefficients, pushing colours towards blue when lowering the colour temperature.
But in both cases, the HLR module (in “clip …” or “reconstruct in LCh” modes) will correct to neutral gray/white relative to the coefficients in the WB module as that’s all it has to work with. And that’s exactly what we want in the “legacy” case.
It also works that way in the “modern” case, so after the WB and HLR modules we again have neutral highlights
Now we add the color calibration. That’s basically adding another WB correction (for the case that we’re dealing with here). But in most situations, that means we correct to a lower colour temperature: typical sunlight would be about 4200 K, which is a lot cooler than the camera reference of 6502 K. So all colours will be pushed towards blue, including our nice neutral corrected highlights, which will turn blue(ish).
Of course, we’re talking highlights, so filmic tends to push them back to neutral white when white reference is lowered enough. But that also tends to kill the details/texture we wanted to recover with LCh reconstruction…
In very ‘oversimplicated easy mode talk’, highlight reconstruction tries to fix clipping issues directly after the white balance module.
So ‘it tries to make it look good at that point in the pipeline’. And if it’s set to ‘as shot’, ‘daylight’ or ‘reference’ or whatever… it doesn’t matter, it just has to look OK at that point :).
CC and the input profile works on that output.
In case of the CR2 file in the topic-start, there is very little difference between ‘as shot’ and ‘reference’, so this really doesn’t affect much. At least here on my system.
This shot has a bit of an issue where the reconstructed areas don’t match with the colors of the clouds around. So even if I get rid of the magenta of the clipping by reconstruction, it still has a cast compared to the white pure clouds around. Makes me actually kind of prefer the Lch-reconstruct which I normally do not like at all.
reconstruct-color and segmentation both add a color which shouldn’t be there IMHO .
Anyway, in the end you’ll end up with the same as always: Modern filmic tries to preserve as much color in highlights as possible. Because v5 got criticized of unsaturating the skies, I think.
So it tries it best to preserve all the color that’s there. In case of clipped highlights, there probably is some ‘false’ color in there that you do not want at all (like in this shot). With no filmic / sigmoid, just ‘white balance’, ‘reconstruct’ and put the exposure way down, so we can see what’s happening, shows this:
And filmic v6 tries to preserve that redish color in the reconstructed clouds, which makes it stand out against the more white clouds around it.
You can lower the saturation of the highlights with color-balance-rgb, or even try some masking there… or take a filmic approach which does not try to preserve color as much, which is perfectly fine in this case I think.
Preserve-chrominance mode to ‘no’, or ‘luminanceY’ often does the job, although with ‘no’ I often struggle to get the colors in the rest of the picture how I like them.
Filmic’s own reconstruction actually works quite OK here too. We do not want it to preserve the false color, so the slider in the reconstruction tab between ‘gray’ and ‘colorful details’ I move all the way to ‘gray’. And then I start lowering the threshold. You’ll often see that ‘just below 0 EV’ is all that’s needed, with a proper white-point set up. You can even move the ‘structure / texture’ slider all the way to texture, to get some definition back in the blown-out clouds.
I often test this kind of stuff with a very strong local-contrast enabled, just to make all the changes / details really visible (and turn off the effect or lower it later). My usual: local contrast ‘bilateral mode’ with the contrast set to 3, and then the detail slider way up.
Having the exposure at (my) default of 0.7 (With the reconstruction still enabled on segmentation). I enable filmic with (my / Aurélien) defaults: latitude 0.1, hard curves, maxrgb mode, contrast to 1.0. The only thing I then do is use the ‘auto white’ picker, and leave the rest alone.
With the local-contrast boost enabled to visualize things, you’ll see the issue with ‘maxrgb’ mode that you are having: trying to preserve the false/wrong color:
Now, just setting filmic to ‘luminanceY’ mode already improves it a lot:
You’ll still see some dirty color around the details, but it’s way less.
But to demonstrate, go back to maxrgb, and then set filmic’s reconstruction how I explained it (around -0.15ev, complete ‘texture’, complete ‘gray’):
All the dirty color is now gone, even in maxrgb mode. And we still have some cloud-definition in the clipped area. I see no difference with ‘reconstruct color’ and ‘segmentation based’ as HLR options with these settings dialed in. Lch maybe could’ve worked as well, but you need to tweak filmic white point some more.
But, instead of using filmic’s reconstruction on top, you also could add a color-balance-rgb instance, where you use the Jz channel (scene-referred luma as I see it, might be the wrong terms, but it explains it…) to mask out the ‘reconstructed highlights’, and then lower the saturation of it all the way. I guess that only works in this image, because the surroundings are also unsaturated white clouds.
mask:
result:
In all of these tests, using white-balance set to reference and then CC set to as shot, makes absolutely no difference to just white-balance set to as shot. So I don’t see the difference that is reported here between modern-WB and legacy-WB?
For an image as this, using filmic v5 is probably the easiest, but also a very logical way. Whenever I see someone saying ‘ok, I will change to preserve-chrominance no mode by default’ or ‘switch to filmic v5 by default’, I always want to explain what the differences are. Because otherwise it’s just waiting for questions again like ‘Filmic renders this desaturated’ or ‘all my color is gone’.
Explaining the differences makes it easier for people to directly target an option and change it, instead of just ‘trying out all the options to see what works’.
With or without reconstruction, you’re dealing with wrong color in the reconstructed area (in this picture at least). Filmic v5 doesn’t preserve color in the (extreme) highlights, so the problem goes away. But that might not always be the best way forward, specially if you do want to preserve color in the reconstructed area.
The modern-white balance method doesn’t seem to be related to this at all, it’s just another case of ‘clipped highlights and how to deal with them’, in combination with a file that opens with the wrong white-level set.
AFAIK, lch-reconstruction ‘just’ removes the chroma from the reconstructed areas. So the white-balance setting has absolutely no effect, because whatever the surrounding color is at that point in the pipeline, the reconstructed area will be completely desaturated.
The other reconstruction methods just try to ‘feel in the gaps’ in some way with the information around it that isn’t clipped. They don’t care if that information is ‘supposed’ to be blue, or magenta, or red, or whatever depending on your white balance settings… they just take the unclipped pixel-values and use them to overwrite the clipped channels. What the white-balance setting does shouldn’t matter, to be honest. Also, testing this (just having white-balance, reconstruction, and a massive lower-exposure setting to see the reconstructed highlights properly) and messing around with the white-balance setting doesn’t break the HLR module. Only when setting extreme white balance differences, but I’m guessing that I’m then seeing other issues as well.
so, in the end: I find it weird that so many people in this thread talk about a massive difference with legacy-WB and modern-WB. But I really don’t see it? What am I doing differently?
Yes, filmic options affect how the clipped highlights look, but changing white-balance around doesn’t seem to make it behave differently?
For me this is pretty simple. If you have white balance coeffs not set perfectly even a clip to a pretty low value does not give a balanced grey/white after hl reconstruction.
ah, setting reconstruction to ‘clip’ instead always seems to make it ‘white’ (makes sense), so the WB of the stuff around it actually can create or hide differences.
Then trying Lch it seems to do the same, but I have to crank the temperature way up to show it properly.
So setting a WB to make the clouds white, then reconstruct to turn them white, and then load CC to set a proper WB (if you want a different one) can indeed make a difference.
I’m still not seeing a difference in what filmic does with legacy-WB or modern-WB though. Am I doing something wrong, or different?
Agree, that was my point too
Its pretty easy to see for me… and I know how to deal with it…
if you do all defaults and scene referred defaults you get this using CC set to as shot with v6 defaults…
And if you touch nothing from default and set WB to as shot…turn off CC
I was just curious why the same norm which could produce artifact for sure if things are clipped or the raw WB is wrong… would be different enough to create that artifact…
Again its just an observation and i can deal with this
EDIT…Looking at it with the default HLR off as well you can see the two WB settings for this image are not equal (deeper magenta on the right) and so when corrected and compressed by filmic and using a certain norm you will see this…without filmic and just default HLR… you really wont see much of a difference I don’t think between the two WB configurations … also again this is one image and as we have seen depending on the raw white point and combination of HLR and filmic settings you can land on different results…
AP has two videos that pretty much explains everything that’s going on here.
This one is essentially what @jorismak wrote, but more detailed and fully explained:
Ya this is what I meant by this my comment above…I had initially looked at it purely from a WB point of view and so with all things being equal and using only defaults I was seeing the blue artifacts when the modern WB was used but not the legacy one. What I had not thought of was the role of HLR which is applied in both workflows by default as clip highlights. In the second video AP points out that HLR using the default to clip or LCH or color reconstruction really don’t work with CAT derived WB only with legacy. I think around 26 min. In fact as it turns out this is the source of those blue artifacts many are now seeing with filmic v6. I think now that we have a couple of new modes for HLR and the current LP method that can be combined with HLR in filmic as shown in those videos and those made by others this should be less of an issue.
If you use legacy WB and the default HLR you wont see this blue with filmic v6 at least for this image but I think many people are using modern WB and so should be using Filmic HLR with LPHLR if needed or the new segmentation and inpaint methods that seem to work well also…
If you disable all HLR which would have been the right comparison for the posters question then you can still visualize a difference between the two WB modes. Its is however not large and must be due to the chosen d65 coefficients and the CAT calculations (figure below). If you leave the image blown and don’t mess with exposure then the magenta is a little deeper with legacy WB (right side). And adding default filmic doesn’t convert these to blue confirming that indeed it is the combination of the clipping mode and WB mode that leads to this.
Given this I am not sure why when modern WB gets selected in preference that a different mode of HLR is now not the default. Perhaps with the newer less computationally intensive methods this will change.
In any case from all the recent discussions it is important for new users to be able to understand this interplay between all these elements along with the issues for some with incorrect raw whitepoint and questionable D65 coefficients as these can contribute and at times explain the artifacts that appear…
EDIT for completeness
Plus filmic with no HLR so as above but now just Filmic with Legacy on the right. Not the same wb but still basically both with correctable magenta highlights
Now adding default HLR (clip)… this is what people would experience for modern vs legacy
Using filmic recovery only … both methods look pretty close now
Adding in LPHLR for this one might add a bit more gradient if needed and the PC can handle the module
