Skip to content

Expose native orthogonal XY/XZ/YZ review through the managed viewer MCP commands #152

Closed

Description

@trissim

Observed gap

The managed Napari viewer's current exposed command/MCP family provides routed
navigation, camera and layer visibility, but no orthogonal display-axis control.
For a native ZYX volume, agents cannot inspect XY/XZ/YZ source-plus-result views
through the public surface. A Z slider is not orthogonal inspection, and
projection or viewer-console/X11 input is not an acceptable substitute.

Required implementation

Extend the existing declaration-owned viewer command/DTO/service family with
native display-axis selection and reflected current orientation. Derive MCP
exposure through the same owning declaration mechanism. Use the real route's
semantic axes, component domains and native transforms; reject illegal or
non-spatial display combinations at the typed boundary.

Support matched raw-only, result-only and raw-plus-label/point views while
preserving source coordinates, numeric intensity mapping and result identity.
State/capture evidence must report orientation plus current canvas/camera so
agents can detect user changes. Do not synthesize scientific slices, fabricate
annotations, add a parallel viewer controller or mutate array data.

Acceptance evidence

  • Synthetic non-cubic ZYX values verify XY/XZ/YZ plane correspondence and
    raw/result/point alignment, including nontrivial native transforms.
  • Invalid semantic axes fail before viewer mutation; out-of-domain cases have
    explicit structured errors.
  • Existing route navigation/visibility/camera and schema reflection still work.
  • Unit/native contract tests plus a fresh-process isolated/offscreen viewer/MCP
    roundtrip, with bounded RAM and no interaction with the user's desktop.
  • Ownership/proof/test limits documented, implementation in an immediately
    discoverable draft PR. Existing scientific runs and frozen outputs preserved.

No runtime implementation or accuracy improvement is claimed by this issue.

