Timed thermal image capture without blocking the GUI

A thermal preview can remain responsive while your application saves an image every 30 seconds. The reliable approach is to keep acquisition running, schedule snapshot requests independently, and move file writing away from the GUI thread. A loop that sleeps between saves mixes these responsibilities and makes stopping, error reporting, and timing harder.

This procedure is for applications that already receive thermal frames through a supported acquisition interface. You will define what each scheduled snapshot represents, prevent overlapping work, measure timing error, and preserve measurement data when the camera and software expose it.

Decide what the scheduled snapshot means

Timed capture can mean selecting an existing frame or requesting a new exposure. These are not equivalent. A software timer schedules application work; it does not guarantee when the camera exposes an image.

Choose the required behavior before implementing the timer:

For a slowly changing process, selecting the latest frame is often sufficient. For an event that changes faster than the allowed timing error, investigate exposure triggering instead.

The software-triggered capture workflow explains the distinction between an application request and camera acquisition. Here, the focus is repeated scheduling rather than a button-driven request.

Define an acceptance window explicitly. For example, an application might accept a frame received within the previous 200 ms. That threshold is an application requirement, not a camera specification or proof of scene age.

Confirm acquisition and file-format support

Before adding scheduling, verify that your supported software interface can provide:

• A continuous stream or another documented acquisition method.
• Frame identity, preferably with a camera frame counter or timestamp.
• A way to retain a frame safely after its acquisition callback returns.
• A documented export format for the data you need.
• A supported stop, disconnect, and resource-release sequence.

A thermal-looking image is not necessarily a temperature dataset. Confirm whether the interface exposes a palette preview, sensor counts, calibrated temperatures, or a radiometric image object. These require different saving paths.

Browse infrared cameras and the camera finder to compare available interfaces. Interface compatibility alone does not establish radiometric export support or compatibility with your application runtime.

The LS-IRC-0044 is a catalog option to evaluate against that integration checklist.

The LS-IRC-0016 is another catalog option. Confirm its supported acquisition and export workflow before selecting it for scheduled recording.

Do not assume either option supports a particular software library, file container, or temperature-export method without confirmation.

Separate acquisition, scheduling, saving, and display

Use four responsibilities, even if your framework implements them with fewer physical threads:

• Acquisition: receive frames and publish a stable latest-frame reference.
• Scheduling: calculate deadlines and request eligible snapshots.
• Saving: encode and write selected frames through a bounded queue.
• Display: update the preview and status through the GUI's event mechanism.

The acquisition callback should perform only bounded work. Retain the buffer through the documented ownership mechanism, or copy it into application-owned storage before the camera reuses it. Do not compress images or write files inside that callback.

Publish the frame reference, identity, receipt timestamp, and metadata together. Otherwise, the saver could combine an image from one frame with timing information from another. Use a short synchronization operation rather than holding a lock during encoding.

Keep the latest-frame slot separate from the save queue. Updating the preview should not create a growing archive of unsaved frames.

A practical initial queue limit is one active save and one waiting job. When that capacity is exhausted, reject the next snapshot request and record the reason. Increase capacity only after measuring the workload and deciding how much delayed recording is acceptable.

The streaming callback lifecycle guide covers acquisition lifetime problems that a timer cannot repair.

Implement a start-relative schedule

1. Validate the interval and start a new run. Reject zero, negative, or invalid values. Assign a run identifier so reconnects and frame-counter resets cannot create ambiguous records.

2. Start acquisition without blocking the GUI. Follow the acquisition interface's threading requirements. Some interfaces require operations on a particular owning thread; moving every call to an arbitrary worker is not automatically safe.

3. Wait for a valid first frame asynchronously. Keep the Start control disabled while starting, but leave cancellation available. Do not treat a default image object as evidence that acquisition is ready.

4. Record a monotonic start time. Define the first deadline relative to that start. Use a clock that measures elapsed time without jumping when the wall clock changes.

5. At each deadline, attempt a nonblocking selection. Check the run identifier, frame identity, freshness, and available save capacity. Queue an owned frame reference rather than performing file writing in the timer callback.

6. Calculate the next absolute deadline. If execution is late, skip expired schedule slots instead of firing a burst of callbacks. Publish saved, skipped, failed, and pending counts to the GUI.

Use a start-relative schedule:

The following is framework-neutral pseudocode, not a camera-library API:

start_time = monotonic_now()
next_slot = 1

on_timer_wake():
    if run_is_cancelled:
        return

    now = monotonic_now()
    target = start_time + next_slot * interval

    if now < target:
        arm_timer_for(target)
        return

    due_slot = floor((now - start_time) / interval)
    record_expired_slots(due_slot - next_slot)
    next_slot = due_slot + 1

    try_queue_latest_owned_frame(due_slot)
    arm_timer_for(start_time + next_slot * interval)

Serialize this scheduling operation. If the framework permits concurrent timer callbacks, use a nonblocking entry guard or a single scheduling executor. Protect the start and stop transitions as well as the normal callback path.

