パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Google、静止画フォーマットWebPを発表」記事へのコメント

  • by Anonymous Coward

    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時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対応くらい余裕でしょー。

            親コメント
            • by Anonymous Coward
              JPEG2000 (wavelet)は今でも悪くはないと思いますが、 やっぱり処理量が厳しいんでしょうね。 (少なくとも PC で扱うには十分大変に感じます)

              H.264 だのなんだのは基本的にソフト処理ではなく ハードウェアのエンコーダ・デコーダを積んでいるわけですが 「結局流行らせるのに失敗したJPEG2000」では そういうものもないですから、 やっぱり無理。 結局なまじ素のjpegがそこそこ高品質に対応できてしまうので (普及しない 処理系が出てこない)の無限ループから出てこれないんですよね。 depth 8bit超が一つのチャンスかと思っていたのですが…
              • by yosusuki (40683) on 2010年10月02日 14時43分 (#1833609)

                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がいいのかな。

                親コメント
              • by Anonymous Coward on 2010年10月01日 22時39分 (#1833387)

                ちなみにMacOS XのでかいアイコンはJPEG2000圧縮です。
                512x512程度の大きさだとデコード処理時間は数十ミリ秒のオーダーなので全く問題になりません。

                親コメント
          • by Anonymous Coward

            > やりたい人がやるならともかく、「余計なシャープネス処理を問答無用でかける」のだとすれば 正直やめてほしいと思います。
            > 特に入門レベルのデジカメの場合は、その辺を適切にやってくれる

            ところで安物のデジカメは問答無用でシャープネス処理をかける場合があるのは知ってる? もちろんプロにとっては余計なお世話なんだけど、余計なことをしないプロ仕様のデジカメは「写真がボケボケでダメだね(キリッ」とか素人に叩かれるので。いやホント。

          • by Anonymous Coward
            後処理の内容がキッチリ決まっていれば、それに合せてエンコードできるんですよ。

            クッキリした輪郭の画像をDCTかけると高い周波数の成分を残さないとボケてしまうので、あまり圧縮できない。
            しかし、後処理の逆関数のようなものをかけてからDCTかけると高い周波数の成分が少なくて済むので、よく圧縮できると思う。

            むかしのような単純な線形フィルタなら意味がないですが、いまどきの輪郭補正処理は非線形のすんごい処理をしてますんで。

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

処理中...