Real HFOV at different resolutions: crop, scale and getFov

You switch the camera to 720p for bandwidth, call getFov() on the calibration and it returns the same angle it did at full resolution. The live image clearly shows less of the scene, so the number feels wrong. It is not wrong — it answers a different question. getFov() reads the sensor-level calibration, while the crop happens later, inside the ISP. This page gives you the one-line trigonometry for the real horizontal and vertical FOV of any output mode, shows which pipeline stage moves the angle and which does not, and explains how to read the calibrated value instead of the specified one. The same three steps work for any depth or area scan camera whose modes crop or scale the full frame.

Why getFov() ignores your resolution setting

The calibration lives in the device's EEPROM and describes the sensor in its full frame. Intrinsics and FOV are computed for the maximum resolution, because that is what the sensor actually images; the device in the original report returned a specified 108° and a calibrated 79.475° no matter which mode was running. A 720p stream is produced after calibration, when the ISP trims and resizes the frame, so the call has nothing to say about your mode and no built-in call reports its angle. readCalibration() hands you the stored calibration; the pipeline below hands you the rest.

Crop first, scale second: follow the pipeline

Small modes are built by cropping the full frame and then scaling it. The chain for a 720p stream from a 12 MP sensor is documented: crop to 4K, 3840 × 2160, then scale to 1280 × 720. Both frames are 16:9, so the scale is uniform and trims nothing further.

That order decides everything:

• Crop changes the angle. Fewer sensor pixels in play means a narrower cone of rays.
• Scale changes nothing. Resizing keeps the same scene; only the millimetres per pixel change. Decimation and binning behave the same way — see Depth image resolution smaller than expected: check decimation first.

The 720p stream's FOV therefore equals the 4K crop's FOV, and you only ever compute the crop step. Size settings that look ignored on stereo depth output tell the same story — Stereo depth output resolution: why size settings seem ignored works through it.

The FOV formula for a cropped frame

For a centred crop that keeps W_used of the full frame's W_max pixels on one axis:

• HFOV_max comes from the calibration, read with useSpec set to False.
• W_max, H_max are the full-frame pixel dimensions the calibration corresponds to. Read them from the calibration data, not from the mode name.
• W_used, H_used are the pixels the ISP keeps before any scaling.

Two limits worth knowing. W_used = W_max returns the full angle, as it must. Halving W_used does not halve the angle — it halves the tangent of the half-angle, which narrows the view less than you would guess. The formula assumes a rectilinear lens; a fisheye needs its full distortion model, and the atan shortcut underestimates its edge angles.

Worked example: 108° sensor from 12 MP to 720p

