Segmentation Editor: Integrate the Cornerstone3D viewports and Segmentation editor with the Cornerstone cache
Presently the Cornerstone views within the Sonador viewer utilize VTK.js data for their exchange. Upon initialization, the data is persisted to Cornerstone's cache, and then unloaded when the component is unmounted. This decision was made in order to provide a mechanism for integrating Cornerstone3D into the Sonador viewer, but means that there is a lot of unnecessary movement of data.
A better approach would be to utilize the Cornerstone3D cache as a primary store for imaging, labelmaps, and geometries and allow for all Cornerstone viewports to consume it. In the case of the Segmentation Editor, utilizing the storage for geometries would remove the need to re-render geometries whenever a new segmentation is loaded (which is a very time consuming process).
Status
-
Geometries (M3D/STL/GLB) — Cornerstone3D geometry cache is now the primary store, with a reference-counted wrapper (
extensions/viewer3d/src/m3dCache/m3dCacheService.js) providing cache-first/single-flight loads, cross-viewport reuse, and source-blob retrieval; the Three.js M3D viewer consumes it. Implemented in oak-tree/medical-imaging/ohif-viewers!58. -
Surface re-computation —
computeSurfaceData()is single-flighted per segmentation (platform/core/src/utils/polySegSingleFlight.js), so surfaces are computed once rather than re-triggered by render events. Implemented in oak-tree/medical-imaging/ohif-viewers!58. -
Imaging volumes and labelmaps — still VTK.js-primary: data is copied into the Cornerstone3D cache on mount (
cacheVtkImage/cacheVtkLabelmapImageinextensions/vtk/src/utils/cornerstone3d.js) and purged on unmount (purgeLocalVolume), so image/labelmap data is re-transferred on every viewport mount. Migrating these to the Cornerstone3D cache as the primary store is the remaining scope of this issue.
See the implementation assessment against oak-tree/medical-imaging/ohif-viewers!58 in the comments (2026-07-10) for file-level detail.