PaperlayerView exact revision on arXiv

Source-linked AI summary

Volcanite: Commodity-Hardware Segmentation Volume Visualization for Connectomics and Beyond

Max Piochowiak, Reiner Dolp, Julian Herold, Eric Behle, Carsten Dachsbacher, Alexander Schug

arXiv:2609.36898v1cs.GRq-bio.NCq-bio.QM

TL;DR

Dense segmentation volumes are categorical, boundary-sensitive data, but their scale and data characteristics challenge scalar-volume and mesh-based workflows. Volcanite combines compression-aware handling with segmentation-specific rendering for voxel-precise interactive exploration. Across varied datasets, the approach spans domains and label regimes, while the current implementation targets local rendering up to the teravoxel range.

  • Problem

    Dense segmentations are categorical, boundary-sensitive voxel data that existing scalar-volume and mesh-based workflows do not serve well, while benchmark datasets cover few properties or domains.

    Source: Segmentation volume collection for… · p. 5, Discussion · p. 10

  • Method

    Volcanite combines brick-wise multi-resolution CSGV compression with GPU rendering designed for dense segmentation volumes.

    Source: Discussion · p. 10, Compressed segmentation volumes · p. 12

  • Results

    Evaluated datasets span life science, material, and synthetic or computational examples, with object counts from a few labels to millions.

    Source: Discussion · p. 10

  • Takeaways & Limitations

    The evaluated breadth supports Volcanite as a general approach that can be adapted across data sources, acquisition modalities, and segmentation pipelines.

    Source: Discussion · p. 10

    The current implementation targets local rendering up to the teravoxel range; complete petascale volumes remain outside its scope.

    Source: Discussion · p. 11

Abstract

from arXiv · show

Modern imaging produces terabyte-scale segmentation volumes, assigning each voxel an object label. These categorical, boundary-sensitive and label-rich data underpin connectomics and other imaging-driven fields, yet their scale often forces interpretation through slices, approximate meshes or distributed workflows that obscure spatial context and voxel-level defects. Here we show that such volumes can be explored directly on commodity hardware with Volcanite, an open-source framework for dense-segmentation rendering. Combining compression-aware data handling, a Vulkan GPU backend and segmentation-specific rendering, Volcanite enables low-latency exploration without meshing or distributed infrastructure, including for unpublished, sensitive or proprietary data. Across multi-domain datasets, it preserves voxel labels, adds shadows and global illumination, and renders up to half a trillion voxels at 100 frames per second. By replacing lengthy preprocessing with direct inspection, Volcanite decouples hypothesis generation from data preparation and turns teravoxel label fields into interactive evidence for discovery, validation and cross-domain spatial analysis

Results

Volcanite supports interactive, voxel-precise exploration of large segmentation volumes, including inspection of single voxels. Its rendering also exposes alignment defects that are less apparent in mesh-based views.

Novel integrated segmentation volume rendering framework

  • Milliseconds-per-frame rendering provides lossless access to individual voxels during interactive 3D exploration.Visible volume regions are decompressed on demand into a cache for fast access.Source: Novel integrated segmentation volume… · p. 2

Enabling scientific insights through segmentation volume rendering

  • Voxel-precise views revealed mouse-brain vessel discontinuities caused by alignment errors in the stitched segmentation.The errors were less apparent in Neuroglancer meshes because simplification smooths fine surface detail and can remove regions below a voxel-count threshold.Source: Enabling scientific insights through… · p. 2

Novel integrated segmentation volume rendering framework

  • 2.2 TB of H01 human cortex white matter segmentation was explored at 66 frames per second with Full-HD path-traced illumination on commodity hardware.Volcanite preprocessing took under two hours, while generating Neuroglancer meshes took over a week.Source: Figure 1 · p. 3

Enabling scientific insights through segmentation volume rendering

  • Volcanite's shorter rendering times support rapid iteration and interactive inspection of datasets up to 163 GB at 1 bit per voxel.The passage identifies this scale as beyond ParaView's capacity.Source: Enabling scientific insights through… · p. 3

Effective segmentation volume material editor

Volcanite's material editor maps dense segmentation labels and secondary attributes to visual properties. Its curated dataset collection and CSGV compression support evaluation across varied data and efficient rendering.

