test(imq): vet the image-quality family against OpenCV and CellProfiler

[darkclad]

Last family of the vetting series. Six features, three assertion files plus a shared fixture header,
two oracles and one refuted candidate reference, no src/ change. Rebased onto upstream/main
at 6f32f96f.

The family was already labelled vetted on four of its six features. Nothing about that label was
wrong — but nothing about it had been measured either, and the pass found one mispinned golden,
four source defects and a checker gap that spans three families.

Nine registry rows, eleven gtest cases, two benchmarks, five config recipes.

---

Scope: this PR vets the in-RAM paths

Every cell tests/vetting/matrix/imq.md classifies VALID or VALID-BUT-PRODUCTION-ONLY is one that
calculate() reaches. The out-of-core cell is classified and deliberately left unguarded, and
the matrix says so above its own table rather than only in a review thread.

osized_calculate() is reachable production — phase3.cpp:117 drives it for any ROI over the RAM
limit, and all four IMQ feature methods are registered in feature_mgr_init.cpp — so it carries a
SPEC §5.1 disposition rather than "not covered". Its regression guard is outstanding, and the row
says that instead of being closed by relabelling.

It is left open because closing it is a source change, not a vetting pass. All four IMQ classes are
defective on that path, each cited by file and line in the matrix:

• PowerSpectrumFeature::osized_calculate() and SharpnessFeature::osized_calculate() are empty
  {} bodies overriding the base's pure virtual, and
  FeatureMethod::osized_scan_whole_image() calls the no-op and then save_value() regardless;
• FocusScoreFeature::osized_calculate() sets focus_score_ only — local_focus_score_ is
  assigned inside calculate(), on the in-RAM path alone — so it is three features and not two;
• none of the six result members has a default initializer, no constructor assigns one, and
  cleanup_instance() has no override in any of the four classes, so the first oversized ROI
  publishes an indeterminate double rather than a zero;
• the early returns on a constant ROI leak the previous ROI's values, because the base saves
  regardless and feature methods are singletons nothing resets — the same shape as the
  NGTDMFeature::n_levels static;
• get_percent_max_pixels_NT() uses two independent ifs where the in-RAM path uses else if;
• get_focus_score_NT() passes (width, height) where the row count belongs, takes the variance
  over a buffer larger than the region any pixel writes, overruns a 900-entry window on a 100×20
  ROI, and steps the large-ROI branch wrong twice;
• PowerSpectrumFeature::featureset names FOCUS_SCORE where the constructor provides
  POWER_SPECTRUM_SLOPE.

Guarding those per feature needs an oversized-ROI harness this family's gtest fixture does not
build, and that harness overlaps the one the 2D out-of-core repair needs on its own branch —
building a second here would leave two to reconcile.

The follow-up carries, together: the oversized-ROI harness; one matrix row per feature in place
of the single family-wide row, each with its own disposition and its own assertion; and a fix for
every defect above. Explicitly not in it: the POWER_SPECTRUM_SLOPE radial-binning defect, which
is an in-RAM defect the out-of-core path merely inherits, is already pinned by
test_imq_power_spectrum_slope_large_roi_regression, and needs an oracle
(centrosome.radial_power_spectrum.rps) rather than a harness. It will be linked here when it
opens.

---

What was cleaned up

The band was a default parameter. All four oracle assertions called assert_feature() from
test_feature_calculation_common.h, whose signature ends double frac_tolerance = 1000, and none
passed a tolerance. agrees_gt divides the golden by that argument, so 1000 is rel=1e-3 — which
is where the registry's tolerance column got its value. A tolerance that agrees with a helper's
default is not evidence of a measurement.

Measured against fresh runs of both oracles:

feature	oracle	oracle value	Nyxus	abs	rel
FOCUS_SCORE	opencv 4.13.0	34.956597222222221	34.956597222222229	7.1e-15	2.0e-16
LOCAL_FOCUS_SCORE	opencv 4.13.0	7.5763888888888902	7.5763888888888937	3.6e-15	4.7e-16
MIN_SATURATION	cellprofiler 4.2.8	0.1875	0.1875	0	0
MAX_SATURATION	cellprofiler 4.2.8	0.16666666666666669	0.16666666666666666	2.8e-17	1.7e-16

All four now assert with ASSERT_NEAR at SPEC §7's exact tier — that row of the tolerance table is
an absolute 1e-9 band — following a747234, which made the same correction for 2D NGTDM. The
registry's tolerance column reads abs=1e-9.

Structure. A ref_vals_map per file, a named band constant, and one assert helper with a
SCOPED_TRACE, replacing four bare literals in four function bodies — the shape
test_2d_neighbor_cellprofiler.h uses. A new test_imq_common.h carries the templated
calc_imq_feature<F>() and calc_imq_feature_on(), so the three assertion files stop reaching for
roi_cache.h, pixel.h, environment.h, test_data.h and test_main_nyxus.h individually.

check_test_names.py gains TABLE_DIM_AGNOSTIC, the table-level twin of the existing
DIM_AGNOSTIC list for files. The 6.3.1 table rule requires a _2d_/_3d_ token, and imq
carries neither — its registry dim is imq, the same word as its family, so the only conforming
name it could have had was imq_imq_opencv_ref_vals.

---

What changed value, and why

MAX_SATURATION: 0.16666666666666666 → 0.16666666666666669. The pin carried Nyxus' own
16/96 under a comment reading "CellProfiler … = 16/96; tolerance rel=1e-3 (agreement is
exact)". Three things were wrong at once: the value was not CellProfiler's, the agreement was not
exact, and a rel=1e-3 band is five orders looser than "exact" would justify. Both tools count the
same 16 of 96 pixels; CellProfiler reports a percentage, so 100.0*16/96 divided by 100 lands one
ulp above 16/96. A unit conversion, not a disagreement — but the pin of an oracle table should
carry the oracle's digits.

The old generator could not have caught it: it compared CellProfiler against a literal
NYXUS = {...} dict in its own source at TOL=1e-6, three orders above the gap.

SHARPNESS: 2.19047 → 2.1904708385718963. Re-pinned at full %.17g. The truncated value
sat 3.8e-7 relative from what it was guarding.

No other golden moves, and no src/ file is touched.

---

What the generators do now

Both carried a literal golden dict and a transcribed copy of the fixture, so "ALL CHECKS PASSED"
meant the script agreed with its own source. tests/vetting/not_covered.md had recorded that shape
as still live here after the 2D neighbour pass closed the same thing; this closes it. Both now parse
the fixture out of test_data.h and the pins out of the header they feed, carry the reverse check
(a value the oracle produces that the header pins nothing for), and exit non-zero on any mismatch or
unproducible pin.

The pins are re-verified at a round-trip band of 0, not at the band the C++ asserts at. They are
the tool's own digits at %.17g, so a 17-significant-digit literal parses back to the same double
and must round-trip exactly; a non-zero residual means the tool's output moved. Both first shipped
this as the assertion's 1e-9 — the conflation #443's review made gen_ngtdm_mirp.py stop doing,
where a hand-edited golden could drift nine orders and still be reported as verified. Both also
print the versions they actually ran under rather than the literals in their docstrings, per
#448's review.

Three checks worth calling out:

• gen_imq_opencv.py asserts cv2's filtered image equals Nyxus' hand-rolled laplacian() cell
  for cell (max abs diff 0.0) before comparing any scalar. A variance is a scalar and many
  different filtered images share one, so a matching variance alone is weak evidence that two
  implementations filter alike. With the convolution settled, the 7.1e-15 residual means only what
  it looks like it means.
• gen_imq_opencv.py also carries the SPEC §4 negative control for LOCAL_FOCUS_SCORE — see the
  next section.
• gen_imq_cellprofiler.py fails if FOCUS_SCORE or LOCAL_FOCUS_SCORE appear in its table.
  CellProfiler publishes features by those names, and they are a different statistic — normalized
  variance of the raw image, not variance of the Laplacian — so pointing the CP oracle at the names
  it shares would credit a vetting that does not exist.

---

One of the two oracle claims is narrower than it looks, and the gap is now sized

