VIPP 0.13.0a1

Release: GitHub alpha pre-release and PyPI package

Maturity: Alpha pre-release

VIPP 0.13.0a1 is the first substantial GPU-acceleration alpha. It adds an evidence-gated CPU/CUDA execution architecture, makes the same compute request available to interactive workflows and durable automation, and records what actually ran. It also includes workflow tabs, new filtering, thresholding, and colocalization nodes, and a broad set of graph, display, microscope-metadata, optimizer, cache, memory, cancellation, and publication fixes.

This is a progress release, not a claim of complete GPU coverage. The portable baseline remains CPU execution on Windows, macOS, and Linux. A GPU implementation is considered only for its explicitly validated operation, dtype, parameter, shape, dependency, and environment region; other calls use a normal explained CPU decision, an amber fallback from a forced Custom choice, or a typed failure according to the exact rejection and policy.

Workflow schema is now 4

Schema 4 stores the authored compute mode and per-node preferences. A valid schema-3 workflow loads with an explicit CPU request so upgrading cannot silently move an older analysis to a GPU. Saving it in 0.13 writes schema 4. Schemas 1 and 2 remain rejected.

Batch configuration and manifest schemas are now version 3. A version-1 batch config loads with an explicit CPU request; a version-2 config keeps its saved compute request. Both older versions load without source-axis declarations and become version 3 only when reviewed and saved. Generated Python remains locked to the exact VIPP version that created it; regenerate and revalidate every export under 0.13.0a1.

Highlights

• Choose Auto, CPU, Prefer GPU, or Custom from the main toolbar. Auto is the learning default. Prefer GPU uses every reviewed scientifically eligible public GPU candidate regardless of speed. Custom exposes one CPU choice and one choice for each declared GPU library on an implemented node.
• Read compact CPU, CuPy, cuCIM, or amber CPU-fallback badges on calculated node cards, with details available for the actual implementation and reason.
• Benchmark one eligible node or ask VIPP to find a fastest measured whole- pipeline assignment. Results are review-first: the graph does not change until the proposed assignment is applied.
• Preserve the last coherent outputs and actual badges when entering Custom or when work is canceled. Failed/OOM runs never replace prior processing values with uncomputed or provenance-unknown data: verified sources may be accepted, and a cleanup-failed result may additionally retain completed nodes only with matching actual-implementation provenance. Every other retained result is visibly identified as previous/pending rather than relabeled as though the new policy produced it.
• Change compute mode or per-node backend only while idle. During calculation or benchmarking, explicitly cancel and wait for CPU/GPU cleanup first.
• Keep compatible arrays resident across GPU nodes while retaining private, transactional device values, memory admission, synchronized progress, cooperative cancellation, cleanup, and classified OOM behavior.
• Carry compute intent and exact actual-run provenance through Batch workspace, the saved batch runner, generated Python/CLI, and generated-CLI output publication.
• Review ordinary TIFF page meaning through a source-specific Image stack choice. A narrow automatic QYX -> ZYX suggestion replaces repeated technical errors when the graph proves that those pages must be depth slices.
• Work with several independent live workflows through movable tabs without replacing another graph or its caches, undo history, inspector state, or Batch workspace.
• Choose Low, Standard, High, or Very High thumbnail backing detail independently of exact Stack contrast scope; use exact integer Percentile histograms and native Min-max reductions with conservative adaptive CPU/CuPy routing, separate selected-node inspector status, truthful progress, cooperative cancellation, and visible presentation fallback.
• Use new Sigma Filter, ImageJ Auto Threshold (8-bit), Colocalization Scatter Plot, and Masked Colocalization Scatter Plot nodes.

GPU operation coverage in this alpha

The following operation regions have validated accelerator candidates in the 0.13.0a1 code base:

• rolling-ball background estimation and background subtraction;
• median filtering;
• 2D and 3D Gaussian blur;
• ordinary Richardson-Lucy deconvolution;
• Richardson-Lucy TV deconvolution;
• Canny edge detection;
• Otsu thresholding;
• Sigma Filter;
• connected-components labeling; and
• the basic schemas of object measurements with and without intensity.

Coverage is narrower than the corresponding CPU nodes. For example, a provider can be valid only for particular dtypes, dimensionalities, parameter values, or memory bounds. VIPP does not insert an unrequested dtype conversion merely to make a node eligible. In particular, some floating-point filtering and deconvolution workloads can benefit much more from a GPU than native uint16 workloads, but an explicit Convert Dtype node remains a scientific authoring decision—not an optimizer rewrite.

The standard gpu-cuda13 extra installs the pinned CuPy/CuPyX track. It does not distribute the separately reviewed cuCIM build, so Rolling-Ball/Subtract Background and the basic measurement candidates remain CPU after the ordinary public GPU install unless the user completes the pinned local-build route. See the Windows CUDA and cuCIM guide and the archived first-region summary for dtypes, dimensionalities, parameter profiles, and common CPU decisions.

The first public CUDA admission record is intentionally exact: native Windows, 64-bit CPython 3.12, NumPy 2.5.1, SciPy 1.18.0, scikit-image 0.26.0, CuPy/CuPyX 14.1.1, CUDA runtime API 13.2, CUDA driver API 13.3, and the recorded RTX 5090 device. Changed hardware, platform, Python ABI, driver, CUDA runtime, or scientific-stack versions are not silently generalized from that evidence. Native Linux and RTX 40-series Windows qualification remain pending; macOS has no CUDA provider and remains CPU-only while Apple-accelerator research is pending. A bounded M1 Max CPU smoke is recorded below; it does not admit an Apple GPU provider.

cuCIM-backed operation regions are also gated independently. VIPP distributes no cuCIM wheel. Windows users may instead build the exact cuCIM 26.6.0 tag/commit with the release's fixed recipe and install their private artifact through the manifest-verifying existing-environment helper. Each locally built wheel receives its own verified file digest, while policy pins the installed payload and source/recipe provenance. The build omits Clara whole-slide I/O. For 0.13.0a1 this private per-user rebuild is the settled distribution route; VIPP does not host or redistribute the wheel. See the Windows CUDA and cuCIM guide.

See installation for the base and optional CUDA commands, and validation status for the evidence boundary.

Compute policy and optimizer

Auto is the default for a new session. Without compatible history it uses reviewed safe GPU defaults wherever all current admission gates pass. Successful, fallback-free completed full-pipeline runs may append only their exact wall time and assignment to machine-local history. If compatible history is accelerated-only, the next global Auto run measures CPU once on the same execution surface. Once both observations exist, a later matching run uses acceleration only when it clears the reviewed 1.20x/20-ms benefit margin; otherwise it uses CPU. Interactive, batch, and registry-lifecycle timing surfaces are never mixed. Auto never silently benchmarks multiple implementations. Its optional CPU evidence run is preflighted against physical RAM and, on Windows, remaining system commit; unsafe evidence collection is skipped with an explanation while the reviewed safe assignment is retained. Prefer GPU provides global accelerator placement without a speed requirement, while Custom provider choices and Find fastest provide per-node control and measurement. Applying a proposal writes Custom per-node preferences. Setup diagnostics still offer a copyable installation command, and the base application does not import optional GPU packages merely to load a workflow.

Prefer GPU is an explicit global placement policy. It considers every reviewed public GPU provider, including public Custom candidates that Auto does not consider, and does not require the GPU to be faster than CPU. It bypasses only that performance gate: scientific parity, dtype, parameter, shape, dependency, environment, provider, and memory admission remain mandatory, and VIPP never inserts a cast or changes an authored parameter. When every eligible GPU has complete comparable timing evidence, the fastest GPU is selected; otherwise stable implementation-ID order makes the choice deterministic without claiming it is fastest.

Prefer GPU requires visible fallback. A node with no eligible reviewed GPU receives an explained ordinary CPU decision because the policy means GPU where possible and CPU elsewhere; strict Prefer-GPU requests are invalid. Saved per-node preferences remain dormant until Custom is restored. Node benchmarking and Find fastest remain Custom-only. Developer-hidden providers are excluded unless an advanced request explicitly enables experimental admission, which is not a public support claim.

CPU forces the reference CPU path. Custom exposes per-node authored choices and the whole-pipeline optimizer. A loaded exact implementation pin can remain visible for compatibility, but the normal UI uses concise CPU and library-level choices. A provider choice is declaration-based and can remain visible even when call-specific admission later falls back or fails.

