医療データ(主に波形 - 心拍数など)をリアルタイムで送信するために使用できる、堅牢で効率的なデータ圧縮アルゴリズムを探しています。
科学論文への推奨事項/リンクをいただければ幸いです。
編集: システムは、サーバー (ほとんどの場合、ポイント オブ ケア インフラストラクチャ内にインストールされます) とモバイル デバイス (ネイティブ アプリを備えた iOS & Android スマートフォンおよびタブレット) に基づいており、そこに波形が転送されます。サーバーは、病院からすべてのデータ (主に波形データ) を収集します。私の場合、遅延よりも安定性と速度が重要です。
これは、現時点で提供できる最も詳細な仕様です。あなたの推奨事項を調査し、いくつかのアルゴリズムをテストします。しかし、同様のアーキテクチャで正常に実装されたものを探しています。また、サーバーの計算能力やサーバー ソフトウェアに関するご提案もお待ちしております。
リアルタイムまたは医療データとは考えないでください。送信のために圧縮する必要があるデータのパケットと考えてください (TCP パケットである可能性が最も高い)。コンテンツの詳細は、圧縮アルゴリズムの選択においてのみ重要であり、データがどのようにフォーマット/保存されるか、および実際のデータがどのように見えるかは、医療用かどうかではありません。重要なのはデータそのものとシステム全体による制約（例：ホルターモニターのようなデータ収集か、ICUの心臓モニターのようなリアルタイムの状態報告か）、どのようなシステムが受けているかデータ？）。
データを見て、生のバイナリ データとして送信用に提示されていますか、それとも別のコンポーネントまたはデバイスから (たとえば) 数値がテキストとして表された構造化 XML または HL7 として受信されていますか? 元のデータを圧縮するのが最も効率的なオプションですか、それとも実際のデータ範囲のみをカバーする独自のバイナリ形式に変換する必要がありますか (値の範囲をカバーするのに 2、3、または 4 バイトで十分ですか?)。変換によってどのような節約ができるか、互換性の問題は何か (例: HL7 互換性の喪失)。
絶対的に最適な圧縮アルゴリズムを選択しても、帯域幅が非常に狭いシナリオでない限り、追加の作業を行う価値はありません。データが組み込みデバイスからのものである場合は、圧縮効率と、組み込みプロセッサ、ツールセット、およびそれを操作するための周辺システムの機能と制限とのバランスを取る必要があります。カスタム ビルドの圧縮ルーチンにより、既にツールに組み込まれているものよりも 5% 節約できる場合、追加のコーディングとデバッグの時間と組み込みフラッシュのストレージ スペースに見合うだけの価値があるでしょうか? 特に医療機器の場合は、「十分な」出力を生成する既存の検証済みソフトウェア ライブラリが優先される場合があります。
最後に、環境によっては、X パケットの損失がデータの損失につながらないように、データのスライディング ウィンドウを送信するなど、ある程度の冗長性を優先して圧縮の大きなチャンクを犠牲にしたい場合があります。これにより、プロトコルも変更でき、デバイスの構成方法も変更される可能性があります。ストリーミング UDP (失われたパケットの再送信なし) と TCP (送信者が再送信できる必要がある場合) の違いは重要です。
そして、システム側について大騒ぎしたので、RTPなどのストリーミング プロトコルの開発から、GSM/CDMA および VOIP の音声パケット化の詳細に至るまで、アナログ データのパケット化とストリーミングに関する多くの情報があります。それでも、決定の最も重要な要因は、デバイス側とサーバー側で利用できるツールセットになる可能性があります。最も効率的なオプションではない場合でも、既存のツールセットを使用すると、開発 (および市場投入までの時間) の時間を大幅に短縮でき、医療用デバイス/製品の認証を簡素化することもできます。ビジネス面では、ソフトウェア開発にさらに 3 ～ 6 か月を費やすこと、真に資格のある開発者を見つけること、規制当局の承認に対処することが最も重要な要素になる可能性があります。
2012/02/01更新: 合計観測時間が 12 分以上で、XML ファイルのサイズが 6 MB に達する 12 誘導心臓負荷心電図の XML エクスポートを数分間見ただけです。私は、そのファイルの 25% 以上が反復的で非常に圧縮可能な研究ヘッダーの XML であり、波形データは -200 から 200 の範囲のカンマ区切りの数値であり、範囲の中央に集中し、ゆっくりと変化していると推定しています。 、数字がy軸を横切り、しばらくの間その側にとどまります。必要なもののほとんどが波形の値であると仮定すると、この例では、4500KB / 763 秒または約 59 Kbps の圧縮なしのデータ レートが表示されます。完全に非圧縮で、テキスト形式を使用すると、「2.5G」GPRS 接続で簡単に実行できます。
ストック圧縮ライブラリは、この種のデータを昼食に食べると思います (圧縮ヘッダーとおそらくパケット ヘッダーの問題の影響を受けます)。カスタム圧縮を行うことを主張する場合は、生の数値ではなく差分値を送信することを検討します (生データが既にオフセットされていない限り)。あなたのデータが私がレビューしているもののように見える場合、おそらく各項目を -127 から +127 の 1 バイト値に変換し、極端な端をオーバーフローに使用される「特別な」値として予約することができます (ご覧のとおりに処理してください)。フィット - 特別な表現、エラーなど)。送信の効率を少し下げて、処理をわずかに速くしたい場合は、代わりに各値を符号付きの 2 バイト値として送信することができます。
基本的に、データのサイズについて心配する必要はありません。ただし、これが 24 時間 365 日実行され、低容量の重く計測されたワイヤレス接続を介して実行される場合を除きます。
非常に高速な圧縮ソフトウェアのカテゴリがあり、「リアルタイム」と呼べないシナリオはありません。それらは必然的に十分に高速です。このようなアルゴリズムは LZ4、Snappy、LZO、QuickLZ と呼ばれ、CPU あたり数百 MB/秒に達します。
それらの比較はここにあります: http://code.google.com/p/lz4/
「伝送のためのリアルタイム圧縮」も、速度と圧縮率のトレードオフと見なすことができます。圧縮率を高くすると、たとえ遅くても、伝送時間を効果的に節約できます。
圧縮と速度の間の「最適なトレードオフ」の研究は、たとえば次のページで実現されています: http://fastcompression.blogspot.com/p/compression-benchmark.html
多くの圧縮ライブラリをテストしましたが、これが私の結論です
LZO ( http://www.oberhumer.com/opensource/lzo/ ) は、大量のデータ (1 MB 以上) を圧縮することを考えると非常に高速です。
Snappy ( http://code.google.com/p/snappy/ ) は優れていますが、解凍時により多くの処理リソースが必要です (1MB 未満のデータの場合はより適切です)。
http://objectegypt.comは IHCA と呼ばれるライブラリを提供しています。これは、ビッグ データ圧縮で lzo よりも高速で、解凍速度が高く、ライセンスを必要としません。
最後に、独自の圧縮関数を作成することをお勧めします。なぜなら、あなたのデータについてあなた以上に知っている人はいないからです。