Skip to content

Try the VIPP Windows installer

Use this checklist when someone asks you to test the tagged VIPP 0.15.0a5 installer on Windows. You do not need Python knowledge. Check only what you actually tried; leave everything else as not run.

Use the exact tagged installer

Use this checklist only with the exact v0.15.0a5 GitHub asset and its checksum from the official release. Do not use an untagged build or a similarly named file from another site.

A display-independent production-backend install, repair, scientific smoke, and uninstall does not count as a pass for the downloaded installer's visible setup window or operator experience.

Start with the normal Windows installation instructions. If you have a suitable NVIDIA GPU and were asked to test acceleration, also use the Windows NVIDIA GPU instructions.

What to expect from unusual paths

Windows supplies canonical Local App Data through SHGetKnownFolderPath(FOLDERID_LocalAppData). Managed setup accepts only VIPP\environments\cpu or VIPP\environments\cuda13 beneath it; custom managed roots are rejected. The fixed CPU root supports spaces and non-ASCII characters. CUDA supports spaces but requires the complete canonical path to be ASCII. If it is not, one-click CUDA should be unavailable before download and setup should offer CPU.

Keep private information private

Do not post your Windows username, computer name, local paths, unpublished images, support reports, or screenshots publicly. Send the completed notes only to the person who invited you to test. Review the privacy-redacted Compute Doctor support report before sharing it.

Before installing

Record these facts without including your account or computer name:

  • Windows version:
  • Standard or administrator account:
  • Does the account path contain a space? yes / no / unsure
  • Does it contain a non-ASCII character? yes / no / unsure
  • GPU model, if testing CUDA:
  • Start time:

Download the installer and checksum file only from the official v0.15.0a5 entry on the VIPP releases page. The filename should be VIPP-Setup-0.15.0a5-Windows-x86_64-UNSIGNED.exe. In PowerShell, run:

Get-FileHash -Algorithm SHA256 `
  .\VIPP-Setup-0.15.0a5-Windows-x86_64-UNSIGNED.exe

Compare all 64 characters with the installer line in SHA256SUMS-Windows-0.15.0a5.txt. Stop and delete the file if they differ. This alpha is intentionally unsigned, so Unknown publisher is expected; an antivirus threat warning is not expected and must not be bypassed.

The short test

  • The installer opened and its recommended choice made sense without needing to understand Python or CUDA packages.
  • Installation finished and created the expected VIPP shortcut or shortcuts.
  • VIPP or VIPP Automatic opened successfully.
  • I detached the VIPP window and could maximize or resize it in both width and height; reattaching it restored napari's dock behavior.
  • I opened a bundled example, calculated it, and saw a sensible result.
  • I saved the workflow, closed it, reopened it, and calculated it again.
  • I ran a small batch and could find its outputs.
  • Compute Doctor showed short, understandable results and one next action.
  • I could tell whether the calculation actually used CPU or GPU.

What was confusing or did not work:

Capacity and activity check

  • CPU review showed approximately 250 MiB download, 1.5 GiB installed, and 2.5 GiB peak working space.
  • CUDA review showed approximately 1.5 GiB download, 5 GiB installed, and 7 GiB peak working space.
  • The review presented those estimates separately from the enforced minimums: CPU 5 GiB on the installation drive and 1 GiB on temp/records drives; CUDA 15 GiB and 5 GiB respectively.
  • CUDA-ready wording described at least 15 GiB of free disk space on the installation drive and did not compare this value with VRAM.
  • Setup named its current phase and showed elapsed time.
  • Work without a trustworthy total used an indeterminate activity bar; trustworthy byte totals, when available, produced determinate progress.
  • A quiet operation kept its latest concrete activity and later showed a still-working heartbeat without claiming success or failure.
  • Advanced details showed the exact setup-log path and Open setup log opened that file.

What was confusing or did not work:

Extra CUDA check

Complete this only if the installer offered the NVIDIA CUDA route.

  • The CUDA installation location exactly matched canonical Local App Data plus VIPP\environments\cuda13; spaces did not prevent setup.
  • Supplying any other managed root was rejected before resolution or download; setup did not expose a custom-location chooser.
  • If canonical Local App Data contained a non-ASCII character, one-click CUDA was unavailable and setup offered the fixed CPU route instead.
  • Selecting an expert existing CUDA environment remained a separate non-mutating review and never suggested moving, editing, or adopting it.
  • For an installer-owned CUDA copy under a non-ASCII root, setup separately reported any recovery from a prior interrupted transaction; after that recovery, the newly blocked selection performed no new mutation. Setup opened Installed apps for ownership-bound removal; it did not offer a second or custom managed CUDA copy or an in-place/fallback migration.
  • VIPP Automatic, VIPP CPU, and VIPP Prefer GPU all opened.
  • Compute Doctor separately showed CUDA and GPU and VIPP GPU coverage without asking for a second provider installation.
  • Rolling-Ball/Subtract Background and basic object measurements were available through the standard CuPy installation when their input and parameter gates passed.
  • At least one reviewed operation showed that it actually ran on GPU.
  • A CPU-selected or unsupported step explained its CPU fallback and still produced the expected result.
  • The same small workflow completed with Automatic and CPU-only shortcuts.
  • Portable GPU Segmentation Bridge completed in Prefer GPU and CPU, retained four final objects, and showed an explanation for any CPU step.
  • If a node showed a dtype-only GPU tip, Add conversion inserted one visible Convert Dtype node in the expected place and Undo removed it.
  • A relevant GPU tip remained visible after a Prefer GPU calculation.
  • Find fastest pipeline… kept grouped results readable and inspectable, including when it could not choose a winner.

What was confusing or did not work:

Repair, rollback, and removal

Only perform interruption or network-failure tests on a computer where the previous working installation and research data are safely preserved.

  • Rerunning the same installer offered a clear repair choice and the repaired installation still worked.
  • If updating, the previous working version remained usable until the new version passed its checks.
  • For an installer-owned CUDA copy already under a non-ASCII root, any prior-transaction recovery was recorded separately and the newly blocked selection caused no new mutation, with clear fixed-root/CPU guidance.
  • If setup was cancelled, it reached a clear end state and did not present a half-created installation as ready.
  • If the network failed, setup explained what to do and preserved the previous working installation.
  • Retrying after restoring the network completed successfully.
  • Uninstall removed VIPP-owned shortcuts and files without removing unrelated data or another separate CPU/CUDA VIPP installation.

What was confusing or did not work:

Final result

  • CPU fresh installation: pass / fail / not run
  • CUDA fresh installation: pass / fail / not run
  • Spaces path: pass / fail / not run
  • CPU non-ASCII path: pass / fail / not run
  • CUDA non-ASCII-path guidance: pass / fail / not run
  • Cancellation rollback: pass / fail / not run
  • Network-failure rollback: pass / fail / not run
  • Repair/update/uninstall: pass / fail / not run
  • Novice first workflow: pass / fail / not run
  • Finish time:
  • Overall: ready for my use / still has a problem
  • Most important remaining problem:

Automated tests, an older development installer, WSL, or a different VIPP version do not count as a pass for this downloaded 0.15.0a5 installer.