一切为了效率——移动端轻量级影像研发的几个问题
作者：姜疆
编者按：本文作者江湖绰号“姜思密达”，目前在成都进行移动端医学影像工具的创业工作，产品不断完善中，目前正寻求第一轮融资，听说他要的不多哦。而关于医学影像传输，这也是一个学术挑战，其实国内所有仿照figure1，以医学图片分享为切入点进行创业的公司，都绕不过去这个问题，本文也尝试进行一些学术探讨，欢迎其它团队拍砖和提供更好的技术路线触手。另外他们准备将产品封装成SDK，我司珍立拍准备第一个支持他们，选择他们的轻量级图像引擎服务医务工作者。
医学PACS影像是唯一的不受地域限制就能够无损传输的纯数字化数据，基于此我们可以将其尽量延伸到移动端。互联网带给我们的趋势就是工作时间越来越被碎片化。如何轻巧地在移动端显示PACS影像是一个挑战。
技术选型问题
很多的PACS架构设计都比较偏“重型”，有的使用ActiveX技术做到了在PC端网页下载插件程序的方式浏览影像。但是这种方式并不能扩展到移动端。为了适应移动端的环境，我们需要在Android和iOS部署两个开发团队。这样的开发成本对于移动医疗创业型公司来说是一个负担，不仅仅被操作系统厂商牵着鼻子走，还需要谨小慎微地熬过AppStore的审核。快速迭代和持续交付就是一个头疼的问题。在这样的局势下，跨平台的HTML5开发可能是比较好的解决方案之一。
HTML这种技术可以在pc和各个移动端顺畅的使用一套核心代码，而且体验也相差无几。这样的架构无论是对于SAAS架构的系统还是移动端跨平台的应用都有重要的意义。从技术特性上来说，跨平台数据交换，网页嵌入式推广（想想用微信瞬间就关注加载的好处吧）都非常符合当前移动医疗发展的趋势，医生随时随地地高效协同和办公，这就是大家需要力求实现的场景。
H5技术并不是非常完美的技术，在交互性方面并不能100%达到原生可执行程序和APP的交互性。这个时候需要做出一个平衡，为了更好的适配各种大小的屏幕和平台以及满足各个角色社交网络的参与性，H5就像一个流动的胶水，大家不能理解它仅仅是一种生硬的开发技术，而且在推广营销方面，它也有一定的优势。，目前情况下H5+JavaScript是比较好的选择。
效率问题
1）存储效率
PACS是一个大块头的应用，尽管业务流程比不上HIS系统那么复杂，但是数据量都比较大。往往我们在以一个三级医院里面看到，PACS的数据是几十个T非常常见。传统的PACS系统往往后端存储的架构设计比较复杂，什么“分级存储”、“NAS”、”SAN”都是我们经常听到的名词。不过因为云存储架构的出现，我们可以把这些传统的概念抛之脑后。我们曾经在七牛云存储和阿里云存储之间做了测试，综合考虑目前选择阿里云的OSS存储。阿里云put Object方式最大是5GB, 使用multipart上传方式object大小上限是48.8TB，这个对于PACS影像传输来说是绰绰有余。在阿里云存储中每一个对象是一个Object，所有的对象放在一个Bucket里面。也没有什么文件数量的限制，你可以想象通过阿里云的OSS建立一个面向全球的影像存储中心。为了测试部署在青岛机房的阿里云应用，也请美国的朋友做了下载测试，效果非常好。目前阿里云在美国也有机房，如果使用镜像站点，这种技术就可以在全球顺利地开拓市场了。今天的云存储发展已经今非昔比，云端数据的安全性更加牢固稳定，我们的担心很多都是多余的。BGP多线骨干网络接入，处理海量文件的能力（1个文件和十亿个文件毫无差别），让我们可以专心研发影像的前端展现，而不需要担心网络及存储架构，可以说”轻量级的影像展现+云存储“将会把传统PACS颠覆掉一大半。大家没有必要去研究云存储的底层架构，但是需要知道它们的大致特性和技术特点，通过实践合理运用。
目前第一阶段仅仅是把DICOM影像的索引放在阿里云的RDS(数据库服务)里面，存储在mysql数据库里面。后续更加科学的方式应该是我们对于Object文件进行再次封装，重新定义一个存储对象，将数据库的病人信息用json对象的方式和DICOM文件对象整合，构造一个新的对象，我们可以考虑试试比如RethinkDB之类的JOSN数据库。这些松散的数据可以像珠子一样散落在云存储里面，需要的时候可以通过JSON数据库让他们打起精神来，就像是《超能陆战队》智能磁性小机器人一样按照要求排列组合。这样的好处是，区域影像中心和影像社区可以把数据更加容易整合在一起，数据要为利用而生而不是为了各自利益而圈养在自家后院，其实用亚马逊或者金山云道理也完全一样，我们只需要综合平衡性价比和服务质量。
2）影像展现效率
首先，我们将上传到云存储端的影像做一定的裁剪算法处理，就像是用剪刀裁剪照片修边一样，照片就是DICOM像素矩阵，我们把周围的边界阴影部分尽量裁切处理，只留有效的影像部分。大致思路如下：
对一幅图像总是可以看作由感兴趣的前景和背景构成，区分前景和背景的这样一个值的选取是直接关系到整个医学图像处理的质量。在此我们采用otsu法来获取这一阈值。最大类间方差法(otsu)得到的是一个前景和背景图像的方差最大时的一个灰度阈值。当方差最大时，可以认为此时的前景和背景差异是最大的，选取这样一个阈值来作为灰度图像二值化的阈值得到二值化的图像数据或图像矩阵。这样做二值化处理是为了方便后面对图像矩阵作方向上的投影。得到的投影数据根据裁剪阈值得到一个更为精确的图像位置大小信息。裁剪阈值是根据大量的医学图像实验和统计来得到。这里阈值设定有两个作用，一是排除少量由噪声造成的有效数据的影响，二是设置图像无效数据的裁剪度。这一位置大小信息的获取便是下一步图像裁剪的重要参数，这样直接对原图数据作裁剪保存得到的数据为无失真数据，也达到了节约存储空间和上传下载时间的目的。这个裁剪阈值以后会有点意思，如果机器能够自我学习，自我进化能够一刀一个准，越来越精准，那这个算法就非常完美啦。对于图像的算法处理也是无止境。
通过验证证明，一个序列92张图像，平均裁剪效率大约在50%左右，平均每张500KB，大约40M，裁剪后实际只有20M左右。容积小了一半，那么意味着传输效率提升一倍。这点对于移动端处理影像来说意义重大。在网速流畅的情况下(百兆无线网络)，5秒钟内就可以下载一个序列。
其次，我们需要考虑一种更加快速的影像展现方式。
传统的pacs web应用通常将用户上传的dicom文件转化为jpg，再返回给浏览器展示。这是由于在早些时候标准和技术相对落后，浏览器也做不了太复杂的图像操作。因此几乎所有的图片操作都要通过后端完成。导致的直接结果是，每画一条线，或者拖动一下图，可能就要等一下才显示，而等的时间长短取决于网速。客户“感知效率体验”（客户能够感知和体验的效率）体验是一个要命的事情，我们需要重新梳理思路解决这个问题。
如果说图片的旋转缩放尚可以通过js+css3做到前端处理，对于“调窗”这类操作，原有的做法就不行了，只能老老实实重新从后台获取新处理好的图片回来。“调窗”是影像医生最常用的操作之一，是必不可少的。它的作用是将几千范围的ct像素值取其中一段，映射到浏览器的0到255的颜色范围内。不同器官的ct值的范围是不一样的，因此需要“调窗”来让想查看的部分更清晰。与单纯的对比度与亮度调整是两码事，必须对原始数据处理。基于此，我们选择了另一种方式。那就是将用户上传的dicom预处理成一份带信息的像素文件。不再获取jpg，而是通过html5的方式，直接获取像素文件在前端进行canvas绘制。这样，几乎所有的操作都可以在前端完成，可以测量，可以调窗，可以勾画，局部放大。下列这些功能如：W/L、Zoom、Pan、Inverse(反白) 、Fit、Rotate(旋转) 90、Cut、Copy、等功能，线段、夹角(Angle)、放大镜功能等，多张序列、序列绑定等都能在前端实现。定位线和MPR暂时在后端处理。这样很多常用的功能因为在前端处理，所以用户体验就非常好，没有延迟感。当然，并不是所有的东西都应该在前端处理，而是我们需要根据用户的体验做出改进和妥协。并没有完美的技术，只是想将客户的“感知效率“做到极致。什么是快？什么是慢？技术终究为人服务。如果人是生活在虚幻之中的话，产品需要满足这种虚幻。
并不是所有的东西都能用技术算法解决，也需要技巧。比如影像序列下载时候，并不是下载完才能看，完全可以边下边看啊，这个和迅雷边下边播类似，在网速缓慢的时候，这种异步传输的显示方式就会让人的“感知效率”良好。对于医学影像类的APP应用来说，就怕卡死，对于手机或者ipad来说，本地存储空间有限，如何对于缓存进行细化的管理也是需要继续研究的，细节决定成败。技术的实现过程中是有一些暗坑。幸好不是”史前巨兽掉进了焦油坑“，技术团队还可以从坑里面爬出来，踩的坑越多我们以后会更加稳健。一个向前奔跑的人，如果没有穿上一个好的鞋子，明明知道鞋子有点挤脚还是在往前跑着，短跑可以，长跑肯定不行。这个鞋子就是一个“技术债务”，如果换鞋需要花钱花时间，就需要好好评估了，架构师也是在理想和现实中挣扎的一群人，评估并且平衡好技术债务才是真的高手。
（欢迎转载，注明作者和来源即可，愿意与Dr.2交流的请加微信号：2823095726）
浏览次数：2341次