Sony a7 and a7R Raw Compression

[Vladimirovich]

Beside the fact, that Sony compression obviously is required for the excellent live view

how does it ? if it is applied only when you actually writing a raw file ?

[Vladimirovich]

Well, I do not know about the number of bits used in the signal processor, but I do think that making a non linear slope is easy, since the slope is generated with a digital to analog converter, so can have any shape you like. It is not doing compression before the ADC, but as part of the ADC.

those sensors Sony Semi is selling to a lot of companies, not only to Sony Imaging... some of those were designed for customers getting 'em before Sony Imaging and to overburden the simple on-die ADCs with compression is not wise when the only Sony Imaging is using that feature... it is a purely digital compression done post ADC, off sensor by Bionz before writing the data in raw file.

[CptZar]

Vladimirovich, please see this posts from page 3. There is one more on the same page. I am referring to it.

Cheers

Jan

I think that the compression of the tone curve is mostly  irrelevant, since the part of the resolution that is lost is completely swamped in shot noise anyway. The thing is that this compression is almost certainly done in the ADC itself, and doing so is a very smart move.
Sony uses column conversion, meaning they use a lot of ADC's in parallel. This, in combination with some other tricks, seem to get rid of most, if not all, pattern noise and leaves the low read noise. All this is resulting in the great dynamic range of Sony sensors. A problem with having so much ADC's, is that they have to be simple. And simple they are. Sony uses the most basic of ADC's, where a voltage that is ramping up, is compared with the analog voltage out of the sensor. So called slope analog to digital converters. A problem with these is speed. For 14 bits, such an ADC needs 2^14 clock cycles for each conversion. when using say a 400MHz clock, this means 41us per conversion. Sounds fast, but they must perform over 6000 of such a conversions for each image, stretching the conversion time to a bit ore than 0.25 sec. This is a bit slow, for high frame rates, but also for live view.
The slope, or voltage ramp, going into the comparator is generated by an analog to digital converter, meaning that the shape can be made as desired. Sony uses a variation of an exponential slope (the compression). This cuts the conversion time down by a factor of eight (2^11 in stead of 2^14). Now the total conversion time is slightly over 0.03sec. Great for live view.
It might very well be that this explains why Nikon live view is as poor as it is (line skipping to reduce conversion time), compared to that of Sony.
And the elegant thing is that this compression is not really costing much, if anything.  14 bits are needed for he dynamic range. But signal to noise ratio, when light is hitting the sensor, is not only determined by the ADC and read noise, but also by a property of the light itself; shot noise. Say that the a7r sensor has a full well capacity of 60000 (optimistic). Such a full well capacity means that at maximum illumination, the snr is sqrt(60k) is approximately 245, which can easily be resolved with an 8 bits ADC. so with 11 bits, there is room to spare. That is the thing with shot noise, its level goes up with the signal, not just as fast, but it goes up. So the 14 bits are needed for the deep shadows, but once there is enough light on a pixel, you do not need them anymore.

It would indeed be nice is Sony would also allow you to use all 11 (compressed) bits, without the second part of the conversion.

Sorry if all this is a bit technical, I do not know how express the above otherwise.

[Vladimirovich]

It might very well be that this explains why Nikon live view is as poor as it is (line skipping to reduce conversion time), compared to that of Sony.

Sony does the same line skipping... you are not stating that Sony does whole frame readout to feed XGA viewfinder, are you ?

for example E-M1 and GH4 are using this sensor http://www.semicon.panasonic.co.jp/ds8/c3/IS00006AE.pdf

it does 10bit readout and 12 bit readout... why do you need to complicate simple ADC w/ curve compression when you can just do 10bit linear for a speed (to feed EVF/LCD and probably CDAF) when necessary ? it seems it can feed that @ 120 fps w/ lines skipping for EVF and at the same time (w/ uninterrupted EVF/LCD feed) feed CDAF from focusing point subarea @ 120/240/480 readouts per second... I have both E-M1 and A7 and I'd not say that A7 has a better EVF/LCD feed at all  , on the contrary...

[Hans van Driest]

I was referring to 100% live view. there one can see a clear difference between Nikon and Sony. it is indeed also possible to do this with a reduce word length (10bits for example), but then one could ask why live view, at 100%, of the d800 is so (relatively) poor.

[Vladimirovich]

I was referring to 100% live view.

100% LV does not require all rows to be read from sensor - you are reading subset of rows, so non issue either...

there one can see a clear difference between Nikon and Sony.

yes, that is Nikon is dSLR and Sony is dSLM with different priorities in design...

[Guillermo Luijk]

Sorry to revitalize such an old post, but today I came across a Sony A7 II RAW file and there is something I don't understand. The compression seems evident in the RAW histogram obtained with dcraw -D:



Just counting used levels we find 4 zones in the range of decoded values:

• From 128 to 801 all used -> 674 levels
• From 802 to 1424 half the levels used -> (1424-802)/2=311 levels
• From 1427 to 2023 one out of each 4 used -> (2023-1427)/4=149 levels
• From 2029 to 4101 one out of each 8 used -> (4101-2029)/8=259 levels

Total number of used levels: 674+311+149+259=1.393 levels -> log2(1393)=10,44 bits

What I do not fully understand is that if one now develops this RAW file with DCRAW (gamma 1.0 output), levels spread in the final image in the same way as in the decoded RAW file, without any compression curve applied. This shocks me because given the high DR of this sensor, if the decoded values are already linear in a 12-bit range (from which only 10,44 bits are actually used), how can it avoid shadow posterization when lifting the shadows? and if they are not linear, how can the output from DCRAW not linearize them?.

Unless I am missing something or DCRAW is simply ignoring Sony's compression, I don't understand what's going on.

Regards

[NancyP]

This is all quite interesting to a non-engineer like myself. Thank you, thread contributors.