This is a continuation of a series of posts on the Sony a7RIII. You should be able to find all the posts about that camera in the Category List on the right sidebar, below the Articles widget. There’s a drop-down menu there that you can use to get to all the posts in this series.
[This post has been modified to include believable results for the compressed case and to remove the not credible ones. If you look at the comments, you can see that I got a lot of help. In particular, Horshack told me how to fool ACR into opening a7RIII files. I used that below. Iliah and Ilias gave me some advice on using LibRaw, which I will play with soon. Thanks also to Jack Hogan for help using LibRaw.]
I’ve spent the bulk of today working on photon transfer curves for the a7RIII, and I don’t have much to show for it. Here’s one interesting thing:
This is for an uncompressed raw single shot capture with the EFCS on at ISO 100. The horizontal axis is the mean of each sample and is a log base two scale. 0 is full scale, -1 is one stop down from that, and so on. The vertical axis is the standard deviation (RMS value) of the noise in a 200×200 pixel sample. It’s also a log base two scale and 0 is RMS noise equal to full scale. The sampling method was the subtraction of pairs of identical exposures.
Everything looks fine except for those ripples. We’ve seen something like that before with 12-bit conversions and low-noise sensors. But the a7RIII appears to have a 14-bit ADC, and these occur at higher mean values than the 12-bit truncation ripples.
When I tried to do PTCs for compressed raw files, I came a cropper. dcraw, which seemed to be pretty good at decoding compressed raw files with earlier alpha 7 cameras, produced silly results. Normally in a case like that, I’d use Adobe DNG Converter to convert the files to DNG format, and then use dcraw on them. But DNG converter does not currently support the a7RIII. (Neither does Adobe Camera Raw or Lightroom). I loaded the ARW files into Capture One 11, and exported them as DNGs, but got strange results. Then I told the PTC program to look at the compressed results as having 12-bit precision and used a black point of 128.
The ripples are greater, which fools the modeler into thinking there’s more read noise than there really is. I am a bit concerned about what’s happening to the 13th bit.
I used Horshak’s suggestion and tricked the Adobe DNG Converter into thinking the files were from the a7RII, not the III. He suggested that I do that by getting exiftool to mess with the metadata, and that worked great. Then dcraw recognized them as 14-bit files, and here’s what I got for a PTC:
This makes more sense. The other compressed curve had ripples that were caused by dcraw’s truncation of the 13-bit values to 12-bit ones. Note that the ripples are larger with 13-bit precision than 12-bit. Does the camera use a different ADC mode when it’s making compressed files, or is it just the difference in precision. I don’t know, but the Nikon D810 14-bit files didn’t have any ripple at all. [Correction. The green channels don’t have ripple, but the red and blue channels do, and I now think it’s caused by the Nikon white balance prescaling.]
By the way, these curves put the full well capacity (FWC) of the a7RIII at about 52,000 electrons, which is what I got for the a7RII. [This is probably too low by 10 or 15%, because the a7RIII digital scaling invalidates my assumptions for the FWC modeling.]
That knowledge allows us to restate some earlier read noise curves in electrons.
[Added 12/5 13:30 PST]
Mark Shelley has come up with what appears to be an explanation for the ripples in the PTCs.
Here’s an uncompressed file:
And a compressed one:
In the compressed case, the gaps are completely empty. With compression, they are partially depopulated.
Anybody know why Sony does this?