@gadolf the DNG has embedded opcodes that allows an automatic correction of the vignette, if your raw developer supports that. Alternatively, you can also use flat-field correction. Both solutions are one-click.
1 Like
Yes, it does, I checked that with Camera 2 api probe you mentioned before.
… can’t imagine pixel peeping on a 2.99 x 6.49 in screen… thanks anyway for the tip.
Thanks! It seems your Art does!
At first, I thought you were referring to the lensfun database. But then, darktable would also be able to correct it, and it doesn’t (at least not through the lensfun way).
Is there a module in Art that addresses it?
EDIT: Now looking at it, if I zoom out, I can see a bright vertical area at right that doesn’t seem natural. Do you agreee, @agriggio?
(it is showing neutral at this point)
I really have to port this to RT 
2 Likes
Hi
This was applied automatically, without the possibility of turning it off. However, I’ve just changed that. Now you have to enable it explicitly:
EDIT: Now looking at it, if I zoom out, I can see a bright vertical area at right that doesn’t seem natural. Do you agreee, @agriggio?
I’m just applying the embedded gain map (mostly) following the DNG specs. Maybe the embedded gain map is not very precise… but now you can turn it off and apply a flat-field from file if you prefer
1 Like
Cool, thanks!
I thought about that. I wonder if another camera app would produce a more precise one, or if it comes from a low level Android/manufacturer function. As soon as I can get the hands on the phone I’ll compare shots from the default camera app against Open Camera.
cool thank you. i have to try out better, i have tried to upload a p20 lite file to raw.pixls.us and it doesn’t seem to auto correct vignetting. last time i checked flat field with my honor 6a i got strange results. When i’ll try bettter i’ll start a new thread, for now a big thank you!
At least with the Pixel 4 XL, DNG metadata definitely changed with an app update but not OS updated when the device was first released.
Google seemed to have screwed up and customers (including myself) got the phone one day before “official” release day. It’s clear they had a day-0 update for the camera app planned, because the DNG metadata for color profile was utter garbage in anything shot before that app update.
There may also be a general low-level OS “baseline” that affects third-party apps, not sure.
It’s good to see Motorola moving away from explicitly crippling low/midrange devices. The Z2 Play was fully Camera2 capable in the HAL, but they explicitly disabled it in build.prop.
1 Like
I just got a Pixel 4a and I suspect it has the same issue with the color profile from the OS not matching the color profile from the Google Camera app, which would affect any third party apps using raw images.
According to exiftool the DNGs from GCam contain an Adobe dual illuminant profile with HueSatMap and LookTable. These flies seem to work well in ART.
FreeDcam and Open Camera output DNGs for a single frame capture using the functionality built into Android: the Camera2 API provides CameraMetadata corresponding to the DNG profile format, and the DngCreator (Adobe DNG SDK built in to Android) creates a file using that metadata. These dngs don’t look right with the embedded profile, but look better if the profile from a GCam dng is used.
I think that MotionCam might also be affected. It creates stacked raw images from multiple frames similarly to GCam, and then creates DNGs. It does not use the Android DngCreator but creates its own DNGs using its own copy of Adobe DNG SDK. It does use the same CameraMetadata from the OS as the other third party apps.
Maybe the buggy version of GCam was using this profile from the OS before it was updated to use the Adobe profile instead?
Just found something interesting that might explain the issue with the Pixel 4a…
Running the “dumpsys media.camera” command on the device to see the color profile values the OS reports, the values for android.sensor.colorTransform1, colorTransform2, forwardMatrix1, and forwardMatrix2 exactly match the values that are reported for the fake camera in the Android Emulator, as defined here. These are the values that end up in the ColorMatrix1, ColorMatrix2, ForwardMatrix1, and ForwardMatrix2 exif tags of dng files output by FreeDcam or Open Camera using the Android DngCreator.
So maybe the fake camera in the Android Emulator was based on the actual camera in this device. But if not, then it seems like maybe the OS never had the correct values for the device’s camera set and is just reporting these default values from the emulator’s fake camera?
1 Like