7

JPEGよりも高速でありながら十分にサポートされている圧縮アルゴリズムはありますか？私はjpeg2000について知っていますが、聞いたところによると、それほど速くはありません。

編集：圧縮用。

Edit2：Linux 32ビットで実行する必要があり、理想的にはCまたはC++で実行する必要があります。

4

6 に答える 6

4

JPEGのエンコードとデコードは非常に高速である必要があります。より高速なアルゴリズムを見つけるのは難しいでしょう。遅い場合、問題はおそらくフォーマットではなく、エンコーダの不適切な実装にあります。プロジェクトlibavcodec内のエンコーダーを試してください。ffmpeg

于 2010-12-29T17:44:45.300 に答える
3

ターゲットアーキテクチャで利用可能なMMX/SSE2命令はありますか？もしそうなら、libjpeg-turboを試してみてください。または、のようなもので画像を圧縮してzlibから、実際の縮小を別のマシンにオフロードできますか？画像の実際の不可逆圧縮が組み込みデバイス自体で行われることが不可欠ですか？

于 2010-12-29T17:13:13.330 に答える
2

どのような状況で？PCまたはポータブルデバイスで？

私の経験から、あなたはJPEG、JPEG2000、PNGを持っています、そして...ええと、それは広い文脈での「十分にサポートされた」画像タイプのためのそれについてです（損失があるかどうか！）

（GIFが出て行く途中です。）

于 2010-12-29T16:54:46.577 に答える
2

JPEG2000はまったく高速ではありません。jpegでは十分に高速ではないエンコードまたはデコードですか？jpegで4x4FDCTとIDCTを実行するだけで、おそらくはるかに高速になる可能性があります。

IJG libjpegのドキュメントを見つけるのは難しいですが、それを使用する場合は、品質設定を下げてみてください。高速になる可能性があります。また、高速FDCTオプションがあるようです。

SIMD命令を使用し、通常のlibjpegと互換性のあるlibjpeg-turboについて誰かが言及しました。それがあなたの選択肢であるなら、私はあなたがそれを試してみるべきだと思います。

于 2010-12-29T16:57:59.643 に答える
1

ウェーブレットベースの圧縮アルゴリズムは、一般にDCTを使用するアルゴリズムよりも遅いと思います。たぶん、JPEGXRおよびWebP形式を確認する必要があります。

于 2010-12-29T17:01:01.853 に答える
1

完全な画像の忠実度が必要ない場合は、画像のサイズを小さくするだけで済みます。2x2ブロックごとに1つのピクセルに平均化すると、サイズが非常に速く1/4に縮小されます。

于 2010-12-29T17:40:16.587 に答える