PyRadiomics-cuda: GPU-accelerated 3D Shape Features

Updated 4 July 2026

PyRadiomics-cuda is a GPU-accelerated extension that targets 3D shape feature extraction in PyRadiomics, optimizing volumetric radiomics workflows.
It offloads computationally intensive tasks like Marching Cubes mesh generation and diameter computations to CUDA-capable GPUs, achieving up to 2000× speedup.
The extension maintains the original PyRadiomics API intact, ensuring seamless integration and feature value equivalence in existing radiomics pipelines.

PyRadiomics-cuda is a GPU-accelerated extension of the standard PyRadiomics library that targets one specific computational bottleneck in volumetric radiomics: three-dimensional shape feature extraction. It offloads Marching Cubes mesh generation and 3D diameter computation to CUDA-capable GPUs while keeping the original PyRadiomics API 100% intact and falling back to the CPU automatically when no usable GPU is available. In the published system, the mathematical definitions of the features are unchanged; the contribution lies in accelerating the geometric computations that dominate runtime for large segmentations and large cohorts (Lisowski et al., 3 Oct 2025).

1. Scope, motivation, and problem setting

PyRadiomics-cuda was introduced to address the cost of extracting the Shape feature class from realistic 3D medical image segmentations. In standard PyRadiomics, features such as mesh volume, surface area, maximum 3D diameter, and planar diameters in the XY, YZ, and XZ planes are computed on the CPU. For large ROIs, this becomes expensive because mesh generation by Marching Cubes has complexity around $O(n^3)$ , where $n$ is the linear size of the ROI, and the original diameter computation behaves as $O(n^4)$ in the worst case. The paper frames this as a practical limitation for CT, MRI, and PET workflows involving high-throughput radiomics and AI training, and identifies the xLUNGS project, with about 40,000 chest CT scans, as a motivating use case in which CPU-only shape extraction was a major time and cost bottleneck (Lisowski et al., 3 Oct 2025).

The system is intentionally narrow in scope. It does not attempt a full GPU rewrite of PyRadiomics. Instead, it targets the part of the pipeline where the published profiling indicated the largest potential return: 3D shape computation for large volumetric segmentations. This design choice is central to understanding both its impact and its limitations.

2. Software architecture and execution model

PyRadiomics-cuda is implemented in Python and C/CUDA and integrates into PyRadiomics by patching the internal C extension used for shape features. During installation, setuptools checks for nvcc, the NVIDIA CUDA compiler. If CUDA is available, the build compiles the CUDA sources and replaces a single call in the original C extension with a dispatcher. At runtime, that dispatcher checks whether a CUDA-capable GPU is present and whether the driver initializes correctly. If so, execution is routed to the CUDA kernels; otherwise, computation falls back to the original CPU implementation (Lisowski et al., 3 Oct 2025).

From the Python side, the calling convention remains unchanged:

from radiomics import featureextractor

ext = featureextractor.RadiomicsFeatureExtractor()
res = ext.execute('scan.nii.gz', 'mask.nii.gz')

print(res['MeshVolume'], res['SurfaceArea'])

This unchanged API is a defining property of the extension. The CPU–GPU division of labor is also explicit. PyRadiomics continues to perform image reading, pre-processing, mask application, and final feature object assembly on the CPU. PyRadiomics-cuda receives the prepared ROI voxel array, copies it to GPU memory, generates the triangle mesh and computes the diameter-related quantities on the GPU, and returns the resulting geometric data to the original PyRadiomics code path. A plausible implication is that existing PyRadiomics scripts, YAML-driven pipelines, and higher-level wrappers can adopt the extension without redesigning their control flow.

3. Accelerated algorithms and low-level implementation

The CUDA path accelerates two operations: Marching Cubes mesh generation and diameter computation. In the Marching Cubes kernel, many CUDA threads process voxels or small voxel blocks in parallel. Each thread examines a local $2 \times 2 \times 2$ voxel cube, determines the corresponding case from the lookup table, and emits the associated triangle vertices. The paper states that these vertices are written into global GPU memory using a Structure-of-Arrays layout, with separate coordinate arrays such as x[], y[], and z[], to improve coalesced memory access (Lisowski et al., 3 Oct 2025).

The diameter kernels address the second major hotspot. Conceptually, the maximum 3D diameter is the largest Euclidean distance between mesh vertices, and the planar diameters are the corresponding maxima on projected vertex coordinates. The CUDA implementation uses massive parallelization of pairwise distance computations together with multi-level reductions to extract maxima. The reported optimization strategy includes shared memory for reusable data, coalesced global memory access, minimization of atomic operations, and reduction of unnecessary synchronization. The paper does not restate the full feature equations; instead, it explicitly preserves PyRadiomics’ original feature formulas and accelerates only the generation of the geometric primitives on which those formulas depend (Lisowski et al., 3 Oct 2025).

Data transfer is handled at the C-extension boundary. ROI voxel arrays originating as NumPy arrays are passed into the C extension, copied into GPU global memory, processed there, and only the final vertex data and/or diameter values are copied back to the CPU. The authors also describe a dedicated C/CUDA test harness that reads .npy files through the NumPy C API, allowing the GPU kernels to be tested on exactly the same binary inputs that PyRadiomics would generate in normal execution.

4. Empirical performance and numerical validation

The published benchmarks use a subset of KiTS19, the Kidney Tumor Segmentation Challenge 2019 dataset. From more than 200 CT cases, the authors selected 20 samples spanning file sizes from about 50 kB to 9 MB and vertex counts from 2,700 to 236,588. Evaluation was performed on three hardware configurations: a modern cluster with an NVIDIA H100 and AMD EPYC 9534, a desktop with an NVIDIA RTX 4070 and AMD Ryzen 5 7600X, and a budget cluster with an NVIDIA T4 and Intel Xeon E5649 (Lisowski et al., 3 Oct 2025).

