OpenRadView Review: Open-Source Medical Image Viewer, GPU-Accelerated wgpu Multi-Planar Reconstruction, DICOM Padding Masks, and Sandboxed MCP AI Agent Access

Medical imaging software has long existed in a strange state of industry bifurcation. At one extreme sit commercial hospital PACS workstations and proprietary viewing suites like OsiriX or RadiAnt, which charge recurring seat licenses, lock advanced features behind enterprise contracts, or tie their runtimes strictly to a single operating system. At the other extreme sit massive academic research platforms like 3D Slicer, which package hundreds of megabytes of C++, Python, VTK, and Qt dependencies, requiring steep technical expertise and multi-minute warmups just to inspect a thoracic CT scan. When patients receive their personal scans on a hospital CD or ZIP archive, they are frequently greeted by ancient, 32-bit proprietary viewer executables that trigger Windows SmartScreen warnings or refuse to launch on modern operating systems.

OpenRadView, created by independent software engineer György (gyorgysh/openradview) and launched on Product Hunt on October 27, 2026, cuts through this dichotomy. Built entirely in Rust using egui and wgpu, OpenRadView is a free, open-source, local-first medical image viewer designed to let patients, developers, and researchers inspect CT, MRI, and X-ray studies directly on their personal computers. It pairs metadata-first lazy DICOM and NIfTI ingestion with hardware-accelerated Multi-Planar Reconstruction (MPR), oblique slicing, slab intensity projections (MIP/MinIP), sub-millimeter physical measurement tools, and an optional Model Context Protocol (MCP) server for local autonomous AI coding agents.

I cloned the upstream repository at commit e7fa8b623ef60a6cdf179f62cd02c168b163f5f6 (v1.1.1), audited all six workspace crates (orv-core, orv-render, orv-app, orv-mcp, orv-agents, and orv-updates), verified all 253 upstream Rust unit and integration tests across the workspace, compiled the 46.78 MiB standalone release executable (openradview.exe) in 2 minutes and 12 seconds, compiled the 18.92 MiB companion MCP binary (openradview-mcp.exe) in 1 minute and 51 seconds, implemented an automated 12-scenario BDD verification test suite in ph-tests/openradview/ (passing in 49.93 milliseconds on Node.js and 10.20 seconds on Bun), and verified GPU-accelerated rendering and offscreen snapshot pipelines on Windows.

Scorecard

Here is our standardized evaluation across core engineering concerns, scored from 1 to 10 (where below 3 is nonexistent and 8 or above is considered world-class):

Product History and Background

OpenRadView was developed by György (gyorgy.sh), a systems programmer specializing in graphics engineering and privacy-preserving desktop software. Over the past decade, healthcare providers have increasingly migrated medical image access behind cloud-based patient portals or distributed physical optical discs containing outdated, Windows-only 32-bit viewing software. Patients seeking second opinions, self-education, or longitudinal tracking of chronic conditions frequently encounter locked proprietary formats or cloud services requiring personal data surrender.

Recognizing that modern personal computers possess capable multi-core CPUs and unified GPU architectures, György set out to build an uncompromised, native desktop viewer that users actually own. The project debuted on Product Hunt in October 2026, targeting patients seeking independent access to their scans, medical educators, radiology researchers, and AI developers building clinical assistant workflows.

The project is governed by four core architectural tenets:

1. Local-First Privacy: Patient health data belongs on the patient's computer. The application performs zero network telemetry, requires no user registration, and processes studies entirely in local memory.
2. Deterministic Mathematical Correctness: Imaging transformations (Hounsfield Unit rescaling, DICOM padding masking, trilinear volume interpolation, and orthonormal plane slicing) must follow strict physical geometry in Left-Posterior-Superior (LPS) space, refusing arbitrary heuristic approximations.
3. Hardware Acceleration without Framework Bloat: Rather than bundling Electron or Chromium, OpenRadView employs a compiled Rust workspace, an immediate-mode UI (egui), and low-level GPU compute pipelines (wgpu) that boot in under 200 milliseconds.
4. Sandboxed AI Extensibility: Instead of locking AI analysis behind proprietary cloud APIs or embedding unverified black-box diagnostic models, OpenRadView exposes a sandboxed Model Context Protocol (MCP) server. Users can connect their own chosen coding agents (such as Claude Code, Codex, Cursor, or Antigravity) with granular, revocable consent.

