French
DeutschPortable Network Graphics
  上は、8ビット透明チャネルを含むPNG画像。下は、同じ画像を市松模様の背景の上に重ねたもの。市松模様は透明であることを示すためにグラフィックエディタなどでよく用いられる。 | |
| 拡張子 | .png |
|---|---|
| MIMEタイプ | image/png |
| タイプコード |
|
| UTI | public.png |
| マジック ナンバー | 89 'PNG' 0d 0a 1a 0a |
| 開発者 | W3C |
| 種別 | 可逆圧縮ビットマップ画像 |
| 包含物 | 画像、テキスト |
| 拡張 | APNG、JNG、MNG |
| 国際標準 | ISO 15948、IETF RFC 2083 |
（ポータブル・ネットワーク・グラフィックス、PNG、ピング、ピン[1]）はコンピュータでビットマップ画像を扱うファイルフォーマットである。圧縮アルゴリズムとしてDeflateを採用している、圧縮による画質の劣化のない可逆圧縮の画像ファイルフォーマットである。
1996年に登場し、可逆圧縮の画像フォーマットとして既に普及していたGIFの後継フォーマットとなることを目指し、ネットワーク経由での使用を想定した機能や透過処理など、多くの機能をサポートした。ウェブブラウザやグラフィックソフトでのサポートも進み、インターネットを中心に普及した。
「PNG」は「ピング」や「ピン」と多く読まれる。
概説
[編集]画像の色モデルとして、最大16ビットのグレースケール、24ビットと 48ビットのRGB、または8ビットまでのインデックスカラーモード（パレットカラー) を利用することができる[2][3][4]。透過についてはクロマキーによる透過指定、および8ビットから16ビットのアルファチャンネルをサポートする[5]。また、画像に付属するテキストなどのメタデータやガンマ値なども画像ごとに記録できる[1]。
GIFと異なり、PNGにはアニメーション機能はない[2]。ただし、PNGはチャンク（データのブロック）で自由に拡張できるようになっていて、1ファイルに複数の画像を含めることができる。これを使ってアニメーション機能を追加した MNG と APNG が別のフォーマットとして開発されている。他の拡張として、立体視用にステレオPNG (PNS) フォーマット[6]がある。
歴史
[編集]PNGが開発された動機は、1994年末に、GIFに使われていた圧縮アルゴリズムLZWについて米ユニシスが特許を保有しているとし、GIFを使ったソフトウェアに特許権を行使すると発表したことによる[7]。実際、PNGの頭文字は非公式に「PNG is not gif」という意味が込められている[8][9][10]（再帰的頭字語）。また、当時256色以上表示可能なコンピュータが主流になってきたため、GIFフォーマットにある256色までという制限を解消する必要もあった。1999年、ユニシスが非商用ソフトについても特許使用料を請求することを決める[11]と、PNGはさらに注目を集めるようになった。
- 1996年10月1日 - PNG Version 1.0の仕様リリース。後にRFC 2083として承認[12]。同日、W3Cによる勧告[12]。
- 1998年12月31日 - Version 1.1リリース[12]。小規模な変更と三種類の新しいチャンクを追加。
- 1999年8月11日 - Version 1.2リリース。一種類の追加チャンク。
- 2002年8月20日 - 日本において日本工業規格 JIS X4242 『コンピュータグラフィクス及び画像処理－ネットワーク用画像形式(PNG)』が制定される[13]。
- 2003年11月10日 - 国際標準化 (ISO/IEC 15948:2003) 。このバージョンは 1.2 とわずかな差異あり。新規追加チャンクはなし。
- 2004年3月3日 - 国際標準化 (ISO/IEC 15948:2004) [spec 1]
技術詳細
[編集]詳しくは、仕様書[spec 1][spec 2][spec 3]を参照。
ファイルヘッダ
[編集]PNG ファイルはヘッダに 8 バイトのシグネチャ（マジックナンバー）を持つ[14]。16進数の値は「89 50 4E 47 0D 0A 1A 0A」である[14]（制御文字で表すと HTJ P N G CR LF SUB LF）。各値の意味は次の通り。
| ファイル先頭からのバイト位置 | 値 | 説明 |
|---|---|---|
| 1バイト目 | 89 | 8ビットデータをサポートしない転送システムを検知するためのハイビット値[14]。また、テキストファイルが誤ってPNGと認識されるのを防ぐ。 |
| 2バイト目 | 50 | アスキーコードで P、N、G を表す[14]。テキストエディタで開いた場合などに、フォーマットをわかりやすくするため。 |
| 3バイト目 | 4E | |
| 4バイト目 | 47 | |
| 5バイト目 | 0D | MS-DOSスタイルの改行 (CR LF)[14]。MS-DOSからUNIXへの行末データ変換が行われていないかを検知する[14]。 |
| 6バイト目 | 0A | |
| 7バイト目 | 1A | MS-DOSで TYPE コマンドを使ってファイル表示をさせた場合、SUB (EOF) として表示を停止させるバイト[14]。 |
| 8バイト目 | 0A | UNIXスタイルの行末 (LF)[14]。UNIXからMS-DOSへの行末変換が行われていないかを検知する[14]。 |
ファイルヘッダの後にはIHDRチャンクが必ず来て[15]、IHDRチャンクのサイズは13バイト固定なため、シグネチャの次の8バイトも00 00 00 0D 49 48 44 52で固定されている。
チャンク
[編集]ファイルヘッダに続いて、チャンクと呼ばれる複数のデータブロックが続く。各チャンクは画像についての様々な情報を保持するもので、必須チャンクと補助チャンクに分けられる。補助チャンクは任意的なもので、処理プログラム側によっては必ずしも処理されない。このチャンク構造により、PNGフォーマットは拡張性と前方互換性を両立する。
チャンクの構造は、
の順番で配置される[16]。
チャンクの種類は、大文字と小文字が区別されるアルファベット4文字で表される[16]。
- 1 文字目が大文字のときは、必須チャンクに分類される[16]。必須チャンクには、その画像ファイルを読み込むために必要な情報が含まれ、デコーダが解析不可能な必須チャンクに遭遇した場合、エラーとなる[16]。
- 2 文字目の大文字小文字は、そのチャンクがパブリックかプライベートかを示す[16]。大文字がパブリック[16]。パブリックチャンクはその仕様が公開、定義されたもので、公開チャンクともいう。
- 3 文字目は将来的な拡張のためにリザーブされている[16]。現在は常に大文字にしなければいけない[16]。
- 4 文字目の大小は、そのチャンクがそのままコピーできるかどうかを示す[16]。小文字の場合、ファイルへの変更内容に関わらず、そのチャンクをコピーして継続的に使用できる。大文字の場合、他の必須チャンクへの変更の影響を受けることを表す。
必須チャンク
[編集]PNGファイルの読み込みと表示に必要なチャンクで、デコーダが適切に処理する必要がある[16]。
- IHDR - 最も先頭に配置されるチャンクで、以下の順番で13バイトの情報が含まれる。
- PLTE - カラーパレット定義。
- IDAT - zlibにより圧縮されたイメージデータ。複数のIDATチャンクに分割することもできる。この場合ファイルサイズは若干増えるが、PNGをストリームとして生成することができるようになる。
- IEND - イメージの終端を示す。
PLTEチャンクはカラータイプ 3 （インデックスカラー）を使用するときに必須となる。カラータイプ 2 と 6 （トゥルーカラー及び、アルファ情報付きトゥルーカラー）の場合は任意、さらにカラータイプ 0 と 4（グレースケール及び、アルファ情報付きグレースケール）の場合は存在してはいけない。
補助チャンク
[編集]イメージについての付加情報を保持するための任意チャンク。
- acTL - アニメーテッドPNGである事を示し、総フレーム数やループ回数を保持する。
- bKGD - デフォルトの背景色を指定する。これは、単独のイメージビューアで表示するときなど、背景色が特に定まらない場合を想定している。ただし、Internet Explorer 6以前はアルファ値による透過表示をサポートせず、この値を背景色として使用する。
- cHRM - ホワイトバランスを指定する。
- eXIf - Exifメタデータを保持する。
- fcTL - アニメーテッドPNGのフレーム制御情報を保持する。
- fdAT - アニメーテッドPNGのフレーム画像データを保持する。
- gAMA - ガンマ補正値を指定する。
- hIST - ヒストグラム、またはイメージ内で使用されている各色の総量を保持する。
- iCCP - ICCカラープロファイルを保持する。
- iTXt - UTF-8フォーマットのテキストを保持する。圧縮・非圧縮、IETF言語タグを伴うことができる。
- pHYs - ピクセルの物理サイズ、またはイメージのアスペクト比を指定する。
- sBIT - 元データの有効なビット数を示す。
- sPLT - イメージが使用する色を全てカバーできない時に、代替となるパレットを提示する。
- sRGB - 標準的なsRGBの色空間が使われていることを示す。
- tEXt - ISO 8859-1形式のテキストを保持する。キーワードと対になるチャンクを複数持つことができる。テキストの圧縮は行われない。
- tIME - イメージの最終更新日時を保持する。
- tRNS - 透過色情報を保持する。ピクセル単位のアルファ値指定が必要ない場合に使用する。インデックスカラーのイメージについてはインデックスに結びつけるアルファ値、トゥルーカラーやグレースケールのイメージについては、完全に透過とみなす色を指定する。
- zTXt - tEXtチャンクと同じ制限の圧縮テキスト。
フィルタ処理
[編集]PNGのイメージデータはzlibにより圧縮されるが、画像の特徴を利用して圧縮の効率を良くするために、フィルタで事前に処理を行えるようになっている[17]。（展開時には、逆のフィルタがかかる)
例えば、ピクセルの値が次のように並んでいたとする。
100,101,102,103,104,105
このデータには冗長な値が無く、このままDeflate圧縮を行っても効果は得られない。しかし例えば「左の値との差」をとると、データは以下のようになる。
100,1,1,1,1,1
この状態で圧縮すれば、最初の状態よりも高い効果が得られる。上記は極端な例であるが、このように事前に簡単な演算を行うことは、データによっては圧縮率の改善に役立つ。
PNGでは5種類のフィルタを定義している。
- Sub
- 左隣のバイトとの差をとる[17]（上記）。
- Up
- 真上のバイトとの差をとる[17]。
- Average
- 左隣と真上のバイトの平均値との差をとる[17]。
- Paeth
- 左隣、真上、左上の3つのバイトからPaeth値を計算し、その値との差をとる[17]。
- None
- 何もしない[17]。
このフィルタは横一ライン毎に変更できる。どのフィルタをどこに使うかは使用する圧縮プログラムが選択できるため、プログラムによって同じ画像でも異なるサイズになりうる。
圧縮
[編集]圧縮アルゴリズムはDeflate (RFC 1951) を使用し、フォーマットはzlib形式 (RFC 1950) と定められている[18]。DeflateのアルゴリズムそのものはPNGの仕様書には書かれていない。圧縮後のデータは、そのまま IDAT チャンクに格納される。
なおPNGはDeflate以外の圧縮形式もサポート出来るように設計されており、IHDRチャンクやiTXtチャンクには、使用する圧縮形式を明示するCompression methodフィールドがある。ただしVer1.2時点ではCompression methodフィールドで使える値はDeflateを示す一種類だけである。
開発者向けのツール
[編集]PNGを処理するための開発者向けライブラリとしてlibpngがある。これはPNG公式のライブラリであり、最も広く利用されている。C言語で開発されており、多くのプラットフォームで動作する。ライセンスはGPLよりも制限が緩やかである。
他のフォーマットとの比較
[編集]
GIF との比較
[編集]GIF の代替物として開発された経緯があるため、GIFと比較されることが多い。主な差異は以下の通り。
- ほとんどの画像でPNGはGIFより圧縮率が高い[2][19]。
- GIFは1色透過だが、PNGはアルファチャンネルを持ち半透明の表現が可能[5]。
- PNGはフルカラーが可能なため256色のGIFより精細な色表現が可能。
- GIFはアニメーションをサポートしているが、PNGはサポートしていない[2]（アニメーションにはPNGの発展フォーマットであるMNG/APNG形式を用いる）。
- GIFと比較すると圧縮・展開に多少時間が掛かる（ただし前述の通り容量はGIFより小さいため、転送時間の短縮を加味すれば劣点とはならない。サーバ側のプログラムが動的に画像を生成するような使用法では注意を要する）。
- インターレースGIFとインターレースPNG を比較すると、インターレースPNGの方が圧縮率が低い。
- インターレース形式のアルゴリズムが異なり、GIFよりも早い段階で全体像が見える。
JPEGとの比較
[編集]
JPEGは、主に写真的なイメージデータを非可逆圧縮することでPNGよりも小さなファイルサイズに収めることができる。そのため、高画質に設定したJPEGと比較すると、ファイルサイズはJPEGの数倍（大抵は5 - 10倍程度）になる。
PNGは、テキストや線画など色の境界がはっきりしたイメージに適している。線画と写真が混在している場合では、目的に応じて濃淡が目立たない（シャープな）部分を重視する場合はPNG、保存時のファイルサイズを重視する場合はJPEGを選ぶことができる。
JPEGは、非可逆圧縮方式でありジェネレーションロスが生じるため、編集中の一時データの保存には向かない。JPEGで保存をする段階で画像は劣化し、それを繰り返すたびに更に画像は劣化していく。
TIFFとの比較
[編集]PNGとTIFFは、画像を可逆圧縮または無圧縮により劣化なしで画像の保存が可能という点は共通している。
同じ画像を保存する際、ファイルサイズでは一般的にPNGに利点があるとされる[要出典]。
ブラウザの対応
[編集]前述の特許権問題によりGIF排斥運動が起こったが、当初はPNGの普及はなかなか進まなかった。それは主に以下の理由からである。
- 当時のWebブラウザでPNGに正しく対応していないものがあった。
- 広告（バナー）には当時、GIFアニメがよく用いられたが、PNGの仕様そのものにはアニメーション機能が含まれていないため、代替することができなかった。多くのブラウザでAPNGに対応したのは2010年代以降のことである。
- 特許ライセンス料はGIF画像を読み書きできるソフトウェアの製作者が支払うものであり、ソフトウェア技術者やフリーソフト利用者などの間では話題になったものの、PhotoshopやPaintShop Proなど市販のソフトウェアを使用して画像を制作・利用する利用者にとっては関係が薄かった。
特に、2000年代に絶大なシェアを誇ったInternet Explorerはバージョン6までアルファチャンネルを持つPNG画像を正しく描画できなかった。2006年11月にリリースされたバージョン7で、正確に描画できるようになった。（ただしPhotoshopで生成したPNG画像の場合、gAMAチャンクへの不適切な記述のため正常に表示されないことがある）
PNGはGIFと同様な1色透過も扱え、こちらはInternet Explorer 5でも対応していた。なお、IE5.5はアルファチャンネル付きPNGを正しく表示できるActiveXプラグイン (AlphaImageLoader) を搭載しているため、この機能を使うようHTMLファイルに記述すれば表示できた。ただしIEの設定によってはアルファチャンネルとして機能せず、また他ブラウザとの互換を考えると、わざわざこの機能を利用する価値はほとんど無かった。
ユニシスの主張するLZW圧縮アルゴリズムに関する特許は、米国時間2003年6月20日をもって無効（期限切れ）になったため特許問題自体が消失した。PNGはLZW圧縮アルゴリズム特許の有効期間内で全てのGIFファイルを代替するには至らなかったが、対応ブラウザの増加とともに普及していった。
ファイルサイズ
[編集]正しくエンコード処理を行ってメタデータを含まないように作成したPNG画像は、同じように処理して作成したGIF画像より小さくなるはずである。しかしPNGはGIFより機能が多いため、大きなサイズになってしまうことがある。
GIFは256色に制限されているため、多くのソフトはフォーマットの変換を行うとき自動的に256色に減色して保存する。そのためフルカラーの画像をPNGとGIFに保存した場合、GIFの方がサイズが小さくなる（かわりに画質は落ちている）。GIF同様256色のPNGを作ればGIFよりサイズが小さくなるにもかかわらず、PNGは256色より多い色数を利用できるため変換時に自動で減色されない場合がある。その結果同じ画像をGIFにした場合よりサイズが大きくなってしまう。
インターレースPNGはインターレースGIFに比べ、圧縮率が低くファイルサイズが大きくなる場合が多い。また、インターレースPNGは通常のPNGより、ファイルサイズが大きくなりがちである。
ソフトウェアによっては、出力されるPNGファイルのサイズは必ずしも最適化されないため、ファイルサイズを減らすためにはPNG最適化ソフトウェアなどでPNGファイルを最適化するとよい。最適化のためのソフトウェアとしては、 OptiPNG、PNGOUT、pngrewrite、Pngcrushなどがある。また、Windows用ながらもBlastPNGのような複数の最適化ソフトウェアを一度に扱えるフロントエンドなどもある。
PNGはJPEGに取って代わるものではない。JPEGは写真の圧縮に適した非可逆圧縮方式であり、写真画像に限ってはJPEGのほうがファイルサイズが小さくなる。一方で、文字や線画などの保存はJPEGだと圧縮ノイズが目立ってしまうのでPNGのほうが適している上、ファイルサイズもかなり小さくなる。また、加工を繰り返す予定のある画像はJPEGでは劣化が進んでしまうのでPNG保存が望ましい。
出典
[編集]- ^ a b Greg Roelofs 2003, Chapter 1. An Introduction to PNG.
- ^ a b c d Greg Roelofs 2003, 1.2. What Is PNG Good For?.
- ^ Greg Roelofs 2003, 1.2.4. Compression.
- ^ Greg Roelofs 2003, 8.5. PNG Image Types.
- ^ a b Greg Roelofs 2003, 1.2.1. Alpha Channels.
- ^ “nvidia.com 製品情報 3D 画像”. 2012年8月9日閲覧。
- ^ Greg Roelofs 2003, Chapter 7. History of the Portable Network Graphics Format.
- ^ Greg Roelofs (2012年5月29日). “History of PNG”. Libpng.org. 2012年8月9日閲覧。
- ^ “GIF,JPEG OR PNG?”. 2012年8月8日閲覧。
- ^ Greg Roelofs 2003, 7.1. Anatomy of an Internet Working Group.
- ^ “GNUのウェブページにGIFファイルが一つも無い理由”. 2021年12月28日閲覧。
- ^ a b c Greg Roelofs 2003, Table 7-1.
- ^ 『日本産業標準調査会：廃止規格検索 X4242 日本工業標準調査会。
- ^ a b c d e f g h i Greg Roelofs 2003, 8.2. PNG Signature.
- ^ Greg Roelofs 2003, 8.4. The Simplest PNG.
- ^ a b c d e f g h i j Greg Roelofs 2003, 8.1. Chunks.
- ^ a b c d e f Greg Roelofs 2003, 9.1. Filtering.
- ^ Greg Roelofs 2003, 9.2. The Deflate Compression Algorithm.
- ^ Greg Roelofs 2003, 9.3. Real-World Comparisons.
仕様書
[編集]- ^ a b ISO/IEC 15948:2004. ISO. (2004)
- ^ “PNG 1.2 仕様書 日本語訳”. 2005年6月24日時点のオリジナルよりアーカイブ。2005年6月24日閲覧。
- ^ “Portable Network Graphics (PNG) Specification and Extensions” (英語). 2012年8月9日閲覧。
参考文献
[編集]- Greg Roelofs (2003) (英語). PNG: The Definitive Guide (2nd ed.). O'Reilly & Associates 2021年12月28日閲覧。
関連項目
[編集]
外部リンク
[編集]| 典拠管理データベース: 国立図書館 |
|---|
