You could open a bug report for the camera app
I’m not sure about the Open Camera app being responsible, according to @Entropy512 it’s the phone manufacturer who messed up the phone’s Camera2 API implementation, on which Open Camera connects.
We can ask Open Camera app to take the Fairphone’s lacking Camera2 API in consideration and provide sensible Color Matrix values instead, but I’m not someone to ask that of an open source contributor.
1 Like
I’d have to look at the source for Open Camera, but I BELIEVE they try to use metadata provided by the camera HAL - which if the phone doesn’t offer raw capture itself may be incorrect. DngCreator | Android Developers
There’s not really any way for a camera app to fix this, except to detect phones with known-bad metadata and replace it. But that’s asking a huge amount of the camera app developer, because correcting the data requires spending the time to characterize the camera, which requires owning that particular phone and a ColorChecker.
Reporting the problem to the hardware manufacturer is unlikely to go anywhere. The Android world is a shitshow in that regard. I’ve seen critical flaws remain unfixed for more than a year after not only was the problem reported to a manufacturer’s developer relations, but a fix was provided as a patch. (For example, the Galaxy S2 kernel had a bug in the power management, where it would enter a state that would keep the phone from entering deep sleep if the fuel gauge was critically low. For one, this seems ridiculous, if you’re almost out of battery why use more? They may have been worried about current consumption during resume… But clearing the condition required the state of charge to be EXACTLY the threshold value. They used == instead of >= to clear the condition if the SoC rose above that threshold when on charger. I submitted a patch to all of my devrel contacts, and more than a year later, people still constantly complained about fuel_alerted wakelocks.)
After all, this is fairphone we’re talking about. A manufacturer who got so caught-up in anti-Qualcomm whining that they didn’t realize that for all of their flaws, Qualcomm was the least of all evils, and went with Mediatek who were blatant GPL violators instead for their first generation or two.
1 Like
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…
Sure! I tried Hedgecam2 and here are the dngs and the color matrix, next to each other.
Open Camera
opencamera.dng (23.3 MB)
Hedgehog 2
hedgehog2.dng (23.3 MB)
And the color matrices
───────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
│ File: hedgehog2_color_matrix
───────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
1 │ Color Matrix 1 : 1.3828125 -0.65625 -0.2109375 -0.96875 1.875 0.0390625 0.0390625 -0.1484375 0.78125
2 │ Color Matrix 2 : 2.2421875 -1.546875 -0.390625 -1.0703125 2.1796875 -0.0078125 0.0625 -0.140625 1.2578125
3 │ Forward Matrix 1 : 0.4375 0.3828125 0.140625 0.21875 0.71875 0.0625 0.015625 0.09375 0.7109375
4 │ Forward Matrix 2 : 0.4375 0.3828125 0.140625 0.21875 0.71875 0.0625 0.015625 0.09375 0.7109375
───────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
───────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
│ File: open_camera_color_matrix
───────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
1 │ Color Matrix 1 : 1.3828125 -0.65625 -0.2109375 -0.96875 1.875 0.0390625 0.0390625 -0.1484375 0.78125
2 │ Color Matrix 2 : 2.2421875 -1.546875 -0.390625 -1.0703125 2.1796875 -0.0078125 0.0625 -0.140625 1.2578125
3 │ Forward Matrix 1 : 0.4375 0.3828125 0.140625 0.21875 0.71875 0.0625 0.015625 0.09375 0.7109375
4 │ Forward Matrix 2 : 0.4375 0.3828125 0.140625 0.21875 0.71875 0.0625 0.015625 0.09375 0.7109375
───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
I’m afraid it’s all the same.
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…
Then added the legacy CB preset …more punchy
Then cheating because this has some interesting profile issues… I tried substituting rec2020 for the input profile…
I actually like the color this gives…
And then on steroids adding the CB preset to this one.
2022-08-06_en-chemin-vers-JP_0007.dng.xmp (10.3 KB)
1 Like
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.
What is CB ? And what is this preset you talk about ? I’d like to reproduce it, will try with the sidecar xmp you provided.
rgb Color balance…there are 4 presets…by default…
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.
HTH…
3 Likes
This is very clear, thank you.
If you are curious and can scan the bits you don’t need or dont’ interest you…this is really cool…
End to end how your sensor data becomes an image…
1 Like
That is good. I loved this little 5 part series profiling the DNR of his canon…
EDIT sorry if this is starting to drift… last off topic post… promise 
It impacts one thing it would seem…but maybe for another reason…
Use default embedded profile on open camera DNG…
Switch it to standard… usually not much difference as I recall…
Give ART a try…strait up looks very good to me right upon opening…
No profile setting…
Embedded
Camera St is pretty much the same…
Now you can use as test I tried the DCP for the Pixel 3aXL my camera… and it looks like what you were expecting…
If you add the look and tone curve in the profile you get
Finally ART supports GainMaps and you can get this by applying the FlatField correction for your images
You will note the strong vignette of the DNG gets removed by this…
So this could be an option for you…
1 Like