# 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

1. Open the VimbaX Viewer and connect to the camera.
2. Configure it. The Viewer will not let you pick an invalid combination.
3. Save the settings XML over `<profile>.xml` in the profile directory.
4. 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>]`.