アカウント名:
パスワード:
だいたい、そんなところです。libpng は、ファイルフォーマットの組み立て/解釈と、 圧縮率を高めるためのフィルタ処理ぐらいしかしてません。
PI の圧縮/展開コードも書いたことがあるのですが、PNG の deflete 圧縮よりも 速くて平均的に高圧縮率でした。'90年代の初めに pi の英語版の仕様書があれば、 海外からもそれなりの反響があったのかもしれないですね。
一言で言えば、近隣の画素との差を取っているだけです。そうすることで値が0近辺に集中するので、圧縮がかかりやすくなる。
差の取り方が(差を取らない場合も含めて)5種類あって、局所的な画像内容に応じてこれらを自由に切り替えられるので、その選択法によっても圧縮率が変わります。
# ソースを読むより、とりあえず日本語版PNG仕様書の方がわかりやすいと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
PNGって (スコア:2, おもしろおかしい)
に. とどまってしまっらった点も、普及の妨げになった気がします。
まあ今でこそブロードバンド大流行りで200~300KB程度ある
画像も 苦にならなくなっていますが、ダイアルアップ/INS64
全盛期には ・・・・・そう大きい画像は嫌われてましたし(今も?)
Re:PNGって (スコア:0)
GIFも似た感じだった気がするので、外人の作った処理系の合理性を見た気がする。
日本発の画像圧縮(PIC/MAG/PI等)は画像特性(アニメ塗りやタイル)に特化した処理を行っていたので、それと比較して「芸がない」とか思った昨今。
ついでに、PIC2とかJPEG2000とか複雑すぎる実装は重すぎたりライブラリが移植しずらかったり、使っているプログラマが内容を理解できない(俺の事)ので普及にくいのかもしれません。
PNGはよりよく改良された GIF (スコア:1, 興味深い)
PNG 初期の構想が立ち上がった頃は GIF代替が目的でした
けど後に GIFの良い特徴を拡張して備えた新しい GIF の
ような設計になっています。
トゥルーカラーサポート,透過の拡張,良いプログレッシブ
再生,ストリーム転送におけるエラー検出...
そういう点に重きが置かれている一方、特定の特徴をもった
画像に特化する事は設計に含まれません。
例えば自然画像に特化した圧縮機構をもつJPEG(JFIF)の再実装は
避けられました。 それは既に JFIF という良い実装があったので
同じ事をする意味がないというだけでなく、JPEG と PNG を実装
するソフトウェアに対して自然画像向け実装を二つも持たせて
しまうという無駄を避ける意味もありました。
Re:PNGって (スコア:1)
だいたい、そんなところです。libpng は、ファイルフォーマットの組み立て/解釈と、 圧縮率を高めるためのフィルタ処理ぐらいしかしてません。
PI の圧縮/展開コードも書いたことがあるのですが、PNG の deflete 圧縮よりも 速くて平均的に高圧縮率でした。'90年代の初めに pi の英語版の仕様書があれば、 海外からもそれなりの反響があったのかもしれないですね。
Re:PNGって (スコア:0)
PNGもフィルタ処理によって圧縮率が変わるので、どんな事してるのかなぁ~と思って。
ちゃんと調べるか…。
#LIBPNGは大きいので苦手なAC
Re:PNGって (スコア:2, 参考になる)
一言で言えば、近隣の画素との差を取っているだけです。そうすることで値が0近辺に集中するので、圧縮がかかりやすくなる。
差の取り方が(差を取らない場合も含めて)5種類あって、局所的な画像内容に応じてこれらを自由に切り替えられるので、その選択法によっても圧縮率が変わります。
# ソースを読むより、とりあえず日本語版PNG仕様書の方がわかりやすいと思う。
Re:PNGって (スコア:0)
http://tech.millto.net/~pngnews/kndh/PngSpec1.2/PNG-Filters.html
ここを見ればいいでしょう。
要するに、可逆性を保ったまま、画像をzlib好みのデータに変形する処理のことです