Comparison vs Kalibr / Basalt

Where CamCalib sits relative to the toolboxes most people already use. Kalibr is mature and widely validated; CamCalib is not trying to displace it on the single-IMU case it does well.

Feature matrix

Capability	CamCalib	Kalibr	Basalt
Camera intrinsics + distortion	✅	✅	✅
Distortion models	radtan, equidistant, FOV, DS, EUCM, omni_radtan	radtan, equidistant, FOV, DS, EUCM	radtan, KB, DS, EUCM
Mixed models across one rig	✅	✖	✖
Camera–IMU extrinsics + time offset	✅	✅	✅
Multiple IMUs	✅	✖	✖
Per-IMU gyro-only mode	✅	✖	✖
IMU intrinsics (scale, misalignment)	✅ — 3 conventions	✅	✖
G-sensitivity Tg	✅	✅	✖
Gyro↔accel offset t_ga	✅	✖	✖
Rolling-shutter readout	✅	via fork	✖
Corrected-dataset export	✅ apply-calib	✖	✖
Round-trip PASS/FAIL validation	✅ roundtrip	✖	✖
Batch sweep over a dataset family	✅ input.bags	✖	✖
Trajectory model	discrete factor graph	continuous-time B-spline	continuous-time B-spline
Boards	AprilGrid, chessboard, ArUco	AprilGrid, chessboard, circles	AprilGrid
Input	ROS1/ROS2 bag, EuRoC, images, video	ROS bag	ROS bag, EuRoC
Runs without ROS	✅ pure Python	✖	✖
Kalibr camchain interop	✅ read + write	native	✖

What is actually different

No ROS. Pure Python via pip, on Windows, macOS, and Linux. Bags are read with rosbags. For anyone calibrating outside a ROS environment this is the whole story.

More than one IMU. Kalibr and Basalt model a single IMU; a four-IMU rig has to be calibrated pairwise and composed, which accumulates error and throws away the correlations. CamCalib puts every IMU in one graph.

It measures driver artefacts instead of working around them. t_ga quantifies the gyro-vs-accel timing offset a driver’s interpolation introduces — the T265 reads −6.2 ms, stable to ~0.2 ms. Kalibr has no equivalent; the usual alternative is to discard the sensor.

Validation is a command, not a habit. camcalib roundtrip gives a PASS/FAIL that requires IMU intrinsics to collapse and geometry to hold. Nothing comparable ships with the others.

Discrete-time. Kalibr and Basalt fit a B-spline; CamCalib places state nodes at state_hz. The trade-off is in Continuous-time refinement.

Where the others are still ahead

Maturity. Kalibr has a decade of use across the field. CamCalib’s 228-run benchmark is strong evidence, not the same thing as that.

Ecosystem. Kalibr’s target generators, tutorials, and community answers have no CamCalib equivalent yet.

Continuous-time. If your sensors are genuinely asynchronous at high rate, a B-spline handles it natively; CamCalib does not yet offer it.

Agreement with Kalibr

Not a rival claim — a validation. On TUM-VI raw IMU bags, omni_radtan and equidistant reproduce the Kalibr camera–IMU extrinsics to ≤2 mm lever, ≤0.15 mm stereo baseline, ≤1 ms time offset. Camera parameters match the published TUM-VI and Intel T265 calibrations to under 0.6% on focals.

Kalibr output also reads directly (camcalib.io.kalibr), so it is a natural source of initial values — refinement from a Kalibr camchain is a supported workflow, not a migration.

Which to use

• One IMU, one or two cameras, ROS available → Kalibr.
• Multiple IMUs, or a gyro-only auxiliary → CamCalib.
• No ROS on the machine → CamCalib.
• Rolling shutter → CamCalib, or Kalibr’s fork.
• Mixed camera models on one rig → CamCalib.
• You need to prove the calibration is right → CamCalib’s round-trip.

Measured accuracy on shared datasets is on the leaderboard — read Methodology first, especially the consensus-baseline caveat.