It easy to test in ART…try a few of your images with Flat field correction…just select embedded…if you like the improvement you can use dngpreprocess to create the same result for use in DT…
I wouldn’t be surprised if it were a GainMap for some Pixel camera.
OnePlus Nord with GCam
That dng contains a valid gainmap
left before, right after gainmap processing
I just got a Pixel 6. What kind of image do you need? (I don’t have a color chart).
I also have access to 4a (5g) and a 5a
I’m only interested in the image metadata so the content of the image doesn’t matter. Any dng file is usable. Thanks!
Here is one from a Pixel 6.
PXL_20211119_004121420.dng (12.6 MB)
Let me know if you want me to get from the other Pixels.
Just throwing it in ART and doing the flat field…make a huge difference in this file…
EDIT the first 2 have the auto tone curve on…if you disable that then you go from this
nicely removing the dark corners…
Please upload missing samples to https://raw.pixls.us
Just any image? No specific color targets or anything like that?
It basically says any well exposed and focused image without people goes, color chart is only a “nice to have”.
Is there a benefit for uploading a file from each of the sensors (regular, wide, and selfie)?
I think that would be useful, if possible. Different cameras might support different correction. Some phones don’t allow shooting RAW with all cameras.
I think this warning might lead some to believe that DNG are not wanted…even if natively produced by the camera…
We are NOT looking for:
- Series of images with different ISO, aperture, shutter, wb, lighting, or different lenses
- DNG files created with Adobe DNG Converter
- Photographs of people, for legal reasons.
Just because it’s valid data does not necessarily mean it is actually valid for the optical system in question though…
Hacked GCam putting a gainmap in but not the built-in app is a big red flag. Much of the DNG profile metadata saved by GCam, while it SHOULD be obtained from the system - clearly is not. The strongest evidence of this was the Pixel 4 launch - serious color profile issues were rectified by a GCam app update on launch day (some people, including myself, got their devices one day before the official launch day), not a system update.
I think it’s more likely that the built in camera app is just failing to store the GainMap that it receives from the camera API in the dng file. Here’s an example of someone complaining about the dngs from the built in app having a blue cast while the GCam or Lightroom dngs look correct, although it’s not the exact same phone model:
For the Pixel 4 issue, the camera API supplies a bad color matrix with raw captures to apps, and GCam ignores it replacing it with an adobe dcp profile. But GainMaps aren’t constant for a camera model like the color matrix - the camera API provides a unique one with every photo, so it seems unlikely that hacked GCam would output one that didn’t come from the camera API.
iPhone 12 Pro DNG. Don’t know what’s going on here, but it definiely has some kind of gain situation. When I open it in lightroom, it has a default profile called “Apple ProRaw” with local gain stuff. So if anyone wants to investigate… here you go:
IMG_1748.DNG (21.4 MB)
Also rawtherapee and darktable couldn’t read it. This is “ProRaw” so it’s a 3-channel computationally debayered and denoised file. I think LibRaw might support it and https://github.com/syoyo/tinydngloader definitely does.
“Apple ProRaw” profile (left, notice the intense local gains) vs Adobe Standard (right)
I inspected your dng. The only opcode I found, is opcode 1 (WarpRectilinear) in OpcodeList3, means the dng has no embedded gainmap.
There are actually some new fields introduced in Apple ProRaw, aka DNG 1.6: New DNG specific tags introduced in DNG 1.6
Interesting. We definitely don’t need Apple’s local gains applied to raw files though.