fix: qualify native RealityScan and Postshot report imports

CHANGELOG.md

@@ -4,6 +4,8 @@ Versioned entries describe their historical candidates/releases. Version 4.0.1 p
 
 ## [Unreleased]
 
+- Qualify native RealityScan 2.2 input-state reports and Postshot 1.1.69 COLMAP text/binary exports on retained staircase projects. Accept zero-based unsigned camera/image IDs, scope appended logs before UTF-8 decoding, and apply the dark dialog theme to consumer reports. Preserve unknown coverage when a failed Postshot project cannot export camera poses; document the exact correspondence between five mask warnings and five absent Down views.
+
 - Import RealityScan registration/input-state reports and Postshot COLMAP camera exports with optional mask-warning logs in Studio and CLI. Persist per-source evidence across extractions, report coverage per component, capture and direction, and distinguish explicit rejection, absence and unknown membership.
 - Preserve the documented dotted filename extension in the RealityScan report template and cancel active report imports when the dialog is dismissed with Escape.
 

IMPROVEMENTS.md

@@ -1,10 +1,10 @@
 # Improvement roadmap
 
-Updated 2026-11-01 after consolidating the October 28 trials, executing the paired 16/31-capture staircase pilot, repeating it with the merged capture-plan implementation and adding consumer-report import. This is the active roadmap for reliable, inspectable dataset preparation: prepare, diagnose, correct, export and verify in the target application. Dated reports retain their original scope; new evidence updates this roadmap rather than rewriting earlier results.
+Updated 2026-11-02 after qualifying native consumer reports from the retained 16/31 staircase projects and correcting the importer. This is the active roadmap for reliable, inspectable dataset preparation: prepare, diagnose, correct, export and verify in the target application. Dated reports retain their original scope; new evidence updates this roadmap rather than rewriting earlier results.
 
 ## Implemented, exercised and distributed
 
