Referring to Caveats in color calibration, I took an image of my screen (D65) with my M-1MkII and got following WB coefficients when taking the reading from the middle of the image.
R: 1.847
G: 1.000
B: 1.876
I was wondering if there is anyone shooting with the same camera and has done the same experiment and what are her/his results.
If there are others that have got about the same coefficients, is it possible to update the default values in the “source”?
You could create an auto applied WB setting for that camera if it seems better…at least for now
Has anyone done this for the Olympus E-P5 or another camera with the same sensor? (adobe_coeff.c shows that the E-P5, E-PL5, E-PL6, E-PL9, E-PM2, E-10 Mark II and Mark III, and E-M5 all have the same matrix.)
I tried taking a picture of the screen and got:
R=2.136, G=1.000, B=1.600
But I’m not sure if I really calibrated the screen correctly.
I tried shooting a gray card in bright direct sunlight with a clear sky around noon and got:
R=2.146, G=1.000, B=1.564
Haven’t experimented with these enough yet to know whether or not they work any better than the default when camera reference is selected: R=2.306, G=1.000, B=1.585
Yes, I already created a preset, but didn’t make it auto apply yet. I thought of getting some feedback first.
Interesting discussion. I stumbled upon the same thing early this year and happen to have a couple of the cameras mentioned in this post.
For the E-M1 II, I get the following coefficients:
R = 2.157
G = 1.000
B = 1.798
For E-M10 II:
R = 2.194
G = 1.000
B = 1.705
My laptop display is calibrated to D65 (DisplayCal, X-rite i1Display Pro) and DisplayCal reports a measured color temperature of 6477K. I drew a white to black gradient in GIMP, took a photo of it and sampled it in the middle. Raw images are attached.
E-M10 II:
P9030156.ORF (13.2 MB)
E-M1 II:
P9030106.ORF (16.5 MB)
I find it interesting that @Juha_Lintula ended up with quite different coefficients. Might be due to a difference between monitor primaries, but might be worth checking if the gray view on the screen is actually color managed (i.e. a profile-aware image viewer). I’m fairly sure GIMP does color management properly.
I recalibrated my monitor and redid my shot. I used full white screen, out of focus, and no gradients. The color temperature was slightly off at ~6800K instead of D65. I got slightly different results (less red), but still quite close to my original:
R = 1.773
G = 1.000
B = 1.874
Interesting that the red is not at all at the same ball park.
Room lighting maybe??
A monitor’s spectrum doesn’t resemble D65 at all, it can’t be used to measure how a camera will see D65.
Cameras’ Auto WB modes tend to do a decent job with daylight and its variations, to my experience. However, when I want to be persnickety about white balance, I shoot a neutral patch in the scene and use that later in post for a WB sample. That IMHO is the best and easiest way to get a good WB for a session.
A monitor’s spectrum doesn’t resemble D65 at all, it can’t be used to measure how a camera will see D65.
@ilia3101 This is what is recommended in the color calibration documentation as a fix.
@ggbutcher I’m not trying to get the correct WB for the scene I’m photographing but trying to improve the starting point of color calibration.
Well, the best ‘starting point’ is the scene itself, with it’s unique lighting. Making a set of WB multipliers from an arbitrary lab source is not a good starting point.
Darktable applies a rough white balance before demosaic, after which the white point is assumed to be D65. By default, Darktable derives the coefficients for this from the “standard” input matrix, i.e. the one acquired from the commonly used Adobe data. However, for some sensors this doesn’t seem to be very accurate, hence the efforts to find out more accurate coefficients for the initial D65 white balance.
After applying the input color profile, a finer chromatic adaptation transformation is done in the color calibration module. That’s where we want the input data to have a well-defined white point – that module tries to match the final illuminant with the daylight and black body locus and displays GUI controls accordingly (i.e. color temperature sliders if the illuminant is close to daylight or black body).
Danged darktable… 
I should probably stop trying to map my simplistic view of the world into these workflows.
I’ve been having similar problems with images from an E-M1 mk iii in Darktable–the “best” overall settings I can find for any given image tend to leave excess green in parts that should be red/orange/yellow. My knowledge of how the math works isn’t nearly on par with @anon41087856 but my suspicion is a mildly broken input matrix as @flannelhead suggested, since that would explain why scaling channels independently seems to be unable to reach good results (whereas a matrix allows “cross-pollination”).
Is there anything I can do to help fix this? For myself at least it gets quite in the way of enjoying photography. The camera at least deserves better! 
Welcome to the forum.
I have some memories of similar results with my OM-D E-M10 II – there were some pics taken in autumn where I thought the SOOC JPEGs reproduced yellow, orange and red leaves much better than I could achieve with Darktable or RawTherapee. However, that was in 2018, so much has changed in both pieces of software since…
Anyway, you are correct in that independent scaling of the channels only gets you so far. You should definitely familiarize yourself with the modern chromatic adaptation workflow in Darktable. It is nicely described in the manual. The color calibration module also has a channel mixer, which could give you the results you want. If you would like the red (or orange/yellow) pixels to have less green, decrease the value of the input R slider in the G tab – that tells the module to decrease the value of output G based on the input R value.
Going further, you could also perform calibration with a color checker, which is also possible using the color calibration module and nicely described in the manual. I have done this for my E-M10 II, and there indeed there’s a small negative value in the mentioned slider.
I need to look into the settings of my monitor or the way I took the image. Now when I took an image of my laptops screen (calibrated), not my external monitor, I got coefficients that are quite close to you @flannelhead.
R = 2.207
G = 1.000
B = 1.811@Juha_Lintula if you look at the two displays next to each other, is there a visible difference in the color temperatures?
Also some differences of the coefficients may originate from different spectra of the monitors (different type of backlight etc.), and as @ilia3101 noted this method might not be super accurate anyway.
One thing to check (if you’re using DisplayCal) is colorimeter correction data - this is selected based on what kind of illuminant (e.g. white LED) the display uses.