Skip to content

Recording and trigger mode improvements #83

Description

@C-Achard

Context

Several improvements could still be made to the GUI, notably regarding performance and task distribution.
Recent changes (e.g. #82) significantly improved recording performance for monochrome Basler cameras by avoiding unnecessary Mono8 → BGR8 casting. However, for high-throughput multi-camera setups recording can still lose frames, especially with multiple cameras at high FPS/resolution.

  • Making the current data processing pipeline less sequential

Currently it consists of:

camera backend read
→ SingleCameraWorker signal
→ MultiCameraController full-rate slot
→ MultiFrameData construction
→ GUI full-rate frame handler
→ RecordingManager
→ VideoRecorder queue
→ writer thread / WriteGear

The main goals there would be to have:

  • Separate acquisition from downstream processing as much as possible
  • Ensure recording, display, and DLC have independent queue& drop behavior
  • Ensure the camera grabbing path does minimal work, e.g.:
    • Retrieve frame
    • Timestamp
    • Minimal metadata
    • Enqueue/dispatch quickly

  • Ensuring triggered cams are started/stopped properly in regards to recording
    • Start: all followers → master → recording
    • Stop: master → followers stop → finish queues → stop recording

Metadata

Metadata

Assignees

Labels

cameraRelated to cameras and camera backendsconfigRelated to user configs, oading, saving, etcenhancementNew feature or request

Type

No fields configured for Task.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions