Factory calibrated intrinsic parameters vs ROS camera defaults

Your 3D camera boots under its vendor ROS driver, you echo the camera_info topic, and the question arrives: are these factory calibrated intrinsic parameters read from the camera, or placeholders that a default publisher filled in? And for a full calibration model you need the pixel pitch in micrometers, which the camera documentation does not print. This guide gives you the decision rule, a ten-second test on the message fields, and three routes to pixel size with the arithmetic shown. It ends with the cases where you should recalibrate and the larger set where you should leave the factory numbers alone.

Where the values in camera_info come from

A depth camera cannot turn raw sensor pixels into a metric point cloud without a per-unit geometric model. Structured-light, ToF and active-stereo 3D sensors are therefore measured into a fixture at the factory, and the model is stored inside the camera. The vendor ROS driver reads that model out at start-up: it fills the standard camera_info message with it and stamps the message onto every frame it publishes.

ROS itself has defaults only for publishers that have nothing better to publish — an identity matrix for the intrinsic part, zeros for distortion. A maker driver for a calibrated camera does not use them, so the values you echo from camera_info were measured for your serial number. Use them as delivered. The field-by-field detail sits in Depth camera intrinsics and distortion parameters: read, don't guess, and where fx and fy live in a ToF calibration model covers the ToF variant.

If camera_info never arrives, or no camera appears in the driver device list, the fault is enumeration rather than calibration. That failure has its own fix, set out in why no cameras are found in ROS.

The ten-second test: measurements or placeholders

Echo the message once and read fx, fy, cx, cy and D. The signatures split cleanly:

One cross-check closes the case. Focal length in pixels is focal length in millimeters divided by pixel pitch in millimeters:

A fx within a few percent of that quotient confirms a measured model. A fx of 0 or 1 convicts the message as a placeholder.

Which cameras ship factory intrinsics and which leave calibration to you

Depth cameras of the structured-light, ToF and active-stereo kinds keep their factory values for life: the model is measured per unit and the driver only reads it. The MV-DPS200P-02 is a projected structured-light 3D camera and the MV-DT01WMU is a ToF sensing camera — both sit in this keep-the-factory-values class.

An area scan camera is the opposite case. The sensor module carries per-unit correction data in the maker own format, but the pinhole set ROS wants — fx, fy, cx, cy and D — does not exist until you create it with the standard camera_calibration package and a printed target. Until then your camera publisher carries whatever defaults it ships with, which is why reprojecting depth from an uncalibrated frame puts every corner in the wrong place.

The MV-CS200-10UM is a 20 MP mono USB3 camera on a 1" sensor, and the MV-CU020-90GC is a 2.5 MP GigE color camera with a global shutter — both calibrate with the same printed checkerboard and the same package.

Pixel pitch: where it actually hides

camera_info almost never carries pixel size. Four routes, in order of trust:

1. The sensor data sheet. Look for pixel pitch or pixel size in µm in the characteristics table; some sheets print unit cell instead, which is the same number. Color and monochrome versions of a sensor share the pitch.
2. Active width divided by horizontal pixels. If the data sheet gives sensor width and the camera gives resolution, pitch = width ÷ pixels across. The worked example below runs this route, and how to find a depth camera pixel pitch without a data sheet covers the retrieval paths for depth cameras specifically.
3. The optical-format bound. The inch notation is a diagonal convention: one format inch equals 16 mm. A sensor listed as 4000 × 3000 on a 1/1.7" format has a diagonal near 9.4 mm (16 ÷ 1.7) and √(4000² + 3000²) = 5,000 pixels across it, so the pitch cannot exceed 9.4 mm ÷ 5,000 ≈ 1.9 µm even if the active area filled the format. Real active areas leave margin, so expect the true pitch up to about 15% below that bound — tight enough to reject a wrong number, not to feed a calibration.
4. Focal length divided by fx. If the lens focal length is documented and camera_info fx is measured, p = f / fx gives the pitch directly.

Worked example: pitch for a 1024 × 1024 sensor with 169 µm² pixels

