アカウント名:
パスワード:
H.264 and VP8 for still image coding: WebP?http://x264dev.multimedia.cx/?p=541 [multimedia.cx]
本の虫: Dark_Shikari、WebPについて語る [blogspot.com]
さて、ここで当然の疑問が沸き起こる。Googleはアホなのか? JPEGより優れているのならば、WebPとやらをプッシュするのも分かる。もちろん、技術的に、ファイルフォーマットとしては、優れている。フォーマットに基づくエンコーダーも、JPEGより優れたものを出力できるであろう。ただし、「できるであろう」ということに注意しなければならない。なぜlibvpxが、未だにクソエンコーダーであるこの時期に発表するんだ? こんなブラーだらけのクソでJPEGを置き換えるというのか?全世界よりGoogleに告ぐ:まず、てめぇのエンコーダーをまともにしやがれ。代替案として宣伝するのはその後だ。順番が逆ではダメだ。
さて、ここで当然の疑問が沸き起こる。Googleはアホなのか? JPEGより優れているのならば、WebPとやらをプッシュするのも分かる。もちろん、技術的に、ファイルフォーマットとしては、優れている。フォーマットに基づくエンコーダーも、JPEGより優れたものを出力できるであろう。ただし、「できるであろう」ということに注意しなければならない。なぜlibvpxが、未だにクソエンコーダーであるこの時期に発表するんだ? こんなブラーだらけのクソでJPEGを置き換えるというのか?
全世界よりGoogleに告ぐ:まず、てめぇのエンコーダーをまともにしやがれ。代替案として宣伝するのはその後だ。順番が逆ではダメだ。
そこで必然的に評価方法は、「拡大して 1pixel単位で見てみて高画質かどうか(解像度やテクスチャがどこまで残るか・歪みがないか)」となるわ
JPEG 2000がお求めのものに近いと思います。
必要メモリや圧縮伸長のための回路規模が非常にでかくなる、ということで10年前のデジカメ搭載フォーマットとしては嫌われました。が、現在のデジカメはH.264 フルHD動画録画対応なんて機種だってあるくらいなんだから、JPEG 2000対応くらい余裕でしょー。
JPEG2000 (wavelet)は今でも悪くはないと思いますが、やっぱり処理量が厳しいんでしょうね。 (少なくとも PC で扱うには十分大変に感じます)
JPEG2000がそんなに遅いのかと思い時間を計ってみた。1280x800 bmp → jpg jp2 png (全て8bit)(ImageMagickでのお話)
$ time convert test.bmp test.jpg
real 0m0.167suser 0m0.092ssys 0m0.012s
$ time convert test.bmp test.jp2
real 0m0.966suser 0m0.852ssys 0m0.052s
$ time convert test.bmp test.png
real 0m0.394suser 0m0.316ssys 0m0.024s
$ ls -s合計 43643004 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がいいのかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
さっそくx264の中の人がdisってる (スコア:2, 参考になる)
H.264 and VP8 for still image coding: WebP?
http://x264dev.multimedia.cx/?p=541 [multimedia.cx]
Re: (スコア:2, 参考になる)
本の虫: Dark_Shikari、WebPについて語る [blogspot.com]
Re: (スコア: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単位で見てみて高画質かどうか(解像度やテクスチャがどこまで残るか・歪みがないか)」となるわ
Re: (スコア:5, すばらしい洞察)
JPEG 2000がお求めのものに近いと思います。
必要メモリや圧縮伸長のための回路規模が非常にでかくなる、ということで10年前のデジカメ搭載フォーマットとしては嫌われました。が、現在のデジカメはH.264 フルHD動画録画対応なんて機種だってあるくらいなんだから、JPEG 2000対応くらい余裕でしょー。
Re: (スコア:0)
H.264 だのなんだのは基本的にソフト処理ではなく ハードウェアのエンコーダ・デコーダを積んでいるわけですが 「結局流行らせるのに失敗したJPEG2000」では そういうものもないですから、 やっぱり無理。 結局なまじ素のjpegがそこそこ高品質に対応できてしまうので (普及しない 処理系が出てこない)の無限ループから出てこれないんですよね。 depth 8bit超が一つのチャンスかと思っていたのですが…
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がいいのかな。