2017-02-03 23 views
1

WebP技術は、 "JPEG"以上の画像を圧縮する非可逆画像圧縮と、画像圧縮技術で研究しています。だから、もし私がWebPイメージ圧縮のための明確なアルゴリズムを提供できれば、それは私には完全に役立つだろう。WebP技術を使用した画像圧縮

+0

はhttps://medium.com/@duhroach/how-webp-works-lossly-mode-33bd2b1d0670#.26c74n6re – saurabheights

+0

私はまた、あなたが公式リポジトリからすべてのJPEG、PNG、WEBPコードをダウンロードすることをお勧めします。 Mozjpegも同様ですが、早ければ早いほど有益です。 – saurabheights

+0

ありがとうございます@saurabheights –

答えて

2

まあ、すべてのバリアントを含めたロッシーとロスレスの両方の圧縮アルゴリズムを完全に提供することは、このフォーラムでの1つの答えをはるかに超えています。 Googleは無料でlossylosslessビットストリームの仕様を提供しています。しかし、後者は非常に不完全で、不正確で、部分的には間違っています。この仕様に基づいてコーデックを実装するのは苦労しますが、かなりのソースコードも勉強することが不可欠です。

私はここロスレスフォーマットに関する少なくともいくつかの詳細をあなたを与えることができます。

  • ZIPのdeflate圧縮アルゴリズムを使用してPNG、同じように、WEBPも、すべての画像については、ハフマン符号化を使用しています。実際、WebPの圧縮利得の多くは、ハフマン符号化を巧みに採用しています。 DEFLATEの多くの詳細は明らかにコードサイズを15ビットに制限し、Huffman AlphabetsはDEFLATEとほぼ同じ別のハフマンコードでエンコードしています。
  • LZ77スライディングウインドウ圧縮と、最近使用した色からなるサイズ2..2048のオプションのカラーキャッシュによって、追加の圧縮が実現されます。エンコーダは、どちらを使用するかを自由に決めることができます。どちらも混在することができます。しかし、テストではこれが圧縮率に悪影響を及ぼすことがあります。写真画像は通常、大きなカラーキャッシュで細かく圧縮されます。キャッシュを使用する場合は、LZ77後方参照を使用するのではなく、キャッシュに存在しないピクセルのために常時リテラルARGBエンコーディングを使用する方が通常です。
  • LZ77圧縮の使用はDEFLATEとほぼ同じですが、Googleの仕様はバイトに基づくのではなくピクセルです。つまり、ARGB四つ組は、個々のA-R-G-Bバイトではなく、圧縮されています。さらに、WebPでは後方参照の長さを4096ピクセルまで、参照距離を1048576 - 120ピクセルまで許容しています。これはDEFLATEの限界をはるかに超えています。別の利点は、ARGBチャネルに別々のハフマンアルファベットを使用することによって得られる。
  • WebP LZ77圧縮には、PLEと同様にRLE(ランレングスエンコーディング)機能があります。これは、参照長が基準距離を超えた場合に特殊なケースを賢明に処理した結果です。この場合、指定された長さに達するまで、使用可能なバイトが繰り返しコピーされます。私は、この機能を使用すると、同じ色の長いランで "人工的な"画像に大きな圧縮をもたらすことがわかりました。しかし、これはカラーキャッシュと競合し、そのような実行のための非常に効率的なハフマンコードを生成する。私の予備テストに基づいて、カラーキャッシュはRLE機能より優れています。
  • PNGと同様、WebPは未処理のARGBデータでは正常に動作しません。したがって、両方の形式を使用すると、圧縮が開始される前にピクセルデータにさまざまなTransformを適用できます。これらの変換は実際にはピクセルストリームの分散を減少させる大きな仕事をし、その結果得られる盛り上がり比率の大部分を説明します。 WebPでは13の標準予測変換が定義されていますが、PNGは4つしかありませんが、予測関数のほとんどはあまり効果がありません。通常は、選択フィルタを使用します。予測因子として適切であるかのように見えるものである。 PNGの場合と同様に、単純なフィルタは複雑なフィルタより頻繁に優れています。
  • WebPは他の変換を提供していますが、私は「緑減算」のみを試しています。各ピクセルのRとBの両方からGを差し引いてRGBチャネルをデコリレーションします。実際、予測子の後に適用すると、いくつかの利点が見られました。前に適用した場合、写真画像に悪影響を与える可能性があります。
  • WebPはビットストリームに5つの別々のハフマンコードを使用します.1つはグリーンチャネル、LZ77長さコード、およびカラーキャッシュインデックスです.1つは赤チャネル用、1つは青チャネル用、もう1つはアルファチャネル用、 LZ77距離コード用。これは賢明な設計です。なぜなら、ARGBチャンネルの情報は非常に相関がない可能性があるため、アルファベットを1つのアルファベットにマージすることは最適ではない可能性があります。

WebP losslessは、最大限に組み合わせて調整することのできる幅広いオプションを提供します。しかし、私の意見では、ほとんどの組み合わせはテストに値するものではありません。私の観察に基づいて、圧縮は通常次のデフォルトで良好です:

  • 「選択」プレディクタを使用してください。
  • 「減算」変換を適用します。
  • 2048スロットのカラーキャッシュを使用します。
  • 現在のピクセルがキャッシュにない場合は、それをリテラルとしてエンコードします。
関連する問題