Take a 108° camera whose full frame is 4032 × 3024 (12 MP, 4:3 — illustrative dimensions; substitute your calibration's real width). The pipeline crops to 3840 × 2160, then scales to 720p.

Horizontal: 3840 ÷ 4032 = 0.952 and tan(108° ÷ 2) = tan 54° = 1.376, so HFOV = 2 · atan(0.952 × 1.376) = 2 · atan(1.311) = 105.3°.

Vertical: the full-frame angle is 2 · atan((3024 ÷ 4032) × 1.376) = 2 · atan(1.032) = 91.8°. The crop keeps 2160 ÷ 3024 = 0.714 of the height, so VFOV = 2 · atan(0.714 × 1.032) = 2 · atan(0.737) = 72.8°.

The instinct that 720p must crop a lot is wrong horizontally: you lose 2.7° of 108°. The loss is vertical — 19.0° of 91.8° — because 4:3 to 16:9 trims height, not width.

import math

def fov_after_crop(fov_full_deg: float, px_used: int, px_max: int) -> float:
    # FOV in degrees after a centred crop keeps px_used of px_max pixels on one axis
    return math.degrees(2.0 * math.atan((px_used / px_max) * math.tan(math.radians(fov_full_deg / 2.0))))

assert abs(fov_after_crop(108.0, 4032, 4032) - 108.0) < 1e-9      # no crop: identity
print(round(fov_after_crop(108.0, 3840, 4032), 1))                # 105.3
print(round(fov_after_crop(fov_after_crop(108.0, 3024, 4032), 2160, 3024), 1))  # 72.8

Calibrated or specified: which FOV value to use

The EEPROM stores two angles per socket. The specified value is written from sensor and lens data when the device is flashed; the calibrated value is computed from the measured intrinsics. The useSpec flag chooses between them: False returns the calibrated angle, True returns the specified baseline.

They can differ by far more than any mode ever will. On the device in the original report the specified value is 108° and the calibrated one 79.475°. Run the same 0.952 crop on the calibrated number: tan(79.475° ÷ 2) = 0.831, so HFOV = 2 · atan(0.952 × 0.831) = 2 · atan(0.791) = 76.7°, not 105.3°. For coverage geometry, feed your plan the 76.7°.

From angle to coverage: mm per pixel decides the buy

An object of width W_obj just fills the frame when W_obj = 2 · D · tan(HFOV / 2). At D = 1000 mm with the calibrated 76.7° example, the 720p stream sees 2 × 1000 × tan 38.35° = 2000 × 0.791 = 1582 mm across. Divided by 1280 pixels that is 1.2 mm per pixel; a 1 mm defect spans 0.8 px and disappears. The same scene on the 4K crop, 3840 pixels wide, gives 1582 ÷ 3840 = 0.41 mm per pixel, and the defect spans 2.4 px.

The FOV barely moved between the modes; the pixel count did the damage. Check which resolution your target detail actually needs:

If you are sizing a ToF depth camera's coverage before ordering, the same atan check applies at its fixed FOV:

The same steps on an area scan camera

Video modes crop on 2D cameras too. The LS-CMR-0166 outputs 4000 × 3000 over USB3. Draw a centred 2000 × 1000 processing ROI and the horizontal scale factor is 2000 ÷ 4000 = 0.500: with a 60° lens, HFOV = 2 · atan(0.500 × 0.577) = 32.2°, a bit more than half of 60°. Where to place such an ROI, and what it costs on 3D cameras, is covered in 2D vs 3D camera ROI: where to set it and which one wins. The angle also shifts when the sensor behind a lens changes; Same lens on a different sensor: how HFOV changes covers that case.

Checks and decisions

Before you trust a number:

• Read the FOV with useSpec=False, always.
• Take W_max from the calibration's image size. Full frames in the 12 MP class are 4000, 4032 or 4056 pixels wide, and picking the wrong one shifts the result by a degree or two.
• Compare the output aspect ratio with the full frame's. Equal means scale-only after one crop; different means another crop stage — apply the formula twice.
• Assume the crop is centred; measure an off-centre ROI by its own span.
• Bench-check once per device type: stand a ruler at a measured distance D, read the visible width W at the frame edges, compute 2 · atan((W ÷ 2) ÷ D), and expect agreement within about 2°.

Decisions by case:

• Crop-then-scale mode (the 720p case): FOV equals the crop stage's angle — 105.3° horizontal and 72.8° vertical on the specified basis, 76.7° horizontal on the calibrated one. Commit those to the coverage math, not the getFov() output.
• Scale-only or decimated output: FOV unchanged; only mm per pixel moves.
• Aspect mismatch: expect the trim on the short axis — 19.0° vertical lost versus 2.7° horizontal on the example.
• Buying: a part needing better than 1.2 mm per pixel at 1 m cannot ride the 720p stream at this FOV. Take the 4K path, mount closer, or choose a narrower-angle depth camera. For guidance work, a projected structured-light camera is the usual choice once its FOV covers the work area at the mounting height:

Size the rest from the camera finder, browse the 3D sensors and area scan cameras categories, or start the camera configurator. More geometry like this sits on the 3D vision topic page, and the team answers set-up questions through the contact page.