Hello,
as I was researching the iPhone RAW/dng bit per sample depth for the FULL resolution content, it quickly became very confusing to determine what is really the BitPerSample used in a DNG photo produced by an iPhoneX (mine). So I downloaded various RAW photos from various cameras, and used exiftool to display the relevant information. I am not sure why Canon and Apple report that information differently/incorrectly than the other camera manufacturers or is it a bug in exiftool (which I doubt) ?
One can potentially infer the "correct" BitsPerSample from the WhiteLevel, as per Adobe's Spec [(2 ** BitsPerSample) -1], so that would make the iPhone XsMax BitsPerSample 12, which somehow I doubt ... Is there another deterministic way from RAW values to determine this ?
QuoteSystem Info
1- MacOS HighSiera (10.13.6)
2- exiftool ver 11.11
3- exiftool -s -a -u -D -G1 -Model -WhiteLevel -BitsPerSample *
4/5- Have emailed link to images, exiftool output is attached.
Regards and thanks!
I don't see any contradiction here. BitsPerSample represents the number of stored bits per sample, but some of these bits may be unused. Of course, leaving unused bits is a waste of space, but it is a fairly common practice.
Looking at WhiteLevel may be more realistic, but there is nothing stopping the camera from, say, writing the upper 12 bits and setting the lower 4 bits to zero, which wouldn't show up in the WhiteLevel (although I don't know if any cameras do this).
BTW. You should be sure you are looking at tags from the IFD with a SubfileType of "Full-resolution Image".
- Phil
Thanks, indeed I am looking for the bits for full resolution image when I view the full exiftool info. My point is that Nikon seems to report the actual BitsPerSample (12 or 14) and obviously still packs that info into 16bits. Apple iOS/Canon reports 16bits, so then it seems there is no clear definitive way to deduce that information for iOS cameras?
======== DSC_0505.NEF
[IFD0] 272 Model : NIKON D7500
[IFD0] 258 BitsPerSample : 8 8 8
[SubIFD1] 258 BitsPerSample : 14
======== DSC_6019.NEF
[IFD0] 272 Model : NIKON D810
[IFD0] 258 BitsPerSample : 8 8 8
[SubIFD1] 258 BitsPerSample : 12
======== IMGP1018.DNG
[IFD0] 272 Model : PENTAX K-70
[SubIFD] 50717 WhiteLevel : 16319
[Pentax] 126 WhiteLevel : 16319
[IFD0] 258 BitsPerSample : 8 8 8
[SubIFD] 258 BitsPerSample : 14
[SubIFD1] 258 BitsPerSample : 8 8 8
======== IMG_0057.CR2
[IFD0] 272 Model : Canon EOS M100
[IFD0] 258 BitsPerSample : 8 8 8
[IFD2] 258 BitsPerSample : 16 16 16
======== iPhoneXRAW.dng
[IFD0] 272 Model : iPhone X
[SubIFD] 50717 WhiteLevel : 4095
[IFD0] 258 BitsPerSample : 8 8 8
[SubIFD] 258 BitsPerSample : 16
This is sort of outside my realm of expertise. I don't really know much about the details of image decoding.
- Phil
Quote from: Phil Harvey on November 20, 2018, 10:47:26 AM
This is sort of outside my realm of expertise. I don't really know much about the details of image decoding.
:o From your amazing tool I thought you knew everything ! My search continues... and thanks again for your work and replies!
QuoteOne can potentially infer the "correct" BitsPerSample from the WhiteLevel, as per Adobe's Spec [(2 ** BitsPerSample) -1]
For reference by future readers who (like me) stumbled upon this thread: This is exactly what Adobe Lightroom Classic and Adobe Bridge do for reporting Bits Per Sample / Bit Depth for DNGs.
I experimented by changing SubIFD:WhiteLevel of a DNG to various values, and LR and Bridge displayed Bits Per Sample / Bit Depth that was equal to ceiling (log2 (WhiteLevel)).
I believe the apps use this approach because SubIFD:BitsPerSample represents how many bits are used to physically store a sample. But some cameras will use 16 bits to store a sample even though their sensor is capturing less than 16 bits.