Cornerstone3D 2.x升级调研

背景

Cornerstone3D于2024年10月左右已正式发布2.0版本，且3.x版本也于2025年02月开始发版。那在项目已经在1.x版本上稳定运行的前提下，是否需要升级到发生大量API破坏性升级的2.x版本。以下从2.x版本的性能优化、功能更新、使用场景等几个方面进行对比评估。

2.x版本已在 github.com/jianyaoo/vu... 中升级，可通过运行不同的版本对1.x版本和2.x版本进行性能查看

2.x 升级

升级概览

我们通过一张图直观的感受下2.x版本API的破坏性有多强。以下是通过官方升级指导手册罗列的升级变动大纲，除了架构层面的升级不涉及到我们业务代码的改动外，其他子包的升级基本都需要修改我们的业务代码。

优化概述

除了对函数名和参数进行重命名、更新、迁移类的更新外，主要的核心优化为以下几个方面

工具链的升级与整合

2.x中对核心库、周边加载器、适配器等进行了重构和整合。将原本独立的@cornerstonejs/streaming-image-volume-loader 整合进 @cornerstonejs/core，简化了依赖管理。
移除了对 Detect-GPU 的依赖，在使用默认GPU层级的同时也支持用户手动设置GPU性能级别，解决了开发应用无法联网的情况。
取消了 SharedArrayBuffer，由共享数据更新为Dicom数据解码后直接交由GPU处理，使性能更加高效，同时也解决了各种不同环境下不支持SharedArrayBuffer的问题。
打包产物仅输出EMS，目前node及现代浏览器默认都支持ESM，加快了打包速度。

volume升级与统一

volume的升级是2.x中针对性能优化问题做的一重大改进，官方说法为升级后内存占用量约减少一半（实际可能并没有减少这么多），以下为具体的升级内容

1.0中渲染volume的实现流程（大致流程，主要对比内存的节省方面）

元数据预抓取：针对所有的imageIds拿取Tag信息，计算体素总量；
内存预分配：根据体素总量，CPU侧预分配一组相应大小的空内存（SharedArrayBuffer），GPU侧通过vtk创建3D纹理并分配空间内存。
流式加载：Loader将影像资源作为二进制字节流（ArrayBuffer）拉到浏览器，在主线程收到 ArrayBuffer 后交给 Web Worker + dicomParser 进行解码，转成 pixelData。解码完成后，将pixelData写进CPU Buffer 的对应offset，随后传输给GPU进行渲染

总结：在1.x中，CPU & GPU 需要首先预分配一份Volume体素大小的内存来存储MetaData元数据，也是作为了一份Volume缓存数据。这种情况下在1.x中就存在了双缓存（image一份缓存、volume一份缓存）的问题。而作为辅助手段的 SharedArrayBuffer 会存在安全策略问题，禁用SharedArrayBuffer后，又会导致CPU峰值增高，因为复制需要在主线程进行，同时还会影响CPU的带宽。在此基础上，如果浏览器还不支持16 Bit渲染，回退为32Bit，CPU和GPU的占用量又又又翻倍了。

2.x渲染Volume的实现流程

元数据预抓取：针对所有的imageIds拿取Tag信息，计算体素总量（同1.x一致）
流式加载：将影像通过二进制流拉到浏览器后，交给 Web Worker 去进行解码，解码完成后将数据再交给主线程进行缓存。
GPU体渲染：每当一帧解码完成并交还给主线程后，像素数据直接填进GPU纹理指定的z-slice中，viewport在像素插入后立即进行重绘，用户便能看到提像素的渲染。（无需再使用CPU缓存volume的大数据）

当没有scaleData后，2.x中如何获取某点的体素数据？

在1.x中，如果想要获取某个点的体素数据，则会通过获取全部的ScaleData → 计算ijk总和 → 索引得值
在2.x中，Cornerstone3D 新引入了 VoxelManager 进行体素值管理，VoxelManager 会通过index或者ijk去Image Cache中查看对应的体素数据，如下图所示：先查找对应的slice Image，然后在image中查找对应点的像素数据。

Seg架构重构

除了上述中对volume的修改，另一个重大的修改就是Seg的重构。在1.x中Seg是依赖于工具组中，工具组作用于哪个视图便可以在哪个视图上渲染Seg。而在2.x中Seg是直接作用于视图上，便于对不同的视图进行Seg处理

在这一改动上，于性那优化层面感觉影响不大。但是对于Seg的灵活性增强了，尤其是需要对影像进行高度Seg标注的。但是！！！涉及到了Seg的大量API破坏性改动，如果系统中已存在复杂的Seg渲染逻辑，升级需谨慎。

性能对比

在OHIF团队的测试下，使用Cornerstone3D 2.x版本的内存效率约提升1倍。主要对比如下

下图为110张instance时，1.x版本和2.x版本的内存对比

结论

零零碎碎的写了一些分析数据，在系统是否需要升级至2.0这个问题上，主要还是从以下几个方面进行考虑：

对于性能和容量的需求：2.x版本针对大数据量的Dicom文件处理能力明显要比1.x版本要强。如果目前1.x版本已经存在加载性能问题或者后续将会出现大数据量处理的场景，2.x版本会更有优势。
是否存在复杂的标注场景：2.x提供的新分割和标注框架、更丰富的工具链，以及对多模态数据的更好支持，能满足更多高级功能需求。

但是！！！在实际业务系统中，需要充分考虑版本升级带来的工作量及系统回归测试问题。需要留有充足的时间进行功能验证。

写在最后的碎碎念：已经很久很久没有更新Cornerstone3D相关的博客了，从去年开始做其他项目开始就没有再过多的研究使用了。前段时间刚刚开始回归Cornerstone项目，年前有一些小伙伴问会不会写2.x的内容，所以回归后第一时间先是调研了2.x的升级内容，整个调研过程持续了有一段时间了，中间也是断断续续，包括对demo的2.x升级。但是等到真正写文章的时候却有点无处下笔，感觉涉及到的东西有点多。而且自己了解到的也是一些概念性的皮毛，所以也就先写了个大概。

通过自己升级demo的整个过程，目前还没有把线上项目升级到2.x的计划，最主要的原因还是破坏性API的工作量及大量的回归问题。所以目前2.x的只是存在于调研阶段了~