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