高圧縮をうたうJPEGライブラリmozjpeg、第三者によるテストで効果が確認される 19
ストーリー by hylom
普及よ進め 部門より
普及よ進め 部門より
あるAnonymous Coward 曰く、
Mozillaが互換性を維持しつつもより高圧縮を可能にするJPEGライブラリ「mozjpeg」を開発しているが、CDNサービスを提供するCloudFlareが、このmozjpegの効果を検証しその結果を発表している（GIGAZINE）。
検証ではランダムに選んだ10000のJPEG画像を対象に、mozjpegを使って再エンコードを実行したという。これによると、そのうち691ファイルは元のファイルサイズと比べて小さいサイズにはならなかったものの、それ以外についてはファイルサイズを縮小する効果が確認できたという。また、5割以上のファイルでファイルサイズを3％以上小さくできたという結果も示されている。
ただし、圧縮処理にかかる時間は従来のJPEGエンコーダであるlibjpeg-turboよりも大きくなる傾向があるということも述べられている。
比較になってます (スコア:5, 参考になる)
これタレコミがひどいですね。
元記事にない「再エンコード」とかいう言葉を持ち出してきてたり、
元記事のテーマは mozjpeg と既存コーデックとの比較なのに
オリジナルファイルよりも小さくなったよ、って話になってたり。
元記事をざくっと要約すると、
・10000 個の jpeg ファイルを jpegtran で再圧縮した
・再圧縮の際、libjpeg-turbo コーデックと mozjpeg コーデックをそれぞれ用い、
双方の結果を比較した
・再圧縮でファイルが小さくできなかった件数は、libjpeg-turbo では 3471 件、
mozjpeg では 691 件であった
・再圧縮でファイルが小さくできたものについては、libjpeg-turbo では平均 2.5% 小さくなり、
mozjpeg では平均 3.0% 小さくなった
・処理時間は libjpeg-turbo では 273 秒であったが mozjpeg では 474 秒と 1.7 倍必要だった
※taka2 氏も書かれてますが、jpegtran は不可逆圧縮されたデータの展開 (デコード) 、
再圧縮 (エンコード) は行わず、再配置により構造を変更するツール (当然ロスレス)
って感じでしょうか。
GIGAZINE にはありませんが元記事には追伸も追記されてまして、
プログレッシブ JPEG にすると libjpeg-turbo でももっと縮むようです。
そのへんも踏まえた追加検証記事がそのうち出るのかもしれませんね。
Re:比較になってます (スコア:1)
ハフマンテーブルの最適化とか、そういうテクニックなんでしょうかね？
和物では、carmine [vector.co.jp]というのをたまに使いますが、似たようなものかな…。
デジカメだと処理時間やプロセッサ性能の都合で、最適化してない場合がままあるそうで。
※同じ作者の無劣化回転とかトリミング [geocities.co.jp]も重宝してます。
Re: (スコア:0)
> プログレッシブ JPEG にすると libjpeg-turbo でももっと縮むようです。
mozjpegが稼いでいる圧縮率のほとんどすべては単にプログレッシブJPEGにしただけで得られるというツッコミが前回もあったような。
既出 (スコア:2)
関連リンクにある
http://it.srad.jp/story/14/03/07/0416229/Mozilla%E3%81%8CJPEG%E3%83%95... [srad.jp]
で既出のネタを、今更っていう感じ。
Re: (スコア:0)
第三者での検証って事ですよ。
十分に意味があると思いますが。
jpegtranはなかなか良い (スコア:2)
以前、jpegtranとかjpegoptimとかでいろいろ遊んでたとき、JPEGでも規格上は一般的に使われるHuffman codingだけでなくArithmetic coding(算術符号)も利用できるってことを知った。
Huffman codingの代わりにArithmetic codingを使うようにファイルを変換してもデータは劣化せず(ロスレス)、サイズは6%くらい小さくなるらしい [filmicgames.com]ので、
(すでに他の人が書いてるけど)ベースラインの代わりにプログレッシブを使って、それに加えてArithmetic codingを使うようにすると、ずいぶん(もう覚えてないけど10%くらい？)小さくなった気がする。
どちらもロスレスな変換だし、jpegtranの-progressiveと-arithmeticオプションで一括変換できるから「こりゃいいや」と思って使おうとしたけど、Arithmetic codingは特許の影響(特許自体はすでに切れているらしいが [wikipedia.org])で対応してるソフトウェアがとても少なくて諦めた。
ちなみに、jpegtranはプログレッシブ変換とかArithmetic coding変換以外にも、画像の回転とか反転もロスレスでできます。他にもロスレスでいろいろな処理ができるっぽいので、詳しくはjpegtranのmanpage [ubuntu.com]を。
それと、Arithmetic codingのJPEGファイルのサンプルは http://filmicgames.com/Images/Patents/bedroom_arithmetic.jpg [filmicgames.com] にあるので、表示できるか試したりしたい方はどうぞ。
Re: (スコア:0)
jpegtranというか、libjpegのVer.7以降はライブラリ自体が Arithmetic coding に対応しています。
だから、新しめのlibjpegをリンクするだけで対応できるんですが…。
もっと使われてほしいです。
ちなみにgigazineで取り上げられている画像ファイル [i.gzn.jp]
1897476byteが算術圧縮にすると1748447byteになります。
8.5%小さくなりました。
Re: (スコア:0)
ブラウザのJPEGデコーダがArithmetic codingに対応していなければ無意味だけどそっちの対応状況はどんなものなんでしょ。
比較になってるの？ (スコア:1)
サイズしか比べてないように思える。条件を揃えるには、同じ圧縮による劣化の下での（圧縮後）ファイルサイズ、あるいは同じファイルサイズでの劣化の差を比べないと優劣なんて言えないのでは？
S/Nと圧縮率をそれぞれXY軸に取った散布図を作成して比べないと。
劣化はありません。同じ画質でのサイズ比較です。 (スコア:5, 参考になる)
変換には、
というコマンドで処理しているとあります。jpegtran [sakura.ne.jp]は、不可逆圧縮されたDCT変換後のデータはそのまま手を付けずに(不可逆な変換処理は行わずに)、JPEG画像ファイルを再構築するコマンドです。
ですから、「同じ圧縮による劣化の下での（圧縮後）ファイルサイズ」という比較を行っていることになります。
ただ、今回のMozillaの最適化とは関係なさそうなのが一点。「-copy none」で、Exifなどのおまけデータを破棄していますので、それだけでも(従来のlibjpegでも)ファイル削減は行われます。
Re: (スコア:0)
libjpegとmozjpegそれぞれでハフマンテーブルの最適化を行い、
どちらが小さくなるか比較したって事でしょうか？
時折、photoshop等が内部的に使ってるらしいデータが付いたままのjpegがあり、-copy none するとだけで何割か小さくなることがあります。
あるいはサムネイル画像を含んでいたり。
また、最近のlibjpegでは算術圧縮が使えるので、
jpegtran -outfile out.jpg -arithmetic -copy none in.jpg
で変換するともっと小さくなりそうな。
ただ、ブラウザやビュアーが対応していないかもしれませんが。
Re: (スコア:0)
俺も思った。元のjpegより劣化してたら本末転倒じゃねえのか、これ。
サイズの圧縮なんてもうあんまり意味ない気がする
サイズを気にするならwebpとか使ったほうがまだマシだよ、こんなの
Re: (スコア:0)
それ以前に、このテストは他のJPEG圧縮ライブラリですでに圧縮された（劣化した）画像をデコードして、
それをインプットとしてmozjpegに渡して再圧縮して「ほらもとの画像より小さくなった」とかやっているわけで、
mozjpegと他のJPEG圧縮ライブラリとで与えられたインプットデータさえ同じではない。
それでいったい何の比較が出来ると主張するのか、理解しがたい。
Re:比較になってるの？ (スコア:2, 参考になる)
インプットは同じでしょう？
元画像→mozjpegでの圧縮
元画像→libjpeg-turboでの圧縮
を比較しているのだから。
#タレコミの文章からは読み取れないけど。
かつ、他のコメントにあるように、使ってるコマンドが
jpegtranで、これはロスレスの処理しかできない。
ので、十分比較出来てると思う。
Re: (スコア:0)
S/N比が悪くとも人間の目にはあまり劣化して見えないエンコード技術かもよ？
人間の目 (スコア:0)
個人的に、人間の目で見て違いがわからなければOK、と思ってるので劣化しようがサイズが小さくなるのは嬉しい。
なのでjpegminiが必須です。こっちはホントに見た目違いがわからないけどサイズが半分以下になったり。
# ステマではありません
JPEG再圧縮 mozjpeg Ver2.01とVer1.00の比較 (スコア:0)
mozjpeg Ver1.00とVer2.01の比較をしてみました。
十分なテストはしてませんが、あまり性能に変わりはありませんでした。
http://www.canal.mokuren.ne.jp/memo/mozjpeg.html [mokuren.ne.jp]