Effective segmentation volume material editor

  • Materials group intervals of visible labels and map secondary attributes, supporting dense segmentations with millions of labels.The editor can use automatically computed attributes or values supplied in .sqlite or .csv files.Source: Effective segmentation volume material… · pp. 3–5

Segmentation volume collection for visualization evaluation

  • The curated evaluation collection spans varied sizes, acquisition methods, and domains, from 72 MB Fabricval data to a 2 TB H01 white-matter subset.Examples cover plant analysis, cellular simulations, materials, battery design, fabrics, and connectomics.Source: Segmentation volume collection for… · p. 5

CSGV segmentation volume compression

  • CSGV compression enables terabyte volumes on a single commodity GPU, with compression largely independent of label count and dependent instead on brick-local label density.The finest LOD can be streamed to the GPU on demand; the CSGV encoding represents multi-LOD bricks as streams of label-copy operations.Source: CSGV segmentation volume compression · p. 6
  • Volcanite preprocessing is faster and storage smaller than VTK or Neuroglancer, while retaining lossless voxel data rather than mesh approximations.The figure compares frame timings under local shading and reports the smallest storage and shortest preprocessing times for Volcanite.Source: Figure 3 · p. 5, CSGV segmentation volume compression · p. 6
  • Palette back references can shorten palettes yet rarely improve and sometimes worsen compression; the revised operation supports unlimited back-reference distances and avoids duplicate entries.The reported compression tradeoff arises because δ entries can skew symbol frequencies in secondary ANS coding.Source: CSGV segmentation volume compression · pp. 7–8

Image and video rendering performance

Volcanite renders static views and moving-camera videos interactively, with shading modes that trade speed for image quality. More advanced shading can increase render times as it accesses more bricks.

Image and video rendering performance

  • 2 and 29 ms per frame are the reported settled timings, with rare higher outliers; moving-camera video rendering remains interactive.The second frame is slower because initially visible bricks must be decoded, while camera motion causes ongoing decompression and caching.Source: Image and video rendering performance · p. 8

Flexible shading modes

  • Path tracing offers the highest visual quality, while shadow rays and ambient occlusion improve perception of spatial structures.Render times increase by up to a factor of 5.5 from local shading to path tracing; shading modes can be switched interactively.Source: Flexible shading modes · p. 8

GPU-based rendering pipeline

Volcanite uses a GPU-resident brick-cache pipeline to render visible segmentation data, then combines denoising and upsampling while managing memory to fit large volumes on commodity hardware.

GPU-based rendering pipeline

  • The GPU pipeline requests, provisions, assigns, and decompresses visible bricks before ray marching and post-processing, with cache stages having negligible frame-time impact.Decompression and rendering dominate timings; decompression is especially affected by camera movement and both depend on accessed brick LODs.Source: GPU-based rendering pipeline · p. 8, Figure 6 · p. 9

Fast combined upsampling and denoising filter

  • The unified A-trous filter denoises and upsamples through G-buffer-guided blending in three image-sized textures, fading out as static-view samples accumulate.In early frames, rendered pixels blend with kernel neighbors while non-rendered pixels track offsets to rendered neighbors; the final pass copies their colors.Source: Fast combined upsampling and denoising… · p. 10

GPU memory utilization optimization

  • 65.7% of H01WM’s CSGV memory is saved by streaming its finest LOD, while packed indices and pixel-limited brick requests help keep rendering within 16 GiB VRAM.Limiting requests can require more frames for convergence, but prevents cache deadlocks and preserves correctly rendered results.Source: GPU memory utilization optimization · p. 10

Discussion

Volcanite treats dense segmentations as boundary-sensitive categorical voxel data, enabling local, voxel-precise inspection across varied domains while remaining limited to teravoxel-scale volumes.

