パスワードを忘れた? アカウント作成
259660 story
Google

Google、静止画フォーマットWebPを発表 72

ストーリー by hylom
この分野死屍累々なんですが 部門より

maia 曰く

Googleが静止画フォーマットWebPを発表した(CNETの記事Chromium Blogの記事)。

WebPは同じくGoogle発の動画フォーマットWebM(VP8)の派生技術で、ファイルサイズはJPEGより平均39%少なくなると評価されている。圧縮率は絵柄によって異なるが、サンプルではおよそ10%~75%圧縮など色々なようだ。

JPEG代替フォーマットとしては、JPEG 2000や、Microsoft発のJPEG XRもあるが、いずれも普及しているとは言いがたい。WebPの技術的詳細はよく分からないが、注目しておきたいところ。

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

    ★静止画
    IE9: JPEG-XR
    Safari: JPEG 2000
    Chrome: WebP
    Firefox: APNG
    ★音声
    IE9: MP3
    Safari: MP3, WAV
    Chrome: MP3, Vorbis
    Firefox: Vorbis, WAV
    ★動画
    IE9, Safari: H.264
    Firefox 4, Opera: WebM
    ★ダウンローダブルフォント
    IE8: EOT
    Firefox: WOFF
    Safari for iOS: SVGフォント
    Opera: Raw TTF

    HTML parserを統一する気になるまで10年くらいかかってるみたいだから
    メディアファイルについて状況が少しはましになるのにも同じくらいかかるだろうなあ…。

  • SVG「JPGがやられたようだな…」
    MNG「フフフ…奴は四天王の中でも最弱…」
    JPEG2000「にわか規格ごときに負けるとは画像フォーマットの面汚しよ…」
  • CMYK (スコア:3, 参考になる)

    by asanagi (22217) on 2010年10月01日 15時21分 (#1833139) 日記

    jpegにはあるCMYKはあるんですかね?
    Webに特化するならハブかれそうな予感

    • Re:CMYK (スコア:2, 参考になる)

      by 127.0.0.1 (33105) on 2010年10月01日 15時53分 (#1833163) 日記
      逆にCMYKなjpeg画像は、IEで何で見られないんだとかゴネる人がいるからなあ。
      親コメント
      • Re:CMYK (スコア:1, 参考になる)

        by Anonymous Coward on 2010年10月02日 16時25分 (#1833658)
        カラープロファイルの取り扱いがJPEGの必須仕様として明示されてないから、非対応環境が出てきて泣くことになるわけで。
        最初からカラープロファイルまで含めて仕様を定義してもらえれば(ライブラリ使う側の実装が糞面倒にはなるものの)よりマシになる。

        リファレンスライブラリの仕様として、デフォルトでsRGB、表示側のプロファイルを設定すれば対応する調節掛けて出力とかなってりゃ使う側としては楽なんだが、リファレンスライブラリにカラープロファイルの処理エンジン一式組み込むとかダルそうだな…
        親コメント
  • by Anonymous Coward on 2010年10月01日 16時06分 (#1833173)
    まずユーザーはJPEGで困っているかどうかを考えた方が良いと思う。
    答えはおそらく何も困っていない。正直画質そのままで3~5割り容量が減ったとしても”だから何”としか思わないだろう。
    今一番ネットで困っているのはgifに代わるアニメーションが表示可能な画像フォーマット。
    なんでそこに注目しないのか。
    • 最近はWebアプリ全盛なんで業務の世界でもWeb界隈の影響は大きいのですが
      医療・放送・デザイン等々の業務の世界では JPEG なんてカス扱いですよ。
      個人的にはJPEGでいいじゃんと思う所も業界の方々からはJPEG有り得ん、の一言で却下です。
      BtoBに限らずともBtoCやCtoCでもコアな(マニアな)ユーザーの世界ではJPEGは、まあ IE6 ぐらいには嫌われているのです。

      親コメント
      • by Anonymous Coward on 2010年10月01日 16時53分 (#1833214)

        そりゃ単に劣化する不可逆圧縮フォーマットがカスってだけじゃないの?
        医療分野ではノイズを影と見間違えたら文字通り致命的に困るし放送素材やデザインの編集を繰り返してる最中にどんどん劣化していくなんて話にならないに決まってる。
        ロスレスオプションすらないWebPが取って代わろうとしてる分野で困ってるか? に対する反論の根拠として挙げるにはちょっと無理ありすぎ。

        親コメント
    • by s02222 (20350) on 2010年10月01日 17時39分 (#1833244)
      >正直画質そのままで3~5割り容量が減ったとしても”だから何”としか思わないだろう。

      一方、操作そのままでフォーマットがWebPになっても、ユーザは同じ感想を抱くと思う。このジャンルの場合、ユーザを喜ばせる必要はなく、むしろ、ユーザには気付かれないぐらいこそっと差し替えられる環境を整備できれば十分。その上で転送量が30%減るなら導入を考える事業者は少なくないはず。

      # 出来るかどうかは知らない。MNGぐらいは普及しても良かった気がするんだけどなぁ
      親コメント
    • MNGが全然普及しないことを考えると、実はあんまり誰も困ってないのかも。

      # ていうか、アニメーションはFlashでやる時代? 勘弁してほしいが。

      --
      1を聞いて0を知れ!
      親コメント
    • ユーザのためではなくGoogle側がトラフィックを削減したいために
      より高い圧縮率の方式を提案しているのでは?

      何でもかんでも自分が役に立たなければ無駄的な考えをするのは
      どうかと思う。

      親コメント
    • 例のギャラリーだと高品質の画像だけで、劣化した場合どうなるのかが全く分からなかったので、実際に高品質のJPEGをクォリティー下げてJPEGとWEBPで保存して、比べてみました。

      Googleの提唱するWebPを試してみました [livedoor.jp]

      これがその比較なんですが、JPEGの場合クォリティ下がるとノイズや色ずれが発生してひどいことになったんですが、WebPの場合、クォリティの低いJPEGよりサイズが小さくなるだけでなく、クォリティを下げていくと、ぼやけた感じの画像になるものの、平均的な情報(サムネイルにした時の画像とか)は変わらないという画期的なものでした。

      ちょっと感動したかも|・ω・)

      親コメント
    • Re: (スコア:0, オフトピック)

      pixivにJPEGで投稿すると勝手に再圧縮される問題があって。
      ていうか同じ容量で画質アップするなら嬉しいという人が多いと思います。

      • by Anonymous Coward

        JPEGで投稿→WebPで再圧縮になるのですねわかります。
        # なんでこんな見当はずれのコメントばかりなの? JPEGで困ってるだけじゃなくてWebPで解決する問題でなきゃ少なくともオフトピなんだけど。

    • by Anonymous Coward
      重いのは画像じゃなくて flash だからね。日本では
  • by taim (39834) on 2010年10月01日 19時04分 (#1833285) 日記
    CNETの記事を読んだのですが,以下の部分に違和感があります.

    「画像を何枚か取り込み、その現在の損失の多いフォーマットからWebPへと再圧縮すると、サイズが平均で約40%減少した。これは驚異的な結果である」

    JPGからJPGへの再圧縮(変換?)でも,同様の効果が得られるんですけど.試しに手元の風景写真(JPG形式,529.539bytes)をペイントアプリで開いて,再度JPG形式(70%圧縮)にて保存したら150,156bytes(元データの28%)になりました.パッと見は同じかなと感じました.Googleが言うところの「Webの高速化」は,保存時に2回圧縮をかけるツールが出れば解決するのでは…

    この新フォーマットの威力は,同じRAW画像(BMPでもいいと思いますけど)に対してそれぞれ変換を行なった時,どれだけ差異があるかを見ないといけないのでは?
  • by Anonymous Coward on 2010年10月01日 15時07分 (#1833121)

    H.264 and VP8 for still image coding: WebP?
    http://x264dev.multimedia.cx/?p=541 [multimedia.cx]

    • by Anonymous Coward on 2010年10月01日 15時50分 (#1833156)

      Dark ShikariたんはWebMにもダメ出ししてたけど、その一方で改善にも協力してくれるツンデレさん。

      親コメント
    • by Anonymous Coward on 2010年10月01日 15時11分 (#1833124)

      本の虫: Dark_Shikari、WebPについて語る [blogspot.com]

      さて、ここで当然の疑問が沸き起こる。Googleはアホなのか? JPEGより優れているのならば、WebPとやらをプッシュするのも分かる。もちろん、技術的に、ファイルフォーマットとしては、優れている。フォーマットに基づくエンコーダーも、JPEGより優れたものを出力できるであろう。ただし、「できるであろう」ということに注意しなければならない。なぜlibvpxが、未だにクソエンコーダーであるこの時期に発表するんだ? こんなブラーだらけのクソでJPEGを置き換えるというのか?

      全世界よりGoogleに告ぐ:まず、てめぇのエンコーダーをまともにしやがれ。代替案として宣伝するのはその後だ。順番が逆ではダメだ。

      親コメント
      • by after25h (36752) on 2010年10月01日 15時44分 (#1833152)
        サンプルを見てなんとシャープな画像なんだと感心したものでしかし、どうもクッキリ
        しすぎている。内部でシャープフィルタでも噛んでるのかと思い拡大したわけです。

        テクスチャが死んでますね。ボヤけている。それでいて稜線は残っているから余計に
        クッキリ見えたわけです。ほんと動画のIフレームっぽい味付けでした。

        ただ、200倍も300倍も拡大しない限りはクッキリとした印象そのままなので
        用途次第では使えるかとも思いました。
        あと、WebPの特性が分かっているだけに、この他にもJPEG+フィルタの例とで比べ
        検証する必要があると思います。元の画像が無いんで手元で比べようが無いですが。

        http://cpplover.blogspot.com/2010/10/darkshikariwebp.html
        >VP8は4×4変換(4×4 transform)を使っている。これは一般に、JPEGの8×8変換
        >(8×8 transform)より、ブラーがかかり、細部が失われてしまう。
        親コメント
        • by Anonymous Coward on 2010年10月01日 16時55分 (#1833215)
          やりたい人がやるならともかく、「余計なシャープネス処理を問答無用でかける」のだとすれば 正直やめてほしいと思います。

          ただし、一方でデジカメの高画素化の現状を見るにつけ、 新しい画像フォーマットへの要求条件があっても良いかなとは 思っています。

          従来の画像は基本的に以下の制約条件で作られていますよね。
          • 解像度ありき
          • その中で圧縮効率を競う(xx MBまで圧縮した際によりきれいなのはどちらか)

          そこで必然的に評価方法は、「拡大して 1pixel単位で見てみて高画質かどうか(解像度やテクスチャがどこまで残るか・歪みがないか)」となるわけです。 しかし実際に必要なのは「1ピクセル当たりの情報量が綺麗」なのではなく、 画像全体として綺麗になるフォーマット・方式のはずです。

          最近は、実質画面上では捌ききれない巨大解像度の画像がデジカメ画像を中心に増えてきています。 もちろん元のCMOS/CCDセンサがあるので解像度から開放されるわけではないのですが、 1枚で何十MB というデータよりは「最適な解像度と圧縮率のコンビを適切に選択して圧縮」という 仕組みがああれば、素人にも扱いやすいと思うんですよね。 現状でも、それほどには高画質じゃなくてもよくて「ほどほど」が欲しいという 人はいると思うのですが、それを4000x3000 くらいの元解像度で jpg の圧縮率をあげるという やり方でやってしまうと悲劇が起きてそれだったら2000x1500 くらい、いやさらに 1200x900 くらいで 画素辺りの情報量をほどほどにしておく方が適切かもしれません。

          特に入門レベルのデジカメの場合は、その辺を適切にやってくれるフォーマット・処理系が 搭載されていると嬉しいんじゃないですかね。 (一方で「普及しているjpg」と異なるものであれば初心者向けには意味がないですけど)

          親コメント
          • by TarZ (28055) on 2010年10月01日 17時21分 (#1833227) 日記

            JPEG 2000がお求めのものに近いと思います。

            必要メモリや圧縮伸長のための回路規模が非常にでかくなる、ということで10年前のデジカメ搭載フォーマットとしては嫌われました。が、現在のデジカメはH.264 フルHD動画録画対応なんて機種だってあるくらいなんだから、JPEG 2000対応くらい余裕でしょー。

            親コメント
  • 税金対策なのかも
  • タレコミの英文の方、あるいはITmediaの記事 http://www.itmedia.co.jp/enterprise/articles/1010/01/news027.html [itmedia.co.jp] にもあるんですが、コンテナのサイズが20バイトって少ないんですか?

    無知を承知で、今現在主流の画像コンテナと比較した物を誰か教えて・・・。え? ぐぐれって?

    実際細かい画像が大量にあるような状態だと圧縮率云々よりもこっちのほうが影響ありそうですしね。
    気になります。

  • 静止画となると写真のことは考えなきゃならんと思うのだが、
    "Web"Pという名前からブラウザというかPCモニタ程度の解像度までしか
    考慮しない、むしろ限定することで既存フォーマットをその分野では上回る
    とかいうコンセプトだったりするでしょうかね。
    リンクのChromiun Blogにもwebってやたら強調してるし。

    でもそれならPNGで十分な気がします。
  • by Anonymous Coward on 2010年10月02日 2時14分 (#1833462)

    以前に通信プロトコル「SPDY」が発表されましたが、膨大なデータを収集・処理・配信し続けるGoogleならではの開発ですね。

    JPEGを完全に置き換えるものと考えるのではなく、Webの世界でJPEGが使われているケースうち静止画フォーマットWebPでも充分なケースを何割かでもWebへ置き換える事ができればGoogle的にはOKなんじゃないでしょうか。 少しの効率化、少しの置き換えでもGoogle規模になれば相当なボリュームの改善になるでしょうし。

  • by Anonymous Coward on 2010年10月01日 15時28分 (#1833143)
    wikipediaを見たら、いちお国際標準規格目前みたいですね。でも、仕様に欠陥がある?せいでオープンソースの実装がないと。ふむ、だからまったく普及してないのか。
    対してWebPはすでにソースが公開されてるようだが、国際標準にしようとかJPEGに働きかけようとかいう気はあるんだろうか。単なるデファクトスタンダード狙いか。
    でも・・・jpgで困ってないよね
    • by kuramori (38110) on 2010年10月01日 15時32分 (#1833146) 日記

      HDDの大容量化、ネットワークの高速大容量化の時代なので、もう非可逆圧縮である必要はないでしょう。

      #昔は画像1枚も時間がかかったころが懐かし・・・くはないな。

      親コメント
      • by sageken (33685) on 2010年10月01日 15時53分 (#1833160) ホームページ

        HDDの大容量化、ネットワークの高速大容量化の時代なので、もう非可逆圧縮である必要はないでしょう。

        携帯電話なんかの無線だと有線ほど気軽に帯域を拡張できるわけではないので、 こういうデータ転送を少なくできる技術はニーズがあるかと。

        --
        /.はログインすると色々できます by Dポ研。 [twitter.com]
        親コメント
      • Re:JPEG XRの現在 (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2010年10月01日 16時21分 (#1833187)

        日本におけるクライアント側の環境は月額固定課金なのでいいかもしれませんが、
        サーバ側からすれば規模が大きくなればなるほど転送量の削減は切実です

        親コメント
      • by Anonymous Coward
        > #昔は画像1枚も時間がかかったころが懐かし・・・くはないな。

        最近はデジカメの画像サイズが大きくなって、そいつをブラウザにリサイズさせるもんで、時間がかかるのは相変わらずだったり。
      • by Anonymous Coward

        海外サイトだと非可逆なJPEGでも表示に時間掛かりますよ。
        国内でも個人で運営しているサイトとか、画像が多い同人系サイトとか、まとめスレとか。
        可逆圧縮にしたらもっと酷いことになりそう。

    • by slashushushu (40742) on 2010年10月02日 6時35分 (#1833482)

      こちらのコメント [srad.jp]にもありますが、業務用途ではjpegって嫌われてます。
      それだけでなく、デジカメでもRAWフォーマットに代わる可逆圧縮フォーマットの登場が期待されています。
      できるだけありのままの情報を、限られた記憶媒体の容量の範囲でより多く撮影したい。
      画像の加工は後から幾らでもできるのですから、最初の画像は「生の状態」を維持して欲しいのです。
      ところがjpegは、折角のカメラの撮影能力を正しく伝えていない訳です。

      親コメント
  • by Anonymous Coward on 2010年10月01日 16時04分 (#1833171)
    Web :-p

    実はWebという単語をdisるためのフォーマットなんだよ
typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

読み込み中...