倍精度浮動小数点値でうまく機能する優れた圧縮アルゴリズムに関する推奨事項はありますか？浮動小数点値のバイナリ表現では、一般的な圧縮プログラム（Zip、RAR、7-Zipなど）では圧縮率が非常に低くなることがわかりました。
圧縮する必要のあるデータは、単調に昇順でソートされた8バイト値の1次元配列です。値は、スパンが通常100度未満のケルビン単位の温度を表します。値の数は、数百から最大64Kの範囲です。
明確化
浮動小数点値の表現方法により、バイトレベルで繰り返しが存在しますが、配列内のすべての値は異なります。
これは科学的なデータであるため、ロスレスアルゴリズムが望まれます。ストレージ効率が大幅に向上している場合は、十分な精度（小数点以下5桁まで）の固定小数点表現への変換が許容される場合があります。
アップデート
このテーマに関する興味深い記事を見つけました。このアプローチが私の要件にどの程度適用できるかわかりません。
最初に考慮すべきこと:倍精度に変換する前に、データを圧縮してみてください。David Thornley へのコメントに対して、IR イメージング ADC が 24 ビットの有効ビットを持たない限り、32 ビット浮動小数点数は十分な精度を持つ必要があります。問題になるのは、後続の処理によって生成されるノイズを正確に保持することだけです。それができない場合は、生成される値のテーブルを決定し、代わりにこのテーブルにインデックスを格納することにより、処理をリバース エンジニアリングすることが実用的である可能性があります。
2 つ目: 圧縮アルゴリズムがデータが 8 バイトのチャンクであることを認識している場合は、はるかに効果的です。これは、最上位バイトを最下位バイトと一緒にスローしないためです。大雑把な前処理方法として、gzip のようなバイトベースのコンプレッサーを介してパイプする前に、各 double の前に固有のバイト (おそらく ASCII コンマ?) を付けることができます。これにより、中間ストリームが 12% 大きくなっても、全体の圧縮率が向上するはずです。それほど粗雑ではありませんが、このタスクに適合した独自の圧縮を作成することはより多くの労力になります。おそらく、8 レベルのツリーを使用して、double の各バイトの期待値を表します。
3 番目: 画像データは非常に冗長であるため、何らかの形式のデルタ コーディングまたはその他の画像関連の圧縮により、スペースを節約する必要があります。ただし、画像ノイズは本質的に非圧縮性であるため、可逆圧縮を要求する場合、それほど大きな効果は得られません。また、上記で説明したように、double の下位ビットにある疑似ランダム ハッシュを処理するのにも役立ちません。
リストするすべてのエンコーダーはバイト指向であり、double のいくつかのプロパティによってスローされます。1 つは、12 ビットの指数/符号がバイト境界でうまく機能しないレイアウトであり、もう 1 つは入力のノイズです。最初の部分はさまざまな方法で簡単に対処できますが、2 番目の部分は、適用したロスレス圧縮の効果を制限します。あなたのデータはわかりませんが、多かれ少なかれわずか 25% の節約が期待できると思います。
頭のてっぺんから、そしておそらく役に立たないのは、あなたがこのリストのすべてを考えたからです...
ストリームを 64 ビット整数として扱い、隣接する値をデルタ エンコードします。同じ指数を持つ一連の値がある場合、それは事実上それをゼロにし、おそらくいくつかの上位仮数ビットもゼロにします。オーバーフローが発生しますが、データはまだ 64 ビットしか必要とせず、操作を元に戻すことができます。
この段階で、必要に応じて大雑把な整数予測を試して、差を保存できます。
以前の提案に従った場合、000 で始まる値がほぼ半分になり、FFF で始まる値がほぼ半分になります。現在の LSB が 1 の場合、逆は Fs との XOR で、LSB が 0 の場合は ROR です。
2番目の考えでは、ステップ3を実行する必要がないため、単純に予測を真の値にXORする方が差よりも優れている可能性があります。
バイトを並べ替えて、同じ意味を持つバイトをグループ化することができます。同様に、最初にすべての最上位バイトなど。少なくとも、最初にせいぜい数ビットのノイズを伴う大量のゼロの連続のようなものを取得する必要があります。
一般的なコンプレッサー、またはゼロの実行で最初の RLE を実行し、次に huffman のようなエントロピー エンコーダー、またはより良い、7zip/LZMA のレンジ エンコーダーを実行します。
データには 1 つの良い点があります。それは単調です。データには悪い点があります。それは単にセットが小さすぎるということです。いくらキロバイト節約したいの？何のために？隣接する値の間に指数の違いが頻繁にある場合、圧縮の有効性は大きく損なわれます。
これらのデータセットを大量に処理している場合は、それらの類似性を利用してそれらをより適切に圧縮することを検討する必要があります。おそらく、ある段階でそれらをインターリーブします。多少の損失を許容できる場合は、ソース データと予測の両方で最下位バイトをゼロにすることをお勧めします。これにより、そこにノイズが再導入されなくなります。
高圧縮のアーカイブ ストレージが必要な場合は、Burtscher と Patanaworabhan による「倍精度浮動小数点データの高スループット圧縮」または Lindstrom と Isenberg による「浮動小数点データの高速かつ効率的な圧縮」が役立つ場合があります。
圧縮率を低くして高速な動的アクセスが必要な場合は、1D リフティング ウェーブレットが適切な場合があります。保持する桁数を指定することで、データをより小さな整数に量子化できます。次に、予測モデルでデルタ エンコーディングを使用した後、Haar またはより高価なウェーブレット変換で変換し、指定された値より大きい係数の算術エンコーディングを行います。
それが役に立てば幸い
Lindstrom の ZFP アルゴリズムは、 https ://github.com/LLNL/zfp から入手できます。
隣接する値の間のデルタを実行できますか?
測定間の値の変化に制限はありますか? この変更を最大レート値に制限することは容認できますか (平滑化の導入を犠牲にして)。
温度センサーからの値の実際の精度には明らかに限界があります。64 ビットの精度を格納する必要がありますか、それとも 0.01 ケルビン単位などの整数を格納する方がよいでしょうか?
もう少しエラーを許容でき、増加が比較的スムーズである場合は、関数をデータに適合させ、関数のいくつかの項のみを保存する方がよい場合があります。
編集:
典型的なデータセットを見て、隣接する値の差の範囲を見てください。次に、これを表現するために必要な精度を見てください。
例えば。読み取り値の間に最大 1 度の差がある場合、この 1/256 の変化を 1 バイトに格納できます。より大きな範囲またはより高い精度を保存する必要がある場合は、短い値を何らかの係数で割った値を使用します。
したがって、次の読み取り値は = last_reading + (float)increment/256.0 になります。
圧縮アルゴリズムは繰り返しと規則性の上に成り立っており、浮動小数点数はそれではうまくいきません。
最初の質問は、単精度浮動小数点値を使用できるかどうかです。これにより、すぐに 50% の圧縮が得られます。7 桁まで正確な温度計はほとんどなく、指数は実際に得られる温度よりもかなり低い温度を表します。
そうでない場合は、温度をフィルター処理して、N 桁 (N/.301 ビットの可能性が高い) に相当する値に丸めることはできますか? これにより、有用な規則性が十分に導入される可能性があります。
温度測定値ごとに 64 ビットの情報を保存する必要があり、すべてのビットが重要であり、他のビットから予測できない場合は、事実上、それを圧縮することはできません。
エントロピーコーダー（ハフマン、シャノンファノ、算術符号化）を使用してデータを再符号化することを考えることができます。ただし、これは、データポイントが何度も繰り返され、どのシンボルがどの確率で表示されるかがわかっている場合にのみ、良好な結果を提供します。