Two strands, committed together because they touch the same four files
and answer the same question: an exported PNG must be the image the user
was looking at when they triggered the export.
Dropped view settings (bug fix):
- BatchExportWorker forwarded the DC threshold, bg-sub, pad and row-
averaging to compute_rf_image but never min_freq_mhz, so every RF and
Velocity map was exported with no min peak frequency floor. The pixels
the floor exists to reject came back at their pre-floor peaks.
- That also decided *which source* the image came from: requesting floor
0 makes a stored v7 cache look like a match (cache_mismatch_reasons
only rejects a higher stored floor), so a batch-computed file exported
the cached peak-frequency block verbatim - numbers from an earlier
Batch Compute run, while the screen showed that same cache re-masked
against the live floor. The symptom was a newly loaded file exporting
a stale-looking velocity map, since the floor is a display control
that survives a load while the window's own FFT cache does not.
- export_view_image had the same class of defect with a different
parameter: it dropped row_avg_n, so a file whose stored cache is row-
averaged displayed from the store but exported as a full raw
recompute - a different, and much slower, image. It now reads
sras.precomputed_row_avg_n per file, mirroring _stored_fft_image and
_start_compute, and derived per file for the same reason n_fft is.
Export at the live canvas size:
- Both exporters now take the canvas's current figure size instead of a
hard-coded 7x5. draw_view_image uses aspect="auto", so the figure box
is what sets the map's proportions - a view sized wide on screen was
being squeezed into a different shape on disk. Read at trigger time,
in inches, so a resize mid-batch cannot change images later in the
same run and a HiDPI display exports like a standard one.
- sanitize_figsize clamps a degenerate size (collapsed splitter pane,
minimized window): a wrong-looking aspect ratio must never be the
reason a batch loses an image.
Tests: BatchExportWorker had no coverage at all. Four new tests cover
the floor being applied, a stored cache never being served unfloored,
the menu-to-worker wiring, and the row-averaged cache case; each was
verified to fail against the unfixed code. 166 passed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Thomas Ales [M S E]
48d560fb00