-The tested functional baseline is `dev` at `3bba6be` (PR #29). The public [v4.0.3 prerelease](https://github.com/nicolasdiolez/360Extractor/releases/tag/v4.0.3) predates projects, mask profiles, rolling storage checks and alignment diagnostics. These development features are not in that downloadable binary, even though the source version still reads 4.0.3. Version/build identification needs to distinguish the next candidate. The earlier repository inventory recorded `main` at v4.0.1 and GitHub's latest stable release as v3.3; this consumer revalidation did not re-audit or publish releases.
+The native-report baseline is `dev` at `f780792` (PR #31); the retained extraction/reconstruction pair was produced with `3bba6be` (PR #29). The November 2 importer corrections are prepared on `codex/native-consumer-report-validation`, pending review and integration. The public [v4.0.3 prerelease](https://github.com/nicolasdiolez/360Extractor/releases/tag/v4.0.3) predates projects, mask profiles, rolling storage checks and alignment diagnostics. These development features are not in that downloadable binary, even though the source version still reads 4.0.3. Version/build identification needs to distinguish the next candidate. The earlier repository inventory recorded `main` at v4.0.1 and GitHub's latest stable release as v3.3; this consumer revalidation did not re-audit or publish releases.
 
 | Capability | Development sources | Real-world evidence / remaining limit |
 | :--- | :--- | :--- |
@@ -21,7 +21,7 @@ The [consumer report](docs/implementation-2026-10-28/CONSUMER_VALIDATION.md) and
 
 The first follow-up implementation ([PR #28](https://github.com/nicolasdiolez/360Extractor/pull/28)), merged into `dev`, adds per-model directional coverage and missing views, plus saved per-video extraction ranges in Studio/CLI. See the [implementation checks and limits](docs/implementation-2026-11-01/SELECTION_VALIDATION.md). This does not change the 16-capture diagnostic limit or qualify another reconstruction engine.
 
-1. **Make consumer results inspectable and repeatable.** The [new run with merged dev](docs/implementation-2026-11-01/DEV_REVALIDATION.md) verifies the 96 common JPEGs and 16 common masks by SHA-256 for each consumer profile. Postshot again changes from tracking failure to a reopened 5 kStep splat, now with 118/186 accepted views. RealityScan grows from 8 to 58 views in its largest component, covering 8/16 versus 31/31 physical captures, but still produces 12 fragments in each case. The [earlier pilot](docs/implementation-2026-11-01/SAMPLING_COMPARISON.md) produced different counts from identical image bytes; the cause is not isolated. The first consumer-result importer now records view identities, physical captures, directions and mask warnings; qualify its native exports across versions, then investigate the five unmatched Down masks on Postshot reopen with a separate masked/unmasked test. Run at least three repetitions per arm under a recorded cache/seed protocol before judging repeatability or timing. Keep current defaults and diagnostic limits; an explicit denser diagnostic needs its own resource qualification. No complete-scene or held-out quality claim is established.
+1. **Make consumer results inspectable and repeatable.** The [new run with merged dev](docs/implementation-2026-11-01/DEV_REVALIDATION.md) verifies the 96 common JPEGs and 16 common masks by SHA-256 for each consumer profile. Postshot again changes from tracking failure to a reopened 5 kStep splat, now with 118/186 accepted views. RealityScan grows from 8 to 58 views in its largest component, covering 8/16 versus 31/31 physical captures, but still produces 12 fragments in each case. The [earlier pilot](docs/implementation-2026-11-01/SAMPLING_COMPARISON.md) produced different counts from identical image bytes; the cause is not isolated. The [native-report qualification](docs/implementation-2026-11-02/NATIVE_REPORT_VALIDATION.md) now verifies RealityScan 2.2 input states and Postshot 1.1.69 text/binary identities, including project save/reopen. It corrects zero-based Postshot IDs, log-session decoding and dialog contrast. The five mask warnings map exactly to the five absent Down views; the failed 16-capture project has no camera poses to export. Next isolate mask effects on the same selected views with a separate masked/unmasked test, and extend compatibility to other versions and native registration CSV. Run at least three repetitions per arm under a recorded cache/seed protocol before judging repeatability or timing. Keep current defaults and diagnostic limits; an explicit denser diagnostic needs its own resource qualification. No complete-scene or held-out quality claim is established.
 2. **Complete inspectable extraction selection.** Saved inclusion ranges now restrict full extraction in `dev` (PR #28), preserve global cadence and combine with existing exact-frame exclusions. The editor provides boundary previews; diagnostics respect both extraction ranges and their separate test window. Controlled 16-to-31 densification preserving the original indices is implemented by [PR #29](https://github.com/nicolasdiolez/360Extractor/pull/29), with a frozen Studio/CLI plan and a reusable staircase configuration; see [validation and limits](docs/implementation-2026-11-01/DENSIFICATION_VALIDATION.md). Remaining: graphical timeline editing and an inspectable candidate list with selection/rejection reasons. Evaluate better window-based selection against fixed sampling on the same corpus; the current optical-flow filter demonstrated no benefit in the initial pilot.
 3. **Add persistent manual mask correction.** Brush/polygon corrections and controllable margins should survive reopening and export through each destination profile. Measure missed occluders and false removal on annotated examples, including artwork, hands and poles. The consumer pilots verified association/mode, not the per-pixel effect of every mask.
 4. **Complete project recovery and resource planning.** Add autosave/recovery, complete run history and verified resume using source/settings checks plus a validated output index. Retain fresh run folders as the current safe behavior. Extend planning to model caches and reconstruction workspaces, with measured RAM/VRAM and disk use.
@@ -76,7 +76,8 @@ These implementations are not all qualified on real camera/GPU/software combinat
 - [x] Paired 16-versus-31-capture pilot at 90° on the beginning of the staircase; one run per case/consumer, with results and limits recorded.
 - [x] Repeat the staircase pair with merged `dev`, verify common image/mask hashes and retain native consumer projects.
 - [x] Initial durable consumer-result import in Studio/CLI ([PR #31](https://github.com/nicolasdiolez/360Extractor/pull/31)): RealityScan input states/registration, Postshot COLMAP camera identities, per-component capture/direction coverage and mapped/unmapped mask warnings. See [formats and limits](docs/CONSUMER_REPORTS.md) and [source validation and review](docs/implementation-2026-11-01/CONSUMER_IMPORT_VALIDATION.md).
-- [ ] Qualify real exported reports across supported consumer versions and verify mask association/persistence per pixel. Postshot logs alone still cannot establish capture coverage.
+- [x] Qualify native RealityScan 2.2 input-state reports and Postshot 1.1.69 COLMAP text/binary identities on retained projects, with exact direction/capture coverage and saved-project roundtrip. Corrections remain on the November 2 qualification branch pending integration.
+- [ ] Extend native report qualification to registration CSV and other supported versions; verify mask effects/persistence per pixel. The five mapped warnings concern five absent Down views, and Postshot logs alone still cannot establish capture coverage.
 - [ ] Controlled repeatability qualification with at least three runs per arm; record cache state and seed availability.
 - [ ] Repeated consumer quality comparisons, mask-effect checks and complete-scene acceptance.
 - [ ] Explicit HDR/ICC/alpha handling.

docs/CONSUMER_REPORTS.md

@@ -2,6 +2,8 @@
 
 Development sources provide **Project → RealityScan / Postshot Reports…** for one selected source. This reads existing reconstruction evidence; it does not launch either consumer or change extraction settings. The downloadable v4.0.3 preview does not include this feature.
 
+[Native staircase qualification](implementation-2026-11-02/NATIVE_REPORT_VALIDATION.md) exercised the supplied template in RealityScan 2.2 and both COLMAP formats in Postshot 1.1.69. That follow-up corrects zero-based Postshot IDs and documents the failed-project case; it does not certify every consumer version or registration CSV.
+
 Choose the completed extraction folder containing `manifest.json` and `images.jsonl`, then the camera/input report and optionally a consumer log. The folder does not need a `colmap/` subfolder and may use either destination mask profile. Select one component or Image Set to inspect its view states, physical-capture coverage, directions and mask warnings. Filter by state, filename, direction or frame; the view table pages in groups of 200.
 
 ## Supported evidence
@@ -15,6 +17,8 @@ Choose the completed extraction folder containing `manifest.json` and `images.js
 
 Postshot's camera export is in the **Image Set actions**, distinct from **File → Export Cameras** (animated cameras). See the [Postshot Image Set guide](https://activation.jawset.com/docs/d/Postshot%2BUser%2BGuide/Interface/Scene%2BTree/Image%2BSet). Camera membership does not by itself establish which images participated in a particular training interval or whether their masks were applied correctly.
 
+If Postshot reports **Image Set is empty** and refuses to export camera poses, import its log alone. Coverage remains unknown; partial solver counts are not camera identities. For RealityScan registration CSV, explicitly select **Internal/External camera parameters**. Naming a CLI output `.csv` does not select that format: `exportRegistration` uses current export settings unless a parameter file is supplied.
+
 Use **Save RealityScan report template…**, or the CLI below, to obtain a plain-text report template. Export it from the project with RealityScan's `exportReport` command, for example:
 
 ```text
@@ -28,7 +32,7 @@ The template iterates components, selects each one and reports its input names a
 - Capture indices, directions, timestamps and mask associations come from the **confirmed extraction index**, never from guessing a filename suffix. Custom filenames are supported.
 - Cross-platform paths match exact index-relative names first, then an unambiguous basename. Matching is case-sensitive. Foreign or ambiguous camera names, duplicates, nonfinite/truncated COLMAP records and incomplete exports fail the import. No inferred camera is silently accepted.
 - Coverage denominators are exported views/captures, not an assumed six views per capture, and not proof of all images submitted to the consumer. Physical-capture coverage distinguishes at least one retained view from all exported views retained. No union of components is represented as a coherent reconstruction.
-- Logs use the **last UTC session header** when present; otherwise they use the entire supplied file. A session may contain several runs. Provide a run-specific excerpt when necessary. Warning-to-mask association is a filename correspondence, not proof of the warning's source run. Tracking counts and partial solver attempts are deliberately not used to infer view membership.
+- Logs use the **last UTC session header** when present; otherwise they use the entire supplied file. Scope is selected before UTF-8 decoding, so older sessions with a different encoding do not block a valid current session. The selected scope must still be UTF-8. A session may contain several runs. Provide a run-specific excerpt when necessary. Warning-to-mask association is a filename correspondence, not proof of the warning's source run. Tracking counts and partial solver attempts are deliberately not used to infer view membership.
 - No supplied log means warnings are **unknown**. No warning in a supplied scope does not prove correct mask persistence or pixel effects.
 - Input-file SHA-256 digests, manifest/index digests, export run ID and source size/date are retained with the normalized facts. Names and size/date are not source-pixel verification. No media is copied or reconstructed during import.