Here are two DNGs (HDR+ Enhanced and Night Sight mode) from GCam on a OnePlus Nord. darktable complains about not finding the matrix. They don’t look sharp at the pixel level. They seem to be mosaiced; I don’t know about the bit depth.
HDR+ Enhanced mode:
IMG_20210630_140220.dng (10.3 MB)
Night Sight mode (yes, I know, it’s broad daylight):
IMG_20210630_140232.dng (9.7 MB)
Currently ART is the only OSS raw processor that supports the GainMap (lens shading map) included in dngs from the Pixel and other phones. RawTherapee, darktable, etc, do not support it yet. When it’s included in the dng file and is not a no-op, it’s very important to apply it because it’s not just vignetting but it affects each color channel differently. So if it’s not applied the colors can be correct in the exact center of the image and there’s a heavy color cast closer to the edge.
The example in this thread shows how incorrect the colors can be when the GainMap is not applied. In that case it was mistaken for an incorrect color profile.
I must have been in Art but I swear I did try it in RT…funny…too many programs on my PC 
I think open camera saves tiff’s in a DNG container. You can’t extract a jpg preview from open
camera DNG and the tags showed references to tiff somewhere I think. They are on average 10MB larger than the DNG from the native pixel app so that might make sense. I may be wrong but for sure they are not the same DNG.
Just too a quick shot out my open office door… one pixel and one for open camera…which shoots a very flat raw for me…
IMG_20210630_130155.dng (23.3 MB)
PXL_20210630_165800503.NIGHT.dng (12.7 MB)
TIFF is also just a container. DNG is a TIFF.
The difference in size you’re seeing is most likely due to compression - original Pixel DNGs use JPEG lossless.
Yes, without having inspected the files it’s very likely DNG lossless compression vs. no compression. Open Camera does not compress, while GCam derivatives do. A linear DNG has three channels and a mosaiced bayer raw file has one, so one can guess by looking at the size what flavor it is. 
Ya the open camera DNG tags say full size preview uncompressed but I have not found any thing that could extract a preview. I think most tools expect a jpg for the preview not a tiff so I think the open camera DNG is just the image as you say DNG is a container for tiff file…I am sure there is a nuance but no utility I found or exif could pull out a preview so that is why I surmised what I did…
I believe that kmilos was not talking about the embedded preview data “being a TIFF”, but the mosaiced data (raw DNG) or demosaiced data (Linear DNG) itself conforming to TIFF/EP. If I recall things right Open Camera does not embed any preview data at all, just uncompressed mosaiced data, but don’t quote me on that.
Ya that is what I was trying to articulate badly I guess… I think it just has the data no preview…
Ah, I see. Yes, that is likely the case. You can save plenty of storage by running them through the Adobe DNG Converter with lossless compression enabled.
I haven’t used OC too much I have ON1, Open Camera, Hedgecam, and the Google app. Mostly just shoot in the google app and those files are pretty small around 13MB.
Instead of speculating, just run exiftool -a -u -s -g1 or exiv2 -pa on your files.
For the OpenCamera one:
Indeed, just single image (IFD0) with the full resolution Bayer raw, uncompressed, and from a single frame (10-bit)
For the original (Google camera app) one:
@mikae1 Adobe DNG Converter will indeed provide the identical space saving, as the same JPEG lossless compression will be used (the only one allowed by the baseline DNG spec).
I was referring to running Adobe DNG Converter with lossless compression on the Open Camera DNGs (which are uncompressed). That saves space.
That, or you could run GCam (which as you say are already losslessly compressed). However, the variants of GCam I’ve tried for my phone under LineageOS all require Gapps/Play Services or microG. So, I’ve settled on Open Camera.
EDIT: found this now: GitHub - lukaspieper/Gcam-Services-Provider: App faking only the absolute necessary Apis to use Gcam without Play Services
I know, just saying the expected saving is to be pretty much in line with the GCam DNG as the identical JPEG lossless scheme must be used. Might be even better since 10-bit data is being compressed instead of 14-bit.
Taking it somewhat back to the topic of “finding a smartphone with a good camera”… One of my major gripes with smartphones cameras is that the main camera uses one of my least favorite focal lengths (~28 mm equivalent).
Yes, today there are multi-camera smartphones, but the problem is that every phone I’ve looked at uses a crap sensor for all cameras except for the ~28 mm one. Has anybody found a recent smartphone that does not use an inferior sensor for a 35–45 mm equivalent focal length lens?
Thanks if I knew exiftool as well as you I wouldn’t have to speculate… Thanks for sharing…
The google app now has a nasty habit of creating a useless raw file if you use zoom. In the past you would get a jpg of the crop generated by the zoom and a full sensor raw file. Now it tries to create a raw with the same crop applied so if you zoom in all the way you get a raw that is 900K. Darktable won’t read them and the jpg’s are actually larger in terms of storage at around 2 Mb. I have tried to get feedback from Google but with no luck
Not an iphone or a pixel in the top 5
Comparing two shots - OnePlus Nord with GCam Night Sight vs. Nikon D7000; both handheld.
What I mean to say is that, as long as there’s enough time, our phones have become powerful low-light devices.
Yup, that is saved out of the legacy Google HDR+ pipeline after the tiled align-and-merge but before tonemapping.
Some claims by Google to DPReview staff imply they have remosaiced their newer MFSR pipeline’s results for compatibility, but if you use any digital zoom on a Pixel 4, it becomes obvious that the JPEG came out of an MFSR pipeline but the DNG is not - the DNG will be heavily cropped. I wish Google had done what Apple did and save “Linear DNG” out of the MFSR pipeline instead of crippling their DNGs for compatibility. They may have fixed this in the past two years, but DNGs with any use of digital zoom were garbage back when the Pixel 4 was released.
(Normally digital zoom is garbage, but Google’s MFSR pipeline improves things significantly - Handheld Multi-Frame Super-Resolution )
To the OP: As someone who used to do AOSP-derivative platform maintenance on Samsung devices (I was one of the members of teamhacksung back in the Galaxy S2/S3 days), I’d avoid Samsung like the plague. Their software is horrible. Stuff like “let’s hack the frameworks to ignore a bogus value reported by the ambient light sensor HAL instead of just fixing the damn HAL to report a correct value”, etc. Let’s not forget them continuing to ship known defective eMMC firmware in the Galaxy S2 (and many of its derivatives) for 6+ months after Google told them that going to production with that eMMC firmware was not going to be allowed for the Galaxy Nexus.