Discussion

  • Volcanite renders teravoxel-scale segmentations interactively on commodity hardware while preserving voxel labels and retaining spatial cues through shadows and global illumination.It avoids mesh generation and treats segmentations as categorical, boundary-sensitive data rather than scalar fields or precomputed surfaces.Source: Discussion · p. 10
  • Using CSGV for both lossless compression and rendering acceleration shortens the path from segmentation output to visual inspection by reducing format conversion and preprocessing.Voxel-precise rendering with depth cues can expose stitching errors, thin structures, and segmentation defects in densely packed morphologies.Source: Discussion · p. 10
  • Local exploration of selected subvolumes supports workstation-based collaboration and handling of unpublished, sensitive, or proprietary data without remote visualization infrastructure.The authors identify quality control, collaborative analysis, and ongoing iterative interpretation as uses beyond final visualization.Source: Discussion · p. 10
  • Evaluated datasets span life science, materials, and synthetic or computational examples, with object counts from a few labels to millions.The authors describe the open-source system as adaptable across data sources, acquisition modalities, and segmentation pipelines.Source: Discussion · p. 10
  • Complete petascale volumes remain outside the current system’s scope, which targets local rendering up to the teravoxel range.The proposed extension is on-demand streaming from CPU memory, local storage, or remote servers, with additional scheduling and latency-hiding mechanisms.Source: Discussion · p. 11

Methods

The evaluation specifies its commodity-hardware setup and rendering parameters, then compares Volcanite with VTK and Neuroglancer using distinct procedures and metrics.

Evaluation setup

  • Evaluation runs use an AMD Ryzen 7 5800X, 48 GiB RAM, and an RTX 4070 Ti Super with 16 GiB VRAM on Ubuntu 24.04.Inputs are read from a Lexar NM790 NVMe drive, and output is stored on a Samsung EVO 970 NVMe drive.Source: Evaluation setup · p. 11

Compression and rendering parameters

  • Brick size is 32 by default and 64 for large datasets, with cache paletting used for high caching demands and detail streaming for H01WM’s finest LOD.Images use 1920 × 1080 resolution; static-camera image evaluations render 1024 frames, while video evaluations use 600 frames with camera movement.Source: Compression and rendering parameters · p. 11

VTK and Neuroglancer comparisons

  • VTK is evaluated with GPU raycasting and a label-to-opacity transfer function, while Neuroglancer uses precomputed compressed data and simplified meshes.Neuroglancer frame times and time-to-first-frame are not measured because client-server streaming and sequential mesh appearance prevent precise measurement.Source: VTK and Neuroglancer comparisons · pp. 11–12

Compressed segmentation volumes

Volcanite relies on lossless, brick-wise multi-resolution CSGV compression and adapts its palette operations to support rendering large segmentation volumes on single-GPU systems.

Compressed segmentation volumes

  • Lossless compression is central to keeping as much segmentation data as possible in GPU memory, using the brick-wise multi-resolution CSGV encoding.The renderer compresses the volume before rendering; CPU compression is parallelized with OpenMP, and encoding times are reported as shorter than disk-read times.Source: Compressed segmentation volumes · p. 12
  • The adapted CSGV encoding can disable operations other than inserting and reading the next palette entry, trading palette duplicates against operation-stream and bit-length compression behavior.The authors generally enable palette back references when small palettes are preferable and label counts are high.Source: Compressed segmentation volumes · p. 12
  • Arbitrary-length back references encode δ in successive 4-bit entries, avoiding palette duplicates; even the stated 64^3-brick worst case uses 28 bits versus 32 for a duplicate.The three least significant bits of each entry extend δ, with another entry indicated by the remaining bit.Source: Compressed segmentation volumes · p. 12
  • Compression is performed on the CPU with OpenMP and can import chunked volumes split across files when the full input would otherwise exceed RAM.The reported encoding times are significantly shorter than reading the volume files from disk.Source: Compressed segmentation volumes · p. 12

Volcanite rendering

Volcanite renders compressed segmentation volumes by voxel ray marching, with shading modes ranging from local reflection to path tracing. Its ray traversal preserves voxel-level boundaries, while post-processing combines edge-aware denoising and upsampling.

Volcanite rendering

  • Voxel ray marching samples labels at original voxel resolution and derives surface materials from each label to compose pixel colors.Compressed data is decoded on demand from GPU memory for visible regions.Source: Volcanite rendering · p. 12
  • Four shading modes range from simple local shading to path tracing, trading rendering speed for effects such as shadows, ambient occlusion, and indirect lighting.Path tracing evaluates one random direction per recursive step and terminates at the volume boundary or a path-depth threshold.Source: Volcanite rendering · p. 13
  • Voxel traversal orders surfaces from nearest to farthest, enabling semi-transparent materials to contribute shading while attenuating the radiance from following surfaces.The renderer does not change ray direction when it enters a semi-transparent material.Source: Volcanite rendering · p. 13

