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.
1 Like
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:
- A small resolution JPEG preview in IFD0
- The full resolution Bayer raw in the SubIFD, but: 14-bit after multi-frame processing, and JPEG lossless compressed
@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).
1 Like
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.
1 Like
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?
1 Like
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.
Nikon D7000 (ISO 6400; kit lens at f/4.5 - sorry, my bad; 1 second exposure time)
What I mean to say is that, as long as there’s enough time, our phones have become powerful low-light devices.
1 Like
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.