Interpreting the True Field of View of Our Vision System

An engineering investigation into how sensor geometry, optics, and software together determine the true field of view of an integrated camera system.

Introduction

When you build a vision system out of off-the-shelf parts, it's tempting to assume that if the sensor and lens are mechanically compatible, they'll behave the way the datasheets say. That assumption held right up until we bolted the camera into our tracker prototype.

For one of our vision modules we paired an onsemi AR0144 global shutter sensor with a Huashi Chengjin 1.8mm M12 fisheye lens. On paper it looked simple: a compact sensor, a 178° diagonal fisheye lens, an M12 mount that physically fit with no issues.

Once the camera was actually running, the numbers stopped matching up. The field of view looked smaller than it should have, the focus math seemed to contradict itself, and neither datasheet explained why.

We ended up tracing the entire optical path, from the light hitting the lens to the image our computer vision pipeline actually sees, instead of treating the lens and sensor as two separate parts that either work together or don't.

The hardware setup

Camera sensor

• Sensor: onsemi AR0144
• Sensor type: CMOS global shutter
• Optical format: 1/4"
• Native resolution: 1280 × 800
• Pixel pitch: 3.0 µm
• Active area: 3.84 mm × 2.40 mm

Lens

• Manufacturer: Huashi Chengjin
• Mount: M12
• Focal length: 1.8 mm
• Projection: equidistant fisheye
• Datasheet FoV: 136° horizontal / 73° vertical / 178° diagonal
• Back focal distance: 3 mm

Nothing about it looked unusual at first. The lens fit, the specs lined up, and the advertised field of view was more than wide enough for what we needed.

It took integrating the camera into the tracker to realize the datasheets only described the two parts on their own, not how they'd behave once put together.

A lens's field of view isn't portable

A common assumption with interchangeable lenses is that the published FoV belongs to the lens itself. That's not really how it works. A lens projects a circular image onto whatever sensor sits behind it, and the sensor only decides how much of that projected circle it actually captures.

It's a bit like projecting a movie onto a wall, then swapping the wall for a smaller screen. The projector hasn't changed, but you're only seeing the center of the image now, so it looks smaller. The same thing happens inside a camera.

The 178° diagonal FoV on our lens datasheet was measured against whatever reference sensor format the manufacturer used to characterize it. Our AR0144 has a smaller active area than that reference, so it only picks up the central part of the image circle. Once we recalculated using the AR0144's actual dimensions, the diagonal FoV dropped from 178° to about 144°, without touching the lens at all.

The lens was doing exactly what it was built to do. We'd just been reading its spec sheet against the wrong sensor

Fisheye lenses don't follow normal camera geometry

Accepting that sensor size affects FoV solved one problem and immediately created another: the standard camera optics equations weren't giving sensible answers.

That's because most photography lenses are rectilinear, and ours isn't. A rectilinear lens follows r = f·tan(θ), where r is image height, f is focal length-, and θ is the incoming light angle. As θ approaches 90°, tan(θ) heads toward infinity, which is why ordinary lenses top out well under 120°.

Fisheye lenses use a different projection: r = f·θ, the equidistant model. Image height scales linearly with angle instead of exploding near 90°, which is exactly what lets a fisheye lens image rays past 90° and reach FoVs near or over 180°.

Running rectilinear equations on a fisheye lens gives the wrong FoV no matter how carefully you measure the sensor. The projection model has to match the lens, not just the numbers.

📐 Engineering insight: The projection model matters as much as the focal length itself. The right equation applied to the wrong lens still gives you the wrong answer.

Back focal distance isn't the same as focal length

The next surprise came from two numbers sitting right next to each other on the datasheet: a 1.8mm focal length and a 3mm back focal distance. Running those through the thin lens equation (1/f = 1/dᵢ + 1/dₒ) put the focus point at about 4.5mm instead of infinity.

Our first read was that something was wrong with the lens. It wasn't. M12 lenses use a threaded barrel rather than a fixed housing, and during assembly the barrel gets rotated until the image plane actually lands on the sensor correctly. The 3mm back focal distance on the datasheet is one geometric parameter of the lens, not a statement about where it ends up focused once it's screwed into a housing and adjusted.

The math was fine the whole time. We were just reading a spec as a conclusion when it was only an input.

