Thermal & Dual-Spectrum Core: LWIR ROIC, ISP, Calibration
← Back to: Security & Surveillance
A Thermal & Dual-Spectrum Core is only “good” when its calibration is trustworthy (versioned, CRC-checked, field-updatable) and its output remains stable after warm-up and FFC. Most failures can be isolated quickly by logging a small evidence set—profile version/slot/CRC, FFC counters, key temperature nodes, and fusion px/ms metrics—then applying the right rollback or re-calibration step.
H2-1. Definition & System Boundary (Thermal / Dual-Spectrum Core)
Answer block (for Google + engineers)
Thermal & dual-spectrum core is the module boundary that starts at an LWIR sensor readout (ROIC/TIA + ADC), passes through thermal ISP (NUC/FFC, bad-pixel repair, radiometry options), optionally aligns and overlays a visible stream, and exposes control/telemetry via Ethernet and serial links. It is defined by calibration integrity, registration accuracy, and testable drift/noise behavior—not by camera mechanics or video platforms.
Thermal core vs full camera: what this page owns
This page is intentionally narrow: it owns the thermal sensing + processing + calibration + I/O boundary. Everything outside this boundary is referenced only by name (no deep design discussion) to prevent scope creep and content overlap.
| In scope (owned) | Out of scope (explicitly excluded) | Why excluded |
|---|---|---|
|
LWIR ROIC/TIA readout, integration/bias, ADC headroom ISP NUC/FFC, bad-pixel maps, nonlinearity handling Cal radiometry/temperature calibration data + integrity (CRC/versioning) Fusion registration/parallax handling and overlay outputs I/O Ethernet stream options + UART/RS-485 command/telemetry |
PTZ mechanics, zoom/focus drive PoE switch/PSE design, video infrastructure NVR/VMS platforms, recording/retention policy Cloud/app/OS tuning tutorials |
Those blocks belong to sibling pages (camera mechanics, PoE infrastructure, recording platforms, platform software). Mixing them removes the ability to validate root causes with evidence inside this core module. |
Dual-spectrum forms (only the engineering impact)
Dual-spectrum implementations vary, but the core engineering impact is always the same: registration, parallax vs distance, and calibration dataset complexity.
- Coaxial / beamsplitter: improves parallax behavior, but adds optical alignment sensitivity; drift often appears as temperature-dependent overlay bias.
- Side-by-side dual module: simpler optics, but parallax becomes distance-dependent; registration typically needs distance-segmented LUTs or model-based warp.
- Calibration implication: besides thermal NUC/radiometry data, fusion needs extrinsics/warp parameters with version control and field-safe update rules.
Evidence-first: what must be measurable
To keep the content “engineering-grade” (EEAT), every claim in later chapters maps to measurable evidence inside this boundary:
- Image statistics: frame mean/std, row/column FPN indicators, histogram clipping counters, bad-pixel count.
- Thermal state: sensor/shutter/baseplate temperatures, warm-up curve, FFC event count and interval.
- Calibration integrity: calib version, NUC map version, CRC status, commit flag (A/B slot if used).
- I/O robustness: stream continuity (loss/late frames), command ACK/error codes, telemetry timestamp monotonicity (interface-level).
Figure F1 — Thermal Core boundary map
[PAGE-URL]#fig-f1 (replace [PAGE-URL] with the published page URL)H2-2. LWIR Sensor + ROIC/TIA Signal Chain (Noise, Bias, Dynamic Range)
Why this chapter exists
Most “image quality” failures that look like ISP problems are created earlier: bias/integration choices, readout headroom, ADC clipping, and drift mechanisms. This chapter ties each symptom to measurable evidence so the correct knob is adjusted first.
Signal chain (engineering view)
The LWIR core begins as an electrical readout problem: a pixel array produces a small signal that must survive conversion to digital codes with enough headroom and stable offsets.
- Pixel/bolometer → ROIC/TIA: sets the effective gain and converts sensor output to a measurable voltage/current domain.
- Integration & bias: determine how close the readout runs to saturation and how visible low-level noise becomes.
- ADC: quantizes the signal; clipping and code compression often masquerade as “bad NUC”.
- Digital offset/gain: must preserve dynamic range; incorrect offsets reduce usable codes even if the sensor is fine.
Dynamic range & saturation: where “flat tops” come from
When hot regions look “clipped” or contrast collapses, identify the first stage that saturates before changing ISP parameters.
- ROIC integration full-well: highlights flatten at a repeatable scene temperature; changing integration shifts the knee.
- ADC full-scale: histogram shows a pile-up at the high end; reducing analog gain or offset restores spread.
- Digital offset too high: black-level rises; low-end detail vanishes; noise appears stronger because fewer codes remain.
Evidence to collect (minimum): frame histogram clip counters (high/low), integration time, and sensor temperature at the moment of clipping.
Noise and NETD: practical decomposition (what to measure)
NETD is the combined outcome of several noise mechanisms. Instead of treating it as a single number, isolate contributors using repeatable scene conditions.
| Mechanism | Typical symptom | Best evidence (fast) | First fix (lowest risk) |
|---|---|---|---|
| Readout noise | Grain in dark/uniform scenes, worse at short integration | Dark-frame RMS vs integration sweep | Rebalance integration / gain; confirm ADC headroom |
| 1/f noise | Slow “breathing” texture; low-frequency shimmer | Time-series mean/std (low-frequency power) | Stabilize thermal state; avoid marginal bias points |
| Temperature drift | Offset shifts during warm-up; apparent temperature bias changes | Correlation: frame mean ↔ sensor/baseplate temp | Warm-up gating + drift-comp tables (later chapters) |
| FPN / column/row pattern | Fixed stripes or repeating textures | Uniform scene shows stable spatial pattern | Verify bias stability; then NUC/FFC effectiveness |
Key tests (bench SOP): minimal but conclusive
These four tests produce enough evidence to separate analog-chain issues from later ISP/correction issues. Record the same metadata every time for comparability.
- 1) Dark scene (occluded / covered): estimate readout noise floor and detect fixed-pattern structure without scene content.
- 2) Uniform scene (blackbody / uniform plate): reveal FPN (row/column) and gain nonuniformities under controlled input.
- 3) Two-temperature points (T1/T2): confirm linear response region and identify saturation knee vs integration/bias.
- 4) Integration sweep (multiple steps): build noise-vs-integration and clipping-vs-integration curves to choose safe operating margin.
Always log: integration_time, analog_bias, digital_offset, sensor_temp, shutter_temp, frame_mean, frame_std, hist_clip_hi/lo.
Common traps (how misdiagnosis happens)
- Changing NUC/FFC parameters before checking ADC clipping causes “improvements” that fail in other scenes.
- Comparing NETD numbers without matching integration time, temperatures, and uniform-scene conditions leads to false conclusions.
- Not recording temperature points during warm-up makes drift look like random noise.
- Using visual judgement only (no frame statistics/histogram) hides headroom problems until field conditions change.
Figure F2 — Pixel → ROIC/TIA → ADC → Digital offset/gain (with evidence taps)
[PAGE-URL]#fig-f2 (replace [PAGE-URL] with the published page URL)H2-3. Thermal ISP Essentials: NUC / FFC / Bad Pixel / Nonlinearity
Answer block (what “makes thermal look right”)
Thermal ISP correctness is dominated by correction maps and their integrity: bad-pixel/row repair prevents “sparkles” and streaks, NUC gain/offset maps remove fixed-pattern nonuniformity, FFC refreshes offsets against drift, and nonlinearity LUTs preserve response across temperature and integration ranges. Engineering success is proven by uniform-scene statistics, stable correction versions, and predictable FFC behavior under warm-up.
NUC (Non-Uniformity Correction): what it fixes and how to prove it
NUC targets spatial nonuniformity (FPN/stripes) that remains stable under uniform inputs. The correction is typically represented as per-pixel (or per-column/row) gain and offset maps generated from controlled uniform scenes.
Primary evidence
Uniform scene spatial std ↓, stripe energy ↓, row/column bias ↓
Required metadata
nuc_version, map_temp, integration_time, CRC
- Two-point NUC: suitable when the response is approximately linear over the operating range; most sensitive to temperature drift and setup mismatch.
- Multi-point NUC: reduces residual structure across wider thermal states; recommended when warm-up drift or nonlinearity creates temperature-region artifacts.
- Fast sanity check: repeat the same uniform scene at two integration settings—if the pattern “moves” with integration, investigate headroom/clipping before blaming NUC.
FFC (Flat-Field Correction): trigger policy vs video interruption
FFC is a refresh event (often involving a shutter) that updates offset-related correction against drift. The failure mode is rarely “FFC exists or not”; it is usually when it triggers and how much it disturbs streaming.
| Policy element | Typical trigger | Evidence to log | Risk if wrong |
|---|---|---|---|
| Thermal drift threshold | Δ(sensor/shutter temp) exceeds a threshold | sensor_temp, shutter_temp, ffc_interval_s | Too frequent FFC → interruption; too rare → drift artifacts |
| Time-based refresh | Periodic (e.g., minutes) | ffc_count, last_ffc_ts | Good for stability; may be unnecessary after warm-up |
| Scene-aware gating | Stable scene / low motion window | motion_flag (or equivalent), drop_frames | Wrong gating → FFC during critical moments |
| Commanded FFC | External request via control plane | cmd_id, ack, err_code | Unsafe in field if not atomic / not logged |
Minimum acceptance evidence: (1) FFC event count over time, (2) pre/post event frame mean/std delta, (3) explicit “FFC happened” flag to correlate video disruptions with correction updates.
Bad pixel / bad row repair: detection rules + interpolation side effects
Bad-pixel handling must distinguish persistent defects from noise spikes. Over-aggressive detection hides detail and creates “soft halos,” while under-detection produces sparkles and thin streaks.
- Detection strategy: mark candidates that violate neighborhood statistics consistently across frames and operating points (temperature + integration), not from one frame.
- Repair strategy: neighbor interpolation is safest but blurs edges; record the algorithm mode used so QA can reproduce the tradeoff.
- Versioning is mandatory: store badmap_version, threshold summary, test conditions (temp/integration), and bad_count.
Fast evidence: compare edge targets before/after repair; if edge contrast drops while sparkles disappear, the threshold is likely too aggressive.
Nonlinearity: when two-point correction is not enough
Thermal response can deviate from linearity across temperature regions or integration ranges. If residual error shows a consistent bias at low or high temperature points, a nonlinearity LUT (or piecewise correction) is required.
- Trigger evidence: multi-point fit residuals show systematic sign (e.g., always positive at high temps).
- Implementation evidence: nlut_version and the temperature/integration domain the LUT covers.
- Failure pattern: “looks fine” on mid temperatures but deviates on extremes; changing NUC alone cannot fix it.
Evidence checklist (minimal, repeatable)
- Uniform scene: spatial std and stripe indicators before/after NUC (with integration_time recorded).
- FFC behavior: ffc_count, ffc_interval_s, and a pre/post frame statistic delta.
- Bad map: bad_count + badmap_version generated under named conditions.
- Correction integrity: nuc_version/nlut_version + CRC + commit flag.
Lowest-risk fix order: verify clipping/headroom → confirm correct map versions → evaluate NUC residuals → tune FFC policy → adjust bad-pixel thresholds → enable/refresh nonlinearity LUT.
Figure F3 — NUC/FFC pipeline (with evidence taps)
[PAGE-URL]#fig-f3 (replace [PAGE-URL] with the published page URL)H2-4. Radiometry & Temperature Calibration (Blackbody, Emissivity, Drift)
Answer block (radiometry vs “just thermal image”)
Radiometric thermal cores must be calibrated and auditable: the pipeline must map sensor codes to temperature (or radiance proxy) using blackbody-derived coefficients, store them with version/CRC/commit integrity, and control drift via warm-up gating and temperature-indexed compensation. Non-radiometric modes can produce visually meaningful heat maps, but they do not guarantee absolute temperature accuracy across materials, environments, and time.
Radiometric vs non-radiometric: choose the correct promise
These two modes differ in what they claim and what must be validated. Mixing them creates unrealistic expectations and inconsistent QA results.
| Mode | Primary output | What must be stored | What QA must prove |
|---|---|---|---|
| Radiometric | Temperature (or radiance proxy) with accuracy expectations | Calibration coefficients, drift tables, metadata with version/CRC | Blackbody residuals, repeatability, drift vs warm-up, field re-check |
| Non-radiometric | Enhanced thermal image (contrast, palette) | NUC/FFC/bad pixel maps (visual consistency) | Stable visual output and low artifact rate (no temperature guarantee) |
Blackbody calibration SOP (two-point to multi-point)
This workflow is designed to be repeatable and field-auditable. The goal is not only “fit coefficients,” but to capture enough metadata to reproduce the calibration later.
- Step 0 — Stabilize: wait for warm-up stability (use sensor/baseplate temperature and time). Avoid calibrating during rapid drift.
- Step 1 — Set blackbody T1: capture N frames, record ambient_temp, sensor_temp, shutter_temp, integration_time.
- Step 2 — Set blackbody T2…Tn: repeat at multiple temperatures if wide-range accuracy is required; keep capture timing consistent.
- Step 3 — Fit + residual check: compute coefficients and verify residuals across points; systematic residuals indicate nonlinearity or unstable conditions.
- Step 4 — Write to NVM atomically: store as a versioned record with CRC and a commit flag; never “half overwrite” in the field.
- Step 5 — Verify: re-measure one or more points after write to confirm no schema mismatch and no drift during the write window.
Emissivity, reflection, and atmosphere: only the directional effects
Absolute temperature error is often dominated by the target and environment, not the sensor. The key is to understand which factors push error in predictable directions and how to validate quickly.
- Emissivity: low-emissivity (shiny) surfaces are more influenced by reflected background; readings become sensitive to scene changes and may appear lower or unstable.
- Reflection: hot/cold background reflections contaminate the apparent temperature; the same object can read differently with different surroundings.
- Atmosphere path: longer distance and humidity increase attenuation and background coupling; error increases with range.
Fast field sanity method: place a high-emissivity reference patch (tape/paint) on the target and compare the reading difference to isolate emissivity/reflection impact.
Drift model: warm-up and temperature-indexed coefficients
Drift is managed by modeling the thermal state and selecting the correct compensation set. Treat drift as a controlled variable, not as random noise.
- Primary drivers: sensor/ROIC temperature, shutter temperature, baseplate temperature, and time since power-on.
- Typical control: warm-up gating + temperature-indexed coefficient tables (select coefficients by temperature region).
- Evidence requirement: correlation curves of output bias vs temperature points, plus clear logs showing which coefficient version is active.
Minimum logs: uptime_s, sensor_temp, baseplate_temp, calib_version, crc_ok, warmup_state.
Error budget checklist (engineering view)
This checklist keeps discussions concrete and prevents “mystery accuracy” claims.
| Error source | Directional impact | Evidence to capture | First mitigation |
|---|---|---|---|
| Unstable warm-up state | Bias changes over time | uptime vs temp vs output bias | Warm-up gating + stable capture for calibration |
| Nonlinearity not modeled | Systematic error at extremes | Multi-point residuals show consistent sign | Add LUT / piecewise compensation |
| Emissivity/reflection effects | Scene-dependent bias | Reference patch comparison | Use reference patch or known emissivity targets |
| Coefficient mismatch (schema/version) | Sudden wrong readings after update | calib_version, CRC, post-write verify | Atomic A/B write + post-write verification |
| Atmospheric path variation | Error increases with distance | Range-tagged tests (near/far) | Define operating range; apply compensation if available |
Figure F4 — Blackbody calibration workflow (fit → commit → field verify)
[PAGE-URL]#fig-f4 (replace [PAGE-URL] with the published page URL)H2-5. Dual-Spectrum Fusion: Registration, Parallax, Overlay Latency
Answer block (fusion is spatial + temporal consistency)
Dual-spectrum fusion is not “overlaying two pictures”. It is a measurable alignment problem across space (registration, parallax vs distance) and time (timestamps, frame-rate mismatch, pipeline offsets). A robust fusion core keeps calibration profiles versioned, selects range bins consistently, and proves correctness with residual statistics and latency logs rather than subjective screenshots.
Registration errors: three classes and how they show up
Registration must be treated as a model with identifiable error sources. Classifying the failure correctly prevents endless “tuning” without evidence.
| Error class | Typical symptom | Best evidence to capture | First corrective action |
|---|---|---|---|
| Intrinsics drift (lens / distortion / focus state) | Center looks OK, edges misalign; distortion-like mismatch | Residual vs image radius; compare across thermal states | Use temperature-indexed intrinsics or lock focus state for calibration |
| Extrinsics assembly offset (mounting angle/translation) | Global shift/rotation that is stable over time | Residual vector field is consistent in direction | Recompute extrinsics once; store as a stable baseline profile |
| Thermo-mechanical drift (structure expansion) | Alignment worsens during warm-up or ambient changes | Residual correlates with temps (baseplate_temp, sensor_temp) | Segment profiles by temperature bands; add warm-up gating |
Minimum required metadata: fusion_profile_version, CRC, active_range_bin, temperature telemetry, and a per-region residual summary (center + edges).
Parallax vs working distance: why near-field is harder
Dual-sensor geometry creates parallax. The closer the target, the larger the apparent displacement between thermal and visible views, even if calibration is perfect.
- Engineering implication: near-field overlay needs either a range-aware warp (profiles per distance band) or a clearly specified minimum working distance boundary.
- Range-bin LUT approach: define distance bands (e.g., 0.5–1m, 1–3m, 3–10m) and store a distinct transform per band.
- Evidence: for each band, log residual_px distribution and ensure the correct band is selected deterministically (active_range_bin).
Acceptance metric
residual_px per distance band (center + edge)
Profile integrity
range_profile_version + CRC + commit flag
Overlay latency & frame sync: control what the user feels
Even perfect spatial registration will look wrong if time alignment is inconsistent. Dual-spectrum systems must handle frame-rate mismatch (thermal vs visible), pipeline buffering, and timestamp mapping.
- Frame-rate mismatch: decide a master timeline (thermal or visible). Use resampling rules (drop/duplicate) that are logged and bounded.
- Pipeline offset: measure a stable pipeline_offset_ms between streams and apply compensation; avoid “floating” offsets without evidence.
- Latency budget: define a target overlay_latency_ms window and prove compliance with timestamps rather than visual inspection.
Minimum logs: ts_thermal, ts_visible, pipeline_offset_ms, drop_count, dup_count.
Field verification: lowest toolset that still proves correctness
- Static board test: measure residuals in center + corners; store a single-page report per profile version.
- Dynamic target test: move a warm object across the scene; observe and quantify “drag” using timestamp deltas.
- Thermal-state sweep: cold start → stable; log residual and offset vs temperature to detect thermo-mechanical drift.
Deliverables: a versioned profile set (by range/temp), plus a repeatable verification script that outputs residual and latency summaries.
Figure F5 — Fusion alignment model (space + time + range bins)
[PAGE-URL]#fig-f5 (replace [PAGE-URL] with the published page URL)H2-6. Interfaces & Output: Ethernet + Serial Control Plane
Answer block (interfaces are contracts, not just protocol names)
Interfaces must be defined as contracts across three planes: the Data plane delivers video/thermal/overlay streams with timestamps and loss counters, the Control plane changes states (palette/ROI) and triggers events (FFC/map switch) with atomicity and acknowledgements, and the Diagnostics plane exports a minimal snapshot (temps, counters, active versions, CRC) to reproduce field issues without platform-level dependencies.
Data plane (Ethernet): common options and engineering tradeoffs
This section lists interface options without tying to any recorder platform. The goal is to define what leaves the device and how to prove it is healthy.
| Option | Strength | Risk / gotcha | Must-have evidence |
|---|---|---|---|
| RTSP/RTP | Interoperable, widely supported | Buffering affects latency; keep timestamps consistent | timestamp_mode, loss_count, latency_ms |
| UDP (custom payload) | Low overhead, low latency potential | Loss handling becomes product responsibility | seq_id, drop_count, jitter_ms |
| Raw / proprietary | Precise control for analytics endpoints | Integration cost; schema drift risk | schema_ver, CRC, compat_flag |
Minimum stream descriptors: stream type (thermal/visible/overlay), fps, resolution, timestamp mode, and per-stream counters (tx_err, loss_count).
Control plane (UART / RS-485 / Ethernet API): atomicity and idempotence
Control interfaces must separate “safe state changes” from “calibration-impacting events.” The system remains debuggable only if commands are acknowledged and state changes are reproducible.
- State settings (idempotent): palette, overlay alpha, ROI, measurement spot/box. Repeating the same command should not change behavior beyond the intended state.
- Event triggers (atomic): trigger FFC, switch NUC/profile versions, commit calibration sets. Never allow partial updates that can brick the image pipeline.
- Required response fields: cmd_id, ack, err_code, and the resulting active_version.
Control parameters commonly exposed: FFC trigger policy, NUC/profile selection, palette/AGC mode, overlay enable/alpha, radiometry enable, measurement regions.
GPIO timing hooks: trigger/shutter/status as evidence channels
GPIO is not only “I/O”; it is a timing and observability tool. A clear GPIO contract makes field debugging possible with minimal equipment.
- Trigger input: external sync marks or capture gates; record the event timestamp (gpio_event_ts).
- Shutter/FFC status output: assert when FFC is in progress; correlate stream artifacts with real events (ffc_in_progress).
- Heartbeat/status: optional health pin for quick diagnosis during integration.
Diagnostics plane: minimal snapshot to reproduce issues
Diagnostics must provide enough information to determine whether the problem is stream transport, control misuse, or calibration state mismatch—without any platform dependency.
Counters
ffc_count • shutter_count • bad_count • drop_frames
Integrity
active_profile_version • CRC_OK • commit flag
Thermal state
sensor_temp • shutter_temp • baseplate_temp
Errors
err_code class: interface / storage / calib / thermal-state
Rule: any calibration-affecting command must be traceable to a resulting version number and CRC status in this snapshot.
Figure F6 — Data plane vs Control plane vs Diagnostics (with GPIO hooks)
[PAGE-URL]#fig-f6 (replace [PAGE-URL] with the published page URL)H2-7. Calibration Storage & Integrity: NVM Layout, Versioning, CRC
Answer block (calibration is a versioned asset set with atomic commit)
Calibration storage must be an engineering deliverable: a versioned set of assets (NUC maps, bad pixels, LUTs, radiometry coeffs, extrinsics) stored in a defined NVM layout with atomic writes, CRC-backed integrity, and a rollback-safe selection rule. A field update is valid only when the payload passes CRC and a final commit flag is written—otherwise the system must keep the last known-good slot.
Calibration asset types (what must be versioned independently)
Thermal cores often fail in the field because different assets are updated at different times and end up inconsistent. Treat each asset as a named object in a directory table.
| Asset type | Purpose | Update pattern | Must-have metadata |
|---|---|---|---|
| NUC maps (gain/offset) | Correct non-uniformity; stabilize FPN across temperature | Low frequency; may be per temp band | temp_band • asset_ver • crc32 |
| Bad pixel/line table | Mask and repair defective pixels | Occasional growth over life | count • schema_ver • crc32 |
| Nonlinearity LUT | Correct response vs integration/time/level | Rare; tightly coupled to sensor model | model_id • asset_ver • crc32 |
| Radiometry coeffs | Enable temperature measurement outputs | Rare; highest integrity requirement | profile_ver • created_ts • crc32 |
| Extrinsics (assembly) | Dual-spectrum alignment baseline | Stable; changes imply re-assembly or service | mount_id • asset_ver • crc32 |
Rule: any radiometry-capable mode should expose the currently active calibration profile version and a CRC status in a diagnostics snapshot.
NVM layout: header + directory + payload (avoid mixed-version failures)
A robust layout prevents partial or mixed updates. The directory is the contract that binds assets to a single consistent profile.
- Header (fixed fields): magic, schema_ver, profile_ver, asset_count, payload_len, created_ts, seq, CRCs, commit_flag.
- Directory (asset table): (asset_id, type, offset, length, per-asset CRC, optional temp band).
- Payload: packed assets, aligned for efficient reads; keep high-value assets (radiometry) easy to validate early.
Profile identity
profile_ver + seq + created_ts
Integrity gates
crc_header_ok + crc_payload_ok + commit_flag
Atomic write: A/B slots and the “commit last” rule
Field updates should never touch the last known-good data until the new payload is fully written and verified. A/B slot patterns are simple and effective.
- Write to inactive slot: build header + directory + payload, compute CRCs.
- Verify: read-back or streaming CRC check on the written region.
- Commit last: write commit_flag as the final step (single-word write if possible).
- Select on boot: choose the slot where commit_flag=1 and CRC passes, preferring the highest seq.
Selection rule example: choose slot with (commit=1 AND crc_payload_ok=1 AND seq is max).
Integrity layers (CRC + optional signature + calibration-only rollback)
Integrity should match the failure model. CRC covers random corruption; optional signatures protect against unauthorized modification of calibration assets. Rollback protection applies only to calibration profiles, not the full firmware chain.
- CRC32 (required): per-slot payload CRC, plus optional per-asset CRC to isolate which asset is corrupted.
- Signature (optional): sign the header+directory hash so unauthorized changes are rejected before activation.
- Calibration rollback counter (optional): monotonic counter stored with the profile to prevent activating older profiles when policy requires it.
Fail-safe behavior: if active slot fails CRC, automatically fall back to the last known-good slot and set an explicit error code.
Field update policy: power-good gating, wear control, and safe windows
NVM life is typically lost through uncontrolled writes. Updates should be rare, gated, and auditable.
- Write conditions: only allow updates when power is stable (power_good true), temperature is within a safe band, and the device is not in a critical streaming state.
- Power-loss safety: ensure the commit flag is written last; if power fails mid-write, the new slot remains uncommitted and is ignored.
- Wear control: avoid writing large assets frequently; prefer batching updates and logging write_fail_count, optional erase_count/wear_level.
Operational rule: runtime corrections (like frequent FFC triggers) should not automatically cause frequent NVM writes unless explicitly designed.
Figure F7 — NVM partition map (Slot A/B, header, payload, CRC, commit)
[PAGE-URL]#fig-f7 (replace [PAGE-URL] with the published page URL)H2-8. Power, Thermal Stabilization & Warm-Up Behavior (Core-level)
Answer block (warm-up is a gated state machine tied to calibration validity)
Warm-up is not “wait a while”. A thermal core must define a stability gate across key temperature nodes (sensor/ROIC, shutter, baseplate) and switch compensation coefficients deterministically. Radiometric outputs should be enabled only when temperature drift (dT/dt) and post-FFC settle time meet thresholds; otherwise the system should run in a non-radiometric mode and expose the current gating state via diagnostics.
Key temperature nodes: what each one explains
These nodes are the minimum set required to explain drift and to select the right compensation set. They also provide evidence when field complaints are vague (“measurement is unstable”).
- sensor_temp (ROIC/sensor): strongly correlated with offset, noise behavior, and nonlinearity. Required for temp-band selection.
- shutter_temp: affects FFC reference and shutter-induced artifacts; useful to confirm whether shutter behavior matches policy.
- baseplate_temp: tracks mechanical structure and ambient coupling; helps diagnose thermo-mechanical drift that impacts fusion and radiometry.
Diagnostics minimum: expose all three values with a timestamp in a single snapshot.
Warm-up gating: define “when radiometry is allowed”
Make warm-up explicit as a state machine. This prevents hidden behavior that users interpret as random drift.
| State | Condition (examples) | Allowed output | Must-log fields |
|---|---|---|---|
| S0 Boot/Transient | Temps changing fast; pipeline not settled | Streaming allowed, but radiometry disabled | radiometric_state, dTdt |
| S1 Approaching stability | dT/dt below threshold for a window | Non-radiometric OK; limit measurement claims | active_temp_band, coeff_set_id |
| S2 Radiometric enabled | Stable temps + post-FFC settle time met | Radiometric measurements allowed | ffc_recent, settle_ms |
| S3 Thermal event | Ambient step or self-heating spike | Degrade to S1 or retrigger correction policy | event_id, policy_action |
Engineering rule: any state change should be observable via radiometric_state and a monotonic timestamp to support field root-cause analysis.
Thermal feedback into ISP: deterministic coefficient selection
Temperature should influence correction in a predictable, logged manner. Avoid “continuous hidden tweaking” that cannot be reproduced.
- Temp-band selection: map sensor_temp to active_temp_band and choose a discrete coeff_set_id.
- NUC/radiometry coupling: apply NUC maps and radiometry coefficients from the same profile version to avoid mixed-version behavior.
- FFC as a controlled event: record ffc_count and ffc_recent; enforce a settle window before enabling radiometry.
Active selection
active_temp_band • coeff_set_id
Consistency
profile_ver + CRC_OK (shared by NUC + radiometry)
Core-level validation plan (no full PSU discussion)
- Cold start to stable: log temps + dT/dt + radiometric_state transitions; confirm radiometry enables only after stability conditions.
- Ambient step test: introduce a temperature change and verify deterministic downgrade/recovery behavior.
- Post-FFC settle: verify that a fixed settle window is enforced and exposed in diagnostics.
Deliverable: a one-page warm-up report template that captures state timeline, temps, and active coefficient set.
Figure F8 — Thermal feedback loop (temps → coeff selection → ISP → gating)
[PAGE-URL]#fig-f8 (replace [PAGE-URL] with the published page URL)H2-9. Performance Metrics & Quick Selection Checklist (What to ask vendors)
Answer block (metrics are meaningless without conditions and evidence)
Selection should be evidence-driven. For every metric (NETD, drift, radiometric accuracy, fusion error, latency), require (1) a clear definition, (2) stated test conditions, and (3) raw evidence artifacts (curves/logs/residual tables). Any claim without conditions and artifacts should be treated as Not Verifiable.
Core performance metrics (definition → conditions → evidence)
| Metric | Definition (what it measures) | Conditions that must be stated | Evidence artifacts to request |
|---|---|---|---|
| NETD | Noise-equivalent temperature difference (thermal sensitivity proxy) | Lens F/#, integration time, frame rate, ambient temp, scene temp | NETD vs integration curve; NETD vs ambient curve; method note |
| Frame rate + timestamps | Output cadence and continuity (not just “nominal FPS”) | Mode, streaming format, FFC events, load (fusion on/off) | Timestamp log (frame interval histogram); “dropped/duplicated” counters |
| Response time | Time-to-stabilize after a step change (t90/t95) | Step magnitude, distance, target, airflow, integration time | Step response curve (time vs reported temp/counts) |
| Dynamic range / saturation | Behavior under hot spots and reflections (clip/recovery) | Scene range, integration policy, ISP settings | Curve or sequence showing saturation threshold and recovery time |
| Bad pixel rate | Defective pixels/lines at ship, and growth behavior over life | Definition of “bad”, detection method, masking policy | Bad-pixel map export format; count histogram; versioned map example |
| Drift (°C/h or counts/h) | Long-term stability after warm-up and after FFC | Ambient stability, warm-up gate, temp nodes logged | 1–2 hour drift plot + simultaneous sensor/shutter/baseplate temps |
| FFC frequency & occlusion | How often correction happens and how long imagery is blocked | Trigger policy, settle window, occlusion measurement method | FFC count log; occlusion time (ms/frames); post-FFC settle curve |
| Radiometric accuracy | Temperature error under specified conditions (mean/95%/max) | Distance, emissivity, background reflections, ambient, target size | Multi-point residual table; repeatability runs; stability time note |
| Fusion registration (px) | Overlay alignment error on a known target | Distance (near/mid/far), FOV, warp model/LUT policy | Multi-distance error table; example frames with marked points |
| Overlay latency (ms) | Time skew + pipeline delay between thermal and visible overlays | Frame rates, sync method, motion scenario, timestamp source | End-to-end latency measurement method + results (ms) |
| I/O robustness | Packet loss, jitter, control-plane reliability, diagnostics visibility | Long-run duration, network load, error injection | Packet-loss summary + timestamp continuity; command error-code stats |
Rule: metric claims must always include mode + conditions + raw artifacts. Without these, cross-vendor comparison is invalid.
Quick selection checklist (10 yes/no, with required evidence)
Each item is a contract-style question. Any “Yes” must include the listed evidence artifact; otherwise the answer is effectively “No”.
| # | Yes/No question | Minimum evidence required | Acceptance cue (fast sanity check) |
|---|---|---|---|
| 1 | YES/NO NETD includes full conditions (lens, integration, FPS, ambient) | NETD curves (vs integration, vs ambient) + method note | Curves exist and include axes/units (not only a single number) |
| 2 | YES/NO Residual FPN after NUC is quantified (not just “NUC supported”) | Uniform-field images + histogram/STD before/after NUC | Before/after delta shown with identical conditions |
| 3 | YES/NO Bad-pixel definition + export format is provided | Example bad-pixel map export + counts | Map is versioned (profile_ver/asset_ver) |
| 4 | YES/NO Drift is measured over ≥1 hour with temp nodes logged | Drift plot + sensor/shutter/baseplate temps | Drift expressed as °C/h or counts/h with timestamp |
| 5 | YES/NO FFC occlusion time and settle window are quantified | FFC count log + occlusion (ms/frames) + settle curve | Occlusion measured, not described verbally |
| 6 | YES/NO Radiometric accuracy is stated with distance/emissivity/background | Residual table across multiple points + repeatability runs | Error statistics method stated (mean/95%/max) |
| 7 | YES/NO Fusion registration error is given per distance (parallax-aware) | Near/mid/far pixel error table + target method | Error changes with distance are documented |
| 8 | YES/NO Overlay latency measurement method is documented | Latency results (ms) + measurement setup | Latency decomposed (sync skew vs pipeline delay) |
| 9 | YES/NO Ethernet streaming continuity is proven (timestamps/logs) | Frame timestamp log + packet loss summary | Histogram or continuity check exists (not screenshots) |
| 10 | YES/NO Calibration profile integrity is observable (version + CRC) | Diagnostics field list + example snapshot | Fields include profile_ver + CRC_OK + active slot |
One-line request template
“Please provide curves/logs/residual tables for the listed metrics with full test conditions, plus an example diagnostics snapshot showing profile version and integrity.”
Fast rejection signal
Single-number specs without stated conditions, missing axes/units, or “typical only” claims without raw artifacts.
Figure F9a — Vendor evidence pack map (metrics → conditions → artifacts)
[PAGE-URL]#fig-f9a (replace [PAGE-URL] with the published page URL)H2-10. Validation Plan (Bench Tests + Acceptance Criteria)
Answer block (validation = setup + metrics + pass/fail + artifacts)
Validation is a reproducible checklist. Each test should define (1) bench setup, (2) measured metrics with units, (3) acceptance criteria (threshold or “must be verifiable”), and (4) report artifacts (plots, residual tables, logs). This makes performance claims auditable and comparable across builds and vendors.
Bench validation plan (tests grouped by function)
Acceptance can be defined as thresholds or as “verifiable with raw artifacts”. The key is to avoid tests that only produce screenshots.
| Test group | Setup (bench) | Key metrics | Acceptance criteria (examples) | Required report artifacts |
|---|---|---|---|---|
| Uniform-field (NUC/FPN) | Uniform radiator/field; fixed mode settings; repeat before/after NUC | Residual FPN (STD/histogram), bad-pixel masking effect | Residual FPN reduced and stable across temp band; artifacts explained | Before/after images + histogram/STD table + settings snapshot |
| Thermal chamber sweep | Chamber with stabilized steps; log sensor/shutter/baseplate temps | Drift (°C/h or counts/h), dT/dt, warm-up gating timeline | Radiometry enabled only after stability gate; drift bounded or flagged | Time series plots (temps + drift) + state timeline log |
| Blackbody radiometry | Blackbody at multiple setpoints; fixed distance & emissivity policy | Fit residuals, repeatability, settle time | Error expressed with method (mean/95%/max) under stated conditions | Residual table + curve + repeatability runs |
| FFC behavior | Trigger FFC per policy; measure occlusion and post-FFC settle | Occlusion time (ms/frames), settle window stability | Occlusion and settle measured, repeatable, and logged | FFC event log + occlusion measurement + settle curve |
| Fusion alignment (static) | Target board; near/mid/far distances; fixed calibration profile | Registration error (px), distance-dependent parallax error | Error reported per distance; LUT/warp method documented | Multi-distance error table + marked-point example frames |
| Fusion alignment (motion) | Moving target or pan scene; record both streams | Overlay stability, sync jitter proxy, end-to-end latency | Latency (ms) and jitter method documented; overlay artifacts explained | Latency measurement report + synchronized timestamp logs |
| Ethernet streaming robustness | Long-run stream under load; monitor packet loss and timestamps | Packet loss rate, timestamp continuity, frame-interval histogram | Loss/jitter are quantified; no silent discontinuities | Packet-loss summary + timestamp log + histogram |
| Serial/control robustness | Error-injection (timeouts, invalid params); boundary-value commands | Error codes, recovery behavior, command latency | Deterministic error handling; recovery documented | Command transcript + error-code stats + recovery notes |
Threshold-based acceptance
Use explicit limits for drift/occlusion/px-error/latency when a product spec exists. Keep the method fixed so thresholds remain meaningful.
Verifiability-based acceptance
When deployment conditions vary, enforce raw artifacts and stated conditions as the minimum pass gate (“Not Verifiable” becomes a fail).
Figure F9 — Validation matrix (functions × tests → metric + pass/fail)
[PAGE-URL]#fig-f9 (replace [PAGE-URL] with the published page URL)H2-11. Field Debug Playbook (Symptom → Evidence → Isolate → Fix)
Answer block (minimal tools, auditable evidence)
Goal: turn common field failures into a short decision path using the smallest evidence set. Each symptom follows the same four blocks: First 2 measurements → Discriminator → First fix → Prevent. Any fix that changes calibration must be paired with profile version + integrity (CRC/slot) logging.
Minimum evidence kit (readable in logs / registers)
frame_ts_continuity, frame_interval_hist, dropped_frames, duplicated_frames
profile_ver, profile_id, active_slot(A/B), crc_ok, commit_flag, ffc_count, last_ffc_ts
sensor_temp, shutter_temp, baseplate_temp, radiometric_state, warmup_done
fusion_px_error(near/mid/far), overlay_latency_ms, time_skew_ms
Concrete MPN examples (field-replaceable / reference logging parts)
- Temperature sensors: TI TMP117, ADI ADT7420, Microchip MCP9808 (use for sensor/shutter/baseplate nodes)
- I²C EEPROM (profile/header): Microchip 24AA512 / 24LC512, ST M24C64
- SPI NOR (maps/LUT payload): Winbond W25Q64JV / W25Q128JV, Macronix MX25L12835F
- FRAM (journal/atomic metadata): Infineon/Cypress FM25V10, Fujitsu MB85RS256
- RTC (timestamp anchor, if used): NXP PCF85263A, Microchip MCP7940N
- Ethernet PHY (core I/O): TI DP83867IR, Microchip KSZ9031RNX
- RS-485 transceiver (control plane): TI SN65HVD75, Analog Devices/Maxim MAX3485
- Digital isolator (if serial isolation is present): ADI ADuM1201, TI ISO7721
Note MPNs are reference examples to anchor procurement/debug actions; the exact design may use equivalents with the same interface class.
Symptom 1 — Image “stripes / fixed texture / persistent pattern”
First 2 measurements (fast evidence)
- Uniform scene snapshot: capture one frame in a uniform field (or defocused flat target) and check if the pattern is fixed in pixel coordinates.
- Profile & FFC snapshot: read profile_ver, active_slot, crc_ok, ffc_count, last_ffc_ts and record current integration/palette mode.
Discriminator (prove which bucket)
- FFC-linked: pattern changes sharply right after FFC → suspect FFC baseline / NUC map mismatch or settle-window error.
- FFC-independent: pattern stays identical across FFC → suspect bad-pixel/line map, ADC chain artifact, or ROIC noise/FPN.
First fix (lowest risk, reversible)
- Load known-good calibration slot: switch active_slot A↔B and confirm crc_ok=1. (If profile is stored in SPI NOR like W25Q64JV, verify header + CRC first.)
- Controlled FFC: trigger one FFC and log last_ffc_ts plus shutter_temp; compare before/after uniform frame.
- Re-load bad-pixel/line table: if available, restore the last validated map version; log map_ver and count deltas.
Prevent (make recurrence hard)
- Ship with a uniform-field baseline report (pre/post NUC) tied to profile_ver and stored alongside calibration header (EEPROM like 24AA512 or FRAM like FM25V10).
- Enforce “calibration change requires: A/B + commit_flag + CRC” and expose these fields in diagnostics.
Symptom 2 — Temperature is globally high/low (systematic bias)
First 2 measurements (fast evidence)
- Radiometry state: capture radiometric_state and the active radiometry profile ID/version (if separated from imaging NUC profile).
- Single-point sanity check: measure one known source (blackbody or stable reference) and record distance + ambient + target fill factor.
Discriminator (prove configuration vs coefficients)
- Condition-sensitive bias: error changes dramatically when emissivity/target conditions change → suspect emissivity/reflection configuration or scene assumptions.
- Condition-insensitive bias: error stays nearly constant across conditions → suspect radiometry coefficients (gain/offset), unit mapping, or wrong profile loaded.
First fix (lowest risk, reversible)
- Re-load radiometry profile: restore the last validated coefficient set; verify profile_ver + crc_ok before enabling output.
- Two-point confirmation: run a minimal 2-point check (cold/hot) and compare residuals to the stored reference table (typically stored in SPI NOR like W25Q128JV or EEPROM M24C64).
- Timebase sanity (if timestamps are involved): confirm time anchor (RTC like PCF85263A / MCP7940N) to avoid mis-binning in temperature logging.
Prevent
- Bind radiometry profile to explicit conditions (distance/emissivity policy) and make these values readable via diagnostics API.
- Store a signed-off residual table summary with the profile header; reject activation when CRC fails.
Symptom 3 — Large drift during the first minutes after cold start
First 2 measurements
- 3-node temperature trace: log sensor_temp, shutter_temp, baseplate_temp for the first 3–10 minutes.
- Warm-up gate: capture warmup_done (or equivalent) and the time it flips relative to drift settling.
Discriminator
- Temperature-correlated: drift follows temp slopes → suspect temperature compensation mapping (coeff selection, LUT bin, sensor placement/reading).
- FFC-correlated: drift steps occur around FFC events → suspect FFC baseline / settle window or mis-triggered correction.
First fix
- Enforce gating: do not mark radiometric output “valid” until the stable-state gate is reached (tie to warmup_done).
- Verify temperature sensors: cross-check reported temps using a known-good sensor class (e.g., compare to TMP117 or ADT7420 readings on the same bus).
- Restore compensation LUT/profile: load the validated compensation profile and confirm header integrity in FRAM (FM25V10) or EEPROM (24AA512).
Prevent
- Publish warm-up behavior as a measurable spec: time-to-stable + drift rate after stable, with required temp nodes logged.
- Lock compensation LUT to profile versioning and reject partial writes (A/B + commit_flag).
Symptom 4 — Worse image after FFC (ghosting / afterimage / residual pattern)
First 2 measurements
- FFC delta capture: record one frame immediately before and after FFC; log ffc_count, last_ffc_ts.
- Thermal state at FFC: log shutter_temp and sensor_temp at the FFC moment.
Discriminator
- Temp-window sensitive: issue appears only within a shutter temperature range → suspect settle window too short or shutter thermal model mismatch.
- Profile-linked: issue appears right after profile updates/slot switches → suspect NUC/FFC baseline version mismatch or corrupted payload.
First fix
- Increase settle window: extend the post-FFC settle period and verify via logged frame interval continuity.
- Rollback calibration slot: revert to the last validated A/B slot and confirm crc_ok before enabling FFC.
- Restore NUC payload: re-flash the NUC payload from a known-good image on SPI NOR (e.g., W25Q64JV / MX25L12835F) using an atomic commit (header→payload→CRC→commit_flag).
Prevent
- Always log “FFC event packet”: last_ffc_ts + shutter_temp + profile_ver + crc_ok.
- Require a post-FFC uniform-scene check during validation (part of acceptance matrix).
Symptom 5 — Dual-spectrum overlay misalignment changes with distance
First 2 measurements
- Near vs far px error: measure overlay error (px) at two distances using the same target and record fusion_px_error_near/far.
- Time skew / latency: log time_skew_ms and overlay_latency_ms (or proxy via timestamps).
Discriminator
- Distance-dependent: error increases at close range → suspect parallax and missing/incorrect distance-segmented LUT.
- Distance-independent but motion-sensitive: error worsens with motion → suspect time sync / latency mismatch between streams.
First fix
- Load correct LUT/extrinsics: apply the distance-binned warp LUT/extrinsics profile and log its version + CRC (store in NOR W25Q128JV or FRAM MB85RS256).
- Stabilize timestamps: confirm PHY/stream path continuity and timestamp monotonicity; verify the Ethernet interface stack with PHY examples like DP83867IR / KSZ9031RNX.
- Control-plane verification: if fusion parameters are set over serial, validate command reliability via an RS-485 link (e.g., SN65HVD75 / MAX3485) and log error counters.
Prevent
- Ship a multi-distance fusion report (near/mid/far px error) tied to the LUT/extrinsics profile version.
- Expose time-skew/latency counters and reject fusion enable when timestamps are discontinuous.
Figure F10 — Minimal-tool decision tree (5 symptoms, short nodes)
Use this diagram as the “fast entry” map. Each lane contains only: evidence → discriminator → first fix → prevent. Details live in the symptom cards above.
[PAGE-URL]#fig-f10 (replace [PAGE-URL] with the published page URL)Request a Quote
H2-12. FAQs ×12 (Evidence-based, no scope creep)
Each answer stays inside the thermal / dual-spectrum core boundary and points back to measurable evidence (logs, counters, temperature nodes, profile integrity).
1) FFC triggers too often — sensor drift or bad shutter temperature sensing?
ffc_count/last_ffc_ts together with shutter_temp and the warm-up temps (sensor_temp, baseplate_temp). If spikes correlate with shutter_temp, suspect the shutter sensor path (e.g., TMP117/ADT7420 class) or placement. Otherwise tighten warm-up gating and FFC thresholds.
2) Image looks clean but temperature is wrong — calibration coefficients or emissivity settings?
radiometric_state and confirm the active radiometry profile (profile_id, profile_ver, crc_ok). Then repeat one known reference point and note whether error changes with emissivity settings. If error is configuration-sensitive, fix emissivity/scene assumptions. If nearly constant, reload verified coefficients (stored in 24AA512/W25Q128JV-class NVM) and confirm versioning.
3) NETD meets spec in lab but is worse on site — what 2 logs prove thermal stabilization issue?
sensor_temp, shutter_temp, baseplate_temp) during the first minutes, and (2) a noise proxy such as ROI temporal standard deviation or histogram spread per frame. If noise tracks temperature slope, it is stabilization. If noise is flat but clipping appears, isolate dynamic-range/saturation instead.
4) After firmware update, radiometry changed — did an NVM schema/version mismatch happen?
schema_ver, profile_ver, active_slot, commit_flag, crc_ok. If schema_ver changed or the profile reverted to defaults after update, treat it as a schema mismatch. First fix is to reload a known-good radiometry profile and enforce A/B atomic commit on updates.
5) Dual-spectrum overlay is fine far away but wrong up close — parallax LUT or mounting shift?
fusion_px_error at near and far distances and record the active warp/LUT version (profile_id/profile_ver/crc_ok). If error grows at close range, the distance-binned LUT is missing or wrong. If error is constant at all ranges, suspect extrinsics mounting shift or a fixed registration offset. Reload the validated LUT profile from NVM.
6) Bad pixels increased over time — how to tell sensor aging vs algorithm threshold?
bad_pixel_count plus the bad-pixel map version, then compare a uniform-scene capture under the same integration settings. If new defects appear at stable coordinates and persist across sessions, aging or damage is likely. If locations change with thresholds or scene conditions, the detector is too aggressive. First fix: revert to the last validated thresholds/map and record the new version.
7) CRC passes but image is still wrong — what evidence isolates NUC map vs ADC saturation?
profile_ver/crc_ok. In parallel, check histogram edge-clipping or a saturation flag plus integration time. If FFC changes the artifact and there is no clipping, suspect a wrong NUC map (semantic mismatch despite CRC). If clipping is present, isolate ADC/dynamic-range limits and integration policy.
8) Safest way to update calibration in the field without bricking?
commit_flag, and only then switch active_slot. On boot, accept a slot only if crc_ok=1 and header matches schema_ver. Store small metadata in FRAM (FM25V10/MB85RS256 class) or EEPROM and large maps in SPI NOR (W25Q128JV class) for safer journaling.
9) Temperature jumps after FFC — normal step or calibration instability?
last_ffc_ts, the temperature output delta at that moment, and shutter_temp/sensor_temp. If the step is bounded and repeats at similar shutter temperatures, it is likely expected. If the step is large, non-repeatable, or accompanied by ghosting/stripes, treat it as calibration instability: rollback the NUC/radiometry profile and re-validate against a reference.
10) Ethernet stream is stable but control commands are flaky — serial framing or timing issue?
11) Warm-up time is too long — sensor self-heating or compensation table missing?
warmup_done. If sensor_temp keeps rising after baseplate stabilizes, self-heating/thermal resistance dominates; reduce early gain or tighten duty during warm-up. If temperatures stabilize but warmup_done stays false, the compensation bins or thresholds are missing/too conservative. Reload the correct compensation table and verify profile/version integrity in NVM.
12) How to prove fusion latency vs mis-registration when tracking moving targets?
fusion_px_error; in motion, log overlay_latency_ms and time_skew_ms. If static px error is small but motion misalignment grows, latency/synchronization is the cause—tighten timestamp alignment and buffering. If static error is already large, it is mis-registration (extrinsics/LUT). First fix is to load the validated LUT/extrinsics profile and re-check near/far px error.
