本发明属于图像显示领域，特别涉及一种医学DICOM(Digital Imaging and Communications in Medicine，简称：DICOM)图像显示方法。
背景技术：
DICOM图像文件是X光、CT、MRI、超声等医疗造影设备所要遵循的一个国际标准。医疗造影设备产生的图像以文件的形式保存时也必须满足DICOM标准规定的格式来。DICOM文件的查看一般由专业软件来查看，常用的专用软件都是专门的桌面应用程序或者App。例如，HTML5DICOM Viewer是使用HTML5标准里面的Canvas元素(Element)显示DICOM影像的Web软件。但是传统的HTML5DICOM Viewer的实现方式一般是在服务器端只提供DICOM原始文件的下载，在浏览器页面中直接下载DICOM文件，然后用Javascript直接解码获得图像数据和病人信息、影像信息等，再直接使用Javascript计算窗宽窗位并在Canvas中显示出来。由于一个检查(Study)有很多个序列(Series)，每个序列(Series)也会有很多个实例(Instance)(一般一个实例是一个文件)。因此在实现过程中，有的程序或者系统在服务器端的数据库中缓存病人信息、影像信息等数据，这样便于Viewer先快速的把Study的结构显示出来。因为一个Study会有很多个DICOM文件，因此很多系统都会在网页里预先把一个Study的部分或者全部文件下载并缓存在网页中，缓存中的内容可能是原始的DICOM文件也可能是解析后的影像数据、病人信息。因为CT等设备的一个检查(Study)可能有多达几千个文件，每个文件都是512X512大小的分辨率，每个文件大小约530k左右，一个检查的文件总大小可达到几个G。这是很难在Javascript里直接缓存这么多数据量的。且窗宽床位的计算都是使用JavaScript来计算的，每次计算的过程都是分别取出每个原始像素的值，挨个像素根据应用窗宽窗位算出新的显示用的像素值。待全部像素值计算完成后，再通过js的putimagedata函数显示在Canvas中，从而做到显示一张图的效果。显示完一张图切换到下一张图时，从缓存或者服务器中取得下一幅图，然后应用窗宽床位计算公式再显示出来。
技术实现要素：
为了克服现有技术的不足，本发明的一个目的是提供了一种医学DICOM(Digital Imaging and Communications in Medicine，简称：DICOM)图像显示方法，能够加快客户端的图像加载速度，图像显示速度和操作影像速度，并且节省了用户的网络流量。
本发明提供的技术方案为：
一种医学DICOM图像显示方法，所述方法包括：
获取一患者的一项检查，所述检查中包括多个DICOM图像文件；
在服务器端对所述检查中的每个DICOM图像文件进行解析，获取所述每个DICOM图像文件中的元数据和图像，并将得到的所述检查中的所有元数据保存至一元数据文件中，且将得到的每个图像均保存为一个图片；
浏览器客户端通过HTTP请求所述服务器端的元数据文件和图片，首先显示所述检查的框架图，并使用所述浏览器客户端的HTML Appcache缓存暂不显示的图片，若进行所述检查的DICOM图像显示请求，则由所述浏览器客户端的HTML Appcache响应。
优选的是，所述的医学DICOM图像显示方法，所述首先显示所述检查的框架图，并使用所述浏览器客户端的HTML Appcache缓存暂不显示的图片，若进行所述检查的DICOM图像显示请求，则由所述浏览器客户端的HTML Appcache响应的步骤中，DICOM图像显示的具体方式为：
通过JavaScript的Image对象从所述服务器端加载元数据和图片；
通过WebGL技术调整待显示DICOM图像的窗宽和窗位，并通过Canvas对象获得待显示DICOM图像的像素值。
优选的是，所述的医学DICOM图像显示方法，所述服务器端的运行环境为共有云环境，所述元数据文件和图片均使用云存储；若浏览器客户端通过HTTP请求所述服务器端的元数据文件和图片时，则由云存储响应；并通过内容分发网络加速下载解析后的元数据文件和图片。
优选的是，所述的医学DICOM图像显示方法，所述若进行所述检查的DICOM图像显示请求，则由所述浏览器客户端的HTML Appcache响应，具体还包括：
当进行DICOM图像显示请求时，若所述浏览器客户端的HTML Appcache缓存执行成功，则DICOM图像显示请求通过所述浏览器客户端的HTML Appcache响应，若所述浏览器客户端的HTML Appcache缓存执行未成功，则DICOM图像显示请求由所述浏览器客户端向所述服务器端发出请求并获得响应。
优选的是，所述的医学DICOM图像显示方法，所述浏览器客户端的HTML Appcache缓存执行具体过程为：
若所述浏览器客户端未缓存所述检查的图片，则使用manifest文件的方式指定缓存所述检查的图片；
若所述浏览器客户端缓存的图片不是本次请求的所述检查的图片，则清空所述浏览器客户端缓存的图片；
若所述浏览器客户端缓存的图片是本次请求的所述检查的图片，则使用所述浏览器客户端缓存的图片，不再重新缓存。
优选的是，所述的医学DICOM图像显示方法，所述每个DICOM图像文件中的元数据包括：病人信息、检查信息、序列信息及图像信息；
优选的是，所述的医学DICOM图像显示方法，所述检查包括多个序列，每个序列均包括多个DICOM图像文件；
所述首先显示所述检查的框架图具体过程为：每个序列均显示该序列内的第一个图像的缩略图，并显示该序列内实例的数量；所述检查的框架图显示该框架内的第一张图像。
本发明至少包括以下有益效果：一、由于在服务器端对所述检查中的每个DICOM图像文件进行解析，获取所述每个DICOM图像文件中的元数据和图像，在系统整体上减少了传统viewer解析DICOM图像文件的时间。对于多达几千个DICOM图像文件的检查来说，这些时间的总和还是很客观的。二、在互联网上使用云存储和内容分发网络(Content Delivery Network，简称为CDN)响应图片请求，即最大限度利用了云计算的能力和优势，减少了我们自身服务器的压力，又能极大的提高全国甚至全球各地用户下载图片的速度和响应时间。三、使用HTTP直接下载图片，比传统的WADO模式下载图片省去了DICOM图像文件处理的过程，减少了服务器的压力和响应时间。四、使用HTML5Appcache缓存图像，既能在浏览器端缓存较大数据量的图片，提高图像加载的响应速度，又能透明的支持图像的访问，并且屏蔽了网络波动对图片下载的响应。同时由于在本地缓存，在此访问时避免了再次请求服务器，节省了网络流量。五、使用WebGL直接显示下载的图片，避免了使用Javascript解析DICOM图像文件，提高了处理文件的响应速度，避免了使用计算能力低的JavaScript进行大数据量的图像处理计算，让原来的窗宽窗位的计算由几十毫秒或者几百毫秒变成在1毫秒内即可完成。六、使用Canvas取得原始图像的像素值，避免了使用JavaScript解析图像获取像素值，提高了计算速度。
本发明的其它优点、目标和特征将部分通过下面的说明体现，部分还将通过对本发明的研究和实践而为本领域的技术人员所理解。
附图说明
图1为本发明所述的医学DICOM图像显示方法的流程示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
为了下述实施例的描述清楚，首先给出相关背景的简要介绍：
DICOM是医学图像和相关信息的国际标准，它定义了质量能满足临床需要的可用于数据交换的医学图像格式。
DICOM图像文件包含4个内容层次：病人(Patient)、检查(Study)、序列(Series)和图像(Image)。
DICOM图像文件是由DICOM文件头(DICOM File Meta Information)和DICOM数据集(Data Set)组成的，且数据集放在文件头之后。数据集，由多组数据元素组成，它包括病人信息、检查信息、序列信息及图像信息，是DICOM图像文件的主要部分。
为使本发明技术方案的优点更加清楚，下面结合附图和实施例对本发明作详细说明。
如图1所示，本发明实施例提供的医学DICOM图像显示方法，所述方法包括：
S110、获取一患者的一项检查，所述检查中包括多个DICOM图像文件。
S120、在服务器端对所述检查中的每个DICOM图像文件进行解析，获取所述每个DICOM图像文件中的元数据和图像，并将得到的所述检查中的所有元数据保存至一元数据文件中，且将得到的每个图像均保存为一个图片。
其中，所述每个DICOM图像文件中的元数据包括：病人信息、检查信息、序列信息及图像信息。
其中，所述检查包括多个序列，每个序列均包括多个DICOM图像文件。
需要说明的是，CT、MRI等设备一次扫描产生的影像叫一个检查(Study)，每个检查分成多个序列(Series)，每个序列又包含多个实例(Instance)，每个实例文件都包含图像和病人信息、影像信息等数据，所以每个检查中都包含大数据量的DICOM图像文件。每个DICOM图像文件可能会有一幅或多幅图像，解析完成后，每一幅图像保存为一张图片。解析后的所有元数据可以保存到数据库中，也可以按照图像的结构保存到一个元数据文件(例如JSON文件)中。元数据文件中记录了每个序列的每个实例的每张图片的访问路径信息。保存的图片是完整保存了所有灰度值的图像，不是DICOM文件转换后显示时的8位灰度图像。图片的保存方式和格式可以有很多种，可以按照需求进行选取，本发明实施例不做具体的限定。
S130、浏览器客户端通过HTTP请求所述服务器端的元数据文件和图片，首先显示所述检查的框架图，并使用所述浏览器客户端的HTML Appcache缓存暂不显示的图片。
其中，所述首先显示所述检查的框架图具体过程为：每个序列均显示该序列内的第一个图像的缩略图，并显示该序列内实例的数量；所述检查的框架图显示该框架内的第一张图像。
其中，所述服务器端的运行环境为共有云环境时，所述元数据文件和图片均使用云存储；若浏览器客户端通过HTTP请求所述服务器端的元数据文件和图片时，则由云存储响应；并通过内容分发网络(Content Delivery Network，简称为CDN)加速下载解析后的元数据文件和图片。
需要说明的是，若服务器端是部署在传统服务器上，则直接将解析生成的图片和显示用到的元数据文件(JSON文件)保存到磁盘或者NAS(Network Attached Storage：网络附属存储)等存储中，可以部署一个Httpserver直接从存储中取得元数据文件并输出到HTTP请求。
S140、若进行所述检查的DICOM图像显示请求，则由所述浏览器客户端的HTML Appcache响应。
其中，所述首先显示所述检查的框架图，并使用所述浏览器客户端的HTML Appcache缓存暂不显示的图片，若进行所述检查的DICOM图像显示请求，则由所述浏览器客户端的HTML Appcache响应的步骤中，DICOM图像显示的具体方式为：
通过JavaScript的Image对象从所述服务器端加载元数据和图片；
通过WebGL技术调整待显示DICOM图像的窗宽和窗位，并通过Canvas对象获得待显示DICOM图像的像素值。
需要说明的是，进行DICOM图像显示时，是直接将下载获得的图片转换成对应Canvas对象的WebGL纹理对象，然后使用WebGL的shader语言编写处理窗宽窗位和Modality LUT处理的程序。在调整窗宽窗位时，只需要将新的窗宽窗位的值传递给WebGL的shader程序，即可快速切换窗宽窗位的值。如果需要获得图像某一区域的原始的DICOM图像的像素值，则使用一个新的Canvas对象，直接用drawimage绘制下载所得图像的指定区域，然后用canvas的getimagedata取得像素值，然后通过计算可得原始的DICOM值。
具体的，由所述浏览器客户端的HTML Appcache响应，还包括两种情况：
当进行DICOM图像显示请求时，若所述浏览器客户端的HTML Appcache缓存执行成功，则DICOM图像显示请求通过所述浏览器客户端的HTML Appcache响应，若所述浏览器客户端的HTML Appcache缓存执行未成功，则DICOM图像显示请求由所述浏览器客户端向所述服务器端发出请求并获得响应。
但是，所述浏览器客户端的HTML Appcache缓存执行过程又包括下述几种情况：
若所述浏览器客户端未缓存所述检查的图片，则使用manifest文件的方式指定缓存所述检查的图片；
若所述浏览器客户端缓存的图片不是本次请求的所述检查的图片，则清空所述浏览器客户端缓存的图片；
若所述浏览器客户端缓存的图片是本次请求的所述检查的图片，则使用所述浏览器客户端缓存的图片，不再重新缓存。
需要说明的是，DICOM解析生成后的图片使用HTML5标准规定的Appcache(https://www.w3.org/TR/html5/browsers.html#offline)方式缓存到浏览器的本地磁盘。由于每个检查的数据量比较大，因此在浏览器本地一般只缓存1个或者很少的几个检查。
如上所述，本发明实施例能够加快客户端的图像加载速度，图像显示速度和操作影像速度，并且节省了用户的网络流量。
尽管本发明的实施方案已公开如上，但其并不仅仅限于说明书和实施方式中所列运用，它完全可以被适用于各种适合本发明的领域，对于熟悉本领域的人员而言，可容易地实现另外的修改，因此在不背离权利要求及等同范围所限定的一般概念下，本发明并不限于特定的细节和这里示出与描述的图例。