れで正しいと思ってました」という毎度おな じみの「いままでバケツでウランの粉末をす くっていて問題がなかった」パターンを回 答され脱力したのである。 しかし , 「問題なかった」というのは厳密 にいうと大嘘であって , 現実に問題が起き たのだが [ 1 ] , 当事者はまるで納得している 感じではなかった。おそらく , この人は今 後も同じような事故を繰り返し , しかもな せ悪かったかという理由がわからないまま であるまいか。 ちなみに同じプログラムを筆者の AT 互換 機の Linux MLD4 で gcc ( egcs -1.1.2 release) を使って試したところ , Segmentation fault (core dumped) というメッセージとともに途中で中断して しまった。明らかにメモリ上の問題をかか えているわけだ。こういう問題をかかえて いるにもかかわらず「問題なし」と勘違いさ れたのはメモリの保護が甘い MS - DOS だっ たからというわけではない。実はライプラ リの実装のおかげで助かっているだけの話 である。 MS-DOS で動かしたプログラムの仕 ee の実 装は , free すると同時にメモリプールに返 としておけば , theM = malloc(YYY) が実行 却するという実装ではなく , malloc したメ モリプロックの先頭に置いているヘッダ領 域の特定のビットを操作するという考えで あった。この場合 , メモリプールの返却は 起きず , 単なるメモリ破壊が起きるが , 運 よく ( ? ) 破壊されて困る領域を避けてビッ ト操作が起きたので , 見かけ上「問題なし」 になっただけだ。まったく別の実装をされ ところで , ANSI C 準拠であることが前提 つけたバグであることを付け加えておく。 な症状が起きており , それを調べていて見 なし」は嘘で , 実際にはメモリ破壊で不可解 だったのはいうまでもない。ちなみに「問題 「いままでバケツでウランの・・・・・・」パターン このバグも当事者に指摘したら , やはり ないのだ。 した場合 , これも何が起きるかは保証でき その状態で関数の最後の丘 ee ( theM ) を実行 う値になっているか保証されない。さらに かが実行されなかった場合 , 山 eM はどうい もう答えはわかっただろうが , 迂 ( ) のな List 2 のようなバグも発見したことがある。 そういえば , この「優秀な会社」の作品で , 不定値の free きる可能性が大きいのである。 た場合は , やはり不可解な症状で問題が起 char * theM = NULL; intthel; void f(void) { 条件だが , みたいなチェックは不要である ( もちろん free(theM); if(NULL ! = theM) も起きないことが保証されているので , 題はなくなる。 free(NULL) とした場合 , 何 が入っているため , 関数の最後の free で問 されなかった場合 , theM には確実に NULL ANSIC 準拠でない場合は必要になるが ) 。 仕様書の未定義な場合 先ほどの「優秀な会社」を雇っている , さ らに「優秀な」某大手家電メーカーの仕事で も , どういう意図なのか理解に苦しむ変な 仕事があった。普通は , こういう変な仕事 を発注するような者は , 自分の仕事ぶりも 変で効率が悪いため , 小さい企業あたりだ と「おまえクビ ! 」になる可能性が大きいの だが , さすがに労働組合がキチンと従業員 を守ってくれる大企業は恵まれている。ど うせ会社員になるなら , キチンとした労働 組合のある会社に入るべきだと「ナニワ金 融道」を書いた青木雄二氏も述べている。 それはさておき , どういう不思議な仕事 かというと , あるコンバイラのライブラリ関数で「戻り 値が 0 なら正常 , 0 以外なら異常」と仕様書 に書いているが , 異常なときはどうい う値が返っているかを調べろ である。どう不思議かというと , 仕様書に 「戻り値が 0 なら正常 , 0 以外なら異常」とあ るならそれを信じてプログラムするべきで , もともと異常であると明記されている " 0 以 外 " というのが具体的にどういう値なのかが わかってもまったく無意味だからである。つ まり , この関数の設計者は , if(0 = = func()) { / * 正常な場合 * / }else { / * 異常な場合 * / 予定外を f 「 ee void f(void) 土 n セ the char *theM = ma Ⅱ oc ( 1024 for(thel = thel く 102 thel 十十 ){ if(TEST—PAT = = *theM) break; 十十 theM; free ( theM 130 C MAGAZINE 2000 6 不定値の f 「 ee void f(void) int thel; char * e 場 if(xxx){ theM = malloc(YYY); free(theM);
なり 1.0 に近づいているように見えるが今 後 W3C などでの標準化が行われることも考 慮すると , まだ時間はかかるかもしれない。 仕様も細かい部分では変更される可能性は あるだろう。現に , Ver. 0.96 では 14 項目ほ どの仕様の改訂が行われている。これは , フォーマットの仕様としては決して少ない 数ではないだろう。 なお , これから行われる改訂でも , いま までの仕様とは極力互換性をとっていく予 定だという。とはいえ , 滝版としての位置 付けである以上 , 技術的な欠陥に関しては 互換性にかかわらず修正される予定だ。な お現状ではすでに , 改訂のためには投票に よる承認を必要とする状態まできている。 MNG はまだドラフトのため , メディアタ イプとして「 video/x-mng 」を利用すること になるが , 将来的にはおそらく「 video/mng 」 が定義されるようになるだろう。 MNG はドラフトであることが , 普及に至 らないひとつの原因であることは確かだ しかし , MNG を利用するアプリケーション が少ないというのも , 普及を妨げる原因の 一端ではある。もっとも , これは「ニワト リが先か卵が先か」というのと同じで , ド ラフトだからアプリケーションで採用され ない , という側面は大きい。 とくにプラウザでの対応は , フォーマッ トの普及には大きく影響している。画像を 表示するプラウザとしては , lnternet Explo rer と Netscape Communicator (Navigator) の ふたつが圧倒的なシェアを持っている。し かし残念ながら現状では , 機能追加のほと んど止まってしまった Netscape Commun icator(Navigator) はもちろんのこと , lnter net Explorer でも MNG には対応していない ( それどころか , 正確にいえば PNG の実装も 完全とはいえない状況なのだが ) 。 対応が進まない理由には , これらのプラ ウザは企業による製品であるため , LZW の ライセンスがそれほど大きな問題とならな いという面がある。そのため , GIF のサポ ートで十分工ンドユーザの目的を果たすこ とができているわけだ。また , MNG の規模 が大きく実装が難しいという部分も理由の ひとつだと思われる。 実際 , そのほかの画像処理ソフトウェア で MNG に対応しているものでも , MNG-LC までの対応が多いようだ。フルスペックの MNG となると , それほど多いわけではな しかし , プラウザでの対応が行われない かぎり , いくら MNG によるデータの作成環 境が整ってもどうにもならない。 Microsoft と AOL(Netsc 叩 e) には , 早急な対応を願い たいところだ。なお , 未確認だが MoziIIa で は MNG への対応を予定しているようだ。 これらの状況は , おそらく MNG が W3C などで標準化される段階までいけば好転す るのではないかと思われる。「標準仕様に従 う」というのは , プラウザではもはや大前 提になっているため , 標準化されてしまえ ば , ほば間違いなく対応される可能性が高 いからだ ( PNG を見ていると , Netscape は期 待できないかもしれないが・・ 動作確認などでつらい思いをするかもし れないが , 開発者は標準化されるまでにツ ールなどでの対応をしておくのが理想的だ 関連 URL といえるだろう。 ・ MNG D 「 aft Specification のも多いので , 参考になるだろう。 ンに関しては , ソースの公開されているも ュースも掲載されている。アプリケーショ NG に対応したアプリケーションや , 各種ニ 情報源を当たるのは絶対に必要になる。 M NG はまだまだ発展途上であるため , 英語の 報はほばここに集約されている。とくに M となる。むろん英語だが , MNG に関する情 http://www.cdrom.com/pub/mng/ MNG のオフィシャルサイトは , Graphics Home) Page ・ MNG (Multiple-image Network にある。 MNG-LC や MNG-VI ℃ , JNG , DeI http://www.cdrom.com/pub/mng/spec/ MNG の最新の仕様書は , 0 ロ 2 闘 NG ね - PNG などの仕様が含まれている。また PNG の仕様に依存しているため , PNG の仕 様書も参照する必要があるだろう。 ・ PNG (Portable Network Graphics) Home Page PNG のオフィシャルサイト。 http://www cdrom.com/pub/png/ 最新の仕様である PNG Specification 1.2 が公開されている。 PNG に関するニュース や対応アプリケーションなどの情報がある。 ・ PO a e Network Graphics W3C で正式に勧告された PNG の仕様書。 http://www.w3.org/Graphics/PNG/ ・ Animation Sh 叩 2 Productlnformation http://www.jasc.com/as2.html は , 国内でも有名な画像処理ソフトウェア である PaintShopPro のバンドルソフトで , MNG に対応している ( 英語で Windows 用 ) 。 ・ ImageMagick - lmage Conversion and Manipulation Software http://www.wizards.dupont.com/cristy/ lmageMagick. html こちらは UN Ⅸ互換環境で有名な画像処 理ソフトウェアだ ( 英語で Wrndows 用 ) 。 駆け足で MNG の概要と現状をまとめて みたが , いかがだっただろうか。 MNG の仕様は大きく , また現状ではま だまだ発展途上の仕様だ。とくに , 一部の 画像処理ツールが徐々に対応を始めている ものの , プラウザでも対応されておらず , 仕様もドラフトだという状況なのは , まだ まだ普及前の技術仕様だという印象を強く 感じてしまう。実装も少なく , 仕様やソー スの規模も大きいため , 今回の原稿は調べ ながら書き進めている部分が多い。そのた め , 一部に間違いや勘違いがあるかもしれ ない。もし , ミスがあったらご容赦いただ きたい。 最後に 特集 2 MNG 41
て「 image/png 」が定義され , 利用できるよ うになっている。 PNG は , I ノ W 特許を避けた GIF の代替と なるフォーマットというだけではなく , ほ かにもアルフアチャネルや TrueColor , ガン マへの対応など , 数多くの特徴を持ってい る。 PNG には , ほかにも特筆すべきさまざ まな特徴があるが , 本稿の趣旨からは外れ こでは割愛する。 るので , その一方で , PNG には冒頭でも述べたよ うに GIF が持っていたアニメーションの 仕様がなく , 完全な静止画のためのフォー マットに特化している。現実問題として , GIF アニメーションは Web 上の簡易なアニ メーション機能として , もはやなくてはな らない技術になっている。そのため , せっ かく特許問題を回避でき , なおかっ GIF に 対する多くのアドバンテージがあるにもか かわらず , PNG は単純に GIF を代替するこ とができなかった。 しかし , PNG にアニメーション機能がな いという問題が , そのまま放置されている はずがない。静止画として割り切って策定 された PNG に対して , 同じアプローチ , 同 じスタンスで設計 , 策定された動画フォー マットが今回紹介する MNG だ。 MNG の概要 動画フォーマットとしての比較対象を探 替手段というものではない。 模であり , 単なる GIF アニメーションの代 い。前述のとおり , その仕様はかなりの規 ーマットとしてとらえたほうがわかりやす 語られることが多いが , 実際には動画フォ うしても GIF アニメーションの代替として MNG は PNG との関係が大きいため , ど タとしても認識することができる。 タ的に見れば PNG のデータは MNG のデー NG に準じた仕様になっているため , デー 一種となっている ( コラム 2 ) 。構造的には P めのフォーマットで , PNG フォーマットの メーションなどの複雑な構造を実現するた 像データから成る , スライドショー , アニ MNG は , 複数の PNG と JNG ( 後述 ) の画 すとなると , MPEG が候補にあがってくる と思うが , MNG は MPEG を代替するもので はなく , 補完を目指すものとされている。 MPEG が非可逆なフォーマットなのに対し , MNG が可逆なフォーマットだという点から 見ると , JPEG に対する PNG と同じような 位置付けだと思えばいいのだろう。ただし , MNG には JNG があるため完全に非可逆なフ ォーマットのみというわけではない。同じ ように , AVI や ReaIV1deo などとも補完し合 う関係だと思っていいだろう。 MNG の種類 MNG には , サプセットとなる仕様とし て , MNG-LC (Low Complexity) , MNG-VL C (Very Low Complexity) のふたつの仕様 そして JNG (JPEG Network Graphics) とい うフォーマットも定義されている。 ( 筆者の解釈が正しければ ) MNG のデー タフォーマット側には , MNG-LC や MNG-V LC という区別はなく , これらはあくまで実 装側のサポートを表現する単語だ。もちろ ん , MNG-LC や MNG-VLC にマッチするデ ータというのは存在し得る。 ・ MNG-LC MNG-LC は Low CompIexity の名のとお り , 簡易な MNG のようなもので , 下位互換 性を持った軽量版的な仕様だ。 MNG-LC も基本は MNG であるため , PN G の一種であり , PNG のデータは MNG-LC のデータとしても合致する。 これは筆者の推測にすぎないが , MNG- は MNG 全体の仕様がかなり大きなもの になってしまっているため , 実装時にその 発音について コラム 2 れている。 のように発音すると各仕様書に書か ・ JNG : 「じんぐ」 (jing) ・ MNG : 「みんぐ」 (ming) ・ PNG : 「びんぐ」 (ping) 各フォーマットの発音の仕方だカ ロ 2 闘 NG 複雑さが障壁となって , 最終的に普及を妨 げてしまうことがないように作られたもの のようだ。また , MNG のすべてを実装でき ないような規模のプラウザのための仕様と いう側面もあるかもしれない。なお仕様書 内では , 最低限の実装に適合するものとし て , 複数ベージの FAX データを扱うといっ た例が出されている。 MNG-LC は , フルセットの MNG と比べる と , 画像 0 のみに対応しループは 1 回まで , 「複合 MNG 機能」や Del ね - PNG に対応せず , ある種の MNG チャンクも利用できない。 そして「シンプル MNG 機能」や透過がサ ポート範囲に入り , 拡張仕様として JNG へ の対応を行ってもよいという仕様となる。 ・ MNG-VLC MNG-VLC は Very Low Complexity , つま り MNG-LC よりもさらに簡易な仕様だ。 MNG-VLC では , MNG-LC からさらに「シ ンプル MNG 機能」の対応もなくなり , 透過 のみがサポートされている。 MNG-LC と同 じように JNG の拡張対応は行ってもよい。 これは実装がかなり単純になり , GIF アニ メーションの PNG 版という状態に近いもの となる。 ・ JNG JNG は , これらの MNG のサプセットとは 少々異なる。これは JPEG データを MNG の オプジェクトとして利用するために定義さ れたものだ。ただし , PNG に準拠する形で 定義されているため , 単体のデータとして ファイル化することもできる。いってみれ ば , PNG の枠組みで JPEG を扱えるように したものだと思えばいいだろう。 JNG による JPEG は , JFIF 互換の ISO/IE C -1091 & 1 で定義される baseline , extended- sequential , progressive JPEG となっている。 なお , JNG では JPEG のアルフアや色空間情 報などをそのまま利用できる。 MNG-LC や MNG-VLC は JNG をサポート する必要はないが , 対応する実装に拡張す ることは問題ない仕様となっている。 特集 2 MNG 39
an Brunschen , cb@df.lth.se/Glen Chapma n , glenc@clark.net/Adam M. Coste110 , a mc@cs.berkeley.edu/Lee Daniel Crocker , lee@piclab.com/Peter da Silva , peter@star base.neosoft.com/Andreas Dilger , adilger @enel.ucalgary.ca/Oliver Fromme , oliver @fromme.com/Jean-loup Gailly , jloup@gzi p.org/Chris Herborth , chrish@qnx.com/A lex Jakulin , jakulin@acm.org/Gerard Juyn , gjuyn@xs4aII.nl/Neal Kettler , neal@westw 00d.com/Tom lnne , tgl@sss.pgh.pa.us/Al exander Lehmann , alex@hal.rhein-main.de /Chris Lilley , chris@w3.org/Dave Martind ale , davem@cs.ubc.ca/Carl Morris , msftr ncs@htcnet.com/Owen Mortensen , ojm@ acm.org/Josh M. Osborne , stripes@va.pub nix.com/Keith S. Pickens , ksp@rice.edu/ Glenn Randers-Pehrson , randeg@alum.rpi. edu/Nancy M. Randers-Pehrson , randeg@ alum.rpi.edu/Greg Roelofs , newt@pobox.c om/WiIIem van Schaik , willem@schaik.c om/Guy Schalnat , gschal@infinet.com/Pa ul Schmidt , pschmidt@photodex.com/Sm arry Smarasderagd , smar@reptiles.0rg/羽1 Fig. 15 とても簡単な動画データの例 ¥ 212 M N G ¥「 vn Az vn MHDR 256 300 1 5 4 4 1 TER M 3 0 120 1 0 旧 DR IDAT ・・ 旧 D 日・・ 旧 D 日・・ 旧 D 日・・ MEND ・•IDAT ・・ IDAT ・・ ・•IDAT ・・ ・・ IEND IEND ・・ IEND ・・ IEND Fig. 16 簡単なスライドショーを行うテータの例 ¥ 212 M N G ¥「 vn Az vn MHDR 720 468 1 6 5 5 1 TERM 1 0 2 2 0 2 1 600 0 SAVE SEE ぐ Briefing to the Wo 「 kfo 「 c ざ MNG 識別子 幅と高さ 1 秒当たり 1 回の単位時間 レイヤ数 , フレーム数 , 再生時間 MNG ー VLC 簡易プロファイル 終了したら動画を 1 0 回繰り返す 四つの PNG データストリームが読み込まれ , 表示される MNG 識別子 幅と高さ 1 秒当たり 1 回の単位時間 レイヤ数 , フレーム数 , 再生時間 MNG-VLC 簡易プロファイル フレーム間遅延を 1 , タイムアウトを 600 秒 , 同期 ID リストを 0 に設定する DEFI 0 , 可視性と抽象性が暗黙のうちに仮定される 旧 D 日・・ ・・ IDAT ・・ SEE ぐ Outline" 旧 D 日・・ ・ヨ DAT ・・ SEE ぐ Our Vision" 旧 D 日・・ ・・ IDAT SEEK ℃ ur Mission 旧 DR ・・ ・・ IDAT ・・ ・・ IEND ・・ IEND ・・ IEND IEND SEECDownsizing Plans 旧 D 日・・ ・・ IDAT ・・ ・・ IEND MEND ロ 2 、 G omas R. Tanner , ttehtann@argonet. CO. uk/ Guido VoIIbeding , guivol@esc.de/Tm We gner , twegner@phoenix.net/Alaric B. W111i ams , alaric@alaric-williams.com ・商標 GIF は CompuServe lncorporated のサービ スマークである。 PostScript は Adobe Syste ms の商標である。 ・出典 この文書は 2000 年 2 月 29 日付のファイル mng - maste 广 20000228 から構成された ・著作権表示 Copyright ◎ 1998 , 1999 , 2000 by 6 enn Randers-Pehrson 特集 2 MNG 63 していただきたい。 的としていない。法律文書としては原文を参照 のであり , 法的根拠として利用されることを目 著作権表示の訳文は読者の便宜を図るためのも [ 訳注 3 ] 持者に帰属する駅囿 関する著作権はいかなる場合でも著作権保 い。この仕様書およびすべての関連文書に 様書に関する広告や宣伝に使ってはならな による事前の承諾を得ないかぎり , この仕 著作権保持者の名前および商標は , 紙面 利用についていかなる責任も負わない。 保証しない。著作権保持者はこの仕様書の を , これらの例示にとどまらず表示せず , 権 , 商標そのほかの権利を侵害しないこと この仕様書の利用が第三者の特許 , 著作 こと , 何らかの目的に適合すること , また 作権保持者はこの仕様書に商品価値がある せよ , いかなる表示も保証も行わない。著 作権保持者は明示されたものにせよ暗黙に この仕様書は現状のまま提供される。著 配布することを許諾する。 ることなくこの仕様書を利用し , 複製し , る目的に対しても , 費用や使用料を徴収す が完全な形で含まれているかぎり , いかな やその一部分のすべての複製に以下の注記 読者による変更部分も含め , この仕様書 理解し , 受諾しなければならない。 めには , 以下の利用期間および条件を読み , 仕様書を入手し , 利用あるいは複製するた 利用許諾に基づいて提供されている。この この仕様書は著作権保持者により以下の
P A R T MNG-LC フォーマット Ver. O. 97 仕様書 4 マット群のひとつだ。このフォーマットは 複数の PNG 単一画像データストリームから なる動画 ( スライドショー ) や複合静止画を 格納できる。 MNG-LC フォーマットは PNG 仕様で定義 されているものと同じチャンク構造を用い , また PNG フォーマットのそのほかの機能も 受け継いでいる。正しい PNG データストリ ームは正しい MNG-LC データストリームで もある。 MNG-LC のフレームには通常 2 次元 画像あるいは 2 次元に配置された小さい画 像が含まれている。また , 2 次元平面 ( 断層 断面 ) の並びとして配置され , それぞれの 平面が PNG データストリームとして表現さ れている 3 次元ボクセルデータを格納する ことも可能だ。 この文書には MNG - LC のさまざまな機能 png-group@w3.org を示すためのサンプルが含まれている。そ png-info@uunet.uu.net この文書は無制限に配布できる。現在 , のなかには簡単な動画や合成フレームも入 この文書の最新版が以下の Web サイトから この文書は PNG 開発グループによる仕様 っている 入手可能だ。 書である。 この仕様書はグループの議決により承認 ftp://swrinde.nde.swri.edu/pub/mng/ されており , 将来技術的な変更がある場合 documents/ この抜粋と正規の MNG 仕様書との間で この文書は MNG フォーマットの低複雑 はグループの正式な議決による承認が必要 食い違いがある場合は , 正規の仕様書が優 性版 (MNG-LC, 正式のサプセット版 ) を紹 だ。可能なかぎり後方互換性を維持すると 先する。 いうのがグループの目的である。しかしな 介するものである。 この仕様書は PNG に依存している。また , がら , 我々は「べータ」版実装の開発中に見 JNG 対応に拡張されている MNG - LC アプリ つかったすべての技術的欠陥を訂正するつ ケーションは JNG の仕様書に依存している。 もりだ。 この文書は MNG - LC フォーマットを紹介 PNG の仕様書は以下の PNG の Web サイトで この文書への意見は , 次のいずれかのア するものだ。これは MNG フォーマットの正 入手可能だ。 ドレスで PNG 仕様書管理者へ送ることがで しいサプセットである。 きる。 http://www.cdrom.com/pub/png/ MNG は複数画像に対応した PNG フォー ( 現在は http://www libpng.org/pub/png/ mpng-list@ccrc.wustl.edu へ移行中 ) Fig. 10 典型的な MNG - LC テータの構成 また , JNG の仕様書および正式な MNG の 仕様書は , 以下の MNG の Web サイトから 8 バイト MNG 識別子 入手可能だ。 MHD 日チャンク http://www.cdrom.com/pub/mng/ フレーム定義 ( 現在は http://www libpng.org/pub/mng/ へ移行中 ) MNG-LC データストリームは 0 個以上あ る単一フレームの並びを記述する。それぞ れのフレームは 0 個以上の埋め込み画像か らなる。 埋め込み画像は , PNG あるいは JNG デー GIenn Rande 「 s-Pehrson 訳 : 日下部圭子 / 日下部陽ー 、、本章は MNG の Web サイトで公開されている MNG - LC フォー マット Ver. 0.97 の仕様書を著者である G 厄 nn Randers- Peh 「 son 氏のご協力のもとい翻訳したものである。本書には 原文より抜粋された内容が掲載されている。翻訳された完全 、な文書やオリジナルの文書についてはを付録 CD - ROM に収録 されているので , ーそちらをご覧いただきたい訂、なお , 翻訳し ゞ、た文書は C MAGAZINE の Web サイトにも掲載されている。 この文書の位置付け 1. はじめに フレームはひとつ以上のサプフレームからなり , 最後のフレー ムはゼロでないフレーム間遅延を持ち , ディスプレイ上にすで に存在するものすべてに対して合成される サプフレームはひとつ以上のレイヤとクリッピング情報 , フレ ーム間遅延からなる レイヤとは「埋め込み画像」 , 「背景」のいすれかを指す サプフレーム定義 レイヤ定義 MEND チャンク 50 C MAGAZINE 2000 6
ロ 2 NG タストリームである。 JNG データストリー デコーダと同一の結果を生成するかぎり , ムはフルセット版の MNG データストリーム そのようなデコードモデルや指示に従う必 では認められているが , MNG-LC データス 要がないことに注意してほしい。 トリームには含まれない。しかし , MNG-L MNG データストリームあるいは任意の埋 C をサポートするアプリケーションがそれ め込みオプジェクトの各チャンクはいずれ らを認識して処理するように拡張されるこ も独立した存在である。すなわち , あるチ とはかまわない。典型的な MNG - LC データ ャンクがほかのチャンクのデータ部分に含 ストリームは Fig. 10 のような構成である。 まれることはない。 MNG は基本的に宣言型であり , 要素を PNG 識別子を持つ独立した PNG データス 個々のフレームに至るまで記述する。 0 で PNG 仕様書の用語集やフルセットの MN トリームは正当な MNG - LC のデータストリ ないフレーム間遅延が発生するときに , 期 G 仕様書の「 terminology 」の章も見ること。 ームであり , MNG - LC デコーダはこれを認 待される合成に見合った画面を生成するた 識し , デコードしなければならない。独立 ・要求レベル (requirementlevel) めに効率的な手段を採用するかどうかはデ した JNG データストリームもまた JNG 対応 コーダに任される。簡易デコーダはそれを この文書 ( 本章 ) にある「 MU 」 , 「 MUST の拡張が行われた MNG - LC デコーダで認識 手続き的に処理してもよく , その場合は画 NOT 」 , 「 REQUIRED 」 , 「 SHOULD 」 , 「 SHO され , デコードされるはずのものだ。この 像が現れる順にそれらをフレームバッファ ULD NOT 」 , 「 RECOMMENDED 」 , 「 OPPI() 種の MNG-LC あるいは拡張 MNG-LC データ に合成することになる。しかし , 高性能な NAL 」という言葉は RFC -2119 に記述された ストリームには単一の埋め込み画像しか含 デコーダがそれと異なる方法をとることは , とおりに解釈される。「 CAN 」はその文書に まれない。 最終的なフレームの見栄えが同じになるか あるように「 MAY 」と等価である。「 NOT 用 MNG を構成する埋め込みオプジェクト ぎりかまわない。 LOWED 」と「 NOT PERMIITED 」は「 MUST は通常は PNG フォーマットであり , MNG NOT 」を生ずるような条件を意味する。 なお , MNG は「ミング」と発音する。 は次に示す PNG のすぐれた機能を受け継い 「 ALLOWED 」と「 PERMIITED 」は「 CAN 」を MNG データストリームがファイルに格納 でいる。 生ずるような条件を意味する厭。 されるときにはファイルの拡張子に「 . mng 」 ・特許に抵触しない [ 訳注 1 ] を使うことが推奨される。ネットワークア ・ストリーム化可能 訳文ではこれらの単語と訳語との直接の対応付 プリケーションにおいては , 「 video / x - mng 」 ・すぐれた可逆圧縮 けは行われていない。解釈に厳密さが必要な場 合は原文を参照していただきたい。 というメディア形式を使ってよい。メディ ・ 4 チャネルまで格納できる ( 赤 , 緑 , 青 , ア形式「 video / x - mng 」の登録は将来行われ アルファ ) , 各チャネルは 1 6 ビットまで ・埋め込み画像 (embedded image) るはずだ。 ・透明およびアルフアのチャネルが使え MNG のデータストリームの先頭の 8 バイ MNG データストリームに埋め込まれて存 る 在する画像。 トを 10 進数で示すと以下のようになる。 ・カンマや彩度情報を含むプラットホー ム非依存の色再現 1 38 77 78 71 1 3 1 0 26 10 ・フレーム (frame) バイト位置 0 ~ 3 が「 \ 211PNG 」ではなく 一般ファイル転送工ラーの早期検出 , フレーム間遅延時間が 0 で , 0 個以上のレ 「 \ 212 M N G 」となっていることを除けば ファイル破損の確実な検出 イヤの並びに , 明示された 0 以外の遅延時 PNG 識別子と同じだ。 ・単一画像 G 旧ファイルから損失なく変 間あるいは MEND チャンクを続けたもの。 チャンク構造 ( 長さ , 名前 , データ , CR 換可能 これは静止画あるいは動画の一部として表 C) およびチャンク命名規則は PNG 仕様書で ・ JPEG とは相補的なものであり , 画像 示される。動画は理論上 , 完全な観測者 定義されているものと同一である。 PNG と の損失のある格納について JEPG に取 ( 非人間的に高速な視覚機構を持つもの ) に 同様に , 1 バイトを超える整数はすべてネ って代わろうとするものではない。し とっては静止画像の並びとして見える。フ ットワークバイト順でなければならない。 かしながら , JNG 対応の MNG-LC では MNG のチャンク複製規則は PNG と同じ レーム間遅延時間 0 の MNG 画像の集合は PNG ふうの JNG 形式でコード化された 「フレーム」ではなくて「サプフレーム」 ( 後 仕組みによるが , その規則はフルセットの JPEG コード化画像を格納できる 述 ) を構成する。データストリーム中の最 MNG 仕様書のなかでより完全に説明され また , MNG として追加された機能は次 後のサプフレームは , フレーム間遅延の有 ている。 のようになる。 無にかかわらずフレームを完了させる。 デコーダは , この仕様書で示されるデコ ・フレーム間遅延が可変の動画を扱える ードモデルを採用し , 仕様書の指示に従う ・複数画像を含んだフレームの合成がで フレームのレイヤが MHDR チャンクのフ 特集 2 MNG 51 きる ・複数の画像を格納した GIF ファイルは 損失なく MNG - LC に変換できる ( ただ し「直前の状態を復元する (restore-to-p 「 evious ) 」廃棄方式を採用した G 旧ファ イルは除く ) 五ロ
P A R T 2 ようなアニメーションもサポートしている が , MNG - LC ではこのような機能は省略さ れている。しかし , アニメーションを行う 際の時間制御などの機能は残されている。 レイヤ付きイメージ レイヤとはグラフィックエデイタなどで 利用されるもので , 画像を重ね合わせるこ とで 1 枚の絵を作成するものである。セル 画などをイメージすればわかりやすいだろ う。 MNG では透明色やアルファ値もサポ ートされているので , レイヤ付きの画像を 保存するといった用途にも利用できる。 ボクセルデータ ないので , MNG 仕様は MNG-LC 仕様の上 位互換になる。 ボクセル (Voxel=Volume cell) とは画素 MNG-LC は MNG のサプセットだが , 複数 ( ピクセル : Pixe ト Picture cell) を 3 次元に拡 MNG は画像フォーマット PNG の仕様を 画像をひとつのファイルで扱えるという機 張したもので , 立体データを中身まで詰ま 作成したグループによって提案された画像 能は損なわれていないので , 次のようなデ った形で表現するものだ。一般的にはあま フォーマットである。 PNG が静止画のため ータを格納できる。 り利用されることはないが , 医療分野では のフォーマットであるのに対して , MNG は CT スキャナなどから採取されたデータを解 動画 ( アニメーション ) 複数画像の集合をひとつのファイル , デー 析するときなどに利用される。 収められている複数の画像を逐次切り替 タストリームで表現するためのものである。 ボクセルデータは複数画像を何枚も並べ GIF との対比でいうと , MNG はアニメーシ えて表示することで動画が実現できる。動 たものと考えられるので , MNG フォーマッ ョン GIF に当たるものといえるだろう。し 画といっても MPEG などとは異なり , 音声 トではこのようなデータも格納できる。 かし , アニメーション GIF で表現できる動 データやシーン情報などを格納することは 画だけでなく , 非常に広範囲な利用を考慮 できない。現行のフォーマットではアニメ して設計されている。このため , 利用シー ーション GIF に近いもので , パラバラ漫画 ンによってはオーバスペックともなりうる。 のようなものである。 MNG のデータ構造は Fig. 1 に示すとおり , そのため , 主要部分だけを抜き出したサプ MNG 仕様ではアニメーション GIF のよう 始めにファイル識別子 ( シグネチャ ) があり , セットの仕様も同時に提案されている。 なセル画を順に表示していくだけでなく , そのあとにチャンク (chunk) と呼ばれるデ 1 枚の画像の一部をパンしながら表示する のような仕様として MNG-LC, MNG-VI ℃ ータのかたまりが並んでいる形式になって などがある。 いる。ひとつひとつのチャンクは , Fig. 1 MNG フォーマットの基本構造 本章では , この MNG - LC を中心にデータ ・全体サイズなどの情報 構造を見ていくことにする。ただ , MNG ・ MNG データを構成する画像データ はまだ仕様として確定しておらず , 今後の 改訂のなかで大幅に内容が変化する可能性 ・アニメーションにおける画像の表示方 もある。しかし , PNG フォーマットを元に 法 している以上 , データ格納の仕組みなどに などを記述する。これらのデータが集まっ は変更がないと思われるので , 枠組みを理 てひとつの MNG データストリームを形成し 解しておくことは無駄にはならないだろう ている。 MN&LC は , MNG 仕様より JPEG のサ桑 チャンクには , 表現するデータによって ートやアニメーション用制御機能 ( 繰り返 いくつかの種類があるが , チャンク自体の しなど ) といった要素を取り除いたものに データ構造はチャンクの種類によらずすべ なる。 MNG - LC 独自に追加した機能などは て同じで , Fig. 2 のような四つの部分から 42 C MAGAZINE 2000 6 MNG のフォーマットとデータ構造 昌達 K'z 本章では , MNG に使われているフォーマットとデータ 構造について MNG - LC を中心に解説する。さらに詳しく は , PART4 に掲載されている仕様書をご覧いただくかを 仕様書の原文を見てほしい。また , 本誌 ' 98 年 6 月号の特 集 PNG や ' 99 年 10 月号のグラフィックライプラリに関す る記事についてもあわせて参考にしてほしい。 MNG, MNG-LC について MNG のデータ構造 ァイル識別子 ( シグネチャ ) 8 バイト チャンク チャンク チャンク チャンク チャンクの種類 によってサイズ は変わる
G-LC データストリームでは簡易プロファイ ルのビット 0 は 1 , ビット 2 と 4 は 0 でなければ ならない。もうひとつのサプセットは「 MN G - VLC 」と呼ばれる。 MNG-VLC データスト リームには「簡易 MNG 機能」もなく , したが ってビット 1 も 0 でなければならない。 サプセットが利用可能なのは , 処理しよ うとしている一連の MNG データストリーム が MNG - LC にある機能に限定されているこ とがわかっている ( あるいはそう推測され る ) 場合だけだ。広く配布される WWW プラ ウザの機能が , 8 ビット JNG をサポートする MNG を満たさないよう限定されることはき わめて好ましくない。 MNG がサポートするいくつかのサプセッ トを TabIe 8 にあげておく。これらはおおよ そ複雑さの順に並んでいる。 アプリケーション開発者が従うべき合理 的な手順は , 次のサポートレベルのそれぞ れに対して順にアプリケーションを開発し , テストするというものだろう。 1 . MNG-VLC 2. MNG-LC 3. JNG 付き MNG-LC 4. MNG ( フルセットの MNG 仕様書に従う ) 同様に合理的な開発手順としては次のも のがある。 1 . JNG 付き MNG-VLC 2. JNG 付き MNG-LC 3. MNG ( フルセットの MNG 仕様書に従う ) 逆に , 複数のページからなる FAX 文書を 格納するアプリケーションの開発者は「透 明色なし MNG-VLC 」を超えるものを必要と はしないだろう。 それぞれの必須となるチャンクの対応に ついては , 付録 CD - ROM に収録されている 翻訳された規格書を参照してほしい。 以下の勧告は , 仕様の一部を構成するも 7. 工ンコーダへの勧告 のではない。 速度や滑らかさが正確な色彩表現より重 7.1. 共通色空間を使う 要な場面では , 動画のすべてのレイヤに対 して単一の色空間を使うのはよい考えだ これを実現する最善の方法は , MNG のト ップレベルで単一の色空間を定義し , sRG B チャンクを使うか , あるいは gAMA と cHR M チャンクと場合によっては iCCP チャンク を使い , すべての色空間チャンクを共通色 空間に変換したあとで個々の画像から取り 除くというものである。工ンコーダがすべ ての画像を MNG データストリームに書き出 す前にそれらを単一色空間に変換しておけ ば , デコーダは速度と表示の一貫性を改善 できるようになる。 しかしながら , デコード速度がそれほど 重要ではなく , 正確な色彩表現がより重要 であるかもしれないような単一フレームの MNG データストリームでは , PNG 仕様書 で推奨されているように画像を元の色空間 に置いておくことで変換によるデータの損 失を避け , 画像が異なる色空間を持っ場合 には個々の色空間チャンクを保存するのが 最善の方法だ。 7.2. 正しいフレームモードを使う すべての画像が不透明なら , フレームモ ードは常に 1 か 2 を使うこと。これによって ちらっきを起こす不要な画面クリアが避け られる。 7.3. 即時フレーム同期ポイント 同期ポイントをただちに確立する必要が あるなら , ふたつの連続する FRAM チャン クを使い , 最初の FRAM チャンクで一時的 にフレーム間遅延 , タイムアウト , 同期 ID を 0 に設定し , ふたつ目で同期ポイントを デコーダ処理 8.1. 重大なエラーに対する 8. デコーダへの勧告 3 確立することでそれが可能になる。 ストリームを破棄すべきである。 低レベルのビューワは単にその MNG データ のような致命的工ラーに出会ったとき , 最 不正な CRC や未知の必須 MNG チャンク 0 ロ 2 闘 NG 8.2. インタレース画像に対する デコーダ処理 デコーダはインタレース PNG 画像を含む データストリームを解釈できることを要求 されるが , 完全なフレームを表示できれば よく , 画像が展開される順に表示すること は要求されない。低速な通信リンクを通じ て入力されるデータストリームをデコード するビューワはこれを実現したいのかもし れないが , MNG の作者はそのフレームの最 終的な形を除き , フレームがどのように表 示されるかを仮定すべきではない。 8.3. バレットに対するデコーダ処理 PLTE チャンクを受け取ったとき , それ を含むか継承する PNG データストリームの 表示だけが影響を受ける。デコーダはそれ がこれまでにデコードしたすべてのものに 遡及して影響を与えることのないよう注意 しなければならない。 フレームが複数の画像を含むとき , ひと つの画像に含まれる PLTE チャンクはほか の表示には影響を与えない。 インデックスカラー形式の画像のみから なる複合フレームは , 256 種類以下の色し か含まないと仮定すべきではない。なぜな ら個々のパレットは必ずしも同じ組み合わ せの色を含んでいるわけではないからだ。 8.4. 単一フレームビューワの振る舞い ひとつのフレームだけを表示できるビュ ーワは , 最初に出会ったフレームを表示し なければならない。 8.5. クリッピング 特集 2 MNG 61 拡張子を含むようなシステムでは , MNG ファイル名が慣行上ファイル形式を示す 9.1. ファイル名の拡張子 9. そのほか ig. 14 のクリッピングを提供する。 求されるすべてのクリッピングに加えて , F MNG - LC は表示装置の物理的制約から要
MNG 特集 2 PNG を利用したプログラミングが , よりいっそう身近になれば幸いである。 0.97 仕様書を作者のご協力により掲載することができた。これにより , MNG や とそれらのプログラミング方法を解説する。また , PART4 では MNG-LC Ver. 1 では , MNG が生まれた経緯などを紹介し , PART29 PART3 で MNG の構造 ではこの PNG から生まれた動画用フォーマット「 MNG 」について解説する。 PART 用を中心とした画像フォーマット「 PNG 」の利用が少しすっ進んでいる。本特集 し ZW 圧縮アルゴリズムの特許問題を抱える G に変わり , インターネットでの利 恣岡悄 , 昌達 K' z, 仕様書訳 . 日下部圭子 / 日下部陽ー 刃レゴリズム 動画フォーマットの構造と F に代わる P A R T MNG とは ? 1 恣岡悄 MNG とはいったいどのようなものなのだろうか ? 本 章では MNG の概要と , その生まれた背景 , 資料が置か れている場所などを紹介する。 MNG が生まれた経緯 インターネット上に新しく普及しつつあ る画像フォーマットとして PNG というもの があるのは , ご存じの人も多いだろう。 本誌でも PNG に関しては ' 98 年 6 月号に特 集を組んだり , ' 99 年 10 月号で libpng の使い 方などを紹介しているが , 実は思ったより も普及が進んでいない。普及しない理由は 特集 2 MNG 37
・ Delta-PNG MNG にあって MNG-LC や MNG-VLC にな い大きな特徴として , Delta-PNG という仕様 がある。これは , 簡単にいえば差分による データフォーマットだ。アニメーションの ような連続する画像の場合 , 元となる PNG の画像に対する差分データを用意すること で , 必要なデータ量を大幅に減少させるこ とができる。これをさらに次の画像へとく り返していけば , 全体的に差分だけでデー タを生成できる。 ・ MNG の実装バターン 全体としては , MNG をフルセットとして , MNG-LC がサプセット , MNG-VLC が最低 実装と思えばいいだろう。 JNG は本来の M NG では必須だが , MNG-LC と MNG-VLC で はオプショナルな仕様となる。さらに MNG は , 全体のフレームワークとしては PNG の フォーマットに準じた仕様になっているわ けだ。 PNG と MNG のどちらかがどちらか を内包する , といった関係ではない。 つまり実装としては , ・ MNG(JNG や DeIta-PNG を含むフルセ ・ MNG-LC + JNG ・ MNG-LC ・ MNG-VLC + JNG ・ MNG-VLC の 5 通りのパターンがありうる。 MNG のデメリット MNG そして PNG は , おそらくほとんどの 局面で GIF に対してアドバンテージがある。 しかし , 現状の普及度を除いた技術的な側 面で , GIF と比べてひとつだけデメリットと いえる側面がある。そして , それは MNG の 仕様策定や実装が遅れていることと無関係 ではない。 それは , アニメーションを含む GIF に比 べて , あまりにも仕様が大きいという点だ。 これは , 実装の困難さもさることながら , 実際のデータを扱う段階でどうしても処理 が重くなってしまうことでもある。最近の 40 C MAGAZINE 2000 6 CPU 性能の向上を考えたうえで , さらにコ ードの最適化が進めば , それなりに無視で きるオーバヘッドだといえるかもしれない が , GIF に比べて巨大化した仕様の影響は 少なからずあるのではないだろうか。実際 , もっと単純な GIF 代替フォーマットである なら , とっくにアニメーションまで対応で きていてもおかしくないはずだ。 もっとも , その仕様ゆえに PNG や MNG が魅力のあるフォーマットになっていると いう側面もあり , フォーマットの進化と考 えれば十分納得できる部分ではある。 いずれにせよ , 開発者が GIF 以上に実装 に力を注がなくてはならないのは間違いな MNG の特徴 い事実だといえる。 NG の画像を生成することができる。この場 MNG に変換することや , MNG から PNG や J そのため , PNG や JNG の画像をそのまま でもきちんと継承されている。 といっていい。これは PNG だけでなく MNG 逆圧縮のフォーマットであることは必然だ JPEG ではなく GIF の代替である以上 , 可 ・可逆圧縮 名前に適した仕様だといえるだろう。 を行える。まさに Network Graphics という 能であり , オン・ザ・フライで生成や表示 を考慮してシーケンシャルに読み書きが可 MNG のファイルは , ストリーム的な扱い ・ストリーム的に扱える late/Deflate が使用される。 だ。なお実際の圧縮は , PNG に基づいて lnf うやらかなり入念に確認された事項のよう 由でもあるため当然ではあるが , これはど フォーマットを作成することになった理 ・特許的に問題がない は PNG の特徴と一致する部分が多い。 経緯や構造上当然のことだが , MNG の特徴 おまかにまとめると次のようになる。その 概要を踏まえたうえで , MNG の特徴をお 合 , DeIta - PNG を使った差分形式であって も , きちんと変換が可能なことが保証され ている。 また JPEG に関しても , JNG を利用するこ とで MNG(JNG) にそのままの形で変換する ことができる。同じように , JNG のデータ は元の JPEG に戻すことが可能だ。 ・四つのチャネルに対応 赤 , 緑 , 青 , アルフアまでの , 四つのチ ャネルを , それぞれ最大 16 ビットまで保存 することができる。 ・透明度とアルフアチャネル 多くのリッチな画像フォーマットと同じ ように できる。 でなく , 透明度とアルフアチャネルを利用 これにより , ネットワーク上だけ さまざまな環境で使えるだけのフ ォーマットになっているといえるだろう。 ・ガンマや彩度 ガンマや彩度などの情報を扱うことがで き , プラットホーム / 環境に依存しない色 表現が可能になっている。 ・フレームの概念 MNG では画像をフレーム単位で扱い , そ のフレーム間の遅延をサポートしている。 そのため , 各フレームごとに任意のタイミ ングでアニメーション処理をさせることが 可能だ。さらに , 複数の画像を含んだフレ ームの合成を行うこともでき , サプフレー ムではアニメーションも可能なスプライト 機能も利用できる。 ほかにも , 低速なエンコーディング環境 向けにフレームのプライオリティの設定や , フレーム間の類似性を利用して , データ量 の削減も行うなど , フレームの仕様はかな り充実したものになっている。 重要な点として , MNG は現状ではまだ ドラフト状態だということがあげられる。 2000 年 4 月では , 「 Ver. 0.97 , Draft 70 」とか MNG の現状