パスワードを忘れた? アカウント作成
11391929 story
ソフトウェア

高圧縮をうたうJPEGライブラリmozjpeg、第三者によるテストで効果が確認される 19

ストーリー by hylom
普及よ進め 部門より
あるAnonymous Coward 曰く、

Mozillaが互換性を維持しつつもより高圧縮を可能にするJPEGライブラリ「mozjpeg」を開発しているが、CDNサービスを提供するCloudFlareが、このmozjpegの効果を検証しその結果を発表している(GIGAZINE)。

検証ではランダムに選んだ10000のJPEG画像を対象に、mozjpegを使って再エンコードを実行したという。これによると、そのうち691ファイルは元のファイルサイズと比べて小さいサイズにはならなかったものの、それ以外についてはファイルサイズを縮小する効果が確認できたという。また、5割以上のファイルでファイルサイズを3%以上小さくできたという結果も示されている。

ただし、圧縮処理にかかる時間は従来のJPEGエンコーダであるlibjpeg-turboよりも大きくなる傾向があるということも述べられている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2014年08月01日 15時20分 (#2649232)

    これタレコミがひどいですね。
    元記事にない「再エンコード」とかいう言葉を持ち出してきてたり、
    元記事のテーマは 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 でももっと縮むようです。
    そのへんも踏まえた追加検証記事がそのうち出るのかもしれませんね。

    • by Anonymous Coward on 2014年08月01日 16時28分 (#2649275)

      ハフマンテーブルの最適化とか、そういうテクニックなんでしょうかね?

      和物では、carmine [vector.co.jp]というのをたまに使いますが、似たようなものかな…。
      デジカメだと処理時間やプロセッサ性能の都合で、最適化してない場合がままあるそうで。

      ※同じ作者の無劣化回転とかトリミング [geocities.co.jp]も重宝してます。

      親コメント
    • by Anonymous Coward

      > プログレッシブ JPEG にすると libjpeg-turbo でももっと縮むようです。

      mozjpegが稼いでいる圧縮率のほとんどすべては単にプログレッシブJPEGにしただけで得られるというツッコミが前回もあったような。

  • by miyuri (33181) on 2014年08月01日 17時45分 (#2649305) 日記

    関連リンクにある
    http://it.srad.jp/story/14/03/07/0416229/Mozilla%E3%81%8CJPEG%E3%83%95... [srad.jp]
    で既出のネタを、今更っていう感じ。

    • by Anonymous Coward

      第三者での検証って事ですよ。
      十分に意味があると思いますが。

  • by qoult (41103) on 2014年08月02日 0時44分 (#2649477)

    以前、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] にあるので、表示できるか試したりしたい方はどうぞ。

    • by Anonymous Coward

      jpegtranというか、libjpegのVer.7以降はライブラリ自体が Arithmetic coding に対応しています。
      だから、新しめのlibjpegをリンクするだけで対応できるんですが…。
      もっと使われてほしいです。

      ちなみにgigazineで取り上げられている画像ファイル [i.gzn.jp]
      1897476byteが算術圧縮にすると1748447byteになります。
      8.5%小さくなりました。

      • by Anonymous Coward

        ブラウザのJPEGデコーダがArithmetic codingに対応していなければ無意味だけどそっちの対応状況はどんなものなんでしょ。

  • サイズしか比べてないように思える。条件を揃えるには、同じ圧縮による劣化の下での(圧縮後)ファイルサイズ、あるいは同じファイルサイズでの劣化の差を比べないと優劣なんて言えないのでは?
    S/Nと圧縮率をそれぞれXY軸に取った散布図を作成して比べないと。

    • 変換には、

      jpegtran -outfile out.jpg -optimise -copy none in.jpg

      というコマンドで処理しているとあります。jpegtran [sakura.ne.jp]は、不可逆圧縮されたDCT変換後のデータはそのまま手を付けずに(不可逆な変換処理は行わずに)、JPEG画像ファイルを再構築するコマンドです。
      ですから、「同じ圧縮による劣化の下での(圧縮後)ファイルサイズ」という比較を行っていることになります。

      ただ、今回のMozillaの最適化とは関係なさそうなのが一点。「-copy none」で、Exifなどのおまけデータを破棄していますので、それだけでも(従来のlibjpegでも)ファイル削減は行われます。

      親コメント
      • by Anonymous Coward

        libjpegとmozjpegそれぞれでハフマンテーブルの最適化を行い、
        どちらが小さくなるか比較したって事でしょうか?

        時折、photoshop等が内部的に使ってるらしいデータが付いたままのjpegがあり、-copy none するとだけで何割か小さくなることがあります。
        あるいはサムネイル画像を含んでいたり。

        また、最近のlibjpegでは算術圧縮が使えるので、
        jpegtran -outfile out.jpg -arithmetic -copy none in.jpg
        で変換するともっと小さくなりそうな。

        ただ、ブラウザやビュアーが対応していないかもしれませんが。

    • by Anonymous Coward

      俺も思った。元のjpegより劣化してたら本末転倒じゃねえのか、これ。
      サイズの圧縮なんてもうあんまり意味ない気がする

      サイズを気にするならwebpとか使ったほうがまだマシだよ、こんなの

    • by Anonymous Coward

      それ以前に、このテストは他のJPEG圧縮ライブラリですでに圧縮された(劣化した)画像をデコードして、
      それをインプットとしてmozjpegに渡して再圧縮して「ほらもとの画像より小さくなった」とかやっているわけで、
      mozjpegと他のJPEG圧縮ライブラリとで与えられたインプットデータさえ同じではない。

      それでいったい何の比較が出来ると主張するのか、理解しがたい。

      • by Anonymous Coward on 2014年08月01日 15時12分 (#2649224)

        インプットは同じでしょう?

        元画像→mozjpegでの圧縮
        元画像→libjpeg-turboでの圧縮
        を比較しているのだから。
        #タレコミの文章からは読み取れないけど。

        かつ、他のコメントにあるように、使ってるコマンドが
        jpegtranで、これはロスレスの処理しかできない。

        ので、十分比較出来てると思う。

        親コメント
    • by Anonymous Coward

      S/N比が悪くとも人間の目にはあまり劣化して見えないエンコード技術かもよ?

  • by Anonymous Coward on 2014年08月01日 18時47分 (#2649337)

    個人的に、人間の目で見て違いがわからなければOK、と思ってるので劣化しようがサイズが小さくなるのは嬉しい。
    なのでjpegminiが必須です。こっちはホントに見た目違いがわからないけどサイズが半分以下になったり。

    # ステマではありません

  • by Anonymous Coward on 2014年08月02日 13時19分 (#2649622)

    mozjpeg Ver1.00とVer2.01の比較をしてみました。
    十分なテストはしてませんが、あまり性能に変わりはありませんでした。
    http://www.canal.mokuren.ne.jp/memo/mozjpeg.html [mokuren.ne.jp]

typodupeerror

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

読み込み中...