« (連載)第4回:GIF(じふ) | トップページ | MUSIC R25(2006/10/24) get! »

(連載)第5回:PNG(ぴんぐ)

敢えて言おう、カスであると。

PNG は Unisys が GIF の圧縮技術である LZW について権利を主張し、 GIF の公共性がグラついた事を期に仕様化された。

PNG は GIF を 凌駕(りょうが) 駆逐(くちく) する事が唯一の目的だった。


実際、当時にさかのぼって、Unisys が権利主張し始めた頃は、多くの人が (いきどお)りを感じたものです。

「なんで皆が使っているものに課金する!」
「Unisys 許せない!!」
キィーッ!!

そんな頭に来た人達によって PNG は作られたのです。

本来“ものづくり”というのは、その“もの”を使う人の利益を考えて作らなくてはなりません。
そうしないと決して良いものはできないのです。

ところが、PNG を作る動機は
「GIF ぶっ潰してやる」
「GIF の市場、奪い取ったる」
キィーッ!!
なのですから、全くユーザーの方は見ていないわけです。
動機が不純なのですから、良いものができるはずがありません。
キィーッ!! という感情に任せて作ったものなどダメなのです。



では、PNG がどれほど素晴らしいのかを見ていきましょう。
まずは、圧縮率からです。

一部の人達によって「PNG の圧縮率はたいていの場合、GIF を凌駕する」と言われています。
本当でしょうか?

まずは 256 色の画像について検証してみましょう。
Lena という有名な画像です。
ちなみに、"ZIP" と書いているのは、BMP ファイルをそのまま ZIP 圧縮したものです。
lena (512x512x256)
BMP 263,222 byte
(100.0%)
GIF 191,793 byte
(72.9%)
PNG 194,418 byte
(73.9%)
ZIP 168,255 byte
(63.9%)

GIF の勝ち(辛勝)


1画像だけで判断するのは危険です。
別ファイルでもやってみましょう。
GoldHill という、これも有名な画像です。
gold (720x576x256)
BMP 415,798 byte
(100.0%)
GIF 268,146 byte
(64.5%)
PNG 270,566 byte
(65.1%)
ZIP 240,112 byte
(57.7%)

またも、GIF の勝ち(辛勝)

256 色というのは、PNG にとって不利なのかもしれません。
もう少し色数を落として、規則的なパターンで試してみましょう。
※ 16bits になっていますが、実質 2bits です。
市松模様 (128x128x16)
BMP 8,310 byte
(100.0%)
GIF 1,198 byte
(14.4%)
PNG 1,556 byte
(18.7%)
ZIP 235 byte
(2.8%)

GIF の勝ち
このパターンは PNG よりも GIF に有利だった様です。

PNG にくらべ、ZIP がはるかに圧縮できているのは何故でしょう?

PNG は ZIP と同じ inflate/deflate を用いています。
なぜ ZIP と同じ圧縮エンジンを用いているのでしょうか?
おそらく、キィーッ!!っとなった時に たいした考察もなく
「圧縮エンジンは有名所の ZIP と同じにしておけば良いだろう」
ぐらいの考えだったのでしょう。

それなのに、ZIP に遠く及ばない。。。

ZIP はファイル単位で圧縮を行います。
PNG は画像のライン単位で圧縮を行います。
この差です。

なぜこんな処理にしちゃったのでしょう?

たぶん、インターレースの処理が頭から離れなかったのでしょう。
頭に血が上っているのですから、仕方ないと言えば仕方ない。

ちなみに“可逆”(圧縮して展開すると完全に元に戻る)の場合、
「エントロピーをいかに最大にするか」
が圧縮率の唯一のファクターです。
この分野では ZIP や LZH が凌ぎを削っています。
可逆の画像フォーマットが圧縮率で ZIP を追い抜くという事はかなり難しい事になります。
画像専用の圧縮フォーマットであれば、 画像の持つ特徴に合ったエントロピー圧縮を行えば ZIP を追い抜く可能性が出てきます。

もし PNG が ZIP の圧縮率に近い値を出すことができていれば
  「おまえ、よく頑張った。」
と褒めようという気にもなりますが、、、
同じ圧縮エンジンを用いている割には離され過ぎです。
「桁違いじゃないの。」

結論から言うと、PNG が極端に良い圧縮率を叩き出せるのは、画像データがPNG のフィルタにマッチした著しく特殊なケースだけ、 すなわち PNG にとって都合の良い一部の画像だけなのです。

安易に ZIP の inflate/deflate に手を出した事にも問題があります。
ZIP は今まで何度もセキュリティホールが見つかって修正した過去があります。
ZIP のセキュリティホールを突いたウィルスが画像データの形で撒き散らされたら、と思うと、そら恐ろしい事です。
画像データの圧縮フォーマットを作ろうという人達は、独自の力で圧縮エンジンを作り上げるだけのスキルが必要なのです。
「他の人が作った便利なモノを使えばいいや。」という考え方では安直過ぎるのです。


次に、PNG のもう一つの特徴である「 GIF は 256 色までしか扱えないけど、PNG はフルカラー扱えるもんネー!」について検証してみましょう。
JFIF テスト画像 (227x149x24bit)
BMP 101,970 byte
(100.0%)
GIF -
(24bit 圧縮はできない)
PNG 85,539 byte
(83.9%)
ZIP 77,897 byte
(76.4%)
JPEG 5,446 byte
(5.3%)

“可逆”を捨てきれない PNG は “不可逆”と割り切った JPEG には全く太刀打ちできません。
完敗です。
もし“可逆”が必要な画像データだったら (情報量を落とさずに圧縮したいなら)、 ZIP 圧縮すればよいのです。
「レントゲン写真を JPEG 圧縮して肺にノイズが写ったら困るじゃないかーー!」という PNG 信者による子供地味た反論を聞いた事があります。
「そんな重要なデータは圧縮するな」と言いたいです。



PNG 開発の唯一の、そして最大の目的が“GIF の駆逐”だった訳ですから、 プロパガンダのために宣伝文句が幾つも必要だったはずです。

しかも、圧縮率が悪い、処理時間が遅い、バッファが沢山必要、と実力を伴わないフォーマットなので、極めて不利な戦いだったのです。

キィーッ!!っとなった人達(しかも大して技術を持たない人達)が不利な状況をひっくり返すには “大衆を見方に付ける”というやり方しかなかったのかもしれません。

