自己做的网站如何链接到百度,长春标准网站建设,wordpress4.9.8汉化,wordpress前台英文后台中文背景
Cornerstone3D于2024年10月左右已正式发布2.0版本#xff0c;且3.x版本也于2025年02月开始发版。那在项目已经在1.x版本上稳定运行的前提下#xff0c;是否需要升级到发生大量API破坏性升级的2.x版本。以下从2.x版本的性能优化、功能更新、使用场景等几个方面进行对比评…背景
Cornerstone3D于2024年10月左右已正式发布2.0版本且3.x版本也于2025年02月开始发版。那在项目已经在1.x版本上稳定运行的前提下是否需要升级到发生大量API破坏性升级的2.x版本。以下从2.x版本的性能优化、功能更新、使用场景等几个方面进行对比评估。 2.x版本已在 https://github.com/jianyaoo/vue-cornerstone-demo 中升级可通过运行不同的版本对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侧预分配一组相应大小的空内存SharedArrayBufferGPU侧通过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渲染回退为32BitCPU和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的只是存在于调研阶段了~
