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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

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

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions