html5图片缓存加载,DICOM图像的加载与缓存 by 微至云动云影像 - 极速/专业的互联网医疗影像浏览器 ，HTML5 DICOM Viewer,MPR,互联网医学影像，云影像，云PACS,云报...

就如在《DICOM HTML5

Viewer技术揭秘系列之三-DICOM与图像压缩》文中提到的，图像包含DICOM影像都是是一组2维的像素值的数组，DICOM图像的传输可以直接传输原始的DICOM文件，也可以直接传输DICOM文件中的图像像素数组。但对于互联网上的Web版的云PACS来讲，原始的DICOM影像都是存储在云端的云存储中，而浏览器的内存、磁盘等限制也不允许在DICOM HTML5

Viewer中一次性将全部影像下载到浏览器端。不过在客户端模式的云PACS中倒是可以这么做。

由于一个CT或者MRI检查通常会包含几百上千个DICOM文件，在客户端某一时刻要查看的只是其中的一小部分而已，这就允许我们在图像的加载(预先加载)和缓存策略上下一番功夫，真正提高HTML5

Viewer的用户体验。这种细节处的优化功夫，才正是考校DICOM HTML5 Viewer水平高低和产品成熟度的一个重要考察点。

本文主要将微至云动云影像团队实现DICOM HTML5 Viewer过程中的各个技术点做一个总结，写成文字供大家参考，同时也希望起到一个抛砖引玉的作用，请各位专家、牛人不吝赐教。

DICOM图像加载

如上文所讲，DICOM图像在浏览器端的加载可以是一个原始的DICOM文件，也可以是包含图像像素值数组。本文中不再讨论DICOM图像数据在DICOM HTML5

Viewer中的存储格式，而是主要探讨DICOM图像数据如何从云PACS的云端存储中传输到浏览器中。从现有的HTML5规范来讲，可以使用的图像的加载方式主要是下面两种，并且是各有利弊的：

HTTP下载的方式：将一个DICOM影像数据通过一次HTTP请求(一般是GET)直接传输到浏览器中。这种方式的兼容性最好，并且实现也最为简单。并且配合Cache-Control、Expires等HTTP Header能够简单的实现数据和图像的缓存。

WebSocket传输 ：WebSocket传输本质上是为浏览器提供了一个使用流式接口(Stream API)访问服务器端数据的方式。使用WebSocket传输数据性能更好，数据安全性也更好。但WebSocket对服务器和浏览器的变成实现要求更高更复杂，更需要支持由于网络的原因导致的WebSocket链接中断等问题。

以上两种方式各有利弊，第二种方式虽然理论上性能和安全性更好，但第一种方式更适合互联网的复杂的网络环境，因此在Dodo DICOM HTML5 Viewer中使用的是一种方式。

DICOM图像缓存

不管是DICOM影像还是普通数据，使用Javascript进行浏览器端编程时，都需要考虑在浏览器端进行缓存的问题。通过将某些不变的数据保存在浏览器端，而不是每次使用时都直接向服务器端请求，从而通过缓存给用户带来更好的体验。一般来讲，DICOM影像数据都是一旦生成之后就不再变化，因此可以通过在浏览器端缓存DICOM图像数据的方式，提高DICOM HTML5 Viewer的用户体验。

在Javascript进行浏览器端编程时，浏览器端的图像缓存或者数据缓存方案，其实还是有几个方案可以考虑的：

浏览器的HTTP缓存：通过Cache-Control、Expires等HTTP Header，或者 If-Modified-Since等HTTP Header，借助浏览器和HTTP协议本身提供的缓存能力来加快图像的加载。

使用HTML5

LocalStorage,SessionStorage等本地存储来暂存图像数据到浏览器端。HTML5规范新增的LocalStorage等让浏览器拥有了保存数据的能力，通过这些数据保存能力可以实现一些复杂的可长久保存的数据缓存策略。

Javascript内存缓存：说到HTML5的能力，基本上就是需要借助Javascript来操作浏览器，实现用户所需要的功能。JavaScript可以通过数组等方式直接将DICOM影像数据保存到Javascript对象中，这样的缓存能力最强并且速度也非常快速，但是这个缓存只存在于网页打开时。刷新和关闭网页都将导致缓存数据丢失。

上述几个缓存的实现办法各有各的优点，微至云动云影像的实现是组合了上述各个方法的一个组合方案，同时我们也在不断的改进和优化图像的加载和缓存算法，从而期望为用户提供更好的用户体验。

参考资料

HTML5标准：https://www.w3.org/TR/html5/

新版HTML5标准草案，当前是5.2：http://w3c.github.io/html/

HTTP Header的RFC文档：https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html