Why don't stack sensors have faster video rolling shutter?

Horshack

Forum Pro
Messages
11,231
Solutions
28
Reaction score
12,594
Location
US
The current generation of FF stacked sensors support full-sampled readout rates of <= 5ms (1/200 or faster) in photo mode yet their video rolling-shutter performance is several times worse.

For example, Jim measured the Z9's stills-mode full-sensor readout at 1/270 (3.7ms), yet the Z9's 8K video rolling-shutter is 14.5ms and its 4K oversampled rolling-shutter is 14.5ms (per CineD).

It's understood there are likely processing bottlenecks in the video imaging pipeline but I always assumed all processing would be done on a fully-formed frame buffer, which means those bottlenecks shouldn't require any back-pressure to be applied to the sensor readout stage for buffer flow management. And stills-mode has a similar imaging pipeline (demosaicing, WB scaling, lens corrections, NR, picture controls, etc..., minus the oversampling and H.264/H.265 encoding of video), yet maintains the full readout rate of the sensor. Lastly, video doesn't require/use the full sampling of the sensor - it uses 12-bit sampling at most, and perhaps even 10-bit for the non-raw video modes, which offset the higher continuous frame-rate demands of video vs stills.

A few possibilities come to mind.

One idea (and perhaps most likely) is aggregate internal bus bandwidth limitations. The bandwidth demands for all the bus round-trips of the video processing pipeline stages is huge and perhaps doesn't leave enough available bandwidth to run the sensor at its native readout speeds.

Another idea is the video pipeline is unique in that it processes data directly off the sensor instead of a frame buffer, which would necessitate slowing down the sensor readout to buffer match. But this seems exceedingly unlikely considering the multiple required in the full video pipeline, meaning the data has to be deposited into a SDRAM anyway to accommodate.

Another idea is that the full sensor readout speed isn't available for video due to the multi-row readout scheme used in these sensors, ie Jim found that both the Sony A9 and Nikon Z9 appear to do 12-row parallel readout (and implied ADC). Perhaps that scheme isn't suitable for how data enters the video pipeline...although I can't think of a reason why that would be the case.

Another idea is that the sensor readout is slowed for power consumption reasons.

By comparison, the Sony A7s III has a non-stacked BSI sensor that achieves full-sampled video rolling shutter of 8.7ms in 4K (per CineD). The A7s has a 12MP sensor, so naturally the data load is much lower both for sensor readout and processing, but again, it's not clear that system bandwidth is the gating factor for how fast the camera configures the sensor readout for video.

Ideas?
 
Last edited:
Thanks for this thread. It's an interesting question, and, while I certainly don't know the answer, I'll be paying attention here.
 
The current generation of FF stacked sensors support full-sampled readout rates of <= 5ms (1/200 or faster) in photo mode yet their video rolling-shutter performance is several times worse.

For example, Jim measured the Z9's stills-mode full-sensor readout at 1/270 (3.7ms), yet the Z9's 8K video rolling-shutter is 14.5ms and its 4K oversampled rolling-shutter is 14.5ms (per CineD).

It's understood there are likely processing bottlenecks in the video imaging pipeline but I always assumed all processing would be done on a fully-formed frame buffer, which means those bottlenecks shouldn't require any back-pressure to be applied to the sensor readout stage for buffer flow management. And stills-mode has a similar imaging pipeline (demosaicing, WB scaling, lens corrections, NR, picture controls, etc..., minus the oversampling and H.264/H.265 encoding of video), yet maintains the full readout rate of the sensor. Lastly, video doesn't require/use the full sampling of the sensor - it uses 12-bit sampling at most, and perhaps even 10-bit for the non-raw video modes, which offset the higher continuous frame-rate demands of video vs stills.

A few possibilities come to mind.

One idea (and perhaps most likely) is aggregate internal bus bandwidth limitations. The bandwidth demands for all the bus round-trips of the video processing pipeline stages is huge and perhaps doesn't leave enough available bandwidth to run the sensor at its native readout speeds.

Another idea is the video pipeline is unique in that it processes data directly off the sensor instead of a frame buffer, which would necessitate slowing down the sensor readout to buffer match. But this seems exceedingly unlikely considering the multiple required in the full video pipeline, meaning the data has to be deposited into a SDRAM anyway to accommodate.
FYI, up until the release of the BIONZ XR, specifications of Sony cameras with the BIONZ X clearly hinted at a bottleneck of around 500-600 megapixels/second (IIRC the A7R4 had some video specs that hinted at a 600 megapixel/second limit, everything else seemed to be around 500ish) somewhere in the video pipeline - but that shouldn't be relevant to this.

