アカウント名:
パスワード:
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単位で見てみて高画質かどうか(解像度やテクスチャがどこまで残るか・歪みがないか)」となるわけです。 しかし実際に必要なのは「1ピクセル当たりの情報量が綺麗」なのではなく、 画像全体として綺麗になるフォーマット・方式のはずです。 最近は、実質画面上では捌ききれない巨大解像度の画像がデジカメ画像を中心に増えてきています。 もちろん元のCMOS/CCDセンサがあるので解像度から開放されるわけではないのですが、 1枚で何十MB というデータよりは「最適な解像度と圧縮率のコンビを適切に選択して圧縮」という 仕組みがああれば、素人にも扱いやすいと思うんですよね。 現状でも、それほどには高画質じゃなくてもよくて「ほどほど」が欲しいという 人はいると思うのですが、それを4000x3000 くらいの元解像度で jpg の圧縮率をあげるという やり方でやってしまうと悲劇が起きてそれだったら2000x1500 くらい、いやさらに 1200x900 くらいで 画素辺りの情報量をほどほどにしておく方が適切かもしれません。 特に入門レベルのデジカメの場合は、その辺を適切にやってくれるフォーマット・処理系が 搭載されていると嬉しいんじゃないですかね。 (一方で「普及しているjpg」と異なるものであれば初心者向けには意味がないですけど)
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がいいのかな。
ちなみにMacOS XのでかいアイコンはJPEG2000圧縮です。512x512程度の大きさだとデコード処理時間は数十ミリ秒のオーダーなので全く問題になりません。
> やりたい人がやるならともかく、「余計なシャープネス処理を問答無用でかける」のだとすれば 正直やめてほしいと思います。> 特に入門レベルのデジカメの場合は、その辺を適切にやってくれる
ところで安物のデジカメは問答無用でシャープネス処理をかける場合があるのは知ってる? もちろんプロにとっては余計なお世話なんだけど、余計なことをしないプロ仕様のデジカメは「写真がボケボケでダメだね(キリッ」とか素人に叩かれるので。いやホント。
より多くのコメントがこの議論にあるかもしれませんが、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:さっそく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: (スコア: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がいいのかな。
Re:WebP とは直接関係ないけど (スコア:1, 参考になる)
ちなみにMacOS XのでかいアイコンはJPEG2000圧縮です。
512x512程度の大きさだとデコード処理時間は数十ミリ秒のオーダーなので全く問題になりません。
Re: (スコア:0)
> やりたい人がやるならともかく、「余計なシャープネス処理を問答無用でかける」のだとすれば 正直やめてほしいと思います。
> 特に入門レベルのデジカメの場合は、その辺を適切にやってくれる
ところで安物のデジカメは問答無用でシャープネス処理をかける場合があるのは知ってる? もちろんプロにとっては余計なお世話なんだけど、余計なことをしないプロ仕様のデジカメは「写真がボケボケでダメだね(キリッ」とか素人に叩かれるので。いやホント。
Re: (スコア:0)
クッキリした輪郭の画像をDCTかけると高い周波数の成分を残さないとボケてしまうので、あまり圧縮できない。
しかし、後処理の逆関数のようなものをかけてからDCTかけると高い周波数の成分が少なくて済むので、よく圧縮できると思う。
むかしのような単純な線形フィルタなら意味がないですが、いまどきの輪郭補正処理は非線形のすんごい処理をしてますんで。