为什么DICOM不适合差异化压缩

前几天,同事参加了一个技术讨论会,会间有人热烈的讨论了DICOM影像的单序列多幅的差异化压缩。

想法很简单,就是类似于视频压缩的方法,找出关键帧影像,对非关键帧影像就可以做差异化压缩了。

说实话,我认为这种做法没什么实际价值,原因如下:

1、现在存储很便宜,存储量已经不是什么大问题,但存储的读写速度却一直上不来(SSD太贵),这才是现在要解决的首要问题,所以现在有些人在尝试用HDFS这样的分布式存储系统,来解决这个问题,同时可以解决可靠性

2、DICOM本身没有关键帧的概念,每一幅之间的差距都不小,差异化压缩效果不一定好

3、DICOM文件原本可以独立打开,差异化压缩后,一个关键帧出了问题,其余非关键帧就都报废了,可靠性其实是降低了

4、DICOM影像的每一幅都有MetaData,差异压缩后MetaData如何存储,也是个问题

5、同时,这些计算太消耗CPU了,而且其他厂商并不支持这种压缩方法

6、与其重新造轮子,不如将多幅图片直接转成视频,然后进行无损压缩,不就是“DICOM差异化压缩”了吗,而且遵守DICOM规范

如何快速路由DICOM通讯

DICOM通讯是典型的socket通讯,一般的route方式,都是SCP收到图后,然后CStore给第三方。
但这样的效率不会很高,因为要先收取,解析、再转发。

如何提高转发效率呢?
大家知道DICOM通讯中,对带宽的占用率还是比较高的,而DICOM使用的socket是基于TCP协议的应用层,这样一层层上来,量又大,效果不可能会好。
所以直接用DICOM通讯进行转发,效果不会好。

比较好的方法是,借鉴路由器的工作方式,至少应该在网络层或传输层搞定会比较好。
这样,直接调整一下包的内容,就直接发出去了,效率应该是比较高的。

先记录一下,有空了再试试看。

备注:
2015.10
最近发现最新版本的NGinx,新增了转发功能,测试后,效果很不错。