Well I would say open camera generates a problematic or at least unconventional DNG on my Pixel and its pretty mainstream so I just think its the way it takes the data and packages its version of DNG and since this differs likely from what is expected by standard protocol when opened in raw processing software you get a distorted image… I might have to go back and see …there was another app called hedgehog2 or something like that. I think its really a different face on opencamera but maybe it offers a different DNG output… I will dig it up and check…
EDIT…it was called Hedgecam…ha ha … you could give it a whirl…
I’ll have to check …very interesting…I seem to get much better DNG with the Pixel using it…also it exposes quite a few options in bug fixes and other areas…one is to use their DNG or android DNG…also some other settings are there that could alter things… I am experimenting now…one thing I noted is the illuminants are way off comparing native camera app to Open camera…will have to check HGH2… this is Google…
And this is open camera with D55 illuminant vs d65 and they are reversed??
Well for a phone image, in the end I don’t think its too bad. I wasn’t there to see those flowers but if you want a pretty picture you can get one…not sure if its better or worse than your experience but I took your image and did a quick edit…
Funny thing, at least when the Pixel 4 XL shipped, there was evidence that the HAL was reporting bad color metadata, because the issues I had with DNGs on day -1 (my phone arrived one day before the “official” release date) were fixed by a day zero camera app update, not an OS/HAL update.
Interestingly - different ColorMatrix1/2 tags than the Fairphone, but the EXACT same ForwardMatrix tags. That’s deeply concerning.
It’s clear that Google is overriding whatever the HAL provides and embedding a full blown DCP including HueSatMap 2.5D LUTs in every image.
Its interesting when I make a DNG with DNG converter it sets Illum-1 to Std-A and illum-2 to D65. My pixel does the same for the native camera app but using opencamera it sets illum-1 to D55 and Std-a for two. The fairlight phone sets it to D65 for 1 and Std-A for 2. So correctly D65 but reversed and then has the same matrix issue… So I guess it buyer beware on how open camera might interpret and save the image data as a DNG… and how that might be interpreted as a raw file
As long as the CM matrices are correctly calibrated for the given illuminant, the order doesn’t matter as far as DNG spec (and darktable implementation) are concerned. If there is no D65 matrix, dt will look for the closest one and do chromatic adaptation on it. But if the matrices are garbage in, you’ll get garbage out…
@priort I managed to import your sidecar file, thanks!
Now what are those color matrices anyway ? I tried to look it up but there’s a lot of math involved apparently, and I’m just a humble developer. Anyone have a good explanation, or a link to follow?
This is a bit of math at least worth appreciating. Whether in-camera to a JPEG or raw file through a raw processor, the camera data has to be transformed in color down to a gamut of colors the rendition media can handle. There are a number of ways this can be done, but the simplest and most predominant method is a bit of linear algebra using two sets of 9 numbers, the first set describing the input data, and the second set describing the output destination.
The ColorMatrix sets we’ve been discussing here are the first set; they describe the color response of the particular camera. These numbers are sometimes called the “color primaries”, and they consist of three numbers for each of the red, green and blue encoding of color. The destination numbers describe the gamut of a particular display medium; when we export a JPEG, we usually use sRGB primaries because we don’t know what all is out there on which folks might display our images, and sRGB is a sort of least-common-denominator.