FOCUS_SCORE is wholly OpenCV's — cv2 computes the filter and the population variance.
LOCAL_FOCUS_SCORE is not: cv2 supplies the per-tile statistic, but which tiles and the scale²
divisor are Nyxus' own definition, reproduced in the generator — and that tiling is exactly where
the family's open defect is. Same shape #437's review made GABOR narrow, and it is recorded the same
three ways: a row in not_covered.md §E, the Notes column scan_imq_coverage.py emits, and the
registry row's notes. The oracle column stays opencv, one SPEC §4 token per row.

all_tiles() is the negative control SPEC §4 requires of a partial-pipeline oracle. It walks every
scale² tile — the tiling the /scale² divisor already assumes — and the generator asserts the
gap rather than printing it:

all 4 tiles      28.341145833333336
pinned, 1 tile    7.5763888888888902
gap                        73%

Asserted, not printed, for the reason the control exists: if the gap ever vanished, the one-tile pin
would not be a partial value and the scope note would be overstating the defect, so that case has to
fail too. The shape follows gen_gabor_skimage.py's D2 control, the worked example SPEC §4 names.

Nothing external would close it — no tool implements Nyxus' tiling, because it is not a published
convention. What closes it is fixing the loop bound, at which point the divisor and the tile set
agree and the whole quantity is mean(var(Laplacian(tile))), which cv2 does compute.

---

What was measured and refuted

SHARPNESS' row read candidate_oracle = "reference DOM sharpness (Kumar et al. 2012)",
flag = promote-after-deepdive. The deep dive happened: Nyxus returns 2.1904708385718963 where
the reference returns 0.54592951157710823 on the same fixture. Structural, not numerical — six
differences, of which the first decides the rest: the reference counts pixels above
sharpness_threshold=2; Nyxus sums the sharpness values and has no such parameter. The
reference's Rx is a fraction of edge pixels, bounded by 1, which is what makes the paper's
0 < S < sqrt(2) bound hold; Nyxus' 2.19 is already above sqrt(2). The other five (a row-wise
Sy where the reference is column-wise, swapped edge axes — measured 73/56 against 56/73, the same
numbers exchanged — a shared normalization maximum, no final edge masking, and two unwritten
columns) are in audit/imq_pydom_sharpness_vetting_report.md.

The reference is invoked, never vendored. pydom is GPL-3.0 and this repository is MIT, so
tests/vetting/audit/imq_sharpness_reference_dom.py imports the installed package and calls its
public API — get_sharpness for the score, load/edges/sharpness_matrix for the intermediates
the report tabulates — and reference_sharpness() asserts the intermediates recompose the score
before returning either, so the diagnostics describe the run the entry point produced. It installs
into the offline audit env only and CI never invokes it:

pip install git+https://github.com/umang-singhal/pydom.git

What the script does carry is a port of Nyxus' own MIT-licensed sharpness.cpp, and it has
exactly two checks that can fail: the port reproduces the pinned C++ golden to 2.03e-16 — which is
what makes the six differences a claim about the shipped C++ rather than about a Python script — and
the reference still disagrees. If that second one ever fails, SHARPNESS became promotable, which
is the outcome the report is waiting for.

Row is now candidate_oracle = "… — measured and refuted", flag = impl-defect. Status stays
regression.

---

The config matrix, and the cells no oracle reaches

matrix/imq.md's headline: the family has no configuration axes. None of the four feature
classes reads a NyxSetting, so every knob is a compile-time default on a private static method,
and a recipe here names a fixture rather than a settings bundle. The cells are therefore separated
by input, not by settings.

Every verdict is one of SPEC §5.1's three dispositions, and each
VALID-BUT-PRODUCTION-ONLY cell that calculate() reaches carries a regression guard rather than a
paragraph — five gtest cases, each on the smallest input that reaches its cell:

