I kind of agree, but it doesn’t really bother me as I’m quite happy with the ‘none’ option as I like swapping tonemappers, and so on… and that gives the old ‘as shot’ setting for WB. Apart from possible issues as discussed just above…
Ok, regarding CB… the color workspace is defaults to RGB (display) with ‘None’ and to RGB (scene) with ‘Scene referred (filmic)’.
Yeah, as I said, might be completly FUD from my side. But I would prefer to use the RGB (scene) setting, which I don’t get per default with ‘None’. I really don’t want to annoy anyone, just stating my opinion. The solution last time I mentioned this was, maybe to create presets (which save the color workspace setting). But its really hard to do this consistently (looking at my ~50 presets over all modules).
2 Likes
That may be, but I don’t think the casts that people notice for various cameras are a white balance problem, and consequently white balance is not the right tool to fix them.
To summarize,
- all cameras need a color correction matrix,
- adding one requires specialized equipment (a chart) and knowledge (to process this chart)
- this is apparently so tricky that no matrices were added in the past 7 years,
- lacking that, people can figure out a preset by eyeballing photos for their camera, but it is unclear
a. how much these generalize to other light circumstances,
b. if not, how to automate the process,
c. where to put them in the pipeline.
Again, I am aware that I could just get a color chart for best results. But I am not after that level of fidelity because I am a hobbyist. I just want to get a linear mapping (a matrix) that gives a reasonable starting point.
I will now experiment and will probably find a preset that removes the cast. But the broader issue is that I see no systematic way to share these presets and avoid duplicating the work.
1 Like
I would add that the default dt matrix isn’t just one matrix for all cameras - I’m not familiar with it, but it seems to be quite accurate for many cameras - My Nikons for example are pretty close to my own matrix profiles, when using the defaults.
This is understood. That’s why I want to add one for my own camera. 
1 Like
While I think of it, the other thing that needs doing if you want color calibration to be as accurate as possible is the custom white balance reference value… it’s detailed in the manual. Involves taking a photo of a 6500K light source - like a calibrated computer screen.
I’m wondering what would it take to add Adobe profiles support to DT? They are a great help for me in RawTherapee and ART. I can get good colors and tonal range right away without having to tinker with numerous modules.
1 Like
Quite a bit, adobe profiles are DCP, but DT only handles ICC.
You can generate ICCs from DCPs, I’m pretty sure.
There’s a matrix for every supported camera in darktable, well, actually in rawspeed. Each of those matrices was developed from a target shot of some sort, usually the 24-patch ColorChecker. That’s how matrices are made, from target shots (unless you have spectral data, ah get me going… 
)
https://github.com/darktable-org/rawspeed/blob/develop/data/cameras.xml
Regarding Adobe DCPs, you can extract their matrix, look for the D65 ColorMatrix[1|2].
2 Likes
You can, using Dcamprof, but for someone like me who struggles with terminal applications it’s not easy to do it right. I tried a while back and couldn’t seem to get it right… but to be honest I didn’t try very hard as I was planning on making my own profiles.
I tried a bit too using something… I think it was called dcp2icc you can also break it down to a json file in dcamprof and the write it out but the dcp were d65 and dual illuminant and icc were d50 single illuminant and I don’t think you would get the same corrections in the icc from the hue sat tables… I was never able to land on a combination that seemed to create anything too useful… but thats my fumbling… To be honest from my experience messing around …DT-chart or the colormatch script from Pascal ( GitHub - pmjdebruijn/colormatch: ColorMatch ) were the best two in my hands to get something out of the gate that was matching the jpg… Personally I can live with just editing to taste…
1 Like
If you consider the hassle of making a glare-free target shot, converting the DCP to ICC is rather simple. Here’s what I did with dcamprof, using the Adobe Standard DCP for my Nikon D7000:
$ dcamprof dcp2json "Nikon D7000 Adobe Standard.dcp" nikon_d7000.json
$ dcamprof make-icc nikon_d7000.json nikon_d7000.icc
That sounds a bit like my experience - I did get a resulting ICC profile but it wasn’t “right”. I ended up settling for a custom profile to be accurate as opposed to jpg-matching.
But I’m well aware that this whole field is something that I’m not too worried about - so maybe I should shut up 
Well, it looks like it… in your example! My result was distinctly odd in the colours… and I think I used exactly what you show… maybe I messed up somewhere.
Mine changed the colors also, why I never went past just figuring out how to ICC them. I have spectral profiles for all my cameras, but I just use the libraw-provided matrices for most processing, rendered colors are pleasing enough for me…
1 Like
I know that you have done a lot of tinkering and your work with the spectral stuff gives you great insight I am sure so nothing I say will be new to you and it might not even be correct but I think with darktable this issue is that people just need to settle on a white balance approach and then next on a color approach. For example you can use the legacy WB… read from your camera data and or set by selecting a neutral area. Traditional and fairly straightforward, ie that is a “white” balance. Or you can use the CAT method… which is as I understand it more of a neutral balance than a strict scaling of rgb to make white be white. The role of the CAT is to account for the perceptual aspect of color and to make things that were neutral in the scene appear neutral on the display device or even color appear the same. The result is often very similar to WB but not always. This seems to throw people and have them embark on endless journey to sort it out. The final variable and often something that is a problem is that the CAT calculation for this is based on a set of D65 reference values that have been shown to be off for some camera’s and so they can alter or impact the result.
THe CAT may be a “newer” approach or alternate one but just because its newer people don’t need to force feed it to themselves and I don’t think DT is severely handicapped if you don’t. You can mask it and this can in some circumstances be a benefit for complex images but in the end using legacy vs CAT for most images is not a handicap in my mind… I guess what I am trying to say is that the CAT is a different approach to introduce white or neutral balance to your image its not simply by default a better WB because its newer or more complex…
At least this is how I came away thinking about it from this…
Chromatic Adaptation explained.pdf (3.7 MB)
In any case getting wb sorted in your workflow is going to be the gateway to then work on getting colors that are either accurate or providing a look whatever the user is after…
1 Like
Oh, I agree completely. If the white reference isn’t set properly, there’s no way one can assess colors, either colorimetrically or aesthetically.
I like to use this exercise to demonstrate what white balance is combatting:
In the toolchain in the top-left pane, note there’s all the normal processing except white balance is turned off. This is not about temp/tint…
1 Like
Count me in that camp.
I did convert profiles from Adobe Camera Raw and Capture One to find something better for the Sony A7iv, but it didn’t work out. I think it may not only have to do with the conversion of the profiles, but also with the the input darktable is feeding into the resulting icc profile.
Anyways, I ended also up with a color checker and a custom profile.
1 Like
@Tamas_Papp, I’ve just tried making an ICC profile for the GX9 from this shot here: https://www.imaging-resource.com/PRODS/panasonic-gx9/GX9hVFAI00100.RW2.HTM
Assuming this is a good profile shot (not sure but it seems reasonable), using this matrix profile as the input profile in DT should (arguably…) do away with the need for a matrix in color calibration. (For purposes of accuracy, that is.)
GX-9from Imagingresourcesiso100shot.zip (398 Bytes)
Color calibration can still change colours though - especially if the D65 WB reference value is off as @priort mentioned above. And, again, the this profile is trying to be accurate, i.e. true to life which may not be the same thing as the Jpeg… this is my approach anyway!
Now to test it… I downloaded an image (raw and jpg) from the Imaging Resource (https://www.imaging-resource.com/PRODS/panasonic-gx9/Y-P1011255.HTM), and opened it up in dt. First, I notice the slight reddish tone you mentioned. (BTW I am using the ‘legacy’ WB module only workflow)
Iit turns out that my new profile doesn’t make much difference - suggesting that dt’s standard input profile is pretty good.
Using color calibration in the default manner with the WB module set to reference slightly increases the reddish cast but not substantially.
Next I tried using the same colour checker shot to set up a calibration preset for CC - not much better. I think that target shot might not have been shot under daylight - but in any case it didn’t help the reddish look either.
Next try - an ICC profile using the LUT to provide more accurate color matching than just a matrix. This sort of breaks the scene-referred workflow but tried it anyway. Still that reddish tone!
I’m inclined to think that the GX9 is behaving similarly to my EM5ii - just getting an apparently accurate profile doesn’t produce very pleasing colours. 
Actually, I think it’s looking quite good on the test shot, but it’s definitely different to the jpg.
Next stop I want to try matching the jpg by eye as has been suggested!
1 Like
Ok… if you like, try this style?
sg123-matchjpgGX-9.dtstyle (4.2 KB)
On my example shot (as above in last post) this is looking quite good. Set the WB module to as shot and apply the style. Make sure Filmic is off, and that CC is set to bypass after applying it. I think got it right in-style but just to make sure!
Using sigmoid here, mostly as it looks closer to the jpg with hue preservation turned right down to zero.
2 Likes
Thanks for looking into this. Using studio test images from various sites is an excellent idea, this did not occur to me before.
The style you attached has a greenish cast on my yellows though. So I downloaded the test image from dpeview, their “daylight” version has a 5500k illumination, so I had
- white balance: camera reference
- color calibration: as shot
- color calibration (2nd instance): calibrated using the color chart.
The preset is attached.
GX9 _ dpreview.dtpreset (1.1 KB)
My output ΔE is 1.78 and with a max of 4.55, I am not sure if that is large or small, if someone can put this in context I would appreciate it.
It removes a lot of red and green from adjacent channels. I put it before the default color calibration, hoping that all the module does is a matrix multiplication which is commutative (it seems to be). Then it looks like a reasonable basis for a correction. Now I know what to look for I can tweak it is needed.