一种应用于云胶片系统的原始DICOM影像下载方法与流程

一种应用于云胶片系统的原始dicom影像下载方法
技术领域：
1.本发明属于原始dicom影像下载技术领域，具体涉及一种应用于云胶片系统的原始dicom影像下载方法。


背景技术：

2.数字影像是指医疗机构在x线计算机体层(ct)扫描、磁共振扫描(mri)、x线检查时，将原始生成的无损压缩dicom格式图片储存在服务器上，可通过授权在手机端下载并不限次数直接浏览的影像。数字影像统称为云胶片。
3.云胶片通过多种互联网入口，如检查二维码、医院公众号和云胶片服务号等，并需要使用微信小程序进行开发以及最终实现在手机端采用h5原始影像进行浏览。目前的云胶片在手机端基本是通过微信小程序或者公众号的形势展示。随着检查设备精度的提升，一次ct扫描产生的影像能达到几百至上万张，当用户通过云胶片系统下载原始dicom影像数据给医疗机构或医生诊断时，由于手机端的微信小程序内嵌的浏览器，下载原始dicom图像时，会一张一张下载，且每下载一张图像就会提醒手动端保存一次，也就意味着需要在手机端操作下载保存几百次。这对于用户来说，无疑是增加了操作的负担，严重影响云胶片系统的体验，另外，频繁下载保存图像，增加了手机的存储碎片，降低了手机性能。


技术实现要素：

4.本发明实施例提供了一种应用于云胶片系统的原始dicom影像下载方法，解决了应用于云胶片系统的原始dicom影像下载过程中浏览器下载一张图像需要提醒保存一次的问题。
5.本发明实施例提供了一种应用于云胶片系统的原始dicom影像下载方法，包括以下步骤：
6.将原始dicom影像依次进行无损压缩、存储以及优化下载。
7.在本发明某些实施例中，包括以下步骤：
8.将原始dicom影像依次进行无损压缩、存储以及批量下载。
9.在某些实施例中，采用jpeglossless无损压缩方式对服务器上的原始dicom影像进行无损压缩。
10.在本发明某些实施例中，采用zip存储方式对服务器上的仅经过无损压缩后的指定批量原始dicom影像复制至同一压缩包内并不进行任何压缩操作。
11.在某些实施例中，采用http断点续传方式将指定原始dicom影像进行批量下载。
12.在本发明某些实施例中，所述指定原始dicom影像在进行批量下载的过程中，采用所述http断点续传方式，能够实现从所述指定原始dicom影像上次下载中断的节点开始重新下载。
13.在某些实施例中，在客户端侧包括如下步骤：
14.(1)浏览所述批量指定原始dicom影像；
15.(2)请求下载整个所述批量指定原始dicom影像；
16.(3)提示本地客户端中所述批量指定原始dicom影像存储位置；
17.(4)发送http断点续传请求。
18.在某些实施例中，在服务器侧包括如下步骤：
19.(1)等到客户端侧的步骤(3)完成后，响应下载批量指定原始dicom影像请求；
20.(2)判断是否已经将所述批量指定原始dicom影像打包；
21.(3)在服务器侧的步骤(2)处于已经将所述批量指定原始dicom影像打包的状态下，进入服务器与客户端之间的http断点续传的下载环节；
22.(4)在服务器侧的步骤(2)处于没有将所述批量指定原始dicom影像打包状态下，进入将所述批量指定原始dicom影像打包的环节，其中依次经过步骤：从存储系统下载文件到临时目录、对临时目录进行压缩文件名称设置、设置压缩模式为“存储模式”、开始循环压缩、产生批量指定原始dicom影像归档，并在将所述批量指定原始dicom影像打包的环节结束后，循环进入服务器侧的步骤(2)环节，直至将所述批量指定原始dicom影像打包完成，才能进入服务器侧的步骤(3)环节。
23.在某些实施例中，该应用于云胶片系统的原始dicom影像下载方法还包括位于客户端侧步骤(2)和步骤(3)之间的分解信息处理单元，所述分解信息处理单元包括如下步骤：
24.(1)获取患者检查后得到的原始dicom影像的元数据信息；
25.(2)响应所述分解信息处理单元中的步骤(1)请求；
26.(3)查找患者检查后得到的原始dicom影像文件；
27.(4)遍历解析获取原始dicom影像的元数据信息；
28.(5)去除同一序列的冗余原始dicom影像的元数据信息，保留单张图像的个性信息；
29.(6)建立以序列为父节点，图像为子节点的内存json数据结构；
30.(7)获取json数据结构信息；以及
31.其中，客户端侧的步骤(2)完成后直接进入所述分解信息处理单元中的步骤(1)；所述分解信息处理单元中的步骤(7)完成后直接进入客户端侧的步骤(3)。
32.在某些实施例中，在所述客户端侧的步骤(2)完成后，在客户端侧还包括如下步骤：
33.像素信息压缩包下载完成；
34.json元数据和像素数据还原成原始文件。
35.本发明实施例中的应用于云胶片系统的原始dicom影像下载方法采用zip的存储模式，把服务器上几千张图像打包成一个文件进行下载，通过http断点续传方式，从而实现手机端的图像下载调阅，解决了浏览器下载一张图像需要提醒保存一次的问题。http属于无状态传输协议，该应用于云胶片系统的原始dicom影像下载方法通过断点续传方式，减少http冗余请求次数，提升了下载效率，方便用户手机端调阅和下载图像，避免了多次频繁重复保存操作。
36.本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书以及
附图中所特别指出的结构来实现和获得。
附图说明：
37.附图用来提供对本发明进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
38.图1为在一实施例中应用于云胶片系统的原始dicom影像下载方法的一流程图；
39.图2为在一实施例中应用于云胶片系统的原始dicom影像下载方法的另一流程图；
具体实施方式：
40.为了使得本发明的技术方案的目的、技术方案和优点更加清楚，下文中将结合本发明具体实施例的附图，对本发明实施例的技术方案进行清楚、完整的描述。附图中相同的附图标记代表相同的部件。需要说明的是，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于所描述的本发明的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
41.如图1所示，在一实施例中提供了一种应用于云胶片系统的原始dicom影像下载方法，包括以下步骤：
42.将原始dicom影像依次进行无损压缩、存储以及优化下载。其中，优化下载指提升下载效率。
43.优选地，将原始dicom影像依次进行无损压缩、存储以及批量下载。其中，批量下载是优化下载的一种优选方案。
44.其中批量下载是指两张以上原始dicom影像作为一批次下载，当然在本发明实施例中原始dicom影像单批次规模涉及几百张，甚至几千张。
45.为了解决手机浏览器下载该原始dicom影像时，需要一张张保存原始dicom影像的问题，可以将服务器上原始diocm图像打包成一个文件进行下载。
46.原始diocm图像即医学图像具备数据量大的特性，大数据量的图像信息会给服务器的存储空间、通信以及计算机的处理速度增加极大的压力。单纯靠增加服务器存储、提高网络带宽以及提升计算机的处理速度等方法来解决这个问题是不现实的，因此需要对医学图像进行压缩处理。
47.其中，由于医学图像具备重要的医学价值，因而采用jpeglossless无损压缩方式对服务器上的原始dicom影像进行无损压缩，该无损压缩方式只是消除了医学图像的冗余度，医学图像并没有任何信息损失。
48.考虑到之前已经对原始dicom影像进行无损压缩处理，再采用zip压缩没有任何意义，在某些情况下反而会带来空间浪费，因而在采用zip存储方式对服务器上的仅经过无损压缩后的指定批量原始dicom影像复制至同一压缩包内时并不进行任何压缩操作。具体地，在本发明实施例中采用winzip存储方式将服务器上几千张图像的像素数据打包成一个文件。
49.如图1所示，在一实施例中，采用http断点续传方式将指定原始dicom影像进行批量下载。通过http断点续传方式，从而实现手机端的图像下载调阅。
50.而指定原始dicom影像在进行批量下载的过程中,每次出现异常或者用户主动的
暂停,都会去重头下载,这样很浪费时间，而采用http断点续传方式，能够实现从指定原始dicom影像上次下载中断的节点开始重新下载。
51.其中，指定原始dicom影像在采用http断点续传方式进行批量下载过程中，客户端记录当前指定原始dicom影像下载进度，并在需要续传时，通知服务器本次需要下载的指定原始dicom影像内容片段。
52.其中，采用http断点续传方式对指定原始dicom影像在进行批量下载过程中，在http的请求上多定义了断点续传相关的http头range和content
‑
range字段。
53.如浏览器请求服务器上的一个文件名为externaldoc.zip时,请求内容只展示了一些与本文有关的信息
54.get/externaldoc.zip http/1.1accept
‑
language:zh
‑
cnaccept
‑
encoding:gzip,deflateconnection:keep
‑
al ive；
55.2.服务器收到请求后,按要求寻找请求的文件,提取文件的信息,然后返回给浏览器,返回信息如下:
56.200content
‑
length＝66667777accept
‑
ranges＝bytescontent
‑
type＝application/octet
‑
stream；
57.为了实现从文件已经下载的地方开始继续下载。所以在客户端传给服务器的时候要多加一条信息
‑‑
从哪里开始。下面是客户端请求时的请求信息,要求从44445555字节开始。
58.get/externaldoc.zip http/1.0user
‑
agent:netfoxrange:bytes＝44445555
‑
；
59.上面的请求信息多了一个新的字段range range:bytes＝44445555
‑
；
60.这段话的意思就是告诉服务器externaldoc.zip这个文件从44445555字节开始传,前面的字节不用传了。服务器收到这个请求以后,返回的信息如下:
61.206content
‑
length＝66667777content
‑
range＝bytes44445555
‑
66667777content
‑
type＝application/octet
‑
stream；
62.和第一次服务器返回的信息相比,增加了一行:
63.content
‑
range＝bytes 44445555
‑
66667777；
64.返回的代码也改为206了,而不再是200了。
65.但是在实际场景中，会出现一种情况，即在终端发起续传请求时，url对应的文件内容在服务端已经发生变化，此时续传的数据肯定是错误的。此时需要有一个标识文件唯一性的方法。在rfc2616中也有相应的定义，比如实现last
‑
modified来标识文件的最后修改时间，这样即可判断出续传文件时是否已经发生过改动。同时rfc2616中还定义有一个etag的头，可以使用etag头来放置文件的唯一标识，比如文件的md5值。
66.终端在发起续传请求时应该在http头中申明if
‑
match或者if
‑
modified
‑
since字段，帮助服务端判别文件变化。
67.另外rfc2616中同时定义有一个if
‑
range头，终端如果在续传是使用if
‑
range。if
‑
range中的内容可以为最初收到的etag头或者是last
‑
modfied中的最后修改时候。服务端在收到续传请求时，通过if
‑
range中的内容进行校验，校验一致时返回206的续传回应，不一致时服务端则返回200回应，回应的内容为新的文件的全部数据。
68.如图1所示，在一实施例中，在客户端侧包括如下步骤：
69.(1)浏览批量指定原始dicom影像；
70.(2)请求下载整个批量指定原始dicom影像；
71.(3)提示本地客户端中批量指定原始dicom影像存储位置；
72.(4)发送http断点续传请求。
73.在本发明某些实施例中，在服务器侧包括如下步骤：
74.(1)等到客户端侧的步骤(3)完成后，响应下载批量指定原始dicom影像请求；
75.(2)判断是否已经将批量指定原始dicom影像打包；
76.(3)在服务器侧的步骤(2)处于已经将批量指定原始dicom影像打包的状态下，进入服务器与客户端之间的http断点续传的下载环节；
77.(4)在服务器侧的步骤(2)处于没有将批量指定原始dicom影像打包状态下，进入将批量指定原始dicom影像打包的环节，其中依次经过步骤：从存储系统下载文件到临时目录、对临时目录进行压缩文件名称设置、设置压缩模式为“存储模式”、开始循环压缩、产生批量指定原始dicom影像归档，并在将批量指定原始dicom影像打包的环节结束后，循环进入服务器侧的步骤(2)环节，直至将批量指定原始dicom影像打包完成，才能进入服务器侧的步骤(3)环节。
78.如图2所示，在一实施例中，该应用于云胶片系统的原始dicom影像下载方法还包括位于客户端侧步骤(2)和步骤(3)之间的分解信息处理单元，分解信息处理单元包括如下步骤：
79.(1)获取患者检查后得到的原始dicom影像的元数据信息；
80.(2)响应分解信息处理单元中的步骤(1)请求；
81.(3)查找患者检查后得到的原始dicom影像文件；
82.(4)遍历解析获取原始dicom影像的元数据信息；
83.(5)去除同一序列的冗余原始dicom影像的元数据信息，保留单张图像的个性信息；
84.(6)建立以序列为父节点，图像为子节点的内存json数据结构；
85.(7)获取json数据结构信息；以及
86.其中，客户端侧的步骤(2)完成后直接进入分解信息处理单元中的步骤(1)；分解信息处理单元中的步骤(7)完成后直接进入客户端侧的步骤(3)。
87.优选地，在客户端侧的步骤(2)完成后，在客户端侧还包括如下步骤：
88.像素信息压缩包下载完成；
89.json元数据和像素数据还原成原始文件。
90.针对医学影像如ct，核磁等多序列的影像数据，将医学影像数据分为像素数据和data set数据信息。分别对像素数据和data set数据信息进行处理；
91.医学影像dicom文件的结构，包括文件头和像素数据，文件头信息包括文件引言meta info和数据集data set。对于ct，核磁等多序列的影像数据，文件头中data set的信息数据有90％是冗余的。因此需要对data set信息进行单独处理，提取公共部分和个性部分，公共部分只保留一份，如json元数据；
92.单张图像的data set占据的磁盘存储空间，大概为16k。一般1个人做一次ct检查有10几个序列，其中一个序列按照1000张图像计算，那么这个人单个序列的data set信息
就占据了16000k，即为16m，按照这个人ct检查做了10个序列来计算，那么他本次ct检查，将产生16m*10，即为160m。占据的存储空间是非常大的。
93.因此，分解信息处理单元用来解决医学影像图像下载的问题，其中将医学影像进行分解，分解为像素信息下载和data set信息处理下载，从而提升下载效率，节约带宽。
94.本发明实施例中的应用于云胶片系统的原始dicom影像下载方法采用zip的存储模式，把服务器上几千张图像打包成一个文件进行下载，通过http断点续传方式，从而实现手机端的图像下载调阅，解决了浏览器下载一张图像需要提醒保存一次的问题。http属于无状态传输协议，该应用于云胶片系统的原始dicom影像下载方法通过断点续传方式，减少http冗余请求次数，提升了下载效率，方便用户手机端调阅和下载图像，避免了多次频繁重复保存操作。
95.本发明方案所公开的技术手段不仅限于上述技术手段所公开的技术手段，还包括由以上技术特征等同替换所组成的技术方案。本发明的未尽事宜，属于本领域技术人员的公知常识。