Inputs: a data sheet that lists only two lines — 1,024 × 1,024 active pixels and a 169 µm² pixel area, the worked sensor from a standard optics reference on pixel size and resolution. No pitch, no width, nothing else.

Rule in words: the pitch is the square root of the pixel area; the active width is the pitch times the pixels across; and dividing the width back by the pixels must return the same pitch.

The round trip closes, so the pitch is 13 µm and the active width is 13.3 mm.

Now use it to judge camera_info. Suppose this sensor sits behind a 25 mm lens:

fx = 25 mm ÷ 0.013 mm = 1,923 pixels

A camera_info fx of roughly 1,900 to 1,950 is consistent with measured values; fx = 1 or fx = 0 convicts the message as a placeholder.

Decision: the pitch is 13 µm, keep the factory camera_info as delivered, and re-run the same three lines whenever you bin or crop, because both pitch and pixel count change.

When to recalibrate and when to keep the factory numbers

Keep the factory values when nothing in the optical path or the camera body has changed. The factory measured your unit against fixtures with better metrology than a hand-held checkerboard, so a from-scratch recalibration of a depth camera usually adds error rather than removing it. Exposure, gain, frame rate and trigger mode do not enter the intrinsic model — changing them requires nothing.

Recalibrate when:

• you add a filter or protective window in front of the optics;
• you swap a lens or change its focus or iris on a model with adjustable optics;
• the camera took a drop or impact — a shifted sensor moves cx and cy by whole pixels.

Scale, don't recalibrate, when the resolution changes: 2 × 2 binning doubles the effective pitch and halves fx, fy, cx and cy — camera intrinsics after binning: scale them correctly gives the exact factors. A mixed-resolution stereo pair is the same story on both sides; stereo calibration resolution mismatch: rescale or recalibrate? works the comparison.

If you do recalibrate — area scan cameras especially — validate and publish the result properly: ROS 2 camera calibration: validate and publish camera_info walks the load-and-verify path. Adopt your numbers only if they land within a pixel or two of the factory set.

One distinction saves hours: re-aiming or re-mounting the camera changes extrinsics, not intrinsics — the intrinsic matrix does not know where the camera points. For mounting geometry and standoff, the 3D camera working distance and positioning guide covers the placement side.

Checks before you trust either set

Factory or self-made, the same two measurements settle it:

1. Point-throwing. Take a target corner whose position you know in the camera frame — a flat plate at a measured distance works. Project it with fx, fy, cx and cy. A measured model lands within 2 to 3 pixels; the pixel footprint at that distance is Z / fx, so at 1,000 mm working distance with fx = 1,000 pixels, one pixel is 1 mm.
2. Length error. Reproject the depth cloud over a 100.0 mm gauge step and measure it in the cloud. Within ±0.5% — 99.5 to 100.5 mm — is guidance-grade, and factory-calibrated depth cameras typically meet it out of the box.

A third check applies when a depth camera rides alongside a texture camera: project the depth onto the color frame using each camera own model and look at edges. Alignment within about a pixel says both models are real; the mechanics are in camera intrinsic parameter conversion for depth and texture images. For a camera bolted to a robot arm, extend the same logic to the hand-eye transform — hand-eye calibration accuracy verification: test before you trust it gives the acceptance tests, and camera intrinsics for hand-eye calibration: fix the pose first explains why a bad pose poisons the result.

Decisions, in order

1. Vendor driver on a depth camera: use camera_info as delivered.
2. Zeros and ones in the message: fix the publisher or the device enumeration, not the math.
3. Pitch needed: sensor data sheet first, width ÷ pixels second, the 16 mm per format inch bound to sanity-check.
4. Area scan camera: calibrate once with the camera_calibration package, validate, publish, keep the baseline file.
5. Optics changed or shock suspected: recalibrate and adopt only on agreement with the factory set. Resolution changed: scale, don't recalibrate.

To pick the hardware, the camera finder filters by resolution, shutter and interface, and the configurator builds the camera, lens and light set around your working distance:

More on this family of topics sits on the 3D vision topic page, and for a quote-level integration question, reach us through the contact page.