Activity

  1. trissim commented on Sep 29, 2026

    @trissim
    CollaboratorAuthor

    Implementation tracked in draft PR #154. Jason owns the isolated viewer command/DTO/state surface; result-directory reopening is tracked separately in #134 / PR #153. Runtime implementation, alignment/validation regressions and fresh-process verification are still pending.

  2. trissim commented on Sep 29, 2026

    @trissim
    CollaboratorAuthor

    User requested a rigorously typed, MCP-supported Napari plugin approach, including correct behavior with multiple nonspatial axes.

    Primary-source investigation distinguishes two contracts:

    OpenHCS already packages an npe2 manifest (openhcs:napari.yaml); reuse/extend this entrypoint rather than introduce another package, MCP server, state registry, or control implementation. Jason has the scope extension: plugin UI and generated MCP must use the SAME typed semantic-axis command/state owners.

    Required regressions include channel/time/site/well selectors (Z not necessarily third-last), singleton and non-singleton component dimensions, anisotropic scale/offset transforms, Points/dense Labels alignment, and truthful limitations for per-Z planar Shapes. Bound memory and preserve frozen data/live viewer ownership.

    PR #154 is still a draft tracking checkpoint, not an implemented fix. Sequential XY/XZ/YZ review and linked simultaneous views must be reported separately.

  3. trissim commented on Sep 29, 2026

    @trissim
    CollaboratorAuthor

    PR #154 investigation checkpoint: native sequential display selection passed a CPU-only Napari 0.6.1 7D ViewerModel diagnostic with site/channel/z_index/timepoint/well/y/x axes, Z at axis 2, singleton/non-singleton leading components, anisotropic scale and translations. Six plane cases, 94 image/dense-Labels pixel pairs and six transformed-Points identity checks passed (5.47s wall, 453 MiB peak RSS). This is feasibility evidence, not managed viewer/MCP/plugin or rendered-capture acceptance.

    Precise plugin distinction: napari-orthogonal-views handles >3 dims, preserving the prefix of CURRENT dims.order and rotating its final three entries; an order ending well/y/x does not identify spatial Z/Y/X. It does not universally fail on extra axes. OpenHCS already bundles openhcs:napari.yaml via npe2; proposed typed sequential controls will share the existing command/state/MCP owners, without a second controller or copied arrays. Linked simultaneous panels are separate work.

    Complete NRA/R1 coverage remains a pre-edit blocker: default-deadline and RSS-limited failures are retained. Main assigned Mencius the next exclusive, bounded global scan; no competing scan is running here. Same-context results require source/dependency identity checks before use, and own revision-checked apply/native proof remains necessary. No Python implementation edits yet. Draft and issue remain open. Receipt: https://github.com/OpenHCSDev/openhcs/blob/feat/mcp-orthogonal-viewer-20260929/paper/plans/orthogonal_viewer_receipt_20260929.md . Existing scientific viewer, inputs/results and installed dependencies were not changed.

  4. trissim commented on Sep 29, 2026

    @trissim
    CollaboratorAuthor

    Additional native regression required for PR #154: result selection currently
    derives hidden dimensions from coordinate_width - ndisplay, not the actual
    displayed axes.

    Verified at 35a0b1a4ffb21e17385d1c8808113be0108c4d44:
    runtime/viewer_controls.py:55-106,
    ViewerResultElementCoordinateAuthority.axis_indices, and its caller
    runtime/napari_viewer_server.py:4994-5018.

    Tiny native source-import counterexample, axes (channel, z_index, y, x) and
    point (1, 2, 4, 7): the authority always returns
    {channel: 1, z_index: 2} for two displayed axes. That is correct for XY, but
    XZ needs {channel: 1, y: 4} and YZ needs {channel: 1, x: 7}. A fractional
    Z coordinate is also rejected even when Z would be displayed rather than used
    as an integral hidden selector. These are counterexamples against the pure
    coordinate authority, not an implemented orientation or live viewer test.
    Runtime 0.36 seconds; peak RSS 29,600 KiB; no images or scientific jobs used.

    The same typed semantic-axis/presentation owner must govern display selection
    and result navigation. Preserve existing XY behavior; derive hidden dimensions
    from actual native state, respecting route-local/global transforms. Test Points
    and supported representations without claiming that per-Z planar Shapes provide
    volumetric cross-sections. No second axis map or caller-side dispatch table.

    Production edits remain gated on the complete NRA/R1 audit. The unused 2 GiB
    FULL attempt's prelaunch check was held at 10.81 GiB available versus the 11 GiB
    start gate; no scanner started. Existing incomplete scan evidence remains
    incomplete, not a passed audit. PR #154 remains draft.

  5. trissim commented on Sep 29, 2026

    @trissim
    CollaboratorAuthor

    Checkpoint published in draft PR #154 at 4bcce914f2bf8be14e4f5be39c5b0f406a6f4d6b: standalone supported-Napari 0.9.1 diagnostic passes unchanged 7D six-plane/94 raw-Labels pairs/6 Points assertions. Original monitor's 1776 KiB child undercoverage is explicit; descendant accounting was then verified with an owned 32 MiB child before final repeat (5.14s, native peak 161388 KiB, sampled aggregate including monitor 186116 KiB). Existing wrong-hidden-axis result-selection counterexample is recorded as an acceptance obligation. No production changes or GUI/MCP/plugin acceptance; complete NRA/R1 gate remains pending. Owned diagnostics are terminal; PR stays draft and this issue remains open.

  6. trissim commented on Sep 29, 2026

    @trissim
    CollaboratorAuthor

    Integration owner: blind-analysis coordinator, continuing the original PR #154 after diagnostic handles were not_found. Sequential semantic XY/XZ/YZ navigation, generated MCP exposure, native dimensional/canvas readback and bundled managed-viewer widget are implemented. 75 source/native/widget tests, 75 installed tests and 30 source viewer-service tests pass on supported Napari 0.9.1. Real installed public MCP streamed 18 synthetic TIFF planes into a 7-D route on isolated :90/5692; three personally inspected XY/XZ/YZ captures show populated/enabled plugin controls and the expected raw slices/channel. Nonspatial channel/X plus hide/deselect/index changes rejects without any native view mutation. The live late-mount dropdown defect was found, reproduced and fixed via native events, not polling. Existing H002 UI/viewer and frozen files are preserved. Scope is sequential planes; no simultaneous linked canvases or volumetric interpretation of planar Shapes. Native tests cover anisotropic dense Labels/Points, but their full source-bearing archive/result-review MCP journey and the frozen legacy artifact route remain unverified. Keeping this issue OPEN for that remaining contract, owned by this coordinator; not claiming biological acceptance or full NRA/R1/equivalence. Durable receipts: /home/ts/wt/openhcs-live-point-evidence-20260929/orthogonal-review-20260929.

  7. trissim commented on Oct 2, 2026

    @trissim
    CollaboratorAuthor

    New continuous-journey witness, not a duplicate implementation: a current installed PURE_3D typed point-measurement execution persisted its CSV/native PointROI archive but its automatic Points route failed settlement in NapariPointsLayerDisplayHandler.geometric_component_values with "Fractional-Z point ROI requires a projected z_index axis." Reopening the source-bearing archive subsequently mounted Points; the earlier failed execution remains preserved. This does not establish biological acceptance or successful automatic projection. The blind-analysis coordinator has assigned Planck to the disjoint producer-to-live-projection ownership diagnosis, using a synthetic contract, existing checkout and NRA/refactor-audit before edits. Current #394/#468/#404 changed-file checks show no competing napari_viewer_server implementation. No live author correction, restart, fourth display or in-flight installation change. Any fix must keep invalid-projection rejection, derive the full source Z domain from its original owner, and pass the actual installed source-bearing Points/raw XY-XZ-YZ journey on a reused terminal slot before closure; #134 publication ownership remains separate.

  8. trissim commented on Oct 6, 2026

    @trissim
    CollaboratorAuthor

    Closing against current main and the later source/acceptance history. Native navigation derives display order from the mounted semantic route presentation, validates the complete visible layer graph before mutation, and rejects invalid or incompatible axes. Later PR748 completes automatic and saved source-bearing scalar/point geometry; current main retains that implementation. The installed public journey reopened scalar labels and fractional Points with source calibration/transforms intact and exercised XY/XZ/YZ raw-plus-result views. Evidence and the original acceptance paths are in docs/validation/automatic-point-domain-152-20261005.rst (Completed installed and public delivery), including PLANCK-PUBLIC-ACCEPTANCE16.rst. The actual qualified native stack was Napari 0.6.1; this is not a claim about every newer Napari release. Planar Shapes correctly refuse unsupported volumetric cross-sections rather than fabricate slices. Simultaneous linked canvases and separate triangulation defects are distinct requirements, not the originally missing public orthogonal command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions