我正在寻找一种强大，高效的数据压缩算法，我可以使用它来提供医疗数据的实时传输（主要是波形 - 心率等）。
我很感激任何科学论文的建议/链接。
编辑：系统将基于服务器（最有可能安装在护理点基础设施内）和移动设备（iOS和Android智能手机和带有原生应用的平板电脑），波形将被转移。服务器将收集医院的所有数据（主要是波形数据）。就我而言，稳定性和速度比延迟更重要。
这是我目前可以提供的最详细的规范。我将调查您的建议，然后测试几种算法。但我正在寻找在类似架构中成功实现的东西。我也对任何有关服务器计算能力或服务器软件的建议持开放态度。
答案 0 :(得分：2)
不要将其视为实时或医疗数据 - 将其视为需要压缩传输的数据包（最有可能是TCP数据包）。内容的细节仅与压缩算法的选择有关，即使不是它是否医疗它是如何格式化/存储数据以及实际数据是什么样的。重要的是数据本身和整个系统的限制（例如，它是数据收集，如Holter监视器，还是实时状态报告，如ICU中的心脏监护仪？接收什么样的系统数据？）。
查看数据，它是作为原始二进制数据传输，还是从另一个组件或设备接收（例如）结构化XML或HL7，数值表示为文本？压缩原始数据是最有效的选择，还是应该将其转换为仅覆盖实际数据范围的专有二进制格式（2,3或4个字节足以覆盖值的范围？）？通过转换可以实现什么样的节省以及兼容性问题（例如，丢失HL7兼容性）。
选择绝对最佳压缩算法也可能不值得额外工作，除非您将进入极低带宽的情况;如果数据来自嵌入式设备，您应该平衡压缩效率与嵌入式处理器，工具集和周围系统的功能和限制，以便使用它。如果定制的压缩例程比已经内置到工具中的东西节省了5％，那么嵌入式闪存中的额外编码和调试时间以及存储空间是否值得？现有的经过验证的软件库，可以产生足够好的＆＃34;输出可能是首选，特别是对于医疗设备。
最后，根据环境的不同，您可能希望牺牲一大块压缩来支持某种程度的冗余，例如传输数据的滑动窗口，这样任何X数据包的丢失都不会导致数据丢失。这可能也允许您更改协议，并可能更改设备的配置方式 - 流式UDP（不丢失数据包重传）和TCP（发送方可能需要重新传输）之间的差异可能很大。
而且，既然我已经对系统方面进行了抨击，那么就有关于打包和流式传输模拟数据的大量信息，从RTP等流媒体协议的开发到详细信息用于GSM / CDMA和VOIP的语音分组化。尽管如此，决策最重要的驱动因素可能最终成为设备和服务器端可用的工具集。使用现有的工具集即使它们不是最有效的选项，也可以让您显着缩短开发时间（并缩短产品上市时间），还可以简化您的设备/产品的医疗认证。在业务方面，花费额外3-6个月的软件开发，寻找真正合格的开发人员以及处理监管机构批准可能是最重要的因素。
更新2012/02/01 ：我花了几分钟时间查看12导联心脏压力EKG的XML导出，总观察时间为12+分钟，XML文件大小约6MB我估计该文件中超过25％的文件是重复的，并且在研究标题中是非常可压缩的XML，并且波形数据是以200到200范围内的逗号分隔数字，集中在范围的中心，变化缓慢，数字穿过y轴并停留在那一侧一段时间。假设您想要的大部分是波形值，对于此示例，您将查看没有压缩4500KB / 763秒或大约59 Kbps的数据速率。完全未压缩并使用文本格式，您可以通过＆＃34; 2.5G＆＃34; GPRS连接轻松。在任何现代无线基础设施上，使用的带宽几乎都不会引起注意。
我仍然认为库存压缩库会在午餐时使用这种数据（受压缩标题和可能的包标题问题）。如果您坚持进行自定义压缩，我会考虑发送差值而不是原始数字（除非原始数据已经偏移）。如果您的数据与我正在查看的内容类似，您可能会将每个项目转换为-127到+127的1字节值，可能会保留极端值为＆＃34;特殊＆＃34;用于溢出的值（处理那些你认为合适的值 - 特殊表示，错误等）。如果您的传输效率稍差，处理速度稍慢，则可以将每个值作为带符号的2字节值发送，这仍然会比文本表示使用更少的带宽，因为目前每个值都是2+无论如何都是字节（值是1-4个字符加上不再需要的分隔符）。
基本上，不要担心数据的大小，除非通过低密度的大量计量无线连接全天候运行。
答案 1 :(得分：2)
有一种压缩软件的速度如此之快，以至于我看不到它不能被称为“实时”的情况：它们必须足够快。这种算法称为LZ4，Snappy，LZO，QuickLZ，每个CPU达到数百MB / s。
这里可以比较它们： http://code.google.com/p/lz4/
“用于传输的实时压缩”也可视为速度和压缩比之间的折衷。更多的压缩，即使速度较慢，也可以有效地节省传输时间。
在此页面上已经实现了对压缩和速度之间“最佳权衡”的研究，例如：http://fastcompression.blogspot.com/p/compression-benchmark.html
答案 2 :(得分：1)
我测试了很多压缩库，这是我的结论
LZO（http://www.oberhumer.com/opensource/lzo/）考虑压缩大量数据（超过1 MB）非常快
Snappy（http://code.google.com/p/snappy/）很好但在解压缩时需要更多处理资源（对于小于1MB的数据更好）
http://objectegypt.com提供了一个名为IHCA的库，它在大数据压缩方面比lzo更快，并且提供了良好的解压缩速度并且不需要许可证
终于 你最好制作自己的压缩功能，因为没有人比你更了解你的数据