云胶片（云影像）H5原始图像浏览

1 技术和通讯方案

       目前，前端展示，绝大部分厂商还是采用Html5方式实现的，也有个别公司采用QT+UDP通讯方式的技术路线来开发跨平台客户端。虽然利用QT或者Flash也能实现跨平台，而且可以利用UDP通讯方式，可实现速度更快的传输效果，但是，个人还是偏向于H5方式，毕竟原生客户端方式浏览器，在共享和分发上是软肋，而且随着5G的到来，传输速度的问题一定可以解决。客户端实现方式中，西安#谷最具代表。他们的传输方式是UDP的，体感还是很不错的，他们的缺点就是所有渲染全部都在服务器端，需要耗费大量的计算资源。

       重点说下，Html5的技术方案。也有两种不同的技术实现方式。一种是将所有的DICOM图像解析和后处理，甚至包括MPR渲染计算都放在前端通过JS来进行处理。确定也是显而易见的，展现到用户给终端用户花费的时间比较长，例如，在定位图上展现另外序列（Series）的定位线，必须要等待序列全部都下载完毕后，操作者才能进行交互操作。在网速慢的时候，体感就很差。另外一种方式，所有的图像都的解析和后处理全部都在后端处理，以常见的16bit图像为例，会将窗宽窗位后的8Bit图像压缩为jpeg格式，通过websocket直接下载到前端展示，为了进一步减少传输量，还能根据网速动态调整jpeg压缩质量。例如，加那大的ResMD公司，国内杭州全球影大象也有直接购买他们技术产品。这种技术路线，会将用户所有的操作命令，回传到服务器，服务器将处理好的结果直接发送到前端。这种方案的优点单次传输图像的数据量小，特别在网速慢的时候，体感会大幅提升，同样缺点也是有的，这种体感是有极限的，因为所有图像最终效果的展示都是通过后端渲染好，传输的前端，所以，都没有将所有图像下载本地，处理的速度快；而且，后台CPU一直都会使用，计算资源要求比较多。综上，可知，在网速慢的时候，或者效果不需要这么专业时候（患者的云胶片），第二种方案更好；但是，对于专业的网速快的医生端，反而第一种方案更优。

2 我们采用的技术和通讯方案

      很明显，如果将上述的方案整合在一起，就是一个更好的解决方案。所有影像的元信息（tag信息，例如，wl，pixel size，patient name等）文本信息，都通过websocket的方式传输到前端，这样前端可以利用这些信息，去生成列表，缩略图，定位线等展示信息。影像二进制数据，可以通过websocket获取，这种方式也是通过后台将图像处理成8bit的jpeg发送到前端；也可以将16bit图像压缩成png格式，通过ajax的方式下载到前端。 这样，在加载影像初段，图像还未从院内PACS系统或者云PACS系统中MOVE到引擎中，如果操作者要查看某张图像，可以直接通过后台将此图像以jpeg的格式发送到前端。在影像加载的中，后段，所有的影像二进制数据都以png格式方式发布到一个后台缓冲中，完全可以通过http的ajax的方式下载，这样就可以直接在前台进行js展示。

3 挂片协议
    最近看了几家的浏览器，特别是通过互联网提供给院方的AI结果，先不说影像浏览器的使用是否合理，光是下载速度，交互速度的体感就很不好。因为，目前所有的厂商其实面对的问题都是很复杂的，场景多，设备模态多，网络情况复杂，终端多，最终导致配置杂，代码维护难度陡增。其实，细心点我们就会发现，dicom标准中早就给大家指出了解决方案，那就是挂片协议。只是需要程序员理解后，做些其他的扩展修改。这是静态类的一个详细设计，给工程师同行们做个参考。

这样就可以通过配置挂片协议来适应各种的应用，例如在会诊中的多检查，多报告展示；AI应用中，直接显示病灶影像的某一张图，都可以通过挂片协议来进行配置，大大的降低代码维护难度。

下边是H5浏览器的展示

5 运维

       工程实现中，渲染引擎，还必须要有计算资源负载，编写运维工具，可以查看到各个渲染引擎的当前的状态。