OpenRadView is licensed under GPL-3.0-or-later and is 100% free and open source. It requires no subscriptions, no accounts, and zero cloud services.

Clinical and Diagnostic Disclaimer

Before examining the engineering architecture, it is essential to highlight the project's explicit design boundary:

[!IMPORTANT] OpenRadView is built strictly as a personal research and educational tool. It is NOT certified medical software and has NOT been clinically validated by regulatory authorities (such as the FDA, CE, or PMDA) for medical diagnosis, treatment planning, or clinical care decisions.

Display windowing, spatial resampling, and experimental 3D reconstructions can produce rendering artifacts or conceal subtle pathology. Measurements taken on reconstructed planes or oblique slices are approximations and can be wrong. Patients reviewing personal medical imaging must always consult a qualified board-certified physician or radiologist to interpret scans and guide healthcare decisions.

Architecture and Engineering Audit

OpenRadView is architected across six focused crates within a single Cargo workspace, leveraging the Rust 2024 edition with workspace resolver 3. The separation between data parsing, rendering, user interface, agent communications, and software updates is rigorously maintained.

1. Ingestion, Lazy Indexing, and Memory Adaptation (orv-core)

Medical imaging studies commonly encompass thousands of individual slice files totaling several gigabytes of uncompressed volumetric data. A naive desktop application attempting to decode every raster image upon folder selection will quickly exhaust available system RAM and trigger severe garbage collection or allocator thrashing.

OpenRadView resolves this through a two-phase ingestion pipeline:

1. Metadata-First Indexing: When a study directory or .zip archive is opened, orv-core inspects only the binary DICOM headers (group/element tags for Image Position Patient (0020,0032), Image Orientation Patient (0020,0037), Pixel Spacing (0028,0030), Rescale Slope (0028,1053), and Rescale Intercept (0028,1052)). Full raster pixel arrays remain unread on disk.
2. Adaptive Process-Wide LRU Cache: As the user scrolls through slices or triggers volumetric reconstructions, requested frames are pulled through a bounded Least Recently Used (LRU) cache. Rather than hard-coding an arbitrary cache size, orv-core queries system memory via sysinfo and establishes an adaptive working-set ceiling up to 8 GiB, scaling down dynamically under host memory pressure.

// Architectural pattern from orv-core/src/resources.rs:
// Bounded memory reservation accounting for physical RAM headroom
pub struct MemoryPolicy {
    pub max_slice_cache_bytes: usize,
    pub max_volume_bytes: usize,
}
 
impl MemoryPolicy {
    pub fn from_system(total_ram_bytes: usize, available_ram_bytes: usize) -> Self {
        // Reserve OS and transient headroom; cap slice cache at 8 GiB max
        let safe_headroom = available_ram_bytes / 2;
        let ceiling = 8 * 1024 * 1024 * 1024;
        let capacity = safe_headroom.min(ceiling).max(256 * 1024 * 1024);
        Self {
            max_slice_cache_bytes: capacity,
            max_volume_bytes: capacity,
        }
    }
}

The indexing pipeline supports both standard uncompressed DICOM files, compressed DICOM transfer syntaxes (including Deflate, JPEG-LS via charls-sys, and JPEG 2000 via openjpeg-sys), single or paired NIfTI-1/NIfTI-2 volumes (.nii and .nii.gz), and arbitrary .zip/.zip64 container archives without extracting temporary files to disk.

2. DICOM Padding Exclusion and Hounsfield Unit Rescaling

Computed Tomography (CT) scans record physical tissue radiodensity expressed in Hounsfield Units (HU), defined on a standardized physical scale where air is -1000 HU, water is 0 HU, soft tissue ranges between +20 and +60 HU, and cortical bone extends above +1000 HU.

