- CUAS-focused work was parked around commit `8946631f767ddda77365ebc32d45eef1e3d21936` (October 27, 2025).
- Since then, development emphasis shifted to foliage/global-LMA paths; CUAS branches may require restoration and re-validation for bit-rot before new-data testing.
### Current CUAS target-detection flow (March 2026 LV data)
For the March 2026 LV runs, the current working input list is:
```
/home/elphel/lwir16-proc/LV/lists/lv_site_05.list
```
Per-sequence outputs are created under linked center directories such as:
is the same merged sequence after unsharp masking (for the example above: sigma 2.0 px, amount 1.0).
The next CUAS stage is the moving-target stage:
- estimate a prevailing per-tile motion vector using 2D phase correlation on the merged/unsharp sequence,
- use those vectors as a "virtual moving camera",
- shift each contributing frame according to that motion vector,
- accumulate the shifted frames as a long exposure to improve SNR of dim moving targets,
- then locate/freeze targets on the accumulated data and render target overlays/video products.
This stage is where the sky mask matters operationally: terrain-rich areas are suppressed before accepting local maxima, so target search is effectively constrained to the allowed sky region.
#### CUAS motion-scan details: keyframes, pair geometry, and FAST/SLOW split
The per-tile motion vectors are not estimated from a single frame pair. For each keyframe index, the code builds a short temporal block and accumulates multiple pairwise correlations that all correspond to nearly the same constant-velocity target motion.
The main scan geometry is controlled by:
-`cuas_corr_offset`: separation between the two halves of each pair set
-`cuas_corr_pairs`: number of correlation pairs accumulated inside one keyframe block
-`cuas_half_step`: if `true`, adjacent keyframes advance by `cuas_corr_offset/2`; otherwise by `cuas_corr_offset`
-`cuas_precorr_ra` and `cuas_corr_step`: optional temporal smoothing/decimation before correlation
- for keyframe `n`, `frame0 = start_frame + n * corr_inc`
-`frame1 = frame0 + cuas_corr_offset`
Inside that keyframe, the code correlates multiple temporally aligned pairs:
-`(frame0 + dframe)` against `(frame1 + dframe)`
- where `dframe` runs from `corr_ra_step/2` to `< cuas_corr_pairs`, stepping by `corr_ra_step`
So with the common mental model of `offset = 8` and `pairs = 8`, the effective pairs are approximately:
-`0 vs 8`
-`1 vs 9`
- ...
-`7 vs 15`
or the decimated equivalent if `cuas_corr_step > 1`.
Each pair is correlated tile-by-tile in transform domain (`TDCorrTile`). The pair results are accumulated before conversion back to pixel-domain correlation. If `cuas_smooth` is enabled, the individual pair contributions are weighted by a sine window across the temporal block. After accumulation:
- TD correlations are normalized and converted to pixel-domain using `cuas_fat_zero`
The `*-CORR2D.tiff` files visualize these per-tile 15x15 correlation maps, one keyframe per slice.
FAST and SLOW currently share this same motion-scan geometry. The difference is only in the temporal prefiltering of the input sequence:
- FAST: `temporalUnsharpMask()` using `cuas_temporal_um`
- SLOW: `runningGaussian()` using `cuas_slow_ra`
Both then call the same `prepareMotionBasedSequence()` path and therefore use the same `cuas_corr_offset`, `cuas_corr_pairs`, `cuas_half_step`, `cuas_precorr_ra`, and `cuas_corr_step`.
Practical consequence: if targets are too fast and the peaks in `*-FAST-CORR2D.tiff` hit the `+-7` tile borders, reducing `cuas_corr_offset` will reduce the apparent motion in both FAST and SLOW modes. There is currently no separate fast-only correlation offset parameter; adding one would require a code change.
### Where the current code does this
-`CuasRanging.processMovingTargetsMulti()` renders the per-sequence `...-CUAS...` stack and applies the unsharp mask before creating `fpixels`.
-`CuasMotion.processMovingTargetsMulti()` runs the fast/slow motion-target preparation and resolves non-conflicting motion candidates.
-`CuasMotion.generateExtractFilterMovingTargets()` expands the target field, performs the motion-compensated accumulation, and renders target/background outputs.
-`CuasMotion.shiftAndRenderAccumulate()` is the "virtual moving camera / long exposure" step.
-`CuasMotion.getAccumulatedCoordinates()` searches the accumulated tiles for isolated local maxima, applies the sky mask, and refines target coordinates with the CUAS LMA fit.
### Top-level trigger path
The March 2026 CUAS workflow order is:
1. Normal per-sequence CUAS scene processing (`cuas_proc_mode = 0`) produces the merged/unsharp stacks, motion vectors, accumulated target frames, and per-sequence CUAS outputs.
2.`CUAS Combine` runs later on the already generated linked centers (`CuasMultiSeries.processGlobals()`).
3.`CUAS Video` runs after that to combine/package already produced CUAS video outputs.
So the motion-vector and long-exposure stage belongs to the first, per-sequence CUAS processing pass, while `CUAS Combine` and `CUAS Video` are later-stage steps.
The direct gate for producing the accumulated target outputs is:
```
IntersceneMatchParameters.cuas_generate
```
shown in the UI as:
```
Generate and save detected targets
```
If that checkbox is off, the code will still do earlier target/ranging work but will skip the accumulated target TIFF/video generation stage.
## Latest Additions
### Segment freezing with `keep_segments`
Index scenes (`*-index`) contain `*-INTERFRAME.corr-xml` with keys like:
finalfloat[][]accum_data,// should be around 0, no low-freq
finaldoublelmax_fraction,// 0.7; // Check if local maximum is separated from the surrounding by this fraction of the maximum value
finaldoublelmax_flt_neglim,// -0.3; // limit negative data to reduce ridge influence (>= to disable)
finaldoublelmax_flt_hsigma,// 1.0 // HPF (~UM) subtract GB with this sigma from the data tile
finaldoublelmax_flt_lsigma,// 1.0 // LPF - GB result of the previous subtraction
finaldoublelmax_flt_scale,// 5.0 // scale filtering result
finaldouble[]sky_mask,
finaldoublesky_threshold,// 0.9 // minimal value of the sky mask where target is possible
finaldoublelma_horizon,
finaldoublelmax_hack_ridge,// 0.45; // Hack for ridges: remove horizontal streaks, where average(abs()) for the line exceeds fraction of abs max 0.32-good, 0.55 - bad
finaldoublelmax_radius,// 3; // look inside cuas_lmax_radius* 2 + 1 square for the local maximum isolation
finalbooleanlmax_zero,// true; // zero all data outside this radius from the maximum
finaldoublecentroid_radius,
finalintn_recenter,// re-center window around new maximum. 0 -no refines (single-pass)
booleanshow_empty=true;// false; // show scenes with no (valid) targets
...
...
@@ -8396,7 +7960,7 @@ public class CuasMotion {
int[][]filter5=filter5Targets(// will ignore failed tiles
motion_sequence,// final double [][][] target_sequence,
target_sequence_multi,// final double [][][][] target_sequence_multi,
target_sequence_multi,// final double [][][][] target_sequence_multi,non-centered marked as "used"
// if use motion and select_new will only consider tiles (and compare motion scores in motion_sequence) that have nulls in target_sequence_multi[nseq][ntile]
// if not use motion and select_new will only consider (and compare scores) tiles that have [RSLT_CENTERED] = 0.0
// if not select_new (assumes not use motion) will return best (and good) target indices
...
...
@@ -8443,9 +8007,14 @@ public class CuasMotion {
break;
}
// render and process in centered mode
// double [][][] targets_nonoverlap = applyFilter( // motion vectors // will have nulls not top try
// motion_sequence, // double [][][] motion_scan,
// filter5); // boolean [][] filter5)
double[][][]targets_nonoverlap=applyFilter(// motion vectors // will have nulls not top try