Lens → threaded barrel → sensor, showing barrel rotation changing the sensor-to-lens spacing. Caption: Focus gets dialed in mechanically, by turning the barrel, not by redesigning the optics.

Software quietly changed the camera

Even with the optics sorted out, one more mismatch turned up. The AR0144's native active array is 1280×800, but our software pipeline was outputting 1280×720. That wasn't a resize. The sensor was cropping 80 rows off before the image ever reached the application.

Cropping rows only affects the vertical dimension, so the horizontal FoV held steady while the vertical and diagonal numbers both dropped:

Neither the lens nor the sensor had changed. A single line in a software config had quietly redefined how much of the world the camera could actually see.

Chief ray angle has nothing to do with field of view

The most interesting find in this whole process turned out to have nothing to do with FoV. It's called chief ray angle (CRA), and it comes from a different part of the sensor entirely.

Every pixel on an image sensor sits under a microscopic lens. Near the edges of the sensor, light arrives at increasingly steep angles, so manufacturers physically offset those microlenses during fabrication to compensate, each one tuned for a specific angle. Onsemi builds the AR0144 in a few CRA variants, roughly 0°, 20°, and 28°.

We assumed a wider FoV would mean a higher CRA. That's not the case; the two are unrelated. FoV comes from sensor size and focal length. CRA comes from where the lens's exit pupil sits, the lens's own optical design, and the sensor's microlens geometry. Two lenses can share an identical FoV and behave completely differently on CRA.

Get the CRA wrong and you don't get bad FoV numbers. You get vignetting, color shading, and pixels losing sensitivity toward the edges of the frame. And unlike FoV, you can't estimate CRA from a captured image. The reliable way to find it is to look up the sensor's ordering code, since Onsemi bakes the CRA variant directly into the part number. Sometimes the answer isn't buried in the optics at all. It's just sitting in the documentation nobody read yet.

Rectification changes the field of view again

The last surprise showed up entirely in software. Our vision pipeline runs an OpenCV fisheye calibration model that undistorts the image, converting the curved equidistant projection into something flatter that's easier for computer vision algorithms to work with. That conversion throws away part of the original image, and how much depends on the balance setting, output resolution, and aspect ratio you choose.

So even after accounting for the lens, the sensor, the crop, and the CRA, the field of view can shrink one more time, and this last cut has nothing to do with optics at all. It's purely a side effect of how the rectification step is configured.

Tracing the complete optical pipeline

Stepping back, the camera's effective field of view changed at several points before it ever reached our application:

• 178° — lens datasheet
• ≈144° — sensor active area
• ≈140° — 1280×720 crop
• CRA compatibility — image quality risk, not a FoV number
• Rectification — final vision pipeline

Every one of those stages had a real physical or software explanation. None of them was wrong. Each one just described a different link in the same chain.

How this shows up at Hoomanely

At Hoomanely, this is why we validate every layer of a sensing pipeline instead of trusting individual component specs on their own. Performance comes from how optics, electronics, firmware, and software interact, not from any one of them in isolation. Tracing this camera system end to end showed us how much a small configuration choice, like a crop setting or a rectification parameter, can shift what the system actually perceives. That's the kind of thing we now check for by default.

Key takeaways

• A lens's advertised FoV only holds for the sensor format it was measured against.
• Fisheye lenses need projection-specific math (r = f·θ), not standard rectilinear equations.
• Back focal distance describes lens geometry, not necessarily where an adjustable M12 assembly actually ends up focused.
• Sensor output resolution changes effective FoV, especially when rows or columns get cropped.
• Chief ray angle is independent of FoV and has to be checked separately, through the sensor's part number.
• Rectification can shrink usable FoV again, purely as a software effect.
• The only reliable way to evaluate a camera system is to trace the whole pipeline, from incoming light to the final processed frame.

Conclusion

The real answer is that FoV isn't set by any single component. It's the product of optical projection, sensor dimensions, output configuration, sensor architecture, and image processing, each one capable of changing the final number on its own.

If you're integrating machine vision hardware, the datasheet tells you about the parts. It doesn't tell you about the system you build out of them. That gap is exactly what turns a pile of compatible components into a camera that actually behaves the way you expect.