cell	verdict	guard
MIN/MAX_SATURATION, constant ROI (min == max)	VALID-BUT-PRODUCTION-ONLY	test_imq_{min,max}_saturation_constant_roi_regression — 0 and 1
MIN/MAX_SATURATION, mask narrower than the AABB	VALID-BUT-PRODUCTION-ONLY	test_imq_{min,max}_saturation_narrow_mask_regression — 11/16 and 1/16
POWER_SPECTRUM_SLOPE, short side ≥ 24 px	VALID-BUT-PRODUCTION-ONLY	test_imq_power_spectrum_slope_large_roi_regression — 1.7837481542489078
LOCAL_FOCUS_SCORE, scale ≠ 2	INVALID	no config reaches it — calculate() hardcodes 2 and nothing else calls the method
any feature, out-of-core	VALID-BUT-PRODUCTION-ONLY	open by design — see Scope above

The saturation bands are an absolute 0: every pin is k/16, exactly representable, so any other
value is a change of behaviour and not a float wobble. Those cells exist because CellProfiler
computes a different quantity on each — 100% for both extrema on a constant ROI, mask-only counting
on a narrow mask — so neither can carry an oracle claim, and what stays uncovered is the
agreement, not the code path.

The 24×24 pin needed measuring rather than assuming. It is the first assertion in the tree to
drive PowerSpectrumFeature past its size guard, and power_spectrum_slope() reads raw_radii[i]
from a loop bounded by the padded FFT size — so the pin could have been a snapshot of an
out-of-bounds read. Temporary instrumentation, reverted:

PROBE_PS mag=1024 raw_radii=24 max_i=3 oob=0 surviving=3

Largest index 3 against a 24-element vector, so the read stays in range and the pinned value is
defined. ASan+UBSan on that path agrees — 0 diagnostics. The index remains unbounded in the code;
this shows only that a 24×24 modular ramp keeps it at 3 of 24. The fixture is a deterministic
modular ramp for a second reason: a smooth ramp leaves fewer than two surviving points,
power_spectrum_slope() falls through to the same 0 the guard returns, and the pin could no
longer tell the two code paths apart.

---

What new audit artifacts were added

IMQ had none. This adds the set every other family carries:

• matrix/imq.md — the config matrix, above.
• audit/imq_coverage.csv + audit/scan_imq_coverage.py
• audit/imq_opencv_vetting_report.md, audit/imq_cellprofiler_vetting_report.md,
  audit/imq_pydom_sharpness_vetting_report.md
