JPEGよりもロッシー圧縮が速いのですか？

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

編集：圧縮用。

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

2010-12-29 Richard Knop

解凍または圧縮するには？ – tenfour

好奇心が強い、なぜ画像を圧縮する必要があるのですか？そしてどれくらい？ –

@ Mark Ransom：500MhzのCPUと256MBのRAMを搭載した小型のヒューマノイドロボットからUDPを介してPCに送信し、処理するためにそれらを圧縮する必要があります。私は毎秒少なくとも20枚の画像を取得する必要があり、Wi-Fiスティックは1秒間に多くのデータを送信するのに十分速くないので、JPEGを使用して帯域幅を減らしています。 –

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

出典

2010-12-29 17:44:45

JPEGエンコーディングは、高速デコード用に設計されています。これは必ずしも高速エンコードをも意味するとは限りません（実際には、エンコードするのがずっと遅くなります）。 –

最適なエンコーディングを心がけていない場合、どちらも非常に高速です。ここ数年以内のローエンドx86では、30メガピクセル/秒以上の速度でJPEGをエンコードできるはずです（頭の上からの概算）。 –

ビデオエンコーディングを目的としたエンコーダーは、スピードのために最適化されています。私はMJPEGが長年にわたり充実していたことを知っていますが、私はそれを達成するために特殊なハードウェアが必要だと常に考えていました。 –

どのような状況でですか？ PCやポータブルデバイスでは？あなたはJPEG、JPEG2000、PNG、および...ええとを持っている私の経験から

は、それは万歳（広義の文脈では、「よくサポート」の画像タイプ（非可逆か！）

のためにそれについてですそのGIFが出ています）。

出典

2010-12-29 16:54:46 evilspoons

私はJPEG2000が普遍的ではないと言っているので、リストは実際にはJPEGとPNGだけです。 –

LZWに関する特許は、少なくとも欧州の一部で期限が切れているため、限られた色空間を除いてGIFを避けることは実際の理由はありません。そして、それは迂回することができます（むしろ醜いです）。 – onemasse

組み込みLinuxロボット用です。 –

JPEG2000はそれほど高速ではありません。それはjpegで十分速くないエンコードまたはデコードですか？おそらく、4倍のFDCTとIDCTをjpegで実行するだけで、より高速になります。

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

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

出典

2010-12-29 16:57:59 onemasse

埋め込み型Linuxロボットでは、JPEGへのバイナリイメージのエンコードが遅すぎます。 –

@リチャードノップ：バイナリ？灰色と色のない白黒のように？それは物事をかなり変えます。 –

@マーク・ランソム私は「生の」画像としてバイナリ画像を見ました。彼らはカラフルです。 –

ウェーブレットベースの圧縮アルゴリズムは一般にDCTを使用するアルゴリズムよりも遅いと思います。たぶんあなたはJPEG XRとWebPのフォーマットを見てみるべきです。

出典

2010-12-29 17:01:01

ターゲットアーキテクチャで使用可能なMMX/SSE2命令がありますか？その場合は、libjpeg-turboを試してみてください。あるいは、画像をzlibのように圧縮し、実際の縮小を別のマシンにオフロードできますか？イメージの実際の損失圧縮は、組み込みデバイス自体で行わなければなりませんか？

出典

2010-12-29 17:13:13

libjpeg-turboのライセンスは、商用または実際の/実際のオープンソースプロジェクトの場合、lgpl = not rightです。 –

'zlib'圧縮はjpeg圧縮より数倍遅いです。 –

pngはzlib圧縮を使用します。 zlibは込み入って苦しいですが、コードは実際には32/64ビットではなく、クロスコンパイルが不十分で、デフォルト設定で多くのRAMを必要とします。あなたがどのように埋め込まれているかによって異なります。 –

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

出典

2010-12-29 17:40:16

ダウンスケーリングを行うために非常に最適化されたコードを書かない限り、 'libavcodec'でjpeg圧縮を実行すると、ダウンスケーリングコードよりも時間がかかります。 –

@R、非常に簡単に最適化できると私は提案したアルゴリズムではありませんか？ –

もしあなたがasmで書いているのであれば、私はそのダウンスケーリングアルゴリズムの純粋なC実装が少なくとも現在のコンパイラ技術ではlibavcodecのjpegエンコーダよりも勝てるとは思っていません。 –

JPEGよりもロッシー圧縮が速いのですか？

答えて

関連する問題