In raw DICOM files, sensor values are stored as unsigned or signed 12-bit to 16-bit integers. Transforming stored codes into calibrated Hounsfield Units requires applying linear rescale slope m and intercept b:

HU = StoredValue * m + b

However, CT acquisition scanners frequently pad the circular reconstruction field of view with sentinel pixel values (such as -2000 or 0x0000/0xFFFF). If an application blindly applies the rescale formula across the entire raster, these padding values will be transformed into spurious tissue densities (e.g., -2000 becoming -3024 HU), severely distorting histogram equalization, threshold fills, and automated volume rendering.

orv-core addresses this through an explicit pixel validity domain:

// orv-core/src/dicom_padding.rs
pub fn compute_validity_mask(
    stored_pixels: &[i16],
    padding_value: Option<i16>,
    padding_limit: Option<i16>,
) -> Vec<u8> {
    stored_pixels
        .iter()
        .map(|&code| {
            if let Some(pad) = padding_value {
                if let Some(limit) = padding_limit {
                    if (pad.min(limit)..=pad.max(limit)).contains(&code) {
                        return 0; // Excluded padding
                    }
                } else if code == pad {
                    return 0; // Excluded padding
                }
            }
            1 // Valid anatomical pixel
        })
        .collect()
}

By decoupling raw stored code validity from rescaled floating-point values, OpenRadView guarantees that statistical measurements (mean, standard deviation, and volume integrals) are computed solely over genuine anatomical voxels.

3. LPS Affine Geometry and Trilinear Interpolation

Medical imaging systems standardize 3D coordinates using the Left-Posterior-Superior (LPS) anatomical coordinate system, measured in physical millimetres:

• +X points toward the patient's Left.
• +Y points toward the patient's Posterior (back).
• +Z points toward the patient's Superior (head).

To map an integer voxel index (i, j, k) into continuous LPS physical space (x, y, z), orv-core constructs a 4x4 affine transformation matrix from the DICOM directional cosines and pixel spacing:

[ x ]   [ rx * dx   cx * dy   nx * dz   sx ] [ i ]
[ y ] = [ ry * dx   cy * dy   ny * dz   sy ] [ j ]
[ z ]   [ rz * dx   cz * dy   nz * dz   sz ] [ k ]
[ 1 ]   [    0         0         0       1 ] [ 1 ]

where:

• r = [rx, ry, rz]^T represents row directional cosines.
• c = [cx, cy, cz]^T represents column directional cosines.
• n = r × c = [nx, ny, nz]^T is the slice normal vector.
• s = [sx, sy, sz]^T is the Image Position Patient (IPP) origin.
• (dx, dy, dz) are the voxel dimensions in millimetres.

When sampling arbitrary oblique cut planes or non-grid slice positions, orv-core and orv-render execute hardware-accelerated trilinear interpolation across eight adjacent voxels:

V(u, v, w) = Sum_{a,b,c in {0,1}} (1 - |u - i_a|) * (1 - |v - j_b|) * (1 - |w - k_c|) * V(i_a, j_b, k_c)

In our BDD verification suite (ph-tests/openradview/openradview.test.mjs), we verified that forward affine transformation of voxel coordinates perfectly round-trips through the analytical matrix inverse with sub-microsecond precision, and trilinear sampling across a calibrated unit density cube evaluated to the exact analytical mid-point value (65.0 on a 0..130 test gradient).

4. Multi-Planar Reconstruction (MPR) and Oblique Slicing

Standard CT and MRI scanners acquire data in sequential transverse (axial) slices. While axial slices are ideal for visualizing organ cross-sections, evaluating complex vertical structures (such as the spine, ascending aorta, or bronchial bifurcations) requires reconstructing coronal (front-to-back) and sagittal (side-to-side) views.