• audit/imq_golden_regen.md
• benchmarks.md gains bench_imq_quality_roi, recording that the fixture's 18 zero pixels are
  a coordinate typo in the literal (rows y=7..9 repeat rows 1..3's coordinates for x=3..8) that
  three features now depend on, and that its 8 px width is what leaves POWER_SPECTRUM_SLOPE pinned
  at its guard; and bench_imq_matrix_cell_rois, the three probe ROIs for the cells that
  fixture cannot reach — a constant 4×4, a 4×4 whose mask covers 5 of the 16 pixels in its bounding
  box, and a 24×24 modular ramp.
• TOOLS.md gains an opencv row — no env of its own, nyxus_mirp already carries cv2 4.13.0 —
  the cv2 gotchas that matter for a filter oracle (ksize=1 and ksize=3 are different filters;
  borderType is part of the recipe; compare the filtered image), the JVM PATH entries that
  turn CellProfiler's bare exit 127 into a working import, and the general rule the DOM
  reference produced: a reference under a copyleft licence is invoked or reimplemented from the
  publication, never pasted in.

scan_imq_coverage.py runs three set differences beyond the row mapping, all cheap and all lifted
from the 3D GLDM pass: table keys against the assertions that read them (a pinned key nothing reads
is where a bad number lives — it is how a 3D GLDM golden sat at another feature's value, 353× off);
test functions against TEST() registrations, both directions; and the six registry features
against featureset.cpp's FeatureIMQ map, compared as sets in both directions, because a
count cannot see a swap. It matches pins to assertions on the key literal the test passes rather
than on the feature name — the stronger check, and the necessary one now that MIN_SATURATION is
pinned three times across the family.

---

Four defects found, none of them blocking

Recorded with measurements in tests/vetting/matrix/imq.md, and each carried into the
deferred-defect list this series keeps for behaviour changes. None sits between Nyxus and its
oracle, which is why this PR carries no src/ change; the assertions pin current behaviour so
each fix surfaces as a moved golden. Each needs its own branch, since every one of them changes a
public feature value.

1. LOCAL_FOCUS_SCORE reaches one tile of four. get_local_focus_score() loops
   y < height - M with M = height/scale, so at scale=2 exactly one 4×6 tile is visited while
   the divisor stays scale² = 4. The docs say "the mean and median values of the tiles are
   returned", which the code returns neither of. The generator asserts the tile count is 1, so
   fixing the bound fails there rather than silently redefining the golden — and the negative
   control above sizes what that costs: 73%.
2. POWER_SPECTRUM_SLOPE is pinned twice, at the guard and at the algorithm behind it. rps()
   returns early unless floor(min(h,w)/8) >= 3 and the 8 px fixture never clears it, so that pin
   is the guard's return value and its band is abs=0. Past the guard, measured on the committed
   24×24 ROI: the radius axis is floor(sqrt(fft coefficient))+1 — the FFT value, not the
   frequency radius sqrt(kx²+ky²) — and raw_radii is indexed by that bin inside a loop bounded
   by the padded FFT size, 1024 against raw_radii's 24.
3. SHARPNESS is not the DOM measure (above).
4. The out-of-core paths (Scope, above) — the one row this PR ships open.

Two more that are latent rather than live: static int ksize is declared in all four IMQ feature
headers under a "User interface" comment and is defined nowhere and referenced nowhere (a
translation unit that used it would fail to link); and FocusScoreFeature::kernel[9] is a mutable
static the ksize != 1 branch overwrites in place and never restores — unreachable today because
calculate() hardcodes ksize=1, the same shape as the NGTDMFeature::n_levels static the 2D
NGTDM pass fixed.

---

The checker gap, and why it is in this PR

oracle_coverage.csv has three pointer columns. check_coverage.py validated benchmark and
test_name and had no validator for config_recipe at all, so a row could name a SPEC §5
recipe that had never been written and every checker stayed green. Turning the check on found four
dangling ids across three families:

id	rows	state
imq.laplacian_ksize1_zeropad	2	defined nowhere
imq.saturation_observed_extremum	2	defined nowhere
glrlm.ibsi_ng128	32	named in test_2d_glrlm_common.h's comment since that family was vetted; section never written
"Not mode-specific. Any disagreement is a definition, coordinate-frame, …"	34	a prose sentence in a pointer column, on firstorder rows

All four are closed here — the three real recipes are written, the prose moves to notes where it
was always a note — and validate_config_recipes fails on a fifth. This is the third instance of
the same class in the series, after a dangling target_test and thirty GLCM rows describing a
deleted file in notes: an unvalidated column is where stale references live, and the fix is a
validator rather than a one-off correction.

main independently fixed four more of those prose rows while this branch was open — the radial and
zernike ones now name radial.shape2d_native and zernike.shape2d_native — which is why the count
above is 34 and not the 38 the branch started with.

The 32 GLRLM rows and the 34 prose rows are the only places this PR touches another family's data.
The glrlm.ibsi_ng128 section is transcribed from test_2d_glrlm_common.h,
audit/glrlm_2d_pyradiomics_vetting_report.md and audit/glrlm_2d_ibsi_vetting_report.md; no GLRLM
value or verdict changes.

---

How it was verified

Not "tests pass" — each gate below was run on this branch, at this base:

gate	result
gtest, Windows	884 cases, 883 pass, 1 skip without USE_GPU — the skip is TEST_2D_GABOR_GPU_RUNS_MECHANICS. The base's own count at 6f32f96f is 879 (891 TEST() blocks less the 13 behind USE_ARROW/DICOM_SUPPORT/OMEZARR_SUPPORT, plus the one in test_3d_coverage_common.h); this pass adds exactly the five cell guards and removes none, and none of the four IMQ headers contains a TEST( at all
ASan+UBSan, Linux	884 cases, 883 pass, 1 skip, 0 sanitizer diagnostics, gtest rc=0, all eleven IMQ cases confirmed by name. The gate checksums the four IMQ headers, test_all.cc and the four IMQ feature sources before the build and again after the run — the last four are how the no-src/-change claim is made positively, since the synced tree is not a git checkout, and they are byte-identical to the ones the pre-review gate pinned. It asserts CMAKE_HOME_DIRECTORY is its own tree and prints hostname, so a log copied between clones cannot vouch for it
pytest tests/python/	89 passed, 1 skipped, 7 @pytest.mark.arrow failing only because this build is ALLEXTRAS=OFF. 89 is 88 + the one new check_coverage self-test
generators against the headers they feed	gen_imq_opencv.py, gen_imq_cellprofiler.py and imq_sharpness_reference_dom.py all exit 0 against the tree in this PR — every pin re-verified, none unproducible, reverse check clean, negative control asserted
checkers	check_test_names.py --check, check_coverage.py --check, scan_imq_coverage.py --check all clean

EXPECT_TOTAL_CASES in the ASan gate was re-derived after the rebase, not carried forward. The
pre-rebase 882 was 793 TEST_NYXUS cases plus 89 from six parameterized 3D coverage sweeps main
has since retired into individually named cases. Derivation on this tree: 896 TEST( blocks at
column 0 in test_all.cc, 13 of them behind USE_ARROW/DICOM_SUPPORT/OMEZARR_SUPPORT which the
gate's configure line turns off, plus the one case in test_3d_coverage_common.h — 884. The same
arithmetic reproduces the previous round's measured 793 exactly (805 − 13 + 1), and the run
reported 884, so it is a derivation that was then checked rather than a number that was fitted.

Negative controls, twenty-one in the original pass, all behaved. Seven on the assertions: each
band rejects a perturbation just outside it (+2e-9 on the three oracle pins with room, 1e-12 on
POWER_SPECTRUM_SLOPE's exact band, +5e-9 on SHARPNESS), a deleted table key is reported by name
rather than compared against a default-inserted 0, and the unperturbed tree passes. Six on the
scanner: a pinned key nothing reads, an assertion with nothing pinned for it, an unregistered test
function, a row naming the wrong oracle, a feature the enum publishes that no row covers, and a
test_name no gtest case answers to — each named by the checker, with the clean tree passing. Eight
on the generators: a pin drifted by one ulp, a pin they cannot produce, a value the oracle produces
that nothing pins, the tile count changing under the golden, a CellProfiler table pinning a name CP
shares but does not vet, and all three scripts exiting 0 unperturbed. The review round added the
all_tiles() gap assertion, which is a negative control that ships rather than one that was run
once.

The finished branch was then re-audited against the framework protocol and against the review
comments this series has accumulated — #437, #438, #439, #440, #443, #445 and #448. Eight
findings; seven fixed, one (an _invariant file) weighed and declined with the reason. The two that
mattered are in this body: the generators' pin round-trip band, and LOCAL_FOCUS_SCORE's
partial-pipeline oracle.

---

Review round

@vjaganat90's three inline comments and the out-of-core blocker are all answered, in that order:

1. GPL-3.0 code vendored into an MIT repo. Correct, and the more serious of the three. Six
   functions had been transcribed line for line from pydom with no licence or copyright preserved.
   The licence was confirmed against the GitHub licence API rather than assumed. De-vendored by
   invoking upstream, the first remedy the comment named; no number in the refutation moved, and
   divergence 5 got stronger out of it, since the raw sharpness_matrix counts are now printed
   beside the masked ones.
2. Non-SPEC dispositions on reachable production cells. Correct. Every verdict is now one of the
   three §5.1 tokens and each reachable cell has a guard — the five cases in the matrix table above,
   plus two cells the comment did not name brought into the same vocabulary.
3. A partial-pipeline oracle with no negative control. Correct. all_tiles(), asserted, sizing
   the gap at 73%.
4. Blocker: out-of-core is reachable production. Agreed, and two of its three claims are worse
   than stated — the empty bodies publish an indeterminate double rather than skipping, and
   LOCAL_FOCUS_SCORE is in the same position, so it is three features and not two. The comment
   also caught an error of mine, since corrected in the matrix and in not_covered.md: the
   constant-ROI case does not leave both saturations at 0; the base saves regardless and nothing
   resets the singleton. Split into a follow-up by agreement, scoped in the Scope section above.

Types reaching the changelog if this is merged as a merge-commit rather than squashed: seven
test, one chore and one docs, all configured hidden. Nothing lands in the CHANGELOG and no
version moves either way, which is correct for a test-and-tooling PR.

[vjaganat90]

This says the functions below are transcribed line-for-line from pydom, whose repository is GPL-3.0, into MIT-licensed Nyxus without preserving its license/copyright. Please avoid vendoring this copy (invoke upstream or reimplement independently from the paper), or resolve the licensing explicitly before merge.

Yeah this could be kinda bad legally.

[darkclad]

Fixed

[vjaganat90]

VALID-but-divergent and NOT PINNED are not SPEC §5.1 dispositions. These are reachable production cells: classify them as VALID-BUT-PRODUCTION-ONLY and add regression guards, or justify INVALID; recording the defects alone does not satisfy the matrix→test rule.

[darkclad]

Fixed

[vjaganat90]

LOCAL_FOCUS_SCORE is explicitly a partial-pipeline oracle, so SPEC §4 requires a negative control that measures the uncovered gap. EXPECTED_TILES = 1 only checks that the copied Nyxus tiling stays copied; also compute the four-tile result and show it differs from the pinned partial value.

[darkclad]

Fixed

[vjaganat90]

Blocker: Out-of-core is a reachable production execution mode, so NOT COVERED is not a terminal SPEC §5.1 disposition. Add guards/dispositions for each IMQ feature before claiming the family matrix: PowerSpectrum and Sharpness have empty osized_calculate() implementations, while the FocusScore NT path documented below can overrun its 900-element window on a 100×20 ROI and leaves LOCAL_FOCUS_SCORE unset.

[darkclad]

Agreed. fcf3880d already relabels that row VALID-BUT-PRODUCTION-ONLY on your reasoning — it was
pushed after your comment was written, from work that predates it — but that answers the vocabulary
and none of the substance. You asked for guards or dispositions per IMQ feature, and one row for the
family is not that.

All three of your claims check out, and two are worse than you put them:

1. The empty osized_calculate() bodies do not skip those features.
   FeatureMethod::osized_scan_whole_image() calls the no-op and then save_value(), which writes
   slope_ / sharpness_. Neither member has a default initializer, neither constructor assigns
   one, and cleanup_instance() is an empty base with no override in any of the four classes. An
   oversized ROI publishes an indeterminate double, not a zero.
2. LOCAL_FOCUS_SCORE is the same case, so it is three features and not two.
   local_focus_score_ is assigned only at focus_score.cpp:26, inside calculate() — the in-RAM
   path exclusively — while save_value() writes it regardless.
3. The 900-element overrun is real: a 100×20 ROI writes 2000 entries into it.

Your comment also caught an error of mine. The matrix says the constant-ROI case leaves both
saturations at 0. It does not: osized_calculate() early-returns, but the base calls save_value()
anyway, and the feature methods are long-lived singletons nothing resets between ROIs — so what is
published is the previous oversized ROI's values, or indeterminate on the first. Same shape as the
NGTDMFeature::n_levels static. I will fix that text.

On how to close it: every item above is a source defect, and guarding them per feature needs an
oversized-ROI harness this family's gtest fixture does not build — one that overlaps the 2D
out-of-core repair already in flight, so building a second here means two to reconcile later. I would
rather split the out-of-core row into its own PR carrying the harness, the per-feature dispositions
and the fixes together, and leave #457 as a vetting pass over the in-RAM paths with that row marked
open. #457 changes no source file; the four IMQ feature .cpp md5s are byte-identical to the
previous round, verified in the ASan gate.

If you would rather it not land with an open row, say so and I will hold it and do the out-of-core
work here instead — your call. Either way I will restore the per-feature detail above into
matrix/imq.md.

[vjaganat90]

Agreed — splitting the out-of-core repair into a separate PR is reasonable. Please define that follow-up’s scope explicitly (the oversized-ROI harness plus per-feature dispositions/guards and fixes for every defect listed above), and make PR #457’s description and matrix/imq.md equally clear that this PR vets only the in-RAM paths and deliberately leaves the out-of-core row open. Please also link the follow-up from #457 once it exists.

[vjaganat90]

LGTM*

*with view of follow-up PR we agreed upon