Some GUI timers execute callbacks on the GUI thread. Such timers are suitable only when the callback remains short and never waits for acquisition, encoding, disk access, or a worker to finish.

Check freshness and preserve measurement data

At minimum, store the last frame identity selected for saving. If the next deadline finds the same frame, report a stale-frame skip rather than silently duplicating it. Frame identity should include the acquisition run because counters can reset after reconnecting.

For the latest-frame policy, calculate receipt age using the same monotonic clock:

Receipt age detects a stalled host-side stream, but it cannot reveal every buffered old image. A frame can arrive recently after waiting elsewhere in the acquisition pipeline. Where available, use documented camera timestamps and a verified clock relationship to assess exposure age.

For a next-frame policy, create a pending request instead of waiting inside the timer callback. Let acquisition satisfy that request, with a timeout and explicit eligibility rules. Do not accumulate unlimited pending requests when the stream stops.

Keep these fields with each saved record:

• Run identifier, schedule slot, and frame identity.
• Scheduled deadline and actual selection time on the monotonic clock.
• UTC timestamp for the record and camera timestamp when available.
• Pixel representation, dimensions, and relevant calibration metadata.
• Save outcome, destination, and any skipped-slot reason.

Do not subtract a camera timestamp from a host timestamp unless their units, epochs, and synchronization relationship are established. The timestamp-based frame matching guide explains why independent clocks require special handling.

Save measurement data separately from the display palette. A colorized preview can be useful for browsing, but its colors are not a substitute for the original numerical data. Follow the documented radiometric export path where one exists.

Use the high-bit-depth thermal export guide for storage representation and thermal calibration essentials before interpreting raw values as temperatures.

Work through the timing and storage numbers

Assume a requested interval of 30 s and a save operation lasting 0.12 s. These are illustrative application measurements, not product specifications.

A loop that completes its save and then waits adds the save duration to every cycle:

Start-relative deadlines remain at 30 s, 60 s, 90 s, and subsequent multiples. Individual callbacks can still run late, but save duration does not automatically shift every later target.

If a callback wakes at 95 s after missing earlier deadlines, the illustrated scheduler services the 90 s slot and schedules 120 s next. It records unserved earlier slots rather than pretending to reconstruct historical images.

Estimate writer demand as well:

This average leaves substantial headroom, but occasional long writes still require a queue policy. If average saving takes 38 s, utilization becomes 38 / 30 ≈ 1.27. A single writer cannot sustain that schedule indefinitely, regardless of queue size.

For storage planning, suppose each complete saved record occupies 1 MiB. At a 30 s interval:

Measure actual record sizes, including metadata and preview files, before setting retention limits.

Verify timing, responsiveness, and saved files

Test with a shorter interval first, then repeat under the intended workload. A faster test exposes race conditions, but it does not replace a longer run that reveals storage growth or resource leaks.

Use these acceptance checks:

• Schedule: log deadline, callback time, and selection time. Report maximum and percentile lateness rather than only an average.
• Freshness: interrupt the stream and confirm the application marks stale frames instead of recording duplicates.
• Responsiveness: move the window and operate Stop while a save is active. The GUI should continue processing input.
• Backpressure: deliberately slow the writer. Queue depth must remain bounded and rejected requests must be counted.
• File integrity: reopen saved records and verify dimensions, representation, metadata, and numerical values where applicable.
• Failure handling: test an unavailable destination and insufficient storage. A failed write must not appear as a successful snapshot.

Use unique filenames containing a run identifier and schedule slot. Write to a temporary destination and finalize the record only after successful completion, using an atomic rename where the filesystem supports it.

Distinguish a selected snapshot from a completed save in the status display. A queued frame can still fail during encoding or writing.

Cancel cleanly and handle common failures

Stopping requires coordination, not just changing a flag. First prevent new scheduling work and invalidate the active run token. Then stop the timer and remove frame subscriptions through the documented interface.

Callbacks already in progress may still complete after subscription removal. Track active work and prevent late callbacks from accessing disposed resources or updating a newly started run.

Decide whether Stop drains pending saves or discards jobs that have not started. Let an active file write finish safely when immediate cancellation would leave a corrupt record. Wait for worker completion asynchronously so the GUI remains responsive.

Stop acquisition and release resources on the required owning thread, after outstanding frame ownership has been resolved.

After reconnecting, establish a new run and wait for a fresh valid frame. Do not reuse the previous stream's timing assumptions automatically.

Check the integration before ordering

A periodic recorder needs more than an image connection. Confirm these items before choosing hardware or committing to a software architecture:

• The supported interface exposes the required image or measurement representation.
• Frame ownership and timestamp behavior are documented.
• The application can maintain acquisition while saving independently.
• Trigger support matches any exposure-timing requirement.
• The destination sustains the measured write workload.
• Queue overflow, disconnection, cancellation, and restart behavior are defined.

Start with the camera configuration step when the acquisition interface is still undecided. For an existing recorder, send your interval, acceptable timing error, required file contents, and measured save duration through application support so the hardware discussion follows the actual recording requirements.