That's not the sensor-to-ISP throughput - Jim has clearly measured much higher numbers for non-stacked sensors like the A7R3. e.g. the A7R3's video limitations (And that of nearly every other BIONZ X body) were clearly somewhere downstream of the SLVS-EC interface.

I don't think Jim ever had any tests of rolling shutter in video mode from these bodies to see if there were any interesting differences.
Another idea is that the full sensor readout speed isn't available for video due to the multi-row readout scheme used in these sensors, ie Jim found that both the Sony A9 and Nikon Z9 appear to do 12-row parallel readout (and implied ADC). Perhaps that scheme isn't suitable for how data enters the video pipeline...although I can't think of a reason why that would be the case.
Does anyone know if the VENICE sensor (which is VERY similar in specification to the A9/A9II sensor, enough so that it might be identical with a different system-level implementation enabling a few additional features) did the multirow readout?
Another idea is that the sensor readout is slowed for power consumption reasons.
This is the only technical explanation I can think of.
By comparison, the Sony A7s III has a non-stacked BSI sensor that achieves full-sampled video rolling shutter of 8.7ms in 4K (per CineD). The A7s has a 12MP sensor, so naturally the data load is much lower both for sensor readout and processing, but again, it's not clear that system bandwidth is the gating factor for how fast the camera configures the sensor readout for video.

Ideas?
You've omitted the one non-technical explanation: A probable lack of desire by Sony to cannibalize their midrange cinema camera market by having their hybrids offer a rolling shutter spec that absolutely blows away anything in their midrange video lineup.
 
I have no clue but I remember one of the bragging points of the A9 was its' on sensor memory. I kinda assume that is so that it can cache image data that is read off at full 1/150th second speed while it is transferred to the camera through a slower bus.

So maybe one possible theory could be that the memory is disabled for video for some reason, so readout speed is limited by the bus speed..

Now the Canon R3 can shoot stills up to almost 200FPS, does that also have slower rolling shutter in video?

--
Best Regards,
Morten Smedsrud
https://flickr.com/photos/154088944@N03/albums/72177720303431191
https://500px.com/msmedsru
 
Last edited:
I have no clue but I remember one of the bragging points of the A9 was its' on sensor memory. I kinda assume that is so that it can cache image data that is read off at full 1/150th second speed while it is transferred to the camera through a slower bus.

So maybe one possible theory could be that the memory is disabled for video for some reason, so readout speed is limited by the bus speed..

Now the Canon R3 can shoot stills up to almost 200FPS, does that also have slower rolling shutter in video?
Yep, in the OP I mentioned the possibility of the video logic having to read directly from the sensor and bypassing the stacked frame buffer. The possible reason is power consumption and/or thermals.
 
In my sensor readout speed thread I posted a visual showing the 12-row readout employed by the Z8/Z9, which looks like this from a raw still:



In the OP here I theorized that perhaps video modes can't or don't employ the 12-row concurrent readout used for current FF stacked sensors to achieve their very fast readout rates. Today I captured 8K N-RAW using the same methodology above to determine how many rows are readout concurrently. Here's what it looks like:



It's not as clear a visual as a NEF but I'm pretty sure this indicates that video on the Z8/Z9 is using a 4-row concurrent readout, as opposed to the 12-row for stills. Some math:
  • Z8/Z9 full-sensor photo readout speed is 3.73ms (1/268), for 5504 rows of pixels
  • Z8/Z9 per-row photo average readout speed of 677ns, which is actually 8.124us when you account for 12 rows being read concurrently. In other words, the readout occurs in groups of 12 rows, all of which are read concurrently and each row takes 8.124us to read - since they're all read concurrently the total readout time for all 12 rows is the same as the time for a single row - 8.124us
  • If video reads out 4 rows instead of 12, that means the effective max video readout speed is 1/3 of stills
  • The Z8/Z9 8K video full-sensor measured readout is 14.42ms (1/69) for 4320 rows of pixels, with a per-row average of 3.337us. With 4 fours read concurrently that works out for an actual per individual video row readout time of 13.348us vs 8.124us for photo, which is 64% slower than photo. Considering video surely does 12-bit readouts vs 14-bit for photo's, the actual potential readout speed difference is greater than this 64%. So it appears the difference in video readout speed here is a combination of 4 vs 12 concurrent rows and a slower actual per-row rate.
 

Attachments

  • 4408442.jpg
    4408442.jpg
    243.3 KB · Views: 0
  • 4408497.jpg
    4408497.jpg
    134.3 KB · Views: 0
Last edited:
I think it is due to the high-power consumption and problems with heat management.

There are clues in the Sony A9 IMX310 sensor spec sheet below:

For reference the Sony A9 internal camera model number is WW361847

OVERPIC.net » Image Hosting (archive.org)

e.g.

"In addition, some functions can't be used in body W361847 to avoid heating problem."

In video mode "On-Clip DRAM function disabled on WW361847" i.e. the senor is not using the stacked memory in video mode.

Interestingly the sensor is also capable of a DR of 96dB (i.e. 16 stop) in a 16bit readout mode. This is disabled on the A9 and in practice ( i have one) the DR only seems to correspond to 12bit readout.

In dedicated cinema cameras I would assume the sensor can run at full read out speed in video.
 
Last edited:
I think it is due to the high-power consumption and problems with heat management.

There are clues in the Sony A9 IMX310 sensor spec sheet below:

For reference the Sony A9 internal camera model number is WW361847

OVERPIC.net » Image Hosting (archive.org)

e.g.

"In addition, some functions can't be used in body W361847 to avoid heating problem."

In video mode "On-Clip DRAM function disabled on WW361847" i.e. the senor is not using the stacked memory in video mode.

Interestingly the sensor is also capable of a DR of 96dB (i.e. 16 stop) in a 16bit readout mode. This is disabled on the A9 and in practice ( i have one) the DR only seems to correspond to 12bit readout.

In dedicated cinema cameras I would assume the sensor can run at full read out speed in video.
Thanks, nice find on the data sheet. Disabling the stack DRAM for video matches the observation of the Z8/Z9 switching to a 4-row parallel readout from 12-rows for stills, since the 12-rows requires the stacked DRAM to offload the faster data read off the sensor.

In the OP I included power consumption as one of the theories (with the implication for thermals) and with your finding that appears to be a prime suspect here.
 
Fastest stacked sensor 4k oversampled result for video I seen short of the OM-1:

Canon R3 Results Sensor Readout Speed results, sorted by 4k30p
Nice, looks like you bought an R3 - just for testing?
Yep. There was a deep discount on R3 refurbs from Canon USA and it went OOS quickly. I should be able to get what I paid when I sell it.
Canon refurbs are often REALLY well priced.

When I switched to Sony from Pentax, for a while most of my lenses were EF-mount, because you could get refurbs of good lenses REALLY cheap (EF 50STM, EF-S 55-250STM), and many lenses weren't available in native E at the time.
 
Fastest stacked sensor 4k oversampled result for video I seen short of the OM-1:

Canon R3 Results Sensor Readout Speed results, sorted by 4k30p
Thanks, a bit unrelated but it is interesting how fast the R5 is in photo and video considering it is just a standard sensor. I think they use an on-sensor column ADC read out approach like Sony now but why are they so much faster than the Sony sensors? Possibly that the R5 is 12bit in ES while the Sony 14bit? Maybe they are also making a trade off; faster redout but higher read noise. This seems to be the case as the DR is lower to comparable Sonys and the R5 seems to also apply baked in NR in RAW as per this review

Canon EOS R5 review: Digital Photography Review (dpreview.com)
 
Fastest stacked sensor 4k oversampled result for video I seen short of the OM-1:

Canon R3 Results Sensor Readout Speed results, sorted by 4k30p
Thanks, a bit unrelated but it is interesting how fast the R5 is in photo and video considering it is just a standard sensor. I think they use an on-sensor column ADC read out approach like Sony now but why are they so much faster than the Sony sensors? Possibly that the R5 is 12bit in ES while the Sony 14bit? Maybe they are also making a trade off; faster redout but higher read noise. This seems to be the case as the DR is lower to comparable Sonys and the R5 seems to also apply baked in NR in RAW as per this review

Canon EOS R5 review: Digital Photography Review (dpreview.com)
The R5 reads out multiple rows at a time - I can't remember if it's 8 or 12 rows. All the stacked sensors I've seen employ this technique as well but the Canon R5 is one of the few non-stacked design I've seen this on for a recent mirrorless body. That of course doesn't explain how the R5 is able to move all those rows off the sensor so quickly. But there are other non-stacked sensors measured that approach that - for example the E-M5 III. The per-row timing on the R5 is still faster though - 3us/row vs 4.15us/row on the E-M5.
 
Last edited:
For example, Jim measured the Z9's stills-mode full-sensor readout at 1/270 (3.7ms), yet the Z9's 8K video rolling-shutter is 14.5ms and its 4K oversampled rolling-shutter is 14.5ms (per CineD).
Presumably then the 8K readout is slowed down to reduce overheating; did you also test 4K without oversampling?
 
Last edited:

Keyboard shortcuts

Back
Top