---
title: "A train becomes the second axis of this line-scan camera"
locale: "en"
url: "https://irz.fr/en/articles/linecam-railway-scanner-en"
markdown_url: "https://irz.fr/en/articles/linecam-railway-scanner-en.md"
category: "creative"
tags: ["photography", "maker", "machine-vision", "railway", "open-source"]
published_at: "2026-08-18T22:42:00.000Z"
author: "Hugo Marchal"
translation: "https://irz.fr/fr/articles/linecam-railway-scanner-fr.md"
---

# A train becomes the second axis of this line-scan camera

Linecam records one vertical strip at a time from a moving train. The hard part is not resolution but measuring motion well enough to decide where every strip belongs.

A flatbed scanner normally holds the subject still and moves a narrow sensor across it. Philo's Linecam does something more inconvenient: the sensor stays pointed out of a train, and the railway moves the entire camera through the world.[1](https://philo.gay/linecam/)

The camera does not capture ordinary rectangular frames: it records one vertical line of 2,048 pixels at a time, and when those lines are collected quickly enough while the train advances, placing one beside the next gradually produces a landscape.[1](https://philo.gay/linecam/)

It sounds like a trick. The interesting part is everything that immediately goes wrong.

**Once movement becomes one axis of the image, speed becomes part of the camera.**

## The second dimension comes from motion

Philo's first experiment used nothing more exotic than a phone on an office chair, recording video as the chair moved past a sofa; a quick script then extracted one column from each frame and joined the columns into a single image.[1](https://philo.gay/linecam/)

The result was recognisable and badly stretched.

That first failure explains the project better than the successful panorama does: when the camera moves twice as far between captured lines, the corresponding slice of the world becomes too narrow, while slowing down makes objects expand. A normal camera tolerates changes in the photographer's speed until motion blur becomes obvious; a line scanner uses the movement itself to construct geometry.

Philo writes about the next attempt on an MBTA train, using phones and accelerometer data, but integrating noisy acceleration into velocity was not enough: by the end of one test, the estimate even had the train moving backwards.[1](https://philo.gay/linecam/)

The project therefore became less about taking many pixels and more about measuring **where each line belongs**.

> Illustration: Diagram showing how camera movement creates the horizontal axis of a line-scan image. Each vertical line is captured at a different position. Uneven movement becomes geometric distortion. Credit: [Philo / philo.gay](https://philo.gay/linecam/).

## A conveyor-belt camera ends up looking through a train window

The serious sensor came from machine vision: a Basler ruL2048-19gm line-scan camera.

> Illustration: Basler line-scan camera used in Linecam. The industrial sensor records one vertical line rather than a conventional rectangular frame. Credit: [Philo / philo.gay](https://philo.gay/linecam/). Its sensor is essentially 1×2048 pixels and can read just under 19,000 lines per second, according to the specifications cited by Philo.[1](https://philo.gay/linecam/)

Above a conveyor belt, such a camera is entirely sensible because the belt provides predictable motion and carries products beneath the sensor, allowing a long strip of material to be inspected without building a giant two-dimensional imager.

A railway is a much less polite conveyor belt.

A train, by contrast, accelerates, brakes and vibrates; nearby objects sweep across the field of view faster than distant ones, stations interrupt the light, other trains intrude, windows reflect the interior, and the route itself dictates the viewpoint.

Light creates another practical limit because, as Philo notes in his post, even the slowest exposure is around 1/100 second; daylight therefore works much better than dark tunnels or dim stations.[1](https://philo.gay/linecam/)

The limitation produces a peculiar photographic instrument. You cannot simply stand somewhere and compose. You choose a railway, a side of the train, a time of day and a stretch of track, then accept that the subject will be sampled according to motion you only partly control.

> Illustration: Linecam system diagram with camera, IMU, GPS, microcontroller, laptop and power. The rig adds motion sensors because train speed is part of image geometry. Credit: [Philo / philo.gay](https://philo.gay/linecam/).

## The rig is mostly an argument with speed

To make the camera usable on a train, Philo designed a simple 3D-printed case with a tripod insert, fitted a 28 mm lens to the C mount, and added an IMU, GPS and microcontroller for motion measurements; a USB-C battery bank supplies power while Ethernet and USB run back to the laptop.[1](https://philo.gay/linecam/)

The resulting setup is not elegant in the consumer-camera sense. The bundle grew directly from earlier failures, with each component answering a problem that had already appeared in testing.

The IMU is there because assuming a constant train speed distorted the image, while GPS supplies another estimate of movement and location; the case solves the more mundane problem that holding a line camera against a train window while managing a laptop requires an unnecessarily ambitious number of hands.

Philo also wrote the capture software instead of relying on a closed acquisition tool. The `linecam-capture` repository uses Basler's Pylon SDK and publishes the code used to grab data from the camera.[2](https://github.com/FlamingSpork/linecam-capture) The separate `grindstone` repository contains the postprocessor for the linear images.[3](https://github.com/FlamingSpork/grindstone)

The separation is useful because capture preserves the raw stream and sensor measurements, leaving post-processing to decide how those measurements should become spatial columns.

The photograph is therefore not finished when the shutter closes. There is barely a shutter to close.

## Correction is part of the lens

A conventional camera keeps most of its geometry in glass and sensor layout, whereas Linecam moves a meaningful part of that job into software.

Each captured line knows what the sensor saw at a moment in time. To become an intelligible panorama, the software has to estimate how far the camera moved during the interval and resample the lines accordingly.[1](https://philo.gay/linecam/)

A bad speed estimate therefore squeezes and inflates the scene instead of merely blurring it.

The distinction matters. Here, image processing is not cosmetic cleanup; it performs part of the work that a mechanical scanner normally gets from a controlled rail.

On a flatbed scanner the motor advances the sensor by a known distance for every step; on Linecam, the MBTA is effectively the motor, except that public transport rather inconsiderately provides no convenient encoder signal.

So Philo adds sensors and inference until the uncontrolled rail can approximate the information a scanner carriage would have supplied directly.

**The software is reconstructing the missing machine.**

> Illustration: Diagram of Linecam post-processing and motion correction. Capture preserves the line stream; post-processing estimates how those lines should be spaced in the final image. Credit: [Philo / philo.gay](https://philo.gay/linecam/).

## The distortions are not all errors

The resulting images are strange even when the speed correction works.

A line camera never captures one shared instant across the panorama: the left side may precede the right by seconds or minutes, a moving car may compress, stretch or repeat according to the way it crosses the scanning line, and foreground objects behave differently from distant ones because their apparent motion differs.[1](https://philo.gay/linecam/)

That makes the output a poor substitute for a normal wide-angle photograph if accuracy is the only goal.

It also makes it a more interesting camera.

The panorama stores time sideways. The railway route becomes a long exposure with a geometry assembled one column at a time. A port, bridge or streetscape is dragged through a narrow sensor aperture, accumulating many viewpoints along the route.

Some distortions need correction because they simply hide the scene, while others are useful precisely because they reveal how this strange image was made.

Philo's project becomes strongest at that boundary. The aim is not to erase every sign that a train performed the scan. The aim is a result coherent enough for the unusual mechanism to remain visible without looking merely broken.

## The project leaves enough behind to be repeated

Linecam is also unusually legible as a project. In this post, Philo does not stop at the finished photos: it shows early chair-and-phone tests, diagrams of the motion problem, pictures of the Basler camera and the train setup, then links to the capture and post-processing code published online.[1](https://philo.gay/linecam/)[2](https://github.com/FlamingSpork/linecam-capture)[3](https://github.com/FlamingSpork/grindstone)

The difficult part of the camera lives in the relationship between its components, not in some hidden proprietary part. It is the chain of choices connecting motion, sensor timing and reconstruction. A photograph of the rig tells you where the hardware went; the diagrams explain what quantity the software is trying to recover; the repositories show how the recorded lines are handled after capture.

To be sure, someone trying the idea on another railway would still have plenty of work. A different train, lens or line sensor changes the numbers, and Philo's code remains project software, not a polished consumer application. But the online record gives the next experimenter something much better than a glamour shot of the final panorama.

Maker projects keep running into the same distinction. Publishing a beautiful result proves that something happened once. Publishing the awkward prototype, failed speed estimate, wiring, code and post-processing lets another reader follow the chain that produced the result. Linecam is interesting as photography, but the website is also a record of the machine being discovered one failure at a time.

## An industrial sensor becomes a photographic rule

Linecam could be described as a clever reuse of a cheap second-hand machine-vision camera. That is true and not quite enough.

The deeper move is to take the operating assumption of the sensor seriously.

A line-scan camera expects the world to move past it. Instead of building a controlled conveyor, Philo asked what existing machine already moves for kilometres with large windows and repeatable routes.

The answer was public transport, and that choice changes everything downstream, from the enclosure and sensors to exposure, software, post-processing and even the definition of a successful image.

The railway does not merely carry the photographer to the subject.

For Linecam, **the railway is one of the camera parts**.

## References

1. [Philo, Using the railway network as a flatbed scanner, Linecam](https://philo.gay/linecam/)
2. [FlamingSpork, linecam-capture source code](https://github.com/FlamingSpork/linecam-capture)
3. [FlamingSpork, Grindstone line-scan image postprocessor](https://github.com/FlamingSpork/grindstone)