fo-dicom内存占用和速度问题

时间:2018-03-12 13:17:32

标签: architecture memory-footprint

到目前为止,我从未使用过fo-dicom,因此我有更多问题需要了解它是否可以帮助我们,或者我唯一的选择是开始开发低级SDK代码多年。我想使用托管SDK,而且似乎也越来越广泛。

我的问题:

  1. 使用可忽略不计的内存量发送时,是否可以编写大型实例或动态创建大型实例?我应该使用相同数量的(小)帧创建具有数亿项和像素数据的每帧组序列。所以我的意思是我们应该支持流媒体。
  2. 当只需要实例中的特定帧时,是否可以避免将大量序列加载到内存中?
  3. 是否可以通过在包含的像素数据中给出其序号而不将其他部分加载到内存中来获得一帧压缩或未压缩?
  4. 我需要一种机制来在写入或发送期间找出未定义长度序列的最终长度。我会将它存储在另一个实例的私有属性中,并且我希望使用该长度来跳过读取查看器的帧时的巨大序列。
  5. 字符集处理是否已经可用? (我们也有亚洲人,阿拉伯人和其他客户)。我们的输出默认为UTF8。

  6. 如果仅考虑工作清单,是否存在更易于用于工作清单开发的托管SDK?

  7. 我甚至乐意为fo-dicom的开发做出贡献,但是它的架构是否适合用这些功能来补充它而没有巨大的重构。 提前感谢您提供任何信息/帮助。

1 个答案:

答案 0 :(得分:0)

我认为特别之处在于,它是完全可移植的。这意味着没有托管SDK,但整个目录都是托管的。只有一些jpeg压缩有本机代码。因此,如果您不需要jpeg压缩,您可以在32位,64位,Windows,andorid,ios,linux,unity,...中运行fo-dicom。如果您需要本机编解码器,则仅限于Windows。

广告1.内存限制应该只是机器内存的限制。但我对这些大数据没有任何基准或经验。我担心,你只需要自己尝试一下。

ad 2.目前在打开一个dicomfile时,只有"标题"没有加载像素,如果第一次访问,则从文件加载像素。目前这不是基于框架的,但这是一个好主意,并不太难实现。

ad 3.与2中的答案相同。目前从文件中加载整个像素。但是当你访问一个帧时,会返回内存的子集,并对该子集执行所有进一步的操作。

ad 4.目前没有api。但这就是开源的好处,你可以随意改变它:-)这部分都是c#。

广告5.应该是。至少我知道一段时间前用户在github上出现了一个问题,其中包含一个包含错误编码字符串的图像,已经解决了。所以假设它应该被实现,但我个人还没有测试过它。

ad 6.使用fo-dicom,您可以实施任何类型的服务或客户端。快速浏览https://github.com/fo-dicom/fo-dicom-samples。在文件夹"桌面"有一个worklist scp示例。好吧,如果你发现它很容易实现取决于你,但我喜欢它: - )