Guides

Setup and troubleshooting

Everything here describes what the current build actually does. If a step does not match what you see, that is worth a report.

Bench setup

1. Use the Next Vision test workstation: 64-bit Windows 10/11 with the existing, working Envi installation. Keep the slit lamp on the bench, without a patient.
2. Close the original camera application and the MVS client. Only one program can hold the camera.
3. Download the current build from Download, verify the SHA-256, extract the ZIP to a new folder and run Envi.Acquisition.exe. No installer, no administrator rights, no separate .NET installation.
4. Select Find cameras, choose the Envi by model/serial, then Connect. There is no simulator fallback in this build.

The x64 MVS runtime

Capture Studio is a 64-bit process and needs the x64 MvCameraControl.dll from the installed MVS runtime. The original application may be 32-bit, so the SDK usually installs both architectures.

• If the app reports the runtime is missing, open Device tools → Choose MVS runtime and pick the x64 DLL. A common location is C:\Program Files (x86)\Common Files\MVS\Runtime\Win64_x64\MvCameraControl.dll.
• Do not select the Win32_i86 DLL and do not copy DLLs from unknown sources. The app deliberately refuses unknown search paths.
• If the x64 runtime is not installed, obtain the official runtime through Next Vision/IT. This portal does not redistribute vendor software.
• The Envi environment check tool reports which runtime architectures are present without changing anything.

Capturing

• Choose OD or OS, then press Capture image or Space. The app saves the next camera frame, not a screenshot.
• F11 / Focus view expands the live image; Esc returns. Capture and eye selection stay available.
• Exposure and gain accept values within the camera-reported ranges. Applying a manual value disables that auto control for the connection. The app tries to restore starting values on a normal disconnect; after a crash or cable loss, confirm settings in the original app.
• Mirror affects the preview only. Saved frames are never mirrored.

Where files go

Default: %LOCALAPPDATA%\EnviAcquisition\

• Captures\<capture-id>\original.raw — exact bytes of the acquired SDK frame (source pixel format and bit depth). Not a standard photo file.
• Captures\<capture-id>\preview.png — full-resolution lossless BGR8 conversion.
• Captures\<capture-id>\capture.json — model/serial, laterality, dimensions, pixel type, frame number, timestamps and SHA-256 checksums.
• Telemetry\session-*.jsonl — local engineering events (see what the app sends), bounded to 1 MiB per session and 20 files.
• Outbox\ — reports and event batches waiting for delivery, with their status.
• last-session-diagnostics.json — the full local diagnostic snapshot written on close. It contains SDK paths, camera serials and raw controller samples; review it before sharing.

Shutter controller (read only)

Under Device tools, Find shutter controller lists HID input collections; Listen counts reports and candidate presses without sending any command and without saving images. Silence is inconclusive: the controller may need a vendor initialization that this build deliberately does not send.

Troubleshooting

“The x64 MVS runtime was not found”

See the runtime section. The app opens Device tools automatically so you can choose the DLL.

No cameras found

• Confirm the original application and MVS client are closed.
• For GigE cameras, check the link and that Windows Firewall allows the app on the camera’s network. The app does not change firewall rules.
• Run the environment check tool and attach its output to a web report.

Connected but “Waiting for camera frames…”

Note the counters in the status line (received, frame-number gaps, timeouts, packet loss) and report the problem from the app; those counters are included as aggregate numbers.

SmartScreen blocked the app

Expected for an unsigned build. See unsigned builds.

The app closed unexpectedly

Reopen it. The crash session’s engineering events were written locally and, if reporting is connected, are queued for delivery on next start. Then use Report a problem so the crash is linked to a receipt.

Reporting a problem

1. Sign in to this portal and open Support → Installations. Create an installation key for the workstation and copy it (it is shown once).
2. In the app, open Device tools → Reporting, paste the key and press Connect. The app checks the key with the server and shows the partner name it is linked to.
3. When something goes wrong, press Report a problem, describe what you were doing, and submit. The report is stored locally first and shows Queued, then Delivered · ENV-XXXXXX once the server acknowledges it, or Failed if delivery gave up. A failed report stays on disk and can be exported.
4. Track the report and its resolution under Support → My reports.

Without the app, file a report on the Support page and attach an explicitly chosen diagnostic export (Export diagnostics in the app). Attachments are private to your organization and the Envi team.

What the app sends, and what it never sends

Only when an installation key is connected, the app uploads an allowlisted engineering envelope: app version, a random installation ID, a random session ID, timestamps, operation names and outcomes (for example camera_connection · failed), exception type, HRESULT and a method-name stack, Windows/.NET version numbers, and aggregate counters (frames, gaps, timeouts, packet loss, captures).

The server rejects any field outside that list. The app never uploads images, raw frames, patient fields, screenshots, memory dumps, file paths, camera serials, workstation or user names, raw controller reports, exception message text, or the full diagnostic snapshot. The diagnostic export exists for you to review and attach deliberately.

Reporting can be disconnected at any time in Device tools; keys can be revoked in the portal. Local logging continues either way. Delivery never blocks acquisition or shutdown.

On start, the app also reads the public /feed/app.json pointer once to show an “update available” banner. That request carries no identifier. Updates are never installed automatically.

Unsigned builds and IT review

Current builds carry no Authenticode signature: no trusted code-signing certificate is available to this project yet. Windows SmartScreen will warn on first run. The right response is to verify the SHA-256 published on the download page against the file you downloaded and have IT approve the file; do not disable SmartScreen, Defender or execution policies for the machine. When a signing identity is established it will be recorded in the feed and on the download page, and older unsigned builds will remain labelled as such.