zlibやlzoのようなインターネット上のデータ圧縮ライブラリを見てきました。しかし、40,000バイトを圧縮する最良の方法についてはわかりません（それらはbyte[][](x,y = color).せいぜい秒。
これが可能かどうか、そして何が最善の選択肢になるかはわかりません。byte[]また、配列の2番目の次元を失い、解凍が発生したときに再び取得できるようにする必要があるという意味で、出力が必要になります。クライアントにデータを送信するので、データをファイルに保存したくありませんbyte[]。(クライアントにデータを送信する方法を変更することはできません。) 助けてくれてありがとう。
編集:データが失われてもかまいません。そのデータが送信されるたびに同じデータが送信される限り、1/4秒ごとに新しい情報で更新が送信されるため、画像を送信していないので、サーバープログラムで色を作成しているので（ファイルから読み取っていない）、png dossentについてあなたが言っていることは本当に役立ちます。お役に立てれば。
基本的に、任意のデータのすべての入力に対してロスレスな方法で大幅な圧縮を達成できる一般的な圧縮スキームはありません。最初よりも多くのデータを取得する可能性、またはデータの損失の可能性を受け入れることができます...それはあなたの選択です. ただし、データを元の 1/20 にまで縮めようとするのは、一般的にかなり難しいことです。
これが画像データであることを考えると、おそらく汎用の圧縮ルーチンを見るべきではありません - 代わりに、JPEG、PNG などの画像フォーマットを見てください。忠実度は低下しますが、より大きな圧縮を達成できます。それでも、200バイトは本当に多くの情報ではありません...
パフォーマンス面に注目する前に、実行可能な結果 (十分に小さいが、十分な品質) を取得することに焦点を当てます。何かが動作するようになったら、それが十分に速いかどうかを確認できます。しかし、最初の要件を満たしていない場合、何かを速くしようと懸命に取り組んでも意味がありません。
画像ベースの圧縮を使用すると、1D/2D 側が失われる可能性があります。ある種のカスタム スキームを使用する場合は、1 つの次元の長さを格納し、もう 1 つの次元を推測するのは簡単です。これは基本的に、要件の最も問題の少ない部分です:)
データを失わずに 40000 バイトを 200 バイトに常に圧縮できるとは限りません。ただし、データがコンピューターで生成された色数の少ない画像である場合、200 バイト以下になる可能性はあまりありません。
1) データを PNG 圧縮ライブラリにフィードします。
最適な圧縮には時間がかかりますが、圧縮レベルをわずかに下げることで時間を大幅に節約できます。ライブラリが OptiPNG の場合、レベル 2 または 3 が速度と圧縮のバランスが取れている可能性があります。
2) イメージのサイズがわかっているので、受信側で回復できるヘッダーとその他すべてのチャンクを削除します。残すべきはIDATチャンクだけです。それでも、最初の数ビット (チャンク ヘッダー) を取り除くことができます)。
解凍時：
1）IHDRチャンク（事前にわかっている）と（パレットを使用する場合）PLTEチャンク（これも事前にわかっている）、およびIDATチャンクのヘッダーを先頭に追加します。IENDチャンクを追加します。
2) このデータを PNG 解凍ライブラリにフィードします。
.pngファイル形式は十分に文書化されています。ウィキペディアを出発点として使用できます。
やろうとしていることが理論的に可能かどうかを確認するには、入力画像の 1 つ以上のサンプルを取得し、そのデータのエントロピー(または「シャノン エントロピー」 ) を計算します。これにより、少なくともデータに実際に含まれる情報 (エントロピー) の量を推定できます。
1 つの入力画像のエントロピーが 200*8 ビットを超えると計算される場合、単一の画像で目的の圧縮を実行できる一般的なロスレス圧縮スキームはおそらく存在しません。
ただし、一連の画像がある場合は、ある画像から次の画像への違いをエンコードするだけで、平均して目標帯域幅を達成できます。たとえば、一般的なビデオ コーデックを参照してください。
たぶん、 「ソースコーディング」についても読んでください。