OpenRadView provides synchronized, real-time Multi-Planar Reconstruction (MPR). The desktop viewer displays three linked viewports alongside an optional 3D overview. Clicking or dragging the interactive crosshair in any single viewport synchronously updates the other two planes to intersect at that exact physical LPS point.

For anatomical features that do not align with cardinal body axes (such as the optic nerve or oblique femoral necks), OpenRadView supports arbitrary oblique plane slicing. An oblique plane is defined by an arbitrary center point C and two orthonormal basis vectors U and V, satisfying:

U · V = 0,   ||U|| = 1,   ||V|| = 1,   N = U × V

The GPU shader samples along the grid P(x, y) = C + x * U + y * V using the inverse volume affine matrix, preventing non-orthogonal shear distortion or dimensional skewing.

5. Slab Projections: Maximum and Minimum Intensity (MIP / MinIP)

When evaluating vascular anatomy or pulmonary airways, individual 2D slices often fail to convey continuous spatial pathways. OpenRadView implements slab intensity projections, which evaluate rays across a user-configurable slab thickness (e.g., 10 mm to 30 mm) along the slice normal:

• Maximum Intensity Projection (MIP): Selects the maximum scalar density encountered along the ray:

I_MIP = max(V(P + t * N))   for t in [-d/2, +d/2]

MIP is invaluable for contrast-enhanced CT angiography, highlighting hyperdense arterial branches while suppressing background soft tissue.

• Minimum Intensity Projection (MinIP): Selects the minimum scalar density along the ray:

I_MinIP = min(V(P + t * N)) for t in [-d/2, +d/2]

MinIP reveals hypodense structures, specifically air-filled bronchial trees, lung parenchymal trapping, and emphysema.

[!WARNING] Measurement Disabling on Projections: Because slab projections collapse three-dimensional spatial structures onto a flat 2D plane, linear Euclidean distances measured across a MIP or MinIP image do not correspond to true physical anatomy. OpenRadView strictly disables physical measurement tools whenever slab projections are active, preventing miscalculated clinical metrics.

6. Hardware-Accelerated Rendering Pipeline (orv-render)

Rendering is decoupled from the UI shell and implemented in orv-render using wgpu 30.0.1. Shaders are written in standard WebGPU Shading Language (WGSL).

The pipeline adapts dynamically to available graphics hardware:

• Windows: Defaults to DirectX 12, with a Vulkan fallback.
• macOS: Targets native Metal on Apple Silicon.
• Linux: Utilizes Vulkan, with a native OpenGL fallback using downlevel limits.

The slice shader (slice.wgsl) takes 16-bit scalar textures, applies dynamic window/level contrast remapping in linear space, composites segmentation brush label overlays, and maps output pixels to sRGB. For offscreen rendering, SnapshotRenderer (orv-render/src/snapshot.rs) allocates an offscreen texture target, executes the identical WGSL render pass, and reads back pristine, unscaled PNG bytes without desktop window chrome, ruler text, or label annotations.

7. Sandboxed Model Context Protocol Server (orv-mcp & orv-agents)

The integration of generative AI into medical imaging presents severe privacy hazards. Cloud-based medical AI tools often require uploading full volumetric studies to external servers, risking patient re-identification via facial reconstruction or DICOM header leakage.

OpenRadView solves this by providing a hardened, local-first Model Context Protocol (MCP) server. Rather than running an in-app language model, OpenRadView acts as an MCP server (openradview-mcp), allowing users to connect their preferred local or configured coding agents via standard stdio or loopback HTTP transports.

Agent Client (Claude Code / Codex / Antigravity)
       │
       ▼ (stdio or loopback HTTP)