The optimizer compares every scientifically eligible implementation for each unlocked node, reuses exact workload/environment benchmark records, and then validates a proposed whole-pipeline assignment. A long operation can remain inside one honest progress unit when the underlying CPU or GPU library exposes no safe sub-operation checkpoint. Reaching the time limit means the search ended before every planned comparison—not that the current assignment was proved optimal. Completed exact node results are retained for a retry, and no assignment changes until the user reviews and applies it.

After cancellation cleanup, Find fastest can privately establish a fresh baseline for the current graph instead of requiring a stale display to be published first. It may stop a cooperative CPU warm call once a sufficiently measured synchronized GPU incumbent is decisively faster. That outcome is reported as a censored lower bound (CPU > ...; stopped early), never as an exact reusable timing. Independent parity, graph-wide transfer modeling, and final paired end-to-end validation remain required for a changed modeled assignment. If the current assignment wins, its fresh baseline and conservative comparison evidence support retention without a redundant paired comparison against itself.

Durable batch, generated Python, CLI, and export

Interactive and durable surfaces now submit the same versioned compute request to the shared headless executor. They preserve:

• compute mode, per-node preferences, fallback policy, runtime/device choice, and accelerator-memory limits;
• the actual runtime, implementation library, stable implementation ID and version, parity policy, decision reason, environment fingerprint, benchmark digest, and memory estimate for each completed node;
• classified availability and eligibility fallbacks plus attempted device-OOM fallback records;
• operation-level progress on every execution surface, plus nested overall-item progress for collection batch runs; and
• cooperative cancellation, synchronization, cleanup, and publication status.

A version-3 batch manifest stores the configured and effective requests, the override status and fingerprints, raw and effective source axes, the applied axis declaration, and an execution document/digest for every calculated item. Published output records link to that exact item execution. The saved vipp_batch_pipeline.py runner accepts explicit compute overrides, prints both progress streams with --progress, and returns exit code 130 after cooperative cancellation.

Workflow schema 4, batch config schema 3, saved runners, and generated CLIs serialize Prefer GPU as prefer_gpu. Per-node preferences are preserved for a later return to Custom but do not affect Prefer-GPU planning. A CLI mode override to prefer_gpu supplies visible fallback when no fallback override is given; an explicit strict combination fails before execution or publication. Interactive, batch, and generated paths record the same effective request and exact actual implementation provenance.

Generated workflow programs expose a complete compute_request, progress callback, and cancellation token to Python callers. Their CLI accepts --compute-mode, --fallback-policy, repeatable --node-preference, --progress, and --provenance / --no-provenance. The CLI enables provenance by default; the Python save API writes it when the caller supplies the execution document. Failed or cancelled single-output runs attempt a failure sidecar. Generated output publication stages the complete requested output/sidecar set, rejects duplicate destinations, and commits with rollback for caught promotion failures. It returns 0 on success, 2 on setup/execution/publication failure, and 130 after cooperative cancellation. Exact source-byte reverification immediately before promotion remains a saved-batch guarantee. The generated local loader does hash before reading and verify again after materialization; arbitrary generated-Python array callers provide their own source identity and stability.

With visible fallback, one complete device segment can be retried on CPU after a classified, retryable OOM only after GPU synchronization and cleanup. Prefer GPU always uses this visible policy. Strict Custom intent returns the typed failure instead. Other device defects are never renamed as OOM or silently retried. A later batch item is planned independently; one fallback does not rewrite the saved request for the remaining collection.

If cleanup fails during interactive execution, node benchmarking, Find fastest, or a workspace batch, the VIPP process requests cancellation of other active compute and quarantines all further calculation, policy changes (including policy-changing undo/redo), benchmark/optimizer work, and new batch starts until restart. Newly measured optimizer records from an unsafe Find fastest analysis are rolled back; if record-level rollback fails, the full local timing store is poison-marked first and moved under its cross-process lock to an .unsafe-* quarantine filename instead. A later process resolves the marker or refuses the active store. This is distinct from ordinary visible fallback, which requires cleanup to have succeeded.

The generated batch_process() folder helper remains a convenience for one varying primary source. It content-hashes the local source before reading, verifies the identity after materialization, and privately stages and transactionally commits the requested output/sidecar set. It does not provide the saved runner's multi-source pairing, collision plan, final source recheck immediately before publication, checkpoints, manifest, or durable replay/resume guarantees. Use the saved batch runner for production collection processing.

Clear TIFF page interpretation for batches

Some ordinary TIFF files call their page dimension the generic Q without saying whether those pages are depth slices, time points, or something else. Each collection source in Batch workspace now has a plain-language Image stack choice. A new unsaved source begins at Automatic (recommended); Something else (advanced)... remains out of the way unless deliberately selected.

VIPP does not blindly rename Q as Z. Only when a representative reports exactly QYX and a workflow step explicitly requires ZYX does the workspace select Pages are depth slices (Z stack), retry the check, and show one short notice explaining the change. Choose Use the file's labels unchanged to opt out; that decision is respected for the source instead of suggesting Z again.

The resulting QYX -> ZYX declaration changes semantic labels in place. It does not transpose pixels and does not discover a missing Z spacing. Before a run creates its output folder, artifacts, or GPU context, a representative scientific preflight applies the declaration and checks the graph's axis contract. Every later item must still match the declaration when read.

Saving after the guarded suggestion resolves records the exact declaration in version-3 config. Saving a source for which Automatic needed no change records no declaration. Historic version-1 and version-2 configs also load without a declaration and are never automatically reinterpreted; review and save them as version 3 to record an intentional choice.

Workflow and interface changes

• Workflow tabs retain independent graphs, results, caches, histories, inspector state, paths, dirty baselines, and Batch workspaces. A batch remains attached to its originating tab and blocks only lifecycle actions that would invalidate that run.
• Leave batch mode discards retained representative source overrides and returns an idle workflow tab to ordinary single-image work.
• Image Source cards show their current sample, layer, file, or collection binding in an elided subtitle and full tooltip.
• Named output tunnels can be rerouted by dragging their source badge to a compatible output. The edit is validated, atomic, and undoable.
• The compute summary, severity-aware message strip, actionable full-width alerts, and node badges now form one execution-feedback system.
• Thumbnail detail now offers persistent Low (90 × 55), Standard (180 × 110), High (360 × 220), and Very High (720 × 440) backing images without changing card size, pipeline data, or cached exact Stack limits. High and Very High can improve HiDPI display, downsampling, or maximum graph zoom; they do not guarantee a larger on-screen card. Very High uses four times the backing pixels of High. Responsive Slice contrast uses the selected detail's spatial sample and may change slightly with resolution. Stack remains full-output and resolution-independent: uint8/uint16 Percentile uses an exact native-dtype histogram instead of sorting a float copy, while Min-max uses an exact native reduction.
• Presentation statistics have separate Auto/CPU/Prefer-GPU control and a compact selected-node Thumbnail contrast inspector row. Auto routes per result by full output dtype/bytes at conservative cold crossovers of 384 MiB for uint8 and 512 MiB for uint16, or 32 MiB once warm—not thumbnail resolution. These measured defaults are heuristics rather than universal fastest guarantees. Main CPU hard-forces presentation CPU; main Prefer GPU biases presentation Auto and is the explicit override; float and other-dtype percentiles retain exact NumPy-compatible CPU behavior.
• Full-output thumbnail statistics publish node/backend/phase progress through the shared toolbar and support cooperative cancellation. CPU integer work stops between bounded chunks; an active GPU kernel/synchronization or exact float/other-dtype NumPy percentile can contain a non-interruptible inner pass. Safe GPU failure is shown as CPU fallback, and failure of both paths as Error, in the selected node's compact Thumbnail contrast inspector row. Presentation decisions never overwrite the scientific CPU/CuPy/cuCIM badge or provenance, and graph cards no longer reserve space for presentation status.
• The pipeline optimizer reports overall and current-operation progress and explains time-limit exhaustion in terms of completed and remaining work.
• The active VIPP Inspect layer retains a compatible user's camera, slice, translation, rotation, zoom, and display styling across recalculation, so a tuned region does not jump back to a default view. Pinned layers remain separate viewer artifacts rather than saved per-output profiles.
• ND2 ordered-axis metadata now keeps napari/VIPP T, Z, and C navigation aligned with the loaded array.
• Crop Stack preserves image, mask, and label port types, including cropped ROI masks connected to masked analysis nodes.

Scientific-node changes

Sigma Filter is an edge-preserving Lee filter with an explicit, versioned CPU contract and a validated CuPy implementation for its admitted region. ImageJ Auto Threshold (8-bit) provides an experimental, source-aligned ImageJ 1.54p target for scalar uint8, uint16, and float32 conversion plus Default/Triangle behavior without changing VIPP's generic threshold nodes. Boolean and RGB/RGBA handling are VIPP extensions and are not claimed as ImageJ-exact. The two scatter-plot graph nodes make native-range colocalization density and threshold-guide images durable graph outputs.

The scatter inspector now reuses threshold-independent density while exact full-ROI counts are recomputed, moves guides immediately during threshold scrubbing, coalesces rapid requests, and links its colormap with a resizable PNG/TIFF pop-out. Interactive density is capped at 1,024 bins per axis; graph scatter nodes retain independently configured bins/output size up to 4,096, native populated ranges, optional symmetric percentile clipping, and memory-bounded masked accumulation. Inspect display profiles are remembered per node/output/RGB surface and saved independently from scientific parameters.

Colocalization calculations now retain finite native intensities rather than jointly rescaling/clipping both channels to 0–255. Thresholds and intensity sums therefore use native units. The implementation also revises automatic Costes threshold search, Pearson population names, and Manders definitions as a source-aligned compatibility implementation targeting Fiji Coloc 2 3.1.0. Canonical Pearson names now distinguish any-channel (OR) and both-channel populations. Fiji M1/M2 and thresholded tM1/tM2 are separate; legacy manders_m1/manders_m2 columns alias tM1/tM2 for compatibility. Independent numerical parity validation is pending. These changes can materially alter results from an older workflow even when its graph structure is unchanged.

Independent colocalization review remains required

The new colocalization and ImageJ-threshold paths have frozen automated regression fixtures, but not independently generated upstream golden fixtures. Treat these paths as experimental in 0.13.0a1, preserve prior results, and perform an external Fiji/reference comparison before using the revised values in a consequential analysis. The recorded fiji_coloc2_3.1 semantics value names the target contract, not parity certification; tables separately record coloc_validation_status=experimental_source_aligned_golden_parity_pending.

Release verification

The immutable v0.13.0a1 tag resolves to application commit 7520a5bb3ea9fe296bb231c63d1598b833ac10f6 on main. Its exact-source CI run passed package, manifest, lint, distribution-metadata, installed-wheel smoke, and CPython 3.12 and 3.13 tests on Windows, Linux, and macOS.

The exact source's complete native-Windows local suite completed with 4,077 passed, 2 skipped, 2 documented expected failures, 83 warnings, and zero failures. The skips are the opt-in real-CUDA tests and the expected failures are the documented CuPy integer-parity gaps.

The final tagged artifacts published through PyPI and attached to the GitHub pre-release are:

Artifact	SHA-256
napari_vipp-0.13.0a1-py3-none-any.whl	C157D2D0E5909A76A1A6093493AB17A245682DF53D83DD0A23FAA0FDF7A3BE02
napari_vipp-0.13.0a1.tar.gz	E3231CF22EA2907C3FE05F73477E5E3CD3B10FF2A053BBA92A8045D140E7F7E0

The bundled synthetic-volume example was also launched from a clean, non-editable, release-style Windows environment, and the operator explicitly accepted its appearance. A separate headless Prefer-GPU smoke selected cucim-subtract_background-v2 for Subtract Background without fallback, returned a (31, 37) native-uint16 result, and reported clean accelerator cleanup. These are bounded checks of one example and one declared cuCIM region, not broad manual GUI, reader, filesystem, hardware, or assay qualification.

The source-candidate CI distributions were qualification outputs, not the files published above. The final wheel and source distribution were built afresh from the immutable tagged source. Historical artifacts listed below must not be reused.

Historical pre-Prefer-GPU candidate verification

The earlier prepared application candidate was commit e02440989001f05ca17c845e3113ee2537a66c77. Its full local suite completed with 3,722 passed, 2 skipped, and 2 documented expected failures. Package/manifest, lint, and CPython 3.12/3.13 tests passed on Windows, Linux, and macOS in the candidate CI run. The wheel and source distribution passed Twine checks, clean CPU-wheel installation checks, and installed-wheel CUDA diagnostics/durable execution smokes within the stated native-Windows evidence boundary.

These results remain valid evidence for that exact source tree, but they do not qualify the eventual 0.13.0a1 tag: the later Prefer-GPU feature changed application source, compute serialization, planning, UI, and durable CLI behavior. The next automated checkpoint is recorded separately below and is itself now superseded by later hardening.

On 4 August 2026, the e024409 source candidate also received a bounded Apple M1 Max (arm64, macOS 26.5.2) CPU smoke. Manual checks covered launch and basic processing, collection-batch progress and cooperative cancellation, and memory presentation as one system-RAM budget without a fabricated separate VRAM total. Four focused tests covered the CPU-safe cancellation path, worker token and both progress channels, single-shot cancel UI, retained cancelled state, manifest, and cleanup evidence. Commit ff21040 is the follow-up operator record, not a raw log or an Apple-GPU/broad-macOS qualification artifact.

Also on 4 August 2026, the operator reported a bounded native-Windows napari UI smoke pass on the ff21040 development checkout. The local schema-4 Custom workflow loaded the representative private ND2 acquisition and exercised the intended channel, slice navigation and display behavior, and backend-badge presentation. The retained last-run JSON was later overwritten by an Auto run, so it does not independently preserve the exact mixed-backend assignment or cleanup result. This is operator-attested UI regression evidence only; it does not qualify Prefer GPU, a final wheel, durable replay, or broad Windows/GPU behavior.

The earlier locally verified artifacts were:

Artifact	SHA-256
napari_vipp-0.13.0a1-py3-none-any.whl	A05F2292B3C8E1FF37CF6009C5BA6100ECE92EA11E92423A72C20960B179F379
napari_vipp-0.13.0a1.tar.gz	FAEC77C0CD10E2B1F60AFA7C55CEC16139B89ADF42DCE626E76AFB9878A2D12C

These hashes identify files built from e024409; they are not valid artifacts for the later Prefer-GPU development tree and must not be uploaded for this release. Retain this historical table only as the bounded e024409 checkpoint.

Historical Prefer-GPU automated checkpoint (superseded)

Application commit 444f68290fe4359b05c68a027d3ae0a413412fe5 on codex/gpu-cross-platform-support was the next automated checkpoint after e024409. It is no longer the current release candidate: later compute-lifecycle, optimizer, source-loading, generated-CLI, and cleanup- quarantine hardening changed release-relevant application behavior.

The full local suite completed in 299.65 seconds with 3,754 passed, 2 skipped, 2 xfailed, 83 warnings, and zero failures. The skips are the opt-in real-CUDA durable batch smokes. The xfails are the documented CuPy uint8/uint16 integer-parity gaps; they are not unexpected regressions. Ruff, source-tree and installed-wheel npe2 manifest validation, package build, Twine checks, and the installed-wheel resource smoke all passed.

The checkpoint's real RTX 5090 Prefer-GPU integration test also passed. Without authored per-node choices, planning selected:

• CPU for Extract Channel;
• cuCIM GPU for Subtract Background;
• CPU for native-uint16 Gaussian Blur; and
• CuPyX GPU for Median Filter.

The complete result had exact parity, no fallback, and clean accelerator cleanup. This demonstrates the intended global placement rule: reviewed GPUs are used wherever scientifically eligible without casting the native-uint16 Gaussian call or treating its explained CPU decision as a failure.

Clean wheel and source-distribution artifacts built from that exact historical checkpoint commit are:

Artifact	SHA-256
napari_vipp-0.13.0a1-py3-none-any.whl	58b08cbb8396c9fe27d28a69d52b06e160817e58987e6dc3b8c5059f3dae9804
napari_vipp-0.13.0a1.tar.gz	00fcb15452d3ed71d344859d4306cbcdcc458686959169a2c47485d8f7abec9b

These files are superseded checkpoint artifacts, not release candidates or a published release. They must not be uploaded for 0.13.0a1. The selected release source is 7520a5b, and its final tagged artifacts and hashes are recorded in release verification. Only those final files belong on PyPI and the GitHub pre-release.

Refreshed RTX 5090 deconvolution screen

The bounded RTX 5090 refresh recorded these transfer-inclusive timings:

Operation and workload	CPU	GPU	Speedup
Richardson-Lucy, private real-acquisition ND2 volume	24.898 s	0.414 s	60.20x
Richardson-Lucy, medium synthetic volume	35.997 s	0.455 s	79.14x
Richardson-Lucy, large synthetic volume	137.820 s	1.517 s	90.87x
Richardson-Lucy TV, private real-acquisition ND2 volume	34.921 s	0.599 s	58.34x
Richardson-Lucy TV, medium synthetic volume	55.936 s	0.564 s	98.61x

Both RL-TV workloads reported parity and clean cleanup. These are bounded measurements from one RTX 5090 machine and these exact workloads—not portable speed promises, persistent Auto evidence, or a replacement for assay-specific validation.

Upgrade from 0.12.0a3

1. Preserve the 0.12.0a3 environment, original schema-3 workflow, generated Python, batch config/manifests/sidecars, inputs, outputs, and validation evidence.
2. Open a duplicate in 0.13.0a1. Confirm that it reports CPU compute intent, then inspect graph structure, source bindings, parameters, dynamic ports, axes, channels, physical grids, and output declarations.
3. Recalculate and compare decisive intermediates and final results. Cached arrays and tables are not serialized in workflow JSON.
4. Give special attention to colocalization thresholds/metrics, native-unit sums, cropped mask ports, ND2 axis ordering, and any operation for which a GPU preference is later enabled.
5. Save only after review; the duplicate becomes schema 4. Keep the original schema-3 file unchanged for provenance.
6. Recreate or load the Batch workspace. A version-1 batch config becomes an explicit CPU request and a version-2 config retains its saved compute request. Both lack source-axis declarations. Review Image stack for each collection source and save as version 3 before relying on a QYX -> ZYX interpretation or GPU execution.
7. Regenerate exported Python and the saved batch runner under 0.13.0a1. An old generated program refuses the new runtime by design.
8. Run a fresh batch preflight, exercise cancellation on non-critical data, and inspect configured/effective compute requests, node decisions, fallbacks, cleanup, output links, and final item statuses in the manifest.

See versions and compatibility, the workflow and export contract, and process a folder.

Alpha limitations

• GPU support is partial and environment-gated; timing evidence from one RTX 5090 is not a portable speed promise. Raw node benchmarks are never injected into Auto. Auto learns only from exact, compatible, fallback-free completed pipeline timings on this machine. Measured per-node assignments are Custom; Prefer GPU deliberately requests every eligible reviewed accelerator without requiring CPU-speed evidence.
• Label Connected Components acceleration requires a Boolean call resolved as 2D or 3D. Numeric and oversized 2D/3D calls retain CPU, while a Boolean call with another or unresolved spatial rank is a typed non-CPU preflight failure in this alpha; select CPU for that case.
• Native Linux GPU, RTX 40-series Windows, and Apple M1 Max acceleration remain future validation. Clara whole-slide I/O is outside the private Windows cuCIM build and no feature-complete cuCIM/Clara distribution is provided. The bounded M1 Max CPU launch/basic-processing, batch-cancellation, and memory- presentation smoke does not close those accelerator or broad-host gaps.
• The cuCIM provider is an optional pinned local build, not a distributed Windows dependency. Users who do not complete its manifest-verified setup intentionally leave the affected background and basic-measurement nodes on CPU.
• Batch pairing remains local-file, sorted-position pairing. VIPP does not yet iterate semantic T/C/Z combinations or discover plate/well/field HCS layouts.
• Item checkpoints are a recovery trail, not automatic resume. Artifact atomicity is per file; a multi-output promotion failure can create an explicitly recorded partial item.
• A monolithic library call or writer can delay progress and cancellation until its next truthful checkpoint. VIPP does not invent percentages inside calls it cannot observe.
• Generated Python requires the exact creating VIPP version, and the simple generated folder loop is not the durable batch runner.
• Broad reader interoperability, real-assay restoration, colocalization equivalence, large-collection stress, and cross-platform manual GUI evidence remain bounded despite the focused Windows and M1 Max CPU passes described in validation status.

VIPP remains alpha software. Record the application version, workflow, compute request, actual implementation provenance, environment, inputs, batch configuration, manifests, fallbacks, and validation evidence for consequential work.