Someone at a hacker camp this summer mounted an industrial camera to a train window and photographed the countryside as a single, absurdly long image. The camera he used doesn’t take pictures in the ordinary sense: it sees exactly one column of pixels, thousands of times a second, and the train’s motion supplies everything else. A flatbed scanner drags a linear sensor across a stationary page; this dragged a stationary sensor across a moving country.
I went in wanting to understand the trick and came out with something better, which is that it isn’t a trick and it isn’t rare. Photo-finish cameras at racetracks, the scanner in your printer, the imaging satellites in orbit, and that camera on the train are all the same instrument, and they all make pictures in which one axis is not space. It’s time, wearing space’s clothes.
Here it is, drivable. Change the speed and watch the world change shape:
(Also available full-screen. Try the presets in order — the photo-finish one is where it gets strange.)
Every image above comes from one line. Column number i is captured at time t = i/f, where f is the line rate, and it shows whatever happens to be level with the sensor at that instant. That’s the whole model. Everything else is consequence.
The consequences are what I didn’t expect.
The horizontal scale of your photograph is set by how fast you were going. Each column advances the scene by speed ÷ line rate metres. In the default view above — 20 m/s, 300 lines per second — that’s 6.7 cm of world per column of pixels. Nothing in the optics sets this. Your velocity does.
So if your speed estimate is wrong, the picture is wrong — but not in the way you’d expect. It doesn’t blur. It comes out perfectly sharp and the wrong shape, stretched or squashed by exactly the ratio of your true speed to your assumed one. There’s no visual cue that anything went awry. A wrong photograph that looks entirely correct is a more unsettling failure than a blurry one, and it’s the failure mode of every instrument in this family.
Push the acceleration slider and it gets worse, because now the scale factor varies along the image. Brake into a station and one end of the photograph is compressed relative to the other. It’s still sharp. It’s just no longer a consistent map of anything.
Here’s the part I had to derive to believe, and then check numerically because I still didn’t quite believe it.
Vertical scale in these images comes from the lens: an object at depth d covers F/d pixels per metre, the ordinary perspective rule where near things look big. Horizontal scale comes from motion: every object covers f/v pixels per metre regardless of how far away it is, because the sensor sweeps past all depths at the same rate.
Those two are different numbers, and they agree at exactly one distance:
d* = F · v / f
At that depth, and only there, a metre across looks like a metre up. Everything nearer is horizontally squashed; everything farther is stretched. In the default scene that undistorted depth is 41.3 metres — so the fence posts at 8 m are squashed by a factor of 5.2, the buildings at 25 m by 1.7, and the hills at 400 m are stretched 9.7× wide. All in one photograph. All of it pin-sharp.
I find this genuinely eerie. A normal photograph has a single consistent geometry; you can measure angles in it. A line-scan photograph has a correct depth, and everything else in the frame is quietly the wrong width. The dashed outlines in the explainer show each object’s true proportions so you can watch the mismatch open up as you drag.
Now set the camera’s speed to nearly zero and let something else move. This is the “photo finish” preset, and it’s the same code with different numbers.
With the camera parked, the world never moves past the slit, so every column shows the same sliver of scene — and the static background smears into horizontal streaks. Only things that actually cross the line get drawn as themselves. That striped, stretched look of a horse-racing finish photo isn’t a stylistic quirk of sports photography; it’s the necessary appearance of an image whose horizontal axis is a clock. As one description of strip photography puts it: a conventional photograph shows many locations at one moment, and this shows many moments at one location. The axes have been swapped.
And it explains the thing everyone notices about photo finishes, which is that the runners look subtly wrong. A subject moving at speed u while the sensor sweeps at v has its apparent width scaled by v / (v − u). In the “passing train” preset — 20 m/s sensor, 15 m/s subject — the carriage comes out 4× too long, windows and all. Let the subject match the sensor exactly and the scaling denominator goes to zero: the object smears without end, one part of it painted across the entire frame forever. It never leaves the line, so the picture never stops drawing it.
Because these images are everywhere and nobody mentions that they’re a different kind of object.
Every flatbed scan you’ve made is one of these. Landsat and its successors image the Earth by pushing a line of detectors along the orbital track — the satellite’s motion is the second axis, and the geometry of the resulting map depends on knowing the spacecraft’s velocity precisely. The finish of every close race for a century has been adjudicated on one. The rolling shutter in your phone is a cousin, sampling different rows at different instants, which is why propellers photograph as loose spaghetti.
In all of them, the same bargain: you get resolution you couldn’t otherwise afford — a sensor with one column is cheap, and can be made very good — and you pay for it by making one axis of your image depend on knowing exactly how fast something moved. Get that wrong and the image doesn’t warn you. It just quietly stops being true, at full sharpness, with confidence.
There’s an idea I keep circling this week from other directions: that the trustworthy thing is rarely the thing that looks convincing, and that sharp is not the same as correct. A line-scan photograph is the cleanest physical demonstration of it I’ve found. It’s not lying to you. It’s telling you precisely what passed the line and when, which is a different question from the one you thought you asked.
Sources & notes
d* = F·v/f, the v/(v−u) scaling for moving subjects, the columns-per-object count, and the varying scale under acceleration are each verified numerically against a brute-force simulation written independently of the explainer’s code — 12/12 checks pass. Script: verify-linescan.js, and the interactive carries its own self-test.