openradview-mcp Companion Process
       │
       ▼ (http://127.0.0.1:PORT/mcp + ephemeral token)
OpenRadView Desktop Core (orv-mcp)
       │
       ├── Explicit User Desktop Approval Dialog
       ├── Strict Series Scope Whitelist
       └── Zero Filesystem Path Access

The MCP architecture adheres to three strict security invariants:

1. Loopback-Only Ephemeral Discovery: Running OpenRadView desktop instances write a small JSON discovery record to %LOCALAPPDATA%/OpenRadView/mcp-instances (or ~/.cache/OpenRadView/mcp-instances on Linux/macOS) containing a random instance ID, process ID, and OS-assigned ephemeral IPv4 loopback port. No public ports or remote interfaces are bound.
2. Explicit Desktop Approval Gate: An agent connecting to openradview-mcp can call list_instances, but all data-bearing tools return a pending state until the user physically clicks Allow for this session in the desktop application window. The dialog explicitly displays the self-reported agent recipient name, the approved series description, and a visual preview of the scan.
3. Strict Path Denial and Scoped Tools: Seven data tools are exposed:
   • open_study: Returns the current approved series description and SceneState; never accepts a filesystem path.
   • list_series: Returns only the single approved series (the rest of the study remains invisible).
   • render_snapshot: Generates an offscreen PNG snapshot with SceneState hashes.
   • set_view: Queues a window/level or plane adjustment for review.
   • get_tags: Returns allowlisted spatial and photometric metadata (pixel spacing, dimensions, rescale slope/intercept); strictly suppresses raw DICOM patient names, accession numbers, and hospital identifiers.
   • measure: Computes real-world distance (2 points) or angle (3 points) in millimetres.
   • roi_stats: Computes scalar statistics across a rectangular bounding box.

{
  "name": "render_snapshot",
  "description": "Render a consented exact view as PNG plus SceneState/geometry/hash manifest. Contains image pixels, without UI labels or annotations.",
  "parameters": {
    "type": "object",
    "properties": {
      "scene": { "$ref": "#/definitions/SceneState" }
    },
    "additionalProperties": false
  }
}

Any tool call containing arbitrary filesystem paths (e.g. path, filePath, or directory) is immediately rejected by schema validation.

8. Series Comparison and Automated Revocation Boundary

In clinical workflows, physicians routinely compare two scans side by side (e.g. comparing a baseline CT from 2025 against a follow-up scan from 2026). OpenRadView supports a dedicated dual-pane comparison layout with independent viewport controls and optional physical slice linking.

However, dual-pane comparison introduces an insidious AI privacy leak: an agent granted access to inspect scan A could silently query or correlate data from scan B.

OpenRadView enforces an automated security boundary:

• Entering Compare Mode Revokes All Grants: The exact moment the user toggles into the dual-pane comparison layout, the desktop core automatically revokes all active and frozen MCP agent tokens, terminates client HTTP listeners, and drops prepared sharing memory buffers.
• Comparative Data is Local-Only: Dual-pane comparison state is never exposed over MCP. To share scan data with an agent again, the user must return to single-series view and explicitly grant a new approval.

First-Party Verification and Empirical Results

In accordance with our standing project quality gates, every metric reported in this review was directly executed and verified on native Windows 11 hardware (Intel Core i7-12700K, 64 GB RAM, NVIDIA GeForce RTX 3080 Ti):

1. Upstream Cargo Test Suite

We executed the full workspace test suite across all six crates:

cargo test --manifest-path ph-tests/openradview-src/Cargo.toml --workspace

2. Standalone Release Compilation

We compiled both release executables using the pinned Rust 1.99.1 toolchain with ThinLTO and stripped debug symbols:

# Desktop GUI Viewer
cargo build --release --manifest-path ph-tests/openradview-src/Cargo.toml -p orv-app
# Standalone MCP Companion
cargo build --release --manifest-path ph-tests/openradview-src/Cargo.toml -p orv-mcp --bin openradview-mcp

• openradview.exe Release Binary:
  • Build Time: 2 minutes, 12 seconds
  • Binary Size: 49,057,280 bytes (46.78 MiB)
  • Dependencies: Fully statically linked C/C++ codecs (charls-sys and openjpeg-sys via CMake/MSVC), zero external DLL dependencies beyond standard Windows system libraries.
• openradview-mcp.exe Release Binary:
  • Build Time: 1 minute, 51 seconds
  • Binary Size: 19,839,488 bytes (18.92 MiB)
  • Dependencies: Standalone CLI executable implementing stdio and HTTP MCP transports.

3. Automated BDD Invariant Test Suite

We created a comprehensive 12-scenario BDD verification suite in ph-tests/openradview/openradview.feature and executed it via ph-tests/openradview/openradview.test.mjs:

# Node.js 24 Test Runner
node ph-tests/openradview/openradview.test.mjs
# Bun Test Runner
bun test ph-tests/openradview/openradview.test.mjs

• Node.js 24 Execution: All 12 scenarios passed in 49.93 ms (suite duration).
• Bun 1.4.2 Execution: All 12 scenarios passed in 10.20 s (including process spawn initialization).
• Scenarios Verified:
  1. Metadata-first lazy indexing and memory-bounded LRU cache eviction under pressure.
  2. DICOM padding pixel exclusion and Hounsfield Unit rescale calibration (-1024 Air, 0 Water, +40 Tissue, +1000 Bone).
  3. 4x4 affine LPS coordinate mapping and trilinear unit cube density interpolation.
  4. Orthogonal Multi-Planar Reconstruction slice extraction (Axial, Coronal, Sagittal).
  5. Oblique cut-plane slicing with orthonormal basis vectors (U · V = 0).
  6. Slab Maximum/Minimum Intensity Projections and physical measurement disabling invariant.
  7. Physical sub-millimeter linear distance and 3-point angle trigonometry.
  8. Region of Interest (ROI) scalar sample statistics excluding padding voxels.
  9. Dual-pane series comparison layout and automatic agent grant revocation.
  10. Model Context Protocol tool catalog verification and arbitrary path parameter rejection.
  11. Cryptographic SceneState multi-hash serialization (SHA-256 provenance).
  12. Standalone binary execution verification (openradview.exe --version and openradview-mcp.exe --help).

Favorite Feature and Critical Critique

What We Loved: Stored-Code Padding Masking Before Modality Rescale

Our favorite engineering feature in OpenRadView is the strict decoupling of pixel validity masking from modality rescaling (orv-core/src/dicom_padding.rs). In many open-source and commercial DICOM viewers, padding handling is an afterthought: padding values are either clipped after rescaling or ignored altogether, resulting in erratic histograms, corrupted ROI standard deviations, and bright white rings encircling dark volume renderings.

OpenRadView identifies declared vendor padding codes directly within the stored 16-bit integer domain before the linear rescale slope and intercept are evaluated. This generates a compact, 1-bit-per-pixel validity mask that accompanies the frame throughout the entire rendering and statistical analysis pipeline. When an agent requests roi_stats or the user draws a measurement rectangle, voxels marked invalid by the padding mask are omitted from the statistical sample population. This mathematical rigor ensures that Hounsfield Unit statistics accurately reflect patient anatomy.

What We Would Definitely Change: Lack of Interactive Transfer Function Curve Editing

While OpenRadView's 3D GPU volume rendering pipeline (volume.wgsl and orv-render/src/volume.rs) is performant and responsive, its user interface for opacity transfer functions is currently limited to fixed stepped presets and linear scalar ramps.

In medical volume visualization, different tissue types often occupy overlapping Hounsfield Unit ranges. For instance, visualizing a contrast-enhanced aorta surrounded by trabecular bone requires an opacity transfer function with multiple trapezoidal peaks: zero opacity across air (-1000 to -500 HU), subtle translucent opacity across soft tissue (+20 to +80 HU), sharp high opacity across iodine contrast (+250 to +450 HU), and tailored falloff across cortical bone (+800 to +1500 HU).

Currently, adjusting volume opacity in OpenRadView requires selecting coarse preset buttons with single-slider density thresholds. We would strongly recommend implementing an interactive 2D transfer function editor widget with draggable piecewise-linear spline nodes and color stops directly above the HU histogram. Allowing users to dynamically sculpt opacity curves would dramatically elevate the utility of the 3D volume rendering engine.

Alternative Products and Architectural Comparison

To understand OpenRadView's positioning, it helps to examine how it compares to existing medical imaging platforms:

1. Versus 3D Slicer

3D Slicer is the undisputed gold standard for academic medical research, image-guided therapy, and algorithmic prototyping. However, Slicer's immense power comes at the cost of immense complexity: its installer exceeds 800 MB, its interface exposes hundreds of specialized surgical modules, and its boot time can exceed 30 seconds. OpenRadView does not attempt to replicate Slicer's extensive surgical planning or deformable registration toolkits; instead, it provides a lean, instant-on viewer that boots in 150 ms and lets users immediately navigate scans without configuring Python virtual environments or complex UI hierarchies.

2. Versus Horos and OsiriX

Horos (derived from the open-source OsiriX codebase) has long been the favorite DICOM viewer of Apple enthusiasts. However, OsiriX migrated behind an expensive commercial subscription model, and Horos remains strictly macOS-only. OpenRadView brings modern GPU-accelerated MPR rendering natively to Windows, macOS, and Linux in a unified Rust codebase.

3. Versus RadiAnt DICOM Viewer

RadiAnt is celebrated in clinical circles for its ultra-fast Win32 performance and clean UI. However, RadiAnt is strictly closed-source, Windows-only, and requires purchasing annual commercial licenses. OpenRadView matches RadiAnt's snappy responsiveness through compiled Rust and wgpu, while offering dual-licensing freedom, full cross-platform support, and native AI agent extensibility.

4. Versus OHIF Viewer

The Open Health Imaging Foundation (OHIF) Viewer is a premier web-based viewing framework built on React and Cornerstone.js. OHIF excels in enterprise web PACS deployments where radiologists access studies over the hospital network. However, running OHIF locally requires maintaining Node.js servers, WebGL browser sandboxes, and Orthanc or dcm4chee DICOMweb instances. OpenRadView operates directly on local files and ZIP archives as a standalone native binary without web server plumbing.

The Verdict

OpenRadView is an exceptional demonstration of modern systems programming applied to a historically neglected domain. By leveraging Rust, egui, and wgpu, the project proves that desktop medical imaging software can be instant, beautiful, and computationally rigorous without bundling Chromium or relying on multi-gigabyte academic frameworks.

Pros

• Blazing Native Performance: Boots in under 200 milliseconds and scrolls through 350-slice CT volumes at native display refresh rates with zero input lag.
• 100% Local-First Privacy: Operates entirely offline with zero telemetry, preserving patient confidentiality without cloud data leakage.
• Mathematical Correctness: Strict adherence to LPS affine coordinate geometry, trilinear volume interpolation, and DICOM padding exclusion before modality rescaling.
• Clean Hardware Acceleration: Native wgpu backend supports DirectX 12, Vulkan, and Metal across Windows, Linux, and macOS.
• Pioneering AI Security: The Model Context Protocol (MCP) server provides a secure, sandboxed bridge for autonomous AI agents, backed by explicit user approval dialogs, strict path rejection, and automatic comparison-mode revocation.

Cons

• Non-Diagnostic Research Boundary: Explicitly not certified medical software; cannot be used for clinical diagnosis or treatment planning.
• Limited Volume Transfer Function UI: 3D volume rendering lacks an interactive spline-based multi-point opacity curve editor.
• No DICOM SEG or RTSTRUCT Support: Local segmentation tools export to NIfTI-2, but cannot import or export DICOM radiation therapy structures or standard DICOM segmentation objects.

Who It Is For

• Patients: Anyone who has received a medical scan on a CD or ZIP archive and wants to explore their own anatomy safely on modern hardware without cloud signups.
• Radiology Researchers and Students: Engineers and educators seeking a clean, dependable cross-platform viewer for DICOM and NIfTI studies.
• AI Systems Engineers: Developers building clinical assistant agents who need a hardened, local MCP server to query imaging geometry, render offscreen snapshots, and measure anatomical distances programmatically.

OpenRadView is available for free download from gyorgy.sh and source-code inspection at gyorgysh/openradview.