Ray marching

  • Multi-resolution DDA traversal finds voxel hit points, while a decomposed voxel and sub-voxel position keeps distance calculations in the numerically stable [0, 1)³ interval.The method addresses numerical instability and aliasing in large volumes; coarser LOD steps scale voxel size and update the sub-voxel position accordingly.Source: Ray marching · p. 13
  • A shared GPU ray-marching loop handles camera and secondary rays; users can explore with fast modes before rendering with ambient occlusion or path tracing.The multi-resolution hierarchy limits cache use but can bias renderings, and Monte Carlo modes progressively converge from noisy initial frames.Source: Ray marching · p. 14

Post-processing

  • The shared post-processing pipeline performs edge-avoiding denoising and can fill unrendered pixels by copying color from the closest rendered neighbor.Hierarchical accumulation combines both operations; the denoiser reduces memory use by outputting the final down-pass directly rather than storing intermediate results.Source: Post-processing · pp. 14–15

Volcanite application

Volcanite’s application supports interactive material mapping for segmentation labels and command-line control. Label attributes can be computed or queried, then used to drive visualization.

Volcanite application

  • The material editor maps labels to color, opacity, and emission through ordered filter intervals, with optional color maps or randomized categorical coloring.Color maps may use a secondary attribute independently of the filter attribute.Source: Volcanite application · p. 16
  • Label attributes can come from SQL-managed data or be computed per label, including volume and surface area; nondefault attributes trigger label remapping to contiguous indices.The mapping preserves original labels in the database.Source: Volcanite application · p. 16
  • The CLI exposes rendering and compression controls for automation and headless systems, while the GUI provides interactive parameter control.The CLI can be used from Python or bash through filesystem inputs and outputs, though direct Python integration is not supported.Source: Volcanite application · pp. 15–16

GPU rendering pipeline

Volcanite separates CPU-side compression from GPU rendering and decoding, and uses a per-frame cache pipeline to provision visible compressed bricks. Later frames generally keep non-render stages short.

GPU rendering pipeline

  • Volcanite uses C++ and Vulkan, with CPU compression parallelized by OpenMP and rendering, decoding, and caching implemented in GLSL GPU shaders.Just-in-time shader compilation specializes code paths for each compressed volume and encoder configuration.Source: GPU rendering pipeline · p. 16
  • A per-frame request, provision, assign, and decode pipeline identifies visible bricks, allocates cache space, assigns slots, and decompresses required data.Bricks without labels visible under the current transfer function are skipped.Source: GPU rendering pipeline · pp. 16–17
  • After the initially visible bricks are decoded, non-render stages generally run in under 2 ms in later frames.The first frames begin with an empty brick cache and decode all initially visible bricks once.Source: GPU rendering pipeline · p. 17

Memory management

Volcanite manages terascale data within limited GPU memory by compressing volumes, streaming detail on demand, and adapting its cache to rendering needs. It also uses safeguards for cache fragmentation and deep ray paths.

Memory management

  • The finest brick LOD is streamed on demand, while coarser LODs are uploaded fully and reduce cached brick memory by a factor of 8 per LOD.The finest-LOD request pipeline copies requested encodings asynchronously through CPU buffers to the GPU.Source: Memory management · p. 17
  • At compression rates of 1% to 3%, most CSGV encoded volumes fit commodity-GPU VRAM; split buffers address 32-bit brick-offset indexing, which limits contiguous encodings to 16 GiB (GPU API allocations are capped at 4 GiB).Brick indices map to buffers in constant time, and Vulkan buffer device addresses let GPU decompression access encodings without branches.Source: Memory management · p. 17
  • Cache paletting packs palette indices instead of full labels, increasing effective cache capacity at the cost of an additional global-memory fetch.An adapted encoding operation permits arbitrary-length back references and avoids duplicate palette entries that could worsen cache utilization.Source: Memory management · pp. 17–18
  • When LOD free stacks fill, Volcanite skips returning freed regions to avoid deadlock, accepting dead cache space until defragmentation.A full-cache reset defragments the cache; brick request limitation can also concentrate cache ownership on pixels with the fewest samples to free space and prevent deadlocks when visible bricks do not fit.Source: Memory management · p. 18
  • A default ray-request depth limit of 1 curbs decompression of bricks used only by long path-tracing rays, while potentially introducing a usually small bias in low-frequency indirect illumination.Undecoded-brick accesses use the most frequent label from the coarsest brick LOD without invalidating the gathered pixel color.Source: Memory management · p. 18
  • Per-pixel deterministic random-number sequences repeat ray paths until required bricks are available, and change every 256 frames to prevent deadlocks.Seeds use pixel coordinates, accumulated valid sample count, and a tiled blue-noise pattern.Source: Memory management · p. 18

