0

到目前为止，我从未使用过 fo-dicom，所以我有更多问题想知道它是否可以帮助我们，或者我唯一的选择是长期开发低级 SDK 代码。我想使用托管 SDK，而 fo-dicom 似乎越来越广泛。

我的问题：

  1. 仅使用微不足道的内存进行发送时，是否可以即时编写大型实例或创建大型实例？我应该创建一个每帧组序列，其中包含数亿个项目和具有相同数量（小）帧的像素数据。所以我的意思是我们应该支持流媒体。
  2. 当实例只需要特定帧时，是否可以避免将大量序列加载到内存中？
  3. 是否可以通过在包含的像素数据中给出其序号而不将其他部分加载到内存中来压缩或未压缩一帧？
  4. 我需要一种机制来在写入或发送期间找出未定义长度序列的最终长度。我会将它存储在另一个实例的私有属性中，并且我想使用该长度来跳过阅读巨大的序列，从而为观众提供帧。

  5. 字符集处理是否已经可用？（我们也有亚洲、阿拉伯和其他客户）。我们的输出默认为 UTF8。

  6. 如果只考虑工作清单，是否有更易于用于工作清单开发的托管 SDK？

我什至很乐意为 fo-dicom 的开发做出贡献，但它的架构是否适合在不进行大量重构的情况下用这些功能补充它是一个问题。提前感谢您提供任何信息/帮助。

4

1 回答 1

0

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

所以广告1.内存的限制应该只是你机器内存的限制。但我对这样的大数据没有任何基准或经验。恐怕，您只需要自己尝试一下即可。

广告 2. 当前打开 dicomfile 时，仅加载不带像素的“标题”，如果第一次访问，则从文件中加载像素。这目前不是基于框架的，但将是一个好主意，并且不太难实现。

广告 3. 与 2 中的答案相同。目前整个像素都是从文件中加载的。但是当你访问一个帧时，内存的子集会被返回，并且所有进一步的操作都会在这个子集上执行。

广告 4. 目前没有 api。但这就是开源的伟大之处，您可以根据需要自行更改 :-) 这部分都是 c#。

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

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

于 2018-03-16T06:53:22.210 回答