3.9 KiB
RGB camera profiles
A profile is a settings XML exported from the VimbaX Viewer. A profile named
X is X.xml in the profile directory, and [Camera.rgb] profile = X in
config.ini selects it. On a tower that directory is
~/.config/fire_gimbal_control/camera_profiles/rgb/ ([Camera.rgb] profile_dir,
relative to config.ini), not this one: this README is all that lives here.
The program hands the XML straight to the Vimba X SDK (LoadSettings). Nothing
else writes camera settings, and there is no fallback — a missing X.xml is a
startup error. That is deliberate: GenICam validity is stateful
(AcquisitionFrameRate is only writable once AcquisitionFrameRateEnable is
set, Width's maximum depends on binning, IntensityAutoPrecedence takes
Minimizenoise but not MinimizeNoise), so a hand-written list can be
individually plausible and collectively wrong. The Viewer greys out invalid
combinations as you configure; that is the guardrail this design relies on.
These files live on the device only
The XMLs are exported on the LattePanda, because that is where the camera is, so
they exist nowhere in the repo. They live in the tower's own folder,
~/.config/fire_gimbal_control/, which a deploy never reaches. A tower set up
before that folder existed still has them in this directory; deploy.sh
excludes *.xml and *.txt here from its rsync --delete until
scripts/tower-config move has moved them. This README does sync; it is repo
documentation.
Keep a copy somewhere durable if a profile represents real tuning effort: a reflash or a rebuilt device starts with an empty directory.
To create or change a profile
- Open the VimbaX Viewer and connect to the camera.
- Configure it. The Viewer will not let you pick an invalid combination.
- Save the settings XML over
<profile>.xmlin the profile directory. - Restart. The program notices the file changed, regenerates
<profile>.txt, and logs every setting that moved.
The .txt files
Beside each X.xml the program writes X.txt: a generated, human-readable
record of the same settings, so a profile can be read and diffed without opening
the Viewer. It configures nothing. Editing it changes nothing; it is
overwritten whenever the XML changes.
Profiles this rig expects
config.ini ships referencing standard and night. Both are raw capture
(docs/raw12-pipeline-measurements.md): full resolution, binning 1, packed 12-bit
Bayer, converted to colour on the tower and saved as 12-bit JPEG XL.
scripts/export_camera_profile.py builds them on the tower; these are its recipe.
| Setting | standard |
night |
|---|---|---|
BinningHorizontal / Vertical |
1 | 1 |
Width / Height |
sensor maximum | sensor maximum |
PixelFormat |
BayerRG12p |
BayerRG12p |
DeviceLinkThroughputLimit |
250000000 | 250000000 |
AcquisitionFrameRate |
camera maximum (9.86 on the 1800 U-1620c) | camera maximum (exposure-limited at night) |
ChunkModeActive + ChunkEnable |
ExposureTime, Gain, BalanceRatioRed/Blue, Timestamp | same |
BalanceWhiteAuto |
Off (fixed ratios) | Off |
ExposureAutoMin / Max |
200 / 20000 µs | 1000 / 500000 µs |
GainAutoMax |
24 | 48 |
IntensityAutoPrecedence |
MinimizeNoise | MinimizeNoise |
IntensityControllerRate |
100 | 100 |
DeviceIndicatorMode / Luminance |
Active / 10 | Inactive / 0 |
The chunk data is what settle_rule = brightness reads (each item has to be
enabled before ChunkModeActive, which then locks them). A profile left on
RGB8 still works: the program saves it as before.
Earlier profiles used 2×2 binning at RGB8. On the 1620c that gave no extra frame rate (the camera budgets the link against the unbinned frame), which is one reason they were replaced. Their values are in git history.
settle_wait_ms / frame_timeout_ms / settle_rule are not camera settings and are not in
the XML — they live in config.ini under [Camera.rgb.<profile>].