Declarations

The authors report funding sources, author roles, data and code availability, and no competing interests.

Declarations

  • The work received Helmholtz Association support through the listed programs and grants; the funders had no role in study design, data collection, analysis, publication decisions, or manuscript preparation.A.S. and J.H. acknowledge additional support, and A.S. lists further grant support.Source: Declarations · p. 19
  • All evaluated datasets are publicly available except two specified datasets, which are available from the authors on request.A Python script is provided to download public evaluation datasets.Source: Declarations · p. 19
  • Volcanite code is publicly available under GPLv3, and the evaluation repositories include scripts and references to VTK and Neuroglancer evaluations.Precompiled Windows and Ubuntu releases and a repository snapshot are also listed as available.Source: Declarations · p. 19
  • The contribution statement assigns implementation and dataset curation primarily to M.P., with backend work shared by M.P. and R.D.; the authors declare no competing interests.Domain-expert feedback, writing, and funding roles are also listed.Source: Declarations · p. 19

Extended Data

Extended data describes Volcanite’s denoising, memory handling, compression, and rendering pipeline, alongside timing tables and supplementary demonstrations.

Extended Data

  • The denoising figure shows an adapted à-trous filter using G-buffer guidance, with the closest sampled pixel supplying color for unsampled pixels during upsampling.It also illustrates subsampling for 4K output and denoising of early path-tracing frames with one radiance sample per pixel.Source: Figure A1 · p. 20
  • The GPU memory figure explains cache packing and request limitation, and compares total VRAM use with raw data size on a 16 GiB GPU.For small data the cache dominates memory consumption; the listed larger datasets use cache paletting to increase effective cache size.Source: Figure A2 · p. 21
  • The rendering architecture stores brick encodings in large buffers, streams finest-detail bricks on demand, and decompresses visible bricks into a GPU cache during rendering.The figure also depicts the post-processing data flow and CPU pipeline for constructing finest-LOD encoding buffers.Source: Figure A3 · p. 22
  • CSGV volumes range from 1 MB to 30 GB for datasets ranging from 72 MB to over 2 TB, and compression is largely independent of label count.The figure notes that compression rates vary with input bit depth and marginally with local label density.Source: Figure A4 · p. 23
  • Table A1 compares preprocessing times and file sizes for Volcanite, VTK, and Neuroglancer, distinguishing compression and input I/O from first-frame overhead.It notes that Volcanite’s raw compression is faster than reading input files, while Neuroglancer preprocessing includes compression and mesh approximation.Source: Table A1 · p. 26
  • Shading modes access increasing numbers of bricks from local shading through shadow rays and ambient occlusion to path tracing, with more advanced shading reducing performance.The figure shows immediate switching between modes and describes shadows or ambient occlusion as improving visual perception, while path tracing offers the highest visual fidelity.Source: Figure A7 · p. 34
  • Table A2 reports static-image timings over 1024 frames and moving-camera video timings over 600 frames, with initial image-frame decoding as a high outlier.The caption says this cache warm-up largely vanishes by frame 15, while video configurations can incur later decoding overhead when fine-resolution bricks are requested.Source: Table A2 · p. 35
  • Cache paletting reduces memory approximately according to its packing factor, but adds overhead when an unpacked cache already provides sufficient capacity.With a 1 GiB cache, paletting lets required regions reside simultaneously and resolves reduced valid samples and slower frames when the unpacked cache is insufficient.Source: Table A3 · p. 37
Loading 2609.36898v1…