Hi,
I’ve been happily using DT 4.2 for months now to edit and develop my DNG files produced with my Pixel 4A with excellent results.
A few days ago, after a Android update I saw huge problems with color balance. I’m using Manjaro, so still no DT 4.4 here.
I attach two images: one old that works OK and one new producing an error and horrible color cast and I show also the Android versions: HDR+ 1.0.520435816zd (old) and HDR+ 1.0.538010570zd (new) 20230625_0009.dng (17.5 MB) 20230519_0001.dng (17.0 MB)
I have the same issue with Pixel 4a images, but not Pixel 6a images.
Thankfully, the Pixel raws mostly seem to have a baked-in white balance, so presetting a fixed color calibration seems to do the trick as a workaround.
I think that white balance error is because you use color calibration to set white balance while the white-balance is not set to ‘reference’.
This isn’t a problem of you know what you are doing , but a thing to try it to take the color calibration and reset ir ro ‘as shot’ (no matter what the white balance module is set to)
Interesting, it looks like in addition to the move to adding ColorMatrix3 etc from DNG 1.6, they dropped the Profile HueSatMap tables - which are frequently used to handle extremely saturated colors better.
Sadly while they are now using DNG 1.6 features, they’re still not saving as a demosaiced image which they SHOULD be doing whenever their MFSR stacking mechanism is used.
I’m still trying to figure out what is going on here… the Adobe DNG SDK comes with a utility dng_validate which checks the validity of a dng file and can also run it through the entire processing pipeline outputting a sRGB TIFF. So we can consider that a sort of reference implementation for how to properly interpret the file.
mkdir build
cd build
cmake ..
make
./dng_validate/dng_validate
I shot a spydercheckr under daylight and halogen. For the unmodified dng files, the output looks reasonable - no severe color or white balance issue. In this case the DNG SDK sees that it is a triple illuminant v1.6 DNG and would use the ColorMatrix3 / ForwardMatrix3 since the AsShotWhiteXY exactly matches the IlluminantData3. darktable and most other apps do not use these DNG 1.6 tags at all so would never use this matrix.
Now it’s using the ColorMatrix1/2 - darktable would use the daylight one of these two. Now the output is much less saturated, but the white balance still seems approximately ok, not way off like it would be if these files were opened in darktable or some other editors.
This is exactly how darktable would handle the file, using only the D65 matrix and ignoring the others. The white balance is still not obviously wrong:
So maybe the white balance is wrong in darktable because it’s misinterpreting the rarely used AsShotWhiteXY tag? All the other dng files I’ve ever seen use the other alternative AsShotNeutral tag.
That’s definitely an improvement. Now when selecting ‘as shot’ WB in the temperature module and not using color calibration, it sets reasonable channel coefficients. For a daylight shot it set coefficients that were pretty close to the ones I got by picking a gray patch on the color checker.
There is still another issue (unrelated to this fix) when trying to use modern WB with color calibration - when selecting ‘camera reference’ in temperature module, the D65 coefficients it derives from the dng’s color matrix are way off. This didn’t happen with the old color matrix from before they changed the profile. With the AsShotWhiteXY patch to rawspeed, color calibration set to ‘as shot in camera’ is able to correct it somewhat, but only by setting an illuminant with very high chroma.