The largest reported acceleration occurs for the largest ROI, with about 236,588 mesh vertices. On the Xeon CPU, standard PyRadiomics required about 121 seconds in total, whereas PyRadiomics-cuda on the H100 required about 59 milliseconds, corresponding to an approximately $2000 \times$ speedup in the 3D shape computation step. On the NVIDIA T4, the extension achieved $8 \times$ to $24 \times$ speedup over CPU-only 3D feature extraction. When the full workflow is considered, including disk reading and CPU pre-processing, the overall speedup for larger data files with more than 200k vertices was about $8 \times$ . The timing breakdown reported in the paper shows that in CPU-only PyRadiomics, diameter calculation accounts for 95.7% to 99.9% of post-I/O time; the GPU path reduces both Marching Cubes and diameter runtime substantially, while data transfer time remains minor relative to the computational gain (Lisowski et al., 3 Oct 2025).

The validation claims are equally specific. The authors state that output quality is the same as the original PyRadiomics implementation and describe direct comparison of feature values under identical inputs. Minor floating-point differences are not elaborated, but the paper’s conclusion is that CPU and GPU results are equivalent for practical purposes. It also notes that merely changing CPUs yields at most about $3 \times$ speedup in CPU-only PyRadiomics, reflecting the single-threaded nature of the original path and underscoring why GPU acceleration was effective for this workload.

5. Position within the radiomics software ecosystem

PyRadiomics-cuda occupies a targeted position in the broader radiomics software landscape. The 2022 precision-medicine-toolbox wraps standard PyRadiomics inside a reproducible Python workflow for DICOM curation, NRRD/MHA conversion, pre-processing, and feature extraction, but it is explicitly CPU-only and does not add CUDA or GPU acceleration. The 2025 PySERA framework extends the scope of radiomics substantially, computing 557 handcrafted features and deep radiomics embeddings with parallel, memory-aware CPU execution, yet its handcrafted features remain CPU-only, with GPU relevance confined to deep radiomics through PyTorch, TensorFlow, and MONAI. Radiuma, which uses PySERA rather than PyRadiomics as its radiomics engine, likewise reports no built-in GPU or CUDA support. In application papers, GPU is often introduced downstream rather than in feature extraction itself: the spherical radiomics study uses PyRadiomics for Cartesian and shell-based feature extraction without CUDA, and the lung cancer stage-detection study uses PyRadiomics features extracted in 3D Slicer and then moves feature selection and classification into GPU-friendly PyTorch models. A different line of work, cubic, provides device-agnostic GPU acceleration for many SciPy and scikit-image style preprocessing, segmentation, and measurement operations, but it is not presented as a drop-in accelerator for PyRadiomics texture or shape internals (Primakov et al., 2022, Salmanpour et al., 20 Nov 2025, Salmanpour et al., 22 May 2026, Feng et al., 15 Oct 2025, Shakir et al., 3 Jun 2026, Kalinin et al., 15 Oct 2025).

This context makes PyRadiomics-cuda distinctive. It is not a full radiomics platform, not a GUI environment, and not a generalized GPU image-processing library. It is instead a narrow extension that preserves PyRadiomics’ existing interface while accelerating a single feature family that had become a practical bottleneck in large-scale 3D workflows. This suggests that it is best understood as infrastructure for existing PyRadiomics users rather than as a replacement for broader ecosystems such as PySERA or Radiuma.

6. Limitations, deployment, and future directions

A recurrent misconception is that PyRadiomics-cuda accelerates PyRadiomics as a whole. The paper does not support that interpretation. GPU acceleration currently covers only the 3D Shape feature class, specifically mesh generation and diameter computation. First-order statistics, texture matrices such as GLCM, GLRLM, and GLSZM, and all other non-shape features remain CPU-based. File reading, cleaning, normalization, and data preparation also remain on the CPU and can still account for a substantial portion of total runtime. The paper further notes that multi-GPU and distributed GPU execution are not discussed, that the implementation requires an NVIDIA CUDA-capable GPU, and that the current design remains tied to PyRadiomics’ internal CPU feature assembly (Lisowski et al., 3 Oct 2025).

The software is freely available under the BSD license at https://github.com/mis-wut/pyradiomics-CUDA, with a companion test suite and data generator at https://github.com/mis-wut/pyradiomics-cuda-data-gen. The authors also provide a benchmark dataset reference through KiTS19 on Kaggle. The future directions implied in the paper are straightforward: extending GPU acceleration beyond 3D shape features, moving more of the I/O and preprocessing path onto the GPU, and improving pipeline-level parallelization, potentially toward multi-GPU settings. Related work reinforces the plausibility of that direction: cubic demonstrates device-agnostic GPU acceleration for resampling, filtering, morphology, segmentation, and measurement workflows, while PySERA explicitly identifies future GPU acceleration and distributed processing as planned extensions for large cohorts (Lisowski et al., 3 Oct 2025, Kalinin et al., 15 Oct 2025, Salmanpour et al., 20 Nov 2025).

In practical terms, PyRadiomics-cuda is most valuable when 3D shape descriptors are mandatory, ROIs are large, and the workload involves repeated extraction across many scans. In those settings, it converts a historically dominant runtime component into a comparatively small one without requiring new Python APIs, new parameter schemas, or changes to established PyRadiomics calling patterns.