2

我需要知道是否需要在浏览器上显示 DICOM 图像，应该遵循哪种方法？我的图像服务器在云上的其他地方。需要访问dicom图像，在画布上绘画，如果用户编辑则将编辑后的图像上传到服务器。还需要有良好的性能，因为 DICOM 图像的大小非常大（~1gb），这是最好的方法吗？

4

3 回答 3

2

1) DICOM 图像通常不会被用户修改。（可能是注释或窗口/中心值），但它是不同的。

2) 大多数 DICOM 图像约为 1Mb，因此您的图像非常特别。我怀疑大多数标准观众会加载它们。

3) 没有显示器能够一次显示 1Gb，因此发送小分辨率版本的图像（最大 1mpx）就足够了，并且只发送缩放区域的更新。

鉴于这一切，您必须更好地解释您的问题。

于 2010-12-20T21:02:10.447 回答
2

DICOM 并不是真正为这个用例设计的。不仅 DICOM 图像通常不会被用户修改（尽管这是真的）。当您更改像素数据时，更改图像的标识符（SOPInstanceUID）可能是有意义的，您应该更改图像的类型以表明它现在是派生图像。

如果您正在修改像素数据，创建新图像可能是最安全的，因为 DICOM 图像通常是作为患者病历一部分的医学图像。不应修改它们。如果（例如）原件上的肿瘤图像被移除，因为放射科医生在初始诊断中错过了这些图像的未决诉讼，该怎么办？

如果您不进行医学图像处理..您应该避免使用 DICOM。它在其预期用途中是一个很棒的协议，但它并不是真正的通用分布式图像编辑协议。

我所知道的这种方法 1GB 的唯一医学图像是病理图像。为此，您可能会考虑使用 JPIP 来查看图像（这甚至在 DICOM 规范中也是如此）。但这对编辑部分没有帮助，因为 JPIP 用于消费图像，而不是增量修改它们。

于 2011-01-17T15:21:47.457 回答
1

正如 ruslik 所提到的，DICOM 图像的大小和性质使其成为一个棘手的技术问题。业内人士正在使用几种方法来构建 Web 查看器：

  • Flash、Silverlight 或 Active X（在过去）等客户端技术用于制作能够自行完成大部分图像处理的客户端。客户端从服务器接收图像，然后对图像的客户端进行一些操作。诸如窗户平整广告注释之类的事情是在客户端上完成的。
  • 使用零占用客户端，其中完成服务器端渲染，并在用户与图像交互时按需将简单的 JPEG 图像发送到客户端。客户端全部用 Javascript 和/或 HTML5 完成，可以在任何浏览器上运行。
  • 前两者的结合，其中使用了 Flash 或 Silverlight 等客户端技术，但也进行了服务器端渲染以简化客户端。JPEG 或 PNG 图像被发送到客户端。

我认为您很可能会选择其中一种解决方案。最后一点，当新的Healthcare IT Stack Exchange 站点进入测试版时，这将是一个很好的问题。

于 2010-12-22T14:47:27.910 回答