Google、静止画フォーマットWebPを発表 72
ストーリー by hylom
この分野死屍累々なんですが 部門より
この分野死屍累々なんですが 部門より
Googleが静止画フォーマットWebPを発表した（CNETの記事、Chromium Blogの記事）。
WebPは同じくGoogle発の動画フォーマットWebM（VP8）の派生技術で、ファイルサイズはJPEGより平均39％少なくなると評価されている。圧縮率は絵柄によって異なるが、サンプルではおよそ10％～75％圧縮など色々なようだ。
JPEG代替フォーマットとしては、JPEG 2000や、Microsoft発のJPEG XRもあるが、いずれも普及しているとは言いがたい。WebPの技術的詳細はよく分からないが、注目しておきたいところ。
ブラウザ戦争万歳 (スコア:4, 興味深い)
★静止画
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年くらいかかってるみたいだから
メディアファイルについて状況が少しはましになるのにも同じくらいかかるだろうなあ…。
圧縮率の優位性を主張するなら次世代規格と比べないと意味が無い (スコア:3, おもしろおかしい)
MNG「フフフ…奴は四天王の中でも最弱…」
JPEG2000「にわか規格ごときに負けるとは画像フォーマットの面汚しよ…」
Re:圧縮率の優位性を主張するなら次世代規格と比べないと意味が無い (スコア:2, おもしろおかしい)
IE「くらえ非サポートアタック!」
四天王「グアアアアアアア」
の一コマでやられそうなあたりまで原作通りですね。
# SVGだけはかろうじてIE9でサポートされそうなのでAC
Re:圧縮率の優位性を主張するなら次世代規格と比べないと意味が無い (スコア:1, 興味深い)
Re:圧縮率の優位性を主張するなら次世代規格と比べないと意味が無い (スコア:5, おもしろおかしい)
PNGは勝ち組なんで。
Re: (スコア:0)
CMYK (スコア:3, 参考になる)
jpegにはあるCMYKはあるんですかね？
Webに特化するならハブかれそうな予感
Re:CMYK (スコア:2, 参考になる)
Re:CMYK (スコア:1, 参考になる)
最初からカラープロファイルまで含めて仕様を定義してもらえれば(ライブラリ使う側の実装が糞面倒にはなるものの)よりマシになる。
リファレンスライブラリの仕様として、デフォルトでsRGB、表示側のプロファイルを設定すれば対応する調節掛けて出力とかなってりゃ使う側としては楽なんだが、リファレンスライブラリにカラープロファイルの処理エンジン一式組み込むとかダルそうだな…
Re:CMYK (スコア:1)
今のIE8も問題ないようですね。
ユーザーはJPEGで困っているか? (スコア:3, 興味深い)
答えはおそらく何も困っていない。正直画質そのままで３～５割り容量が減ったとしても”だから何”としか思わないだろう。
今一番ネットで困っているのはgifに代わるアニメーションが表示可能な画像フォーマット。
なんでそこに注目しないのか。
Re:ユーザーはJPEGで困っているか? (スコア:2)
最近はWebアプリ全盛なんで業務の世界でもWeb界隈の影響は大きいのですが
医療・放送・デザイン等々の業務の世界では JPEG なんてカス扱いですよ。
個人的にはJPEGでいいじゃんと思う所も業界の方々からはJPEG有り得ん、の一言で却下です。
BtoBに限らずともBtoCやCtoCでもコアな(マニアな)ユーザーの世界ではJPEGは、まあ IE6 ぐらいには嫌われているのです。
Re:ユーザーはJPEGで困っているか? (スコア:4, 興味深い)
そりゃ単に劣化する不可逆圧縮フォーマットがカスってだけじゃないの?
医療分野ではノイズを影と見間違えたら文字通り致命的に困るし放送素材やデザインの編集を繰り返してる最中にどんどん劣化していくなんて話にならないに決まってる。
ロスレスオプションすらないWebPが取って代わろうとしてる分野で困ってるか? に対する反論の根拠として挙げるにはちょっと無理ありすぎ。
Re:ユーザーはJPEGで困っているか? (スコア:2, すばらしい洞察)
一方、操作そのままでフォーマットがWebPになっても、ユーザは同じ感想を抱くと思う。このジャンルの場合、ユーザを喜ばせる必要はなく、むしろ、ユーザには気付かれないぐらいこそっと差し替えられる環境を整備できれば十分。その上で転送量が30%減るなら導入を考える事業者は少なくないはず。
# 出来るかどうかは知らない。MNGぐらいは普及しても良かった気がするんだけどなぁ
Re:ユーザーはJPEGで困っているか? (スコア:1)
MNGが全然普及しないことを考えると、実はあんまり誰も困ってないのかも。
# ていうか、アニメーションはFlashでやる時代？ 勘弁してほしいが。
1を聞いて0を知れ!
Re:ユーザーはJPEGで困っているか? (スコア:1)
ユーザのためではなくGoogle側がトラフィックを削減したいために
より高い圧縮率の方式を提案しているのでは？
何でもかんでも自分が役に立たなければ無駄的な考えをするのは
どうかと思う。
実際にWebP使ってみた感想 (スコア:1)
例のギャラリーだと高品質の画像だけで、劣化した場合どうなるのかが全く分からなかったので、実際に高品質のJPEGをクォリティー下げてJPEGとWEBPで保存して、比べてみました。
Googleの提唱するWebPを試してみました [livedoor.jp]
これがその比較なんですが、JPEGの場合クォリティ下がるとノイズや色ずれが発生してひどいことになったんですが、WebPの場合、クォリティの低いJPEGよりサイズが小さくなるだけでなく、クォリティを下げていくと、ぼやけた感じの画像になるものの、平均的な情報(サムネイルにした時の画像とか)は変わらないという画期的なものでした。
ちょっと感動したかも|･ω･)
Re: (スコア:0, オフトピック)
pixivにJPEGで投稿すると勝手に再圧縮される問題があって。
ていうか同じ容量で画質アップするなら嬉しいという人が多いと思います。
Re: (スコア:0)
JPEGで投稿→WebPで再圧縮になるのですねわかります。
# なんでこんな見当はずれのコメントばかりなの? JPEGで困ってるだけじゃなくてWebPで解決する問題でなきゃ少なくともオフトピなんだけど。
Re: (スコア:0)
何かがおかしい… (スコア:3, 興味深い)
「画像を何枚か取り込み、その現在の損失の多いフォーマットからWebPへと再圧縮すると、サイズが平均で約40％減少した。これは驚異的な結果である」
JPGからJPGへの再圧縮(変換？)でも，同様の効果が得られるんですけど．試しに手元の風景写真(JPG形式，529.539bytes)をペイントアプリで開いて，再度JPG形式(70%圧縮)にて保存したら150,156bytes(元データの28%)になりました．パッと見は同じかなと感じました．Googleが言うところの「Webの高速化」は，保存時に2回圧縮をかけるツールが出れば解決するのでは…
この新フォーマットの威力は，同じRAW画像(BMPでもいいと思いますけど)に対してそれぞれ変換を行なった時，どれだけ差異があるかを見ないといけないのでは？
さっそくx264の中の人がdisってる (スコア:2, 参考になる)
H.264 and VP8 for still image coding: WebP?
http://x264dev.multimedia.cx/?p=541 [multimedia.cx]
Re:さっそくx264の中の人がdisってる (スコア:3, おもしろおかしい)
Dark ShikariたんはWebMにもダメ出ししてたけど、その一方で改善にも協力してくれるツンデレさん。
名前の手前 (スコア:1, おもしろおかしい)
Re:さっそくx264の中の人がdisってる (スコア:2, 参考になる)
本の虫: Dark_Shikari、WebPについて語る [blogspot.com]
Re:さっそくx264の中の人がdisってる (スコア:2, 興味深い)
しすぎている。内部でシャープフィルタでも噛んでるのかと思い拡大したわけです。
テクスチャが死んでますね。ボヤけている。それでいて稜線は残っているから余計に
クッキリ見えたわけです。ほんと動画の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）より、ブラーがかかり、細部が失われてしまう。
WebP とは直接関係ないけど (スコア:3, 興味深い)
ただし、一方でデジカメの高画素化の現状を見るにつけ、 新しい画像フォーマットへの要求条件があっても良いかなとは 思っています。
従来の画像は基本的に以下の制約条件で作られていますよね。
そこで必然的に評価方法は、「拡大して 1pixel単位で見てみて高画質かどうか(解像度やテクスチャがどこまで残るか・歪みがないか)」となるわけです。 しかし実際に必要なのは「1ピクセル当たりの情報量が綺麗」なのではなく、 画像全体として綺麗になるフォーマット・方式のはずです。
最近は、実質画面上では捌ききれない巨大解像度の画像がデジカメ画像を中心に増えてきています。 もちろん元のCMOS/CCDセンサがあるので解像度から開放されるわけではないのですが、 1枚で何十MB というデータよりは「最適な解像度と圧縮率のコンビを適切に選択して圧縮」という 仕組みがああれば、素人にも扱いやすいと思うんですよね。 現状でも、それほどには高画質じゃなくてもよくて「ほどほど」が欲しいという 人はいると思うのですが、それを4000x3000 くらいの元解像度で jpg の圧縮率をあげるという やり方でやってしまうと悲劇が起きてそれだったら2000x1500 くらい、いやさらに 1200x900 くらいで 画素辺りの情報量をほどほどにしておく方が適切かもしれません。
特に入門レベルのデジカメの場合は、その辺を適切にやってくれるフォーマット・処理系が 搭載されていると嬉しいんじゃないですかね。 (一方で「普及しているjpg」と異なるものであれば初心者向けには意味がないですけど)
Re:WebP とは直接関係ないけど (スコア:5, すばらしい洞察)
JPEG 2000がお求めのものに近いと思います。
必要メモリや圧縮伸長のための回路規模が非常にでかくなる、ということで10年前のデジカメ搭載フォーマットとしては嫌われました。が、現在のデジカメはH.264 フルHD動画録画対応なんて機種だってあるくらいなんだから、JPEG 2000対応くらい余裕でしょー。
Re:WebP とは直接関係ないけど (スコア:2, 参考になる)
JPEG2000 (wavelet)は今でも悪くはないと思いますが、やっぱり処理量が厳しいんでしょうね。 (少なくとも PC で扱うには十分大変に感じます)
JPEG2000がそんなに遅いのかと思い時間を計ってみた。
1280x800 bmp → jpg jp2 png (全て8bit)(ImageMagickでのお話)
$ time convert test.bmp test.jpg
real 0m0.167s
user 0m0.092s
sys 0m0.012s
$ time convert test.bmp test.jp2
real 0m0.966s
user 0m0.852s
sys 0m0.052s
$ time convert test.bmp test.png
real 0m0.394s
user 0m0.316s
sys 0m0.024s
$ ls -s
合計 4364
3004 test.bmp 632 test.jp2 252 test.jpg 476 test.png
何回か計ったがよく似た値になった。確かにJPEG2000は体感でも数値でも遅かった。
あとクオリティ指定してなかった為かpngの方がちっさくなってしまった。
ファイルサイズの小さなjpgはモニタを下から見たらモスキートノイズがのってる。
今回のWebPも、モスキートだらけのjpgやファイルサイズの大きいpngを置き換えられれば
それなりに意味のあることなのかもしれませんね。GoogleもデジカメでWebPを
使いたい訳ではなくネットサーフィンの高速化と通信量圧縮が目的のようですから。
しかしデジカメで連写できなくて良いから早くJPEG2000かJPEG XRのどちらか普及してほしい。
#JPEG2000はデコードもjpg,pngに大して6倍以上開きがあった。結局JPEG XRがいいのかな。
Re:WebP とは直接関係ないけど (スコア:1, 参考になる)
ちなみにMacOS XのでかいアイコンはJPEG2000圧縮です。
512x512程度の大きさだとデコード処理時間は数十ミリ秒のオーダーなので全く問題になりません。
もし普及しなくても (スコア:2)
発音は「うぇっぷ」になるのでしょうか (スコア:1)
とおもったら、「ウェッピー」でした。
http://journal.mycom.co.jp/news/2010/10/01/047/index.html [mycom.co.jp]
Re:発音は「うぇっぷ」になるのでしょうか (スコア:1)
もしかして：ウェピー [wikipedia.org]
イメージコンテナのオーバーヘッド (スコア:1)
タレコミの英文の方、あるいはITmediaの記事 http://www.itmedia.co.jp/enterprise/articles/1010/01/news027.html [itmedia.co.jp] にもあるんですが、コンテナのサイズが20バイトって少ないんですか?
無知を承知で、今現在主流の画像コンテナと比較した物を誰か教えて・・・。え? ぐぐれって?
実際細かい画像が大量にあるような状態だと圧縮率云々よりもこっちのほうが影響ありそうですしね。
気になります。
Re:イメージコンテナのオーバーヘッド (スコア:1)
色んなもの仕込めるし。
ということで、セキュリティ的にはいいのかな？
ステガノグラフィ的には使えるエリアが減ってうれしくなかったりして
ターゲットがわからん (スコア:1)
"Web"Pという名前からブラウザというかPCモニタ程度の解像度までしか
考慮しない、むしろ限定することで既存フォーマットをその分野では上回る
とかいうコンセプトだったりするでしょうかね。
リンクのChromiun Blogにもwebってやたら強調してるし。
でもそれならPNGで十分な気がします。
いかに速く、いかに小さく (スコア:1, 興味深い)
以前に通信プロトコル「SPDY」が発表されましたが、膨大なデータを収集・処理・配信し続けるGoogleならではの開発ですね。
JPEGを完全に置き換えるものと考えるのではなく、Webの世界でJPEGが使われているケースうち静止画フォーマットWebPでも充分なケースを何割かでもWebへ置き換える事ができればGoogle的にはOKなんじゃないでしょうか。 少しの効率化、少しの置き換えでもGoogle規模になれば相当なボリュームの改善になるでしょうし。
JPEG XRの現在 (スコア:0)
対してWebPはすでにソースが公開されてるようだが、国際標準にしようとかJPEGに働きかけようとかいう気はあるんだろうか。単なるデファクトスタンダード狙いか。
でも・・・jpgで困ってないよね
Re:JPEG XRの現在 (スコア:2)
HDDの大容量化、ネットワークの高速大容量化の時代なので、もう非可逆圧縮である必要はないでしょう。
＃昔は画像1枚も時間がかかったころが懐かし・・・くはないな。
無線では有効かと (スコア:3, 興味深い)
携帯電話なんかの無線だと有線ほど気軽に帯域を拡張できるわけではないので、 こういうデータ転送を少なくできる技術はニーズがあるかと。
/.はログインすると色々できます by Dポ研。 [twitter.com]
Re:JPEG XRの現在 (スコア:1, すばらしい洞察)
日本におけるクライアント側の環境は月額固定課金なのでいいかもしれませんが、
サーバ側からすれば規模が大きくなればなるほど転送量の削減は切実です
Re: (スコア:0)
最近はデジカメの画像サイズが大きくなって、そいつをブラウザにリサイズさせるもんで、時間がかかるのは相変わらずだったり。
Re: (スコア:0)
海外サイトだと非可逆なJPEGでも表示に時間掛かりますよ。
国内でも個人で運営しているサイトとか、画像が多い同人系サイトとか、まとめスレとか。
可逆圧縮にしたらもっと酷いことになりそう。
Re:JPEG XRの現在 (スコア:1)
こちらのコメント [srad.jp]にもありますが、業務用途ではjpegって嫌われてます。
それだけでなく、デジカメでもRAWフォーマットに代わる可逆圧縮フォーマットの登場が期待されています。
できるだけありのままの情報を、限られた記憶媒体の容量の範囲でより多く撮影したい。
画像の加工は後から幾らでもできるのですから、最初の画像は「生の状態」を維持して欲しいのです。
ところがjpegは、折角のカメラの撮影能力を正しく伝えていない訳です。
顔文字（おふとぴ） (スコア:0)
実はWebという単語をdisるためのフォーマットなんだよ
Re:これは当たるね (スコア:2)
このへんの力を活かして普及させようとしているのであれば、新フォーマットではなく、今からでもいいからJPEG 2000のほうをプッシュしてほしいなあー。
Re:これは当たるね (スコア:1, おもしろおかしい)
つかなんでMSがXPの標準アプリ群をHD Photoに対応させないのか分からん。たぶん普及して欲しくないんだろな。
「さっさとXP居なくなーレ」てことだよ、言わせんな恥ずかしい。
Re:これは当たるね (スコア:1)
そもそもの入力元であるデジカメが対応していない時点でお話にならんかと。
この規格を本気で普及させるつもりがあるなら、デジカメメーカーかエンコードチップメーカーとの提携も同時発表しなきゃ意味がないように思うのですが。
そこまでする気がなかったか、提携するところがなかったか。どっちなんだろう
Re:これは当たるね (スコア:1)
カメラの出力フォーマットとしてJPEGの置き換えを狙うにはexif等、もしくはそれに替わるメタデータ付与に対応してないと話にならんと思うのだけど、WebPはそのあたりどうなってんだろうか。
あと、最近のデジカメのダイナミックレンジに対してJPEGの8bit/チャンネルでは足りんということで、より良いフォーマットが求められてる。
JPEG XRが上記の二つをクリアするのに対して、WebPはどうなのだろうか。
Re: (スコア:0)
古いものを使い続ける人に先進性を訴えかけても意味ないでしょ。
対応させても使う人間って相当限られそう。