そうなると、
「Indexed color だけではなく full color が扱えます」と言わなければならないし、(JPEGには負けるけどネ)
「透明色が1色ではなく、Alpha channel が扱えます」と言わなければならない。(対応しているブラウザあんまり無いけどネ)
「圧縮率で GIF を圧倒する」とデータを改ざんするような真似までして虚栄をはるような事までしなければならない。(ウソはいけないヨネ)
モニタの色温度を考慮するようなブラウザが無いのを知っていて「γ補正が・・・」(意味ないヨ)
必要も無いのに「48ビットが・・・」(これも意味ない)

聞いていて虚しいばかり。。。

プロパガンダのためのスローガンだけが先行する形になってしまう。

たいした中身が無いのに、必要の無い機能まで山ほど詰め込んでウダウダの仕様(バランスを欠いた仕様)になってしまう。


たとえば、あなたが車を買いにディーラーへ出向いたとしましょう。

店員はあなたにこう言います。
「この車、いいでしょう。今ならカーナビお付けしますよ。」
「ETCも付けましょう。」
「5.1chのDVDシアターシステムも付けましょう。」
このぐらいだったらサービスの範囲内かもしれません。
店員はさらにこう言います。
「誰かに“ライフル”で射撃されても大丈夫なように防弾ガラスと装甲車並のボディを付けましょう。」
「だって必要でしょう。無いよりあった方が良いでしょう。」、と。
店員は調子に乗ってさらにこう言います。
撒き菱(まきびし)によってタイヤがパンクさせられるかもしれません。
 今ならキャタピラをお付けしますよ。」

さすがに、この辺で「おかしい!」と気付かなければなりません。

気が付かないと、燃費がひどく悪く、サスペンションも効いていない車に乗るハメになってしまいます。
しかし“目的地にたどり着く”という車の最低限の特徴を備えているために、ディーラーを訴えることもできないのです。

PNG は不要な機能が山ほど付いているという意味で、こんな感じの画像フォーマットなのです。

良いところがほとんど無い。
その上、“GIFを駆逐する”という唯一の目的を成し遂げられなかった。
Unisys の特許失効という燃料切れによって、一気にトーンダウンした。

それが PNG なのです。

もう一度言おう、カスであると。

また、PNG 騒動に踊らされた人にも言いたい。
「ちゃんと検証したのか」と。
「あるいは、ちゃんと考えて、自分なりに納得してそのような結論を出したのか」と。

(おわり)
言いたい事を言ったのでスッキリしました。


市松模様に関する補足(2007/1/23)

“名無しさん”から「bmp2png で圧縮したら 191 バイトだぞ、ゴラァ(゜Д゜#)」というご指摘を受けたので試してみました。

実際にやってみると、181 バイトでした。おー、ふごい。


では、どこに違いがあったのか見てみましょう。

まず GIF から。

青色の部分が LZW による圧縮データ(画像データをエントロピー圧縮した部分)です。
0000000 47 49 46 38 39 61 80 00 80 00 b3 00 00 00 00 00 GIF89a....3.....
0000010 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000030 00 00 00 00 00 00 00 00 00 00 00 00 00 21 f9 04 .............!y.
0000040 00 00 00 00 00 2c 00 00 00 00 80 00 80 00 00 04 .....,..........
0000050 fe 10 04 49 a7 ad f8 ea cc b7 ef e0 27 86 e4 e8 ~..I'-xjL7o`'.dh
0000060 99 65 8a ae 6a cb be a0 2b c3 f4 6c d7 e7 ad e3 .e..jK> +CtlWg-c
0000070 7b cf 4f be e0 4f 48 d4 0c 8f c5 24 12 b8 54 3a {OO>`OHT..E$.8T:
0000080 9b 2f e8 73 2a fd 50 af 55 65 76 8b 75 76 b9 60 ./hs*}P/Uev.uv9`
0000090 61 78 fc d5 95 c9 68 57 7a 7d 26 b5 d9 f0 4c 7c ax|U.IhWz}&5YpL|
00000A0 fe 06 d4 e9 70 fc bd bc d7 a3 fd 7d 57 81 80 60 ~.Tip|=<W#}}W..`
00000B0 84 83 5e 86 89 62 87 8a 4d 8c 8f 50 8d 90 3d 93 ..^..b..M..P..=.
00000C0 92 3f 96 95 36 99 98 34 9c 9b 2d 9f 9e 2b a2 a1 .?..6..4..-..+"!
00000D0 6e a4 a7 72 a5 a8 1b aa ad 39 ab ae 76 b0 ab b3 n$'r%(.*-9+.v0+3
00000E0 b1 b1 b3 b5 a8 b7 b7 b9 ad bb b4 bf be bd a2 c3 1135(779-;4?>="C
00000F0 a5 c1 a7 c5 9e c7 aa c9 9f cb c4 cf ce cd 96 d3 %A'E.G*I.KDONM.S
0000100 99 d1 9c d5 92 d7 9b d9 93 db d4 df de dd 89 e3 .Q.U.W.Y.[T_^].c
0000110 8f e1 8d e5 86 e7 90 e9 87 eb e4 ef ee ed 7e f3 .a.e.g.i.kdonm~s
0000120 81 f1 84 f5 7a f7 83 f9 7b fb f4 ff fc f5 9b 33 .q.uzw.y{{t.|u.3
0000130 b0 4e 40 3c 05 e3 1c bc 93 b0 cd 42 82 0f 1d 36 0N@<.c.<.0MB...6
0000140 5c 33 91 4f c5 3f 11 d9 64 3c 73 b1 cb 46 8a 55 \3.OE?.Yd<s1KF.U
0000150 1f 3d 76 1c 33 52 50 c9 42 21 c9 a4 c4 72 72 ca .=v.3RPIB!I$DrrJ
0000160 4a 92 2f 5d b6 dc 32 13 51 4c 9a 37 6d d6 8c 94 J./]6\2.QL.7mV..
0000170 33 4b 4f 2d 3f a5 04 2d b2 33 c9 50 9e 45 1d 25 3KO-?%.-23IP.E.%
0000180 5d b4 14 c9 51 a6 4f 87 44 f5 d1 34 c8 d4 23 55 ]4.IQ&O.DuQ4HT#U
0000190 9d 66 dd b1 55 6a d7 1b 5f 79 5c e5 3a 56 6c d8 .f]1UjW._y\e:VlX
00001A0 19 67 6b 44 00 00 3b                            .gkD..;
次に PNG です。
同じく青色の部分が(LZW ではなく)zlib による圧縮データです。
見事に小さいですね。
0000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 .PNG........IHDR
0000010 00 00 00 80 00 00 00 80 04 03 00 00 00 31 10 7c .............1.|
0000020 f8 00 00 00 30 50 4c 54 45 00 00 00 80 00 00 00 x...0PLTE.......
0000030 80 00 80 80 00 00 00 80 80 00 80 00 80 80 80 80 ................
0000040 80 c0 c0 c0 ff 00 00 00 ff 00 ff ff 00 00 00 ff .@@@............
0000050 ff 00 ff 00 ff ff ff ff ff 7b 1f b1 c4 00 00 00 .........{.1D...
0000060 40 49 44 41 54 68 81 ed ce 31 0d 00 00 08 03 b0 @IDATh.mN1.....0
0000070 39 c0 bf 4b 24 20 62 17 49 ab a0 99 52 b6 14 03 9@?K$ b.I+ .R6..
0000080 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 ................
0000090 03 03 03 03 03 03 03 03 03 03 03 03 03 83 e7 83 ..............g.
00000A0 03 2b 5e f0 e2 dd 71 f1 12 00 00 00 00 49 45 4e .+^pb]qq.....IEN
00000B0 44 ae 42 60 82                                  D.B`.
もう少し詳しく見てみましょう。

IHDRの12バイト目、赤色の
00
の部分は Filter method を示す。
Filter method = 0 は「フィルター無し」を意味すし、
続く、緑色の
00
の部分は、Interlace method を示す。
Interlace method = 0 は「インタレース無し」を意味する。

つまり libpng の部分はデータそのものには加工を加えていない。
圧縮率には全く寄与していない事になります。
高い圧縮率は zlib によってもたらされたものです。
「エンジン性能が良いから高い圧縮率が得られた。」
それだけの事です。

私の主張はこうです。
「だったらわざわざ PNG のヘッダなんて付けずに、ZIP 圧縮しろよ。」

PNG の存在意義を私は認めません。

ちなみに、10月24日にアップした上記の記事ですが、
IrfanView 3.98 とその plug-in
PNGOUT.DLL (Dec 26 2005) Optimized PNG Format - PNGOUT by Ken Silverman
を用いています。
PNG と GIF とを同条件で圧縮した結果です。

|

« (連載)第4回:GIF(じふ) | トップページ | MUSIC R25(2006/10/24) get! »

画像フォーマット」カテゴリの記事

コメント

ぜんぜんエロくないのですが、
これもSPAMでしょうか?

投稿: これもSPAM? | 2006年10月24日 (火) 20時38分

Even Smudge was as much, within five miles of those clumsy traders that sailed, her boom being guyed out on the forecastle.

投稿: investment advisor due diligence | 2006年12月20日 (水) 16時46分

>また、PNG 騒動に踊らされた人にも言いたい。
>「ちゃんと検証したのか」と。
>「あるいは、ちゃんと考えて、自分なりに納得してそのような結論を出したのか」と。

逆に君に言いたい。

元の画像データが無いので細かい検証はできないが、少なくとも3つ目(市松模様)の画像はpngで191byteまで圧縮できる。

使用ソフト:bmp2png Ver.1.62 (http://cetus.sakura.ne.jp/softlab/)

少なくともこの回のデータはまったく信用できない。

投稿: | 2007年1月21日 (日) 23時13分

元画像は、棒グラフの上のところ、

BMP 8,310 byte(100.0%)
 ↑ここ

の [BMP] や [GIF],[PNG],[ZIP]をクリックしていただけると得る事ができます。

よろしくどうぞ。

投稿: koujinz | 2007年1月22日 (月) 05時11分

She was down, that Talcott was quitting the coast of South America, his broadside was delivered in among our luck, sir, you are after; for what could you agree.

投稿: nasa sp-125 | 2007年2月 1日 (木) 18時02分

This appeal could not withstand, though mild light of the spot, reasonably enough offering as a log, one of the great centre of the sea, they are not to impede the motion of the Hurons take to admiring her sister.

投稿: collision course | 2007年2月 4日 (日) 06時34分


http://shoeshere.srirud.info/index10.html 355af auto clip flash hot shoes sunpak
355af auto clip flash hot shoes sunpak
http://shoeshere.srirud.info/index11.html dsw locator shoes store
dsw locator shoes store

投稿: hoagedj | 2007年2月 9日 (金) 01時07分


http://shoeshere.srirud.info/index10.html 355af auto clip flash hot shoes sunpak
355af auto clip flash hot shoes sunpak
http://shoeshere.srirud.info/index11.html dsw locator shoes store
dsw locator shoes store

投稿: hoagedj | 2007年2月 9日 (金) 01時09分

初めまして、はてなブックマークより辿り着きました。
わたしも PNG は最近使い始めたので詳しい訳ではないのですけれど、こちらの実験結果にはとても疑問を持ったので、元画像から GIF と PNG に圧縮して検証してみました。

使用ソフトは Yukari + BlastPNG です。 もちろんすべて同条件で圧縮してあります。

lena:

GIF → 187KB
PNG → 156KB 31KB 勝ち

gold:

GIF → 261KB
PNG → 219KB 42KB 勝ち

市松模様:

GIF → 1.16KB
PNG → 0.93B 0.23KB 勝ち

JFIF テスト画像:

JPG → 6.78KB
PNG → 47.5KB 40.72 負け

検証結果まとめ ZIP: http://eclucifer.net/png.zip

色数の少ない市松模様や一色のものなどは GIF が強いみたいですけれど、PNG の方がどれも大分勝っていると思います。 さすがに JPEG ( BTJ32 を使用しました ) には勝てませんが、非可逆であることがネックの場合もあるので、ケースバイケースですよね。

もっと詳しい方の手によれば違う結果にもなると思うのですけれど、詳しくないわたしがソフトの自動設定でポチっと圧縮しただけでもこれだけの差が出ました。 PNG はカスじゃありません。 とっても良い仕事をしてくれています。

投稿: lynx | 2007年5月12日 (土) 09時47分

256階調アルファチャンネルによる透過処理やガンマ値保持による環境に左右され難い色表示といった利点をスルーして圧縮率だけで語るのはあまり適正な評価姿勢とは言えないのでは?

投稿: 芹沢 | 2007年5月12日 (土) 13時31分

lynxさん、芹沢さんへ

まず最初に断っておきますが、
「カスである/カスでない。」というのは主観です。
ですから、これに関して議論するのは不毛です。
宗教論争で両者の意見が平行線をたどるのと一緒です。

私の主張(PNG=カス)は変わる事がありません。

●PNG, GIF 圧縮率について
1/23 の追加分で書きましたが、

圧縮率で PNG が GIF を上回る場合があるとすれば、
それは PNG そのものの寄与ではなく、圧縮エンジンとして使われている zlib が優れているからです。

GIF は LZW を用いていますが、これが 1980 年代の旧式エンジンです。
zlib は ZIP として知られていますが、年々進歩しているようです。
zlib 1.2.3 は 2005 年式です。

「圧縮エンジンが優れているから圧縮率が高い」
この図式です。
「自分の力で勝ったのではないぞ。そのモビルスーツの性能のおかげだという事を忘れるな!」
という事なのです。

であれば、
「 PNG 圧縮などせずに、素直に zip 圧縮すればいいんじゃないの?」
というのが私の主張です。

画像データをシーケンシャルなデータととらえて圧縮する場合、
エントロピーの上限というものが存在します。
「エントロピー圧縮の限界にどこまで近づけるか」
その意味で 1980 年代に進歩を止めたのが GIF の LZW、
今なお進化を続けているのが zlib です。

しかし、如何せん、上限があって、そのギリギリに近づけるかどうかを競っていては『どんぐりの背比べ』な訳です。
少なくとも PNG の宣伝文句「ほとんどの画像で PNG は GIF よりも圧倒的な圧縮率」は嘘ですね。

それに比べ JPE2000 という画像フォーマットがあります。
JPEG2000 では、
「画像は周波数分解すると一部の周波数にピークが現れる」
という画像ならではの特徴に着目しています。
JPEG2000 には非可逆モード(元に戻らない)と可逆モード(元に戻る)とがあります。

JPEG2000 の可逆モードは PNG の比較にならない程の圧縮率を実現しています。

もしかすると、将来いつか、zlib が JPEG2000 の圧縮方法を取り入れる時が来るかもしれません。
その時には、PNG は GIF に比べ圧倒的な圧縮率を誇る事ができるでしょう。

ただ、その時でも、私の主張は変わりません。
「だったら、素直に zip 圧縮すれば?」

● GIF が PNG に比べ優れている点
GIF は恐ろしくシンプルに出来ています。
プログラムを書けば、たぶん数キロラインで書けるのではないでしょうか?

ワークサイズの容量にしても、プログラムコードのシンプルさにしても、
GIF の機能美は圧倒的です。
※ 機能美かどうか、というのも主観ですので、異論はあるかと思いますが、
 私は、GIF の機能美を主張します。

● αチャンネル、ガンマ補正について
PNG はαチャンネル、ガンマ・チャンクを備えています。
ただ、その機能がどれだけ使われているのか?

Web ブラウザでは、αチャンネルはほぼ実現されていると思います。(未確認ですが)
携帯電話では、PNG が表示できるもの、できないものがあります。
その内、αチャンネルに対応しているものはどの位あるのでしょう。
標準となっていない機能、そんな機能は必要なのでしょうか?

ガンマ補正はどうでしょう?
ガンマ補正をするには表示デバイスの色温度が分からなければ話になりません。
そんな補正をしているアプリはあるのでしょうか。

これも私の主観ですが、
「PNG は GIF が特許問題で使いづらかった期間だけ存在価値があったのです。」
「GIF 特許という後ろ盾を失った今では、存在価値の根拠が無くなったのです。」

投稿: koujinz | 2007年5月12日 (土) 17時42分

お返事ありがとうございました。 カスかどうかはおっしゃるとおり主観なので、きのこの山かたけのこの里かの論争のように自分がどう思うかなのであって他者の意見は関係ないのはそのとおりですよね。 これに関して論争したい訳ではないのでそれはさておき。

でも、zip では Web ページに表示出来ませんよ。 何でそこで zip zip 言うのかが判らないのですけれど、わたしは絵を描くので、それを載せるためには JPEG が GIF か PNG で、PSD などをダウンロードしていただくときに zip は使います。 でも zip で圧縮されたものそのものを絵として表示することは出来ませんよね。 だから PNG じゃなくて zip 使えば良いじゃない、というのは、それとこれとは話が別なんですけど、と思いました。

難しいことは専門家ではないので判らないのでどうでも良いのですけれど、JPEG も GIF も PNG も Web に表示させたいから変換する形式ですよね。 圧縮率がどうのこうのとか、PNG はキィー! とかはさておき、綺麗で軽いものなら何でも良いのです。

JPEG、GIF、PNG、それぞれに良いところがあって、それぞれに気に入らないところがあって、色数がたくさんあるものは JPEG で、透過したりアニメーションにしたりするなら GIF、透過もアニメもないなら GIF より軽い PNG で、というように使い分けられます。

だから、PNG の存在価値はなくなったりしていません。 シーケンシャルだとかエントロピーだとかプログラムとかコードとか難しいことはどうでも良くて、わたしみたいな絵描きには、いかに綺麗に表示しつつファイルサイズが軽く出来るかだけが重要なのであって、その点に関して PNG は GIF よりファイルサイズも軽いし JPEG より綺麗で価値あるものだと思います。 もちろんこれもわたしの主観です。

けれど、このように使う人や使い方によって利点がある以上、「 PNG は GIF が特許問題で使いづらかった期間だけ存在価値があった」 「 GIF 特許という後ろ盾を失った今では、存在価値の根拠が無くなった 」 というのは必ずしもそうとは言い切れないのではないでしょうか。

それにしても、お話を聴いてみると JPEG 2000 って良さ気ですね。 きちんと調べ尽くしていないのでまだ詳しいことはよく判りませんが、綺麗で軽いもっと凄いのというと、それが実際 『 使える 』 ようになったらこれほど嬉しいことはありませんね~

投稿: lynx | 2007年5月12日 (土) 19時35分

なるほどね。です。

確かに、24bpp を可逆で Web、ということであれば、
PNG か BMP ぐらいしか選択肢は無いのかもしれません。

「軽い=圧縮率」という視点では、BMP は NG で PNG が残る、ということになるのかもしれません。

画像フォーマットと呼ばれるものには JPEG、GIF、BMP(=DIB)、PNG の他にも Tiff、Targa、Pict、PPM など山のようにあります。
どれも「素晴らしいフォーマットだ」と鳴り物入りで登場し、その後「たいした事ないじゃん」「別のフォーマットの方がいいじゃん」と多くの人に忘れ去られてしまったものです。

フォーマットの乱立というのは、エンドユーザーにとって不利益となります。エンドユーザーが振り回される事になるのです。

画像フォーマットだと分かりにくいかもしれないので、物理メディアのたとえをしますが、
以前 VHS とβの争いがありました。
メーカーはそれぞれ VHS、βが世の中の標準となるべく努力しましたが、結局振り回されたのはエンドユーザーでした。
DVD-R、DVD+R、DVD-RW、DVD+RW、DVD-RAM。
CompactFlash、SmartMedia、メモリースティック、SD、miniSD。
エンドユーザーには、機能限定のものを選ぶか、全部を網羅したコンボ型と呼ばれる高価なものを選ぶかしかありませんでした。
誰が得をして、誰が損をしたのでしょう?

私は「エンドユーザーにとって利益の無いフォーマットの乱立は好ましくない」、と思ってます。

TiffやTargaなど、多くの人に見向きもされなくなったフォーマットは、フォーマットそのものが持つ力が弱かったのだと思います。
だから別のフォーマットが出てきた途端にとって替わられた。

PNGというフォーマット。私はフォーマットとして弱い、そう感じています。
「その内、消えても不思議は無い」、そう思っています。
Webブラウザというメディアに限っては、W3CがPNGを標準と認めた事でしばらくは生き延びるでしょう。

JPEG2000にも弱さがあります。
可逆圧縮を求める人々は世の中にそう多くありません。
「非可逆のJPEGで十分じゃないか」そう思う人々が大多数です。
一部の人は可逆にこだわります。
それでも「PNGがあるんだからいいじゃないか」、そう思われてしまっています。
JPEG2000にとってPNGの存在は参入障壁にしかなっていません。

「PNGは中途半端なフォーマットだ」、と私は思っています。

投稿: koujinz | 2007年5月12日 (土) 23時24分

何でそこで png png 言うのかが判らないのですけれど
BMPをgzipで圧縮してあげれば普通のブラウザ(携帯だと無理かもしれませんが...)なら表示できるかと思いますが...

投稿: 通りすがり | 2007年5月21日 (月) 19時16分

通りすがりさんへ、

情報ありがとうございます。

残念ながら、どのようにすれば gzip 表示できるか分かりませんでした。

ですが、調べてみると、HTTP/1.1 にはContent-Encodingなるものがあるようですね。
HTTPサーバー側でブラウザがgzipやx-gipに対応しているかを調べて、対応している場合は、コンテンツをzip圧縮して送る、というもののようです。

たとえば、Apacheの場合はhttpd.confに次のような行があります。
#AddEncoding x-gzip .gz .tgz
(行頭の "#" はコメントアウトされている事を示す。)

試している時間がないので、どの様な動作になるかわかりませんが。

一部のプロバイダ(Yahooとか)はやってるみたいですね。

投稿: koujinz | 2007年5月21日 (月) 20時40分

推測に基づく展開があまりに多すぎて話にならない。

>「なんで皆が使っているものに課金する!」
>「Unisys 許せない!!」
>キィーッ!!
>そんな頭に来た人達によって PNG は作られたのです。

血上ってんのは誰だよ。
先に絵描きさんが言ってるが、ZIPと比べるのはあまりにナンセンスでお粗末。PNGの開発経緯にWebフォーマットの話が出てきたのはWikipediaにも載ってる衆知の事実。誰も単純なファイルのやり取りの際のファイルサイズだけを気にして開発しただけじゃない。小さいファイルやり取りしたいならCABでも使えばいいじゃん。
「当時普及してなかったから」という理由でαチャンネルやその他の機能を切り捨てるのもあまりに頭の悪いこと。それじゃいつまで経っても新技術は普及しない。「CSSなんて普及してない」つっていつまでもテーブルレイアウトしてたウェブデザイナーが生き残ってると思う?

>JPEG2000にも弱さがあります。
>可逆圧縮を求める人々は世の中にそう多くありません。
>「非可逆のJPEGで十分じゃないか」そう思う人々が大多数です。

どこで誰がそんなこと言ってるの?
誰が調査して検証してデータ公開してるの?
ただJPEG2000の戦略展開が下手くそで知名度が低いだけのことでしょ。本当の一般ユーザは可逆・非可逆なんて頭にないだろうよ。選択的にJPEG2000切り捨てるなんてしてない。

投稿: 本当にあった怖い名無し | 2007年6月 7日 (木) 13時58分

本当にあった怖い名無しさんへ

PNGに洗脳されちゃった人はこれだもの。

とりあえず「貴重な意見、ありがとうございます」
とだけコメントしておきます。

投稿: koujinz | 2007年6月 7日 (木) 14時37分

「PNGカス」って自分洗脳してる人は、具体的な指摘に対しても「PNGに洗脳されちゃった人はアレだ」つって見えない振りするわけね。勉強になりました。

投稿: 本当にあった怖い名無し | 2007年6月 7日 (木) 20時29分

本当にあった怖い名無しさんへ

おそらく一生分かり合えない人ですね。
「具体的」というのであれば
PNGのαチャンネルを視覚的効果として反映しているアプリケーションを2,3種類で良いので具体的に教えてもらえないでしょうか。
PNGのガンマチャンクをディスプレイに反映しているアプリケーションを具体的に教えてもらえないでしょうか。
「可逆圧縮を求める人が多くない」に対する具体的な反証を挙げていただけないでしょうか。
「JPEG2000の戦略展開が下手くそ」という具体的な根拠を挙げていただけないでしょうか。

投稿: koujinz | 2007年6月 8日 (金) 01時02分

質問には質問で返せって習ってんの?他人の質問や指摘には一切答えないけど自分の質問には答えろ、ってか。

>PNGのαチャンネルを視覚的効果として反映しているアプリケーションを2,3種類で良いので具体的に教えてもらえないでしょうか。
>PNGのガンマチャンクをディスプレイに反映しているアプリケーションを具体的に教えてもらえないでしょうか。

知らんよ。誰も「現状PNGのαチャンネルは既に普及している技術です」とは書いてない。今後利用されうる技術を「今対応してるアプリケーションがないから不要」と切り捨てるのは馬鹿のやること、とは書いてるけどな。

>「可逆圧縮を求める人が多くない」に対する具体的な反証を挙げていただけないでしょうか。

可逆圧縮を求める人が多くない、と根拠なしに言い出したのは自分でしょ。それについて「根拠ないんじゃね?」と言われて「じゃ根拠がないということについて例示してください」って無理だろ。どうやって「可逆圧縮を求める人は多くないということはあまり調査されてない」って証明すんの。可逆圧縮を求める人が多くないことを具体的に示したデータを出せばぐうの音も出ないのに、どうしてそれをしないの?データが出ていないことを証明するのは悪魔の証明だよ。全世界の全統計の全公開資料をチェックしてるわけがない。ただ今までインターネットを巡っていてそんなものに出くわしたことがないというだけのこと。

>「JPEG2000の戦略展開が下手くそ」という具体的な根拠を挙げていただけないでしょうか。

良質なフォーマットが前時代的な古参を駆逐できないのは、機能が不十分か展開が下手くそか、のどちらか。JPEG2000の能力については先に述べてるみたいだから、ここで注釈する必要はないね。
じゃその優れたJPEG2000がどうして普及しないのか?デファクトスタンダードに取って代われないのか?そもそも知名度があまりに低いのはなぜか?そのへん考えればわかるでしょ。

投稿: 本当にあった怖い名無しさん | 2007年6月 8日 (金) 02時49分

少なくとも日本においては、JPEG2000のSusieプラグインその他それ関係の作者が、昔から結構な騒動を起こす人だったってのはあったな。
かつてはショタコンだと自称していて今でもサイトにそういう絵をたくさん貼っていたり、生きている他のプログラムの作者の死亡報告を自分のホームページで出して祭になったとか。

そんなわけで、JPEG2000が日本で広まらなかった理由とか言われることもあるみたい。
そういう意味で、JPEG2000の戦略展開とかいう以前の問題もあるね。
他の人がJPEG2000のSusieプラグインとかを作っていたらもうちょっと日本ではマシに広まっていたかもね。

あと、画像プログラムを書く上で、PNGのバイナリ列がWindows標準というかIntel標準のリトルエンディアンではなく、Mac標準というかモトローラ系CPU標準のビッグエンディアンなのはムカつくな。
あと、CRC32をチャンクごとに算出するのが面倒とか。
だがまあ、それら以外の仕様はとくに不満を言われることはないな。

GIFは、ひたすら古くさい。
LZWも今となっちゃ古くさい。
GIFのファイルフォーマットは、リトルエンディアンなのでWindowsプログラムはそれなりに書きやすいが、グローバルパレットとローカルパレットと両方あったり、とにかく今みると仕様が格好悪い。

というわけで、いまさらGIFに比べてPNGがカスだ、俺の考えはおまえらが何を説明しても変えるつもりはないとか言っちゃうと、普通は反感買うよねやっぱり。
非合理的だし。
ttp://b.hatena.ne.jp/entry/4694351

逆にいえば、たとえば、deflateより圧縮率の高いLZMAとかを使った画像フォーマットの規格をkoujinzたんが提唱したら注目をあびれるとすら思うよ。

投稿: 通りすがり | 2007年8月 9日 (木) 23時50分

通りすがりさんへ
貴重な意見ありがとうございます。

PNGについての私の見解は(刺激的ではない文体で)その内、書きたいのですが(書ければ…)

■ JPEG と JPEG2000 について
JPEG の認知度/使用度と JPEG2000 の認知度/使用度の違いについては異論ないと思います。
> JPEG2000のSusieプラグインその他それ関係の作者が、
その影響は多少はあるのかもしれませんが、
おそらく、世の中の人が JPEG2000 をそれほど必要としていない事が第一要因だろう、と私は思います。

■ PNG と GIF について
PNG の使用度と GIF の使用度とでは、PNG 使用度はそれほどでも無い、と私はみています。(ちゃんと統計をとったわけでは無いのですが)

> GIFは、ひたすら古くさい。
「古い」と「悪い」はイコールでは無いと思います。
古くても良いものは良い。
たとえば JPEG は規格である ISO/IEC 10919-1 が 1991 年ですが、「JPEG は古いから悪い」という論理は成り立たないと思います。

「新しければ良いのか?」
そうでは無いと思います。

> グローバルパレットとローカルパレットと両方あったり、とにかく今みると仕様が格好悪い。
確かに、パレットについてはその通りですね。

■ PNG カスについて
> 俺の考えはおまえらが何を説明しても変えるつもりはないとか言っちゃうと、
そうは言っていません。そのようにとられるような書き方をしてしまったかもしれませんが、その意図はありません。

私が「PNGってカスじゃないなぁ」と考え方を変えられるだけの材料を誰かが提唱してくれるのであれば、それに従いますが、未だかつて、そのような材料には出会えていません。

私が PNG を批判している理由は主に下記の3点です。
(1) 画像特有の特徴を捉えた圧縮法を導入できていない事。
JPEG、MPEG は DCT 変換という手法で周波数抽出を行っています。
JPEG2000はウェーブレット変換という手法に挑戦しました。
(画像ではありませんが)MP3 は MDCT という方法で周波数抽出しています。
MPEG-4 は DCT をベースとしながらも、4x4 などそれまでの 8x8 とは違った DCT を導入しましたし、固定小数点という手法でデコーダ側の計算誤差を無くしました。
プロパガンダを行わなくても世の中に受け入れられる画像や音声フォーマットは技術面で何か新しいものに挑戦し、それを形にしています。
PNG にはそれがありません。
(2) 市場の大部分が GIF と重なる事。
RGB24 という GIF とは異なる市場部分があるのは確かですが、やはりターゲット市場の大部分は GIF と重なっています。
私は「PNG の誕生には、GIF を市場から追い出すという悪意の目的があった」と思っています。
そして、その目的を遂行できなかった。
そう思っています。
(3) 過度なプロパガンダを行った事。
PNG が世の中に宣伝された時、「PNG は GIF に比べほとんどの画像で“圧倒的な圧縮率”」というプロパガンダが行われた事をご存知でしょうか?

当時は、PNG 圧縮率が GIF 圧縮率に勝る事は、ほとんどの画像で無かったのです。
PNG が圧縮率で GIF に勝てる特別な画像を選ばない限り。
今では deflate の努力で PNG 圧縮率が GIF 圧縮率を上回るようになりましたが、“圧倒的”と言えるほどではありません。
どんぐりの背比べでかろうじて上回った、というぐらいです。
deflate の努力は PNG にとっては他力本願です。(自ら努力した訳ではない。)

■ その他
> deflateより圧縮率の高いLZMAとかを使った
残念ながら、そのつもりは、、、

市場がそれを求めているとは思えないし
(市場の一部はそれを求めているかもしれませんが、市場の大勢はそれを求めていない)

第一、注目を浴びようとは思わない。

投稿: koujinz | 2007年8月10日 (金) 02時27分

レスどもども。

たしかにW3CがやったGIF批判というかUNISYS批判は、いきすぎの部分もあったよねー。
W3CにMacユーザーが多かったのか、ビッグエンディアンなんか採用しやがったし。
Windowsプログラム書きは、結構むかついたと思う。

それでも、今となってはGIFはフルカラーが無いのが決定的に問題で決定的に古くさい部分しょやっぱり。
透過度も無いし、将来的にそういった拡張規格をいれようという話にもならないでしょ今更。

JPEGは、非可逆圧縮で、圧縮過程に離散コサイン変換しているせいで、データを各ピクセルの色情報をある領域の周波数情報として持ったのが、結果的によかったねー。
フルカラーにも対応しているし。
風景写真とかとの相性が良すぎる。
おかげで、デジカメの保存フォーマットのデファクトスタンダードになっちゃったし、この先しばらくはその座を維持するでしょう。
JPEG2000が、ほぼ自滅した感じなのもJPEGが古くさいまま長生きしちゃった理由になったよね。
でも、最近話が出てきたJPEG "HD Photo"へは置き換わっていっちゃうかもね。
なんてったって、今度のは、MS謹製だしさ。

あと、PNGに新しめの圧縮率の高い圧縮方法を今後も入れることがないってのは、理由もあるのよ一応。
koujinzたんも知っているとおもうけどさ、PNG以前はTIFFも結構流通してたんだけど、結局主流にならなかったのよ。
これがなんでかというと、あまりに拡張性を高くしてなんでもありの規格にしちゃったのが原因。
ビッグエンディアンもリトルエンディアンも両方とも使えるようにして、また、圧縮メソッドも標準でパックビットやランレングスがあって、拡張規格としてLZWとかJPEGとかロスレスJPEGによる圧縮が認められていて、非公式な圧縮方法としてDeflateやJPEG2000による圧縮方法を使ったTIFFもある。
そういった規格が広がりすぎたTIFFを全部読み込めるようにするプログラムを書こうと思ったらめちゃくちゃ大変なのよ実際。
しかもTIFFの場合、GIFと同じようにLZWを使ったTIFFは例の特許問題が絡んできやがったしさ。

で、PNGでは、圧縮規格をDeflateだけにして、わけわからん圧縮方法を取り入れたりしないようにしたわけ。
あるいは、新しめの圧縮規格を採用してそれがサブマリン特許で使えなくなるという状況がなくなるようにしたわけ。
そういうわけで、将来サブマリン特許とかで企業から
PNGを使うのに金払えとかいうリスクをほとんど無くしたかわりに、圧縮は当分Deflate一本になっちゃった訳ね。

まあ、そういったわけで、PNGでは画像向きの圧縮メソッドを使っていないというkoujinzたんの批判は、正しい。
正しいんだけど、今のところ、Deflate以上に可逆圧縮で画像向きの圧縮メソッドで将来的にライセンスがややこしくなさそうなのはろくにないでしょ多分。
だからこそ、LZMAなんか良さそうなんで、前のコメントではあんなこと書いたわけ。

一方非可逆圧縮では、画像にしろ音声にしろ、それぞれの感覚の閾値以上の高周波をとっぱらう優秀な圧縮メソッドが山ほど出ているよね。
しかし、それをPNGにあてはめて批判するのはアンフェアでしょう。
PNGは元から非可逆圧縮には手を出さない規格なので。

そういう意味で、koujinzたんにもっと責めてもらいたい(wのは、JNGかな。
W3Cが非可逆圧縮用PNGとしてもちだしてきた規格だけどものの見事に広まっていないよね。
Wikipediaに項目すらないw
そんなわけでさ、このブログの記事もJNG相手にぶちあげていたら今よりものすごく説得力があるし、今ほど反感を買っていなさそうな気がするんである意味残念だな。

投稿: 通りすがり | 2007年8月10日 (金) 17時32分

とりあえず、フルカラーで、かつ、透過が使えるフォーマットは、西田幸司のflash8プロモなどのような、写真切り抜いて使うFLASHでは必須、ということをお忘れのようですね。

こればかりは、代替できるメジャーなフォーマットがないですから。表現を方向性を一つ失うことになります。

投稿: ふーん | 2007年8月30日 (木) 23時28分

ふーんさんへ

情報ありがとうございます。

flashの事は良く知りませんでしたので、「flash8でPNGが必須」というのは初耳です。

Macromedia Flash は優れたフォーマットだと思います。
動画というと、avi や mpeg に見られるように1秒を30frameなり60frameに分割して、それをなんとか圧縮しよう、というアプローチがごくごく自然でしたから。
それを「オブジェクトを動かせばよいだろう」という MHEG にも通じるアイデアで、そのアイデアをいち早く実現した。
「frameを圧縮する」より「オブジェクトを圧縮」の方がコンテンツによっては圧倒的な圧縮率を稼げるわけです。
実際、世の中に流れているflashのビットレートはaviやMPEGのビットレートより格段に低いはずです。

Macromedia Flash はこのような優れた部分があったらか爆発的に普及したのだと思いますよ。

ただね、わからないのは「flash8におけるPNGの必要性」なのです。
PNG でなければならない理由がいまいちわかりません。
私は「写真を圧縮するならJPEGで十分じゃん」と思うのですね。
そのへんが良く分かりません。

投稿: koujinz | 2007年8月31日 (金) 02時06分

(追記)
読み直してわかりました。
「フルカラー」+「透過」なのですね。

画像フォーマットで言えば、確かに PNG しかないかもしれませんが。
ただ、フルカラー画像データとアルファ・マスク・レイヤーを指定できれば良いのなら PNG でなくても、とは思いますね。
「画像データ」+「透過マスク」を2つの画像データとして指定できれば実現可能な気はします。

投稿: koujinz | 2007年8月31日 (金) 02時14分

t/o

投稿: 要するにお前バカだろ | 2007年9月 1日 (土) 03時36分

自分の足下しか見えていないみたいですね。
PNG に絡めると異常反応するようですからそれは置いといて、
世の中可逆圧縮でないと困る人たちは少なからずいますよ。
light room とか aperture とかが重宝されるワケの一つに、
どこまでもロスレスで扱えるという側面があるのをお忘れなく。
それとも light room はニッチな人たちだけの物ですか ?
tiff も忘れ去れさられていると言いますが、
無圧縮でデータを渡さなければならない局面があって、
その場合今でも bmp ではダメで、tiff が求められるんですよ。
具体的には、科学技術の分野ですよ。
人間の数で言えば、50万人程度ですか。
世界の人口の0.7%くらいでしょうか、これって少ないですか?
PNG がカスかどうかは私見なのでどうでもいいですが、
自らの感覚だけを持って皆はこう思っていると思い込み
web 上で何かを述べる事は、
不見識と思われても仕方のない事でしょう。
皆がこう思っていると大風呂敷を広げるのであれば、
どこかリンク貼れる様な所から
統計でも引っ張ってくる事が求められます。
そうでなければ、便所の落書きですね。
「カス」という言葉を用いている時点で、便所の落書きでしたね。
失礼しました。
ちなみに私は Mac なので PNG は扱いづらいから
どちらかというと好きではないです。
でもカスだとは思っていませんけどね。

投稿: ... | 2008年3月30日 (日) 08時44分

GIFの代替を狙うなら、Windows Bitmapのファイルをzipで圧縮して拡張子だけ変更して出来上がり、にしておけば十分だったのに。
メタ情報はテキストファイルにでも書いて一緒に入れておけばよい。
これなら実装も簡単w

投稿: うに | 2009年10月 2日 (金) 07時45分

今現在、PNGがその実力をもって広く普及snail
結局GIFは駆逐されますた。(ー人ー)南無w

投稿: PNGサイキョ | 2010年6月 2日 (水) 11時09分

今どき、そんな事を言っているとはかなり御執心な方だ。

もし自説を主張したいのであれば、根拠をもっと分かりやすく示すべきです。
さもないと、単なるストレスのはけ口としか見られないでしょう。
つまり、相手にされない、という事です。

PNG が普及している?
本当でしょうか?
一時期、GIF が敬遠される事がありました。
しかし、GIF フォーマットそのものが敬遠されたというより、
サブマリン特許を出してきた Unisys が敬遠されたという方が正しいでしょう。

何年か前にその特許の有効期限が切れました。
PNG の存在価値は一気に低下しました。
大多数の人にとって PNG を使う必要性は無くなったのです。

パソコンのブラウザでは、GIF, PNG の両方を表示させて見る事ができます。
モーション GIF の置き換えを狙った MNG は普及しているでしょうか?

携帯電話で画像が表示できます。
PNG, GIF, JPG をサポートするモデルと GIF, JPG をサポートするモデルがあります。
なぜ PNG をサポートしないモデルがあるかご存知ですか?
PNG はメモリ容量と CPU 演算量を必要とするのです。
CPU 演算量が多いとはすなわち、熱の発生、電池の消耗につながります。

ところが GIF をサポートせず PNG, JPG をサポートしているプラットフォームがあります。
日本のデジタルTVのarib規格です。
この規格が決められた時期は Unisys 旋風の真っ只中でした。
GIF を敬遠して PNG に乗ったのでしょう。

このデジタルTVでPNGがどの様に使われているかご存知ですか?
私の記憶では、放送局のロゴが確かPNGだったと思います。
16色程の天気図画像、これはPNGにはもってこいなのですが、なぜかJPGで送られてきます。
世の中、こんなものです。

arib規格も GIF にしておけば良かったのに。
お陰で私の自宅のテレビは今日も無駄な熱を放出します。
環境に優しくないですね。


PNG をありがたがっている小数の人(minority)が居る事は知っています。
けれども大多数(majority)にとっては、どうでもいい事です。

もう数年もすれば、majority からは PNG という名称すら忘れ去られてしまう事でしょう。

投稿: koujinz | 2010年6月 2日 (水) 20時44分

PNGが忘れ去られるのはあと何年くらいかかりますか?

投稿: reo | 2013年10月27日 (日) 22時52分

この解説を見てPNGからBMP+ZIPに切り替えて数年になりますが、
PNGの中途半端っぷりがなかなか良い気もします
我が家だとCPUのcorei7を4.5GHzにOCしてもBMP+ZIPでは時間が結構かかりますが、リアルタイムでPNG生成したりすれば今どきのCPUだとJPGとかと大して変わりません。
それでいて、可逆圧縮でも縮みやすいものはそれなりに縮みますし、HDDの容量が増えたと言っても全部BMPだと嵩張りますしね
ウィンドウズペイントの標準保存も7、8といつのまにかPNGになってますし
オーディオ系もなんだか可逆圧縮がじわりじわりときてたり
仰るとおりPNGが優れている訳ではないんでしょうけど、スイートスポットにハマったように感じます。

投稿: bonjin | 2014年6月18日 (水) 02時13分

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/167561/3934333

この記事へのトラックバック一覧です: (連載)第5回:PNG(ぴんぐ):

» ロケットパワーにんじん君があれば燃費向上でガソリン代が節約できる! [ロケットパワーにんじん君があれば燃費向上でガソリン代が節約できる!]
燃料・ガソリン代が安い!お金が貯まるのでプチ投資にもなる。車を換えてもずっと使える燃費向上グッズです。 [続きを読む]

受信: 2006年10月24日 (火) 14時33分

« (連載)第4回:GIF(じふ) | トップページ | MUSIC R25(2006/10/24) get! »