Global Sensor Bandwidth

The photo-world is all agog over Sony’s just-announced (but not shipping till next year) high-end ($6K) camera, the ɑ9 III, because it has a “global sensor”. No, the “global” label didn’t mean anything to me either, when I first read it. The write-ups about it have explainers and cool pictures (PetaPixel, DPReview). I found myself wondering “What is this thing’s bandwidth?” and thus this note. I’ll toss in another little explainer so you don’t have to click on a link like a savage.

Non-global shutters · A digital camera sensor has millions of pixels arranged on a grid (in non-obvious and geometrically interesting ways, but let’s not go there); they are analog devices that measure how many photons hit them. To produce a digital image the camera runs a bunch of voodoo across the sensors to produce a digital integer array that can be saved in memory and eventually displayed as a colored image on a screen.

But wait, how does the camera go about arranging for the photons to hit the sensor? Well, there can be an actual physical shutter that opens for a very short time and then closes again, or there can be a purely electronic-mode “shutter” that turns on the pixels then reads the values off them after enough time has passed.

But a physical shutter takes nonzero time to traverse the face of the sensor, so the pixels at the top are not exposed at the same instant as the pixels at the bottom. (Of course it’s more complicated than that, there are shutter geometries and other design tricks but let’s not go there.) Which is normally OK, but suppose you’re taking a picture of something that’s moving fast. Then you can get what’s called “banding” or “rolling shutter”, usually shows up as unwanted curvature. There are other problems with synchronizing a flash (but I don’t use those) and in video mode.

Electronic shutters don’t make this problem go away. The pixels are arranged in an array (On my Fujifilm X-T30 6240x4160, on my Pixel 7 4080x3072) and are typically read off about as you’d expect, a row at a time. Which in practice is like a shutter.

“Global shutter” · You’ve likely already figured it out. These things advertise that they read all the pixels off the sensor at once. So, no matter how fast your subject is moving, you’ll get an image of what it really looked like. And those flash and video problems vanish. And because circuits are faster than shutters, you can shoot at an eighty thousandth of a second.

All of which probably doesn’t do much for me, I take pictures of oceans and flowers and trees mostly. But for people who shoot sports or wildlife or in extreme lighting situations, this is probably a big deal. And there’s no need for a physical shutter at all; any time you can get rid of a moving part, that’s a win.

“Simultaneously?” · One result of all this is that the ɑ9 III can take 120 shots/second. At this point I should mention that it has 24.6M pixels, small by modern high-end-camera standards. So, first of all I was wondering how you read those data points “simultaneously”. I’m not a microelectronics whiz but a few jobs ago I learned a lot about memory controllers and, well, that’s a lot of integers to move all at once. Then I wondered, what’s the bandwidth at 120 frames/second?

The first question that arises is, how many bytes is 24.6 million pixels? Starting with, how many bits per pixel? The answer to this is less obvious. My first assumption was that since the pixels on my screen have 24 bits of RGB information it’d be three bytes/pixel, but no, each pixel only measures the dynamic range of one color, then a process called demosaicing produces the RGB pixels. so I thought maybe just 8 bits/pixel? As with everything else, it’s more complicated than that; the answer seems to be somewhere between 10 and 16 bits/pixel.

So I scribbled some Ruby code, whose single argument is a guess at the number of bits per pixel, and computes how many GB/second those 120 shots are. Here’s the Ruby in case you want to check my arithmetic.

def data_rate(bits_per_pixel)
  pixels = 24.6 * 10**6
  shots_per_second = 120
  bits_per_sensor = pixels * bits_per_pixel
  bytes_per_sensor = bits_per_sensor / 8.0
  bandwidth = bytes_per_sensor * shots_per_second
end

bpp = ARGV[0].to_f
bw = data_rate(bpp)
bw_in_g = bw / 10**9
puts "data rate #{bw_in_g}G"

If you trust that Ruby code, at 10 bits/pixel, the camera is moving 3.69GB/sec; 5.90GB/sec at 16. Which I think is a pretty neat trick for a consumer product, even a high-end one.

The future · It seems likely that global shutters will probably get a lot cheaper and become a feature of almost every serious camera. Because those circuit designers and semiconductor-wranglers are really smart people, and you just know they’re going to find a whole lot of ways to take this v1.0 implementation and make it cheaper and better.

What’s interesting is, it’s not obvious to me whether or not global shutters wil be ubiquitous in mobile-phone cameras. They have way more CPU but way less room inside. We’ll see.

But, you know what, I’d sort of thought that we were in a plateau of excellence in camera design, wasn’t expecting any really significant new features to show up. But what with C2PA and now this in the last couple of weeks, it’s pretty clear I was wrong. Fun times!

Contributions