新しいPNG仕様がリリース

 (programmax.net)
9 ポイント 投稿者 GN⁺ 2025-06-26 | 2件のコメント | WhatsAppで共有
  • PNGファイルフォーマットが20年ぶりに大幅改訂され、かつての存在感を取り戻しつつある
  • 今回の仕様では、HDR対応、APNG（アニメーション）、Exifデータの正式サポートなど、多くの最新技術が取り込まれた
  • Adobe、Apple、Googleなどの主要IT企業と放送事業者が共同で開発に参加
  • 最新仕様はChrome、Safari、Photoshopなど複数のプログラムですでにサポートされている
  • 今後は、より優れた圧縮技術と並列エンコード／デコードの追加など、さらなるアップデートも計画されている

序論: PNGの復活と重要性

  • 最近、PNGファイルフォーマットが約20年にわたる停滞を乗り越え、新仕様へと更新された
  • 米国議会図書館、カナダ図書館・文書館、オーストラリア国立公文書館などの主要機関で、公式推奨フォーマットとしてPNGが採用されている
  • 新しい仕様により、PNGは市場での競争力を取り戻し、革新性を示している

新機能と特徴

適切なHDR対応と将来互換性

  • 新しいPNGは**HDR（High Dynamic Range）**対応を提供する
  • Rec. 2020とRec. 709の色域比較画像では、より広い領域（外側の三角形）がHDR画像で表現される色であることが示されている
  • このHDR情報は、追加で4バイト（および既存のPNGチャンクのオーバーヘッド）のみを必要とする
  • Chris Lilleyら初期の著者や主要な技術専門家が参加し、新技術を明確に説明している

APNG（アニメーションPNG）の正式認定

  • Mozillaが最初に提案し、Firefoxが対応した**アニメーションPNG（APNG）**も正式仕様に反映された
  • 以前は一部のソフトウェアのみが対応していたが、現在は多様なプログラムで広く採用されている

Exifデータの正式サポート

  • Exifにより、著作権、カメラ情報、GPS情報などのメタデータを保存できる
  • 画像制作や保管、著作権管理などで高い有用性が見込まれる

全般的な改善とエラー修正

  • 既存仕様の誤り（Errata）の修正と明確化もあわせて行われた

背景と開発プロセス

  • 前回のPNG仕様は約20年前に公開された（iPhone発売の3年半前）
  • W3C Timed Text Working Group（字幕技術標準化）がPNGへのHDR対応の必要性を提起したことで、開発が再開された
  • 提案が行われると、Adobe、Apple、BBC、Google、MovieLabs、W3Cなどの主要技術企業が共同参加した
  • 強力なコンソーシアムが結成され、次世代画像フォーマットとして生まれ変わった
  • 現在、2つの後続アップデートもすでに準備中である

すでに広く適用されている状況

  • Chrome、Safari、Firefox、iOS/macOS、Photoshop、DaVinci Resolve、Avid Media Composerなど多様なプログラムで最新のPNG仕様をサポート
  • 放送事業者や関連ハードウェア、ツール群でも対応が拡大している
  • ニューススクロールやスポーツのスコアバナーなどの放送画像は、新しいHDR PNGの活用事例である

今後の計画

  • 次版では、HDR & SDR互換性をさらに改善する計画
  • 追加で、より高度な圧縮方式、並列エンコード／デコードも進められている
  • 第4版は比較的短いアップデートになる予定で、その後は圧縮技術の研究をもとに第5版の開発が予定されている

関連記事

2件のコメント

 
carnoxen 2025-06-26

APNGは当初、団体側が画像に関する標準ではないとして拒否していたのに、ようやく認めたんですね。
 
GN⁺ 2025-06-26
Hacker Newsのコメント

  • 自分が著者であることを明かし、質問があればいつでも歓迎すると述べている

    • 今回のPNGは完全に新しいフォーマットではなく、既存フォーマットの更新版であることを強調

    • 非常に高い下位互換性を提供すると説明

    • 古いプログラムでも新しいPNGファイルを可能な限りうまく読み取れ、たとえば赤いリンゴの写真であることはそのまま認識できると説明

    • PNGの内部動作に混乱があるかもしれないので、要点を整理している

      • PNGファイルはさまざまなデータチャンク(chunks)で構成される
      • 各チャンクは名前を持っており、プログラムは知らない、または不要なチャンクをそのままスキップできる
      • 画像ストリームは1つしか存在しないことを明記

    • 新しいPNG仕様の機能を活用したサンプルファイルがあるとよく、特にアニメーションやHDR画像を直接ダウンロードしてプログラムの互換性をテストできるデモページがあればよい、という希望を述べている

    • 自分はメタフォーマットと汎用ツーリングを支持していると述べている

      • Office Open XMLやePubのように、単にzipとXMLライブラリさえあればパースできる構造を例に挙げている
      • PNGもほぼInterchange File Format（以下IFF）に似た構造を持っているが、従来は仕様が微妙に異なっていたため、完全に汎用的なIFFパーサーでPNGとIFF系ファイルを同時にパースすることは不可能だったと経験をもとに説明
      • IFFは実装しやすくデータ圧縮にも強みがあるが、これまで旧式ゲームデータ、AIFF・RIFFオーディオなど限られた用途にしか使われておらず、汎用ツーリングが作られなかった理由の1つとしてPNGとIFFの互換性の惜しさを指摘
      • PNGv3でPNGファイルが公式にIFFファイルになるなら、PNGの大衆性を足がかりに汎用IFFエコシステム（例: libiffのようなもの）が拡大し、新しいフォーマット定義にも使えるだろうという期待を述べている
      • 実際にPNG/IFFパーサーを自作したことがあり、単純にPNGを修正してIFF互換性を持たせるのは難しく、下位互換性（特にハードウェアパーサー）も維持しなければならないと述べつつ
      • 自分はPNGが採用している変形IFF構造を、新たなメタフォーマット（IFF 2.0）標準として別途文書化することを提案している
      • IFF 2.0ではPNGv2互換のプロファイルや、AIFF/RIFFなどIFFv1もカバーするプロファイルを公式化して、汎用IFFツーリングを推進してほしいとしている
      • さらに新しいグリーンフィールドプロファイル（最新環境向け新フォーマット）では、たとえばCRCの代わりに現代的なハッシュで完全性チェックを行い、チャンク名の文字セット拡張や、各チャンクの属性情報を効率的に格納する構造を導入することもできるとしている
      • こうした構造によりIFFv1とPNGv2の両方を変換(transcode)可能にし、実際のHTML5でHTML4とXHTMLを組み合わせて互換させるような戦略的プロファイル宣言が望ましいと考えている
      • 結論として、細部よりも設計目標（既存と新フォーマット間の異質性の最小化と、ツールエコシステムの拡大）を重視していると強調している

  • 自分のWebベースのドローイングツールでは、ドキュメントのJSON表現をPNGのコメント欄に保存するトリックを使っている

    • こうすると保存したファイルをそのまま画像としても使え、再びエディターに読み込むこともできる

    • ダウンロードフォルダーに判別しづらいJSONファイルがたまらない利点がある

    • 面白くはあるが、なぜファイルが.pngで保存されるのか、あるいはPaintなどで開いて保存するとデータが消えるのかをユーザーに説明しづらい

    • Kritaもブラシ設定をこの方法で保存しているが、データ量が多すぎると予期しない問題を起こすことがある

    • Macromedia Fireworksは20年前からPNGをデフォルト保存フォーマットとして使っていた

      • もちろん当時JSONを入れていたわけではない

    • 多くのAI画像生成フロントエンドも同様に使っている

      • 画像コメント(comment)にプロンプトや設定を保存し、画像を開くだけで設定を取り込んだり、ComfyUIのようにワークフロー全体を読み込んだりする仕組みだ
      • 実際、画像を扱うツールではこうしたやり方はかなり一般的だと思う

    • Macromedia FireworksはPNGにFireworksファイルを保存しており、

      • AdobeのIllustrator（AI）ファイルは実際にはPDFであり、
      • PhotoshopのPSDファイルもTIFFの中に保存できる
      • そのためPhotoshopでは複数レイヤーが見えるのに、他のソフトウェアでは1レイヤーしか見えないことがある

  • この仕様は、すでに広く実装されているものを明文化したものに近い

    • 次世代PNGだとしても、新しいデコーダーが必要ならPNG2と呼んでもよかった気がする

    • JPEG-XLはすでに多くの人が望む可逆コーデックの条件をほぼ満たしている

      • 問題はエンコード/デコード速度とリソースである

    • 現在の可逆画像コーデックの最高峰はHALICである

    • HALIC議論スレッドを見ると、実際にはLEA 0.5のほうが優れているという

    • 正直に言うと、JPEG XLをしばらくのあいだ「超巨大画像」専用だと思い込んでいて無視していた

    • 自分はコンピュータビジョン用の画像アノテーションツール（XLabel）でpngを使っている

      • クラスラベルを画像メタデータに直接保存できるので、テキストファイルを別に置く必要がない
      • 今後こうした用途向けの拡張フォーマットを作りたい

    • WebPの可逆圧縮は業界トップクラスなのに広く使われていない

      • 可逆圧縮で最高性能を出すこと自体が重要なのではなく、むしろエコシステムへの採用こそが大きな課題であることを示唆している

    • エンコード/デコード速度の問題は時間とともに改善されうる

      • これは過去のjpgエコシステムで実際に起きた変化である

  • 公式にExifデータ対応が入ったことが最高のニュースだ

    • 以前からヘッダーにカスタムデータを書けたが、Exif対応は非常に歓迎できる

    • ちなみにExifにジャイロスコープ（回転）や加速度（重力）関連のフィールドがあるのか気になる

      • Googleカメラアプリで撮った写真にはこうした情報が入っておらず、その後の自動補正やパノラマ合成で惜しいことが多かった

    • 加速度フィールド（Exif.Photo.Acceleration）と高度用フィールド（Exif.Photo.CameraElevationAngle）はあるが、3軸すべてには対応していない

      • 環境センサー（周辺条件）はあるが、仕様作成者が指定した特定項目だけが反映されている
      • Exif.Photo.MakerNoteはメーカーが好きな情報を保存できる自由な領域で、9軸データを書き込んでも十分なほどサイズ制限が大きい

    • Exifは画像レンダリング時の回転処理によって混乱を招くことがある

      • 旧版と新版のデコーダーが、Exif回転の有無によって画像を異なる向きで表示してしまうことがある
      • Exif回転に関する具体的なデコーダー推奨事項がないため、二重回転（たとえばデスクトップ環境とライブラリがそれぞれ処理するなど）のようなバグも頻繁に起こる
      • 「デコーダーがExifデータの信頼性を別途判断できないなら、Exifデータは記録的価値としてのみ扱うべきだ」という曖昧な推奨文言があるだけだ
      • 完全な下位互換性のためには「絶対に回転するな」のような明確な指針が必要だと思う

    • カメラの加速度計や慣性航法装置データを記録する標準フィールドはない

    • 実際、多くのWebサイトはアップロード時にExifデータの大半を削除する

      • 一部のフィールドは個人情報や位置追跡に悪用されるおそれがあるためだ

    • 個人的には、みんなExifではなくXMPを使ってほしい

      • Exifは構造が変で、本質的にはTIFF画像をPNG内に埋め込むようなものだ

  • 今回のPNG仕様は、すでに広く通用しているやり方を公式に明文化したものだ

    • 最高のコーデックは、どこでも、どのアプリでも、OSシェルやAPI、Linuxなどでも動作しなければならない

    • HEICやAV1のようなフォーマットは、OSレベルの対応がなければファイルのプレビューすら難しい

    • まともに流通しないフォーマットはプラットフォームのデフォルトになるべきではない

    • 自分は多様な画像フォーマット、特に特定分野でしか使われない珍しいフォーマットまで扱う仕事をしている

      • さまざまなフォーマットを本当にサポートするのは非常に大きな挑戦だ
      • ライブラリも表向きはjpg/tif/heic対応と書いてあっても、たとえば30GBのjpegやすべてのメタデータ対応まで問題なくできるかというとそうではない

    • この新仕様は、むしろHEICやAV1よりさらに混乱を招く可能性がある

      • PNGの中にどのコーデックが入っているのか、ファイルを開くまでまったく分からない

  • これまでHDRが、明確な輝度・コントラスト比の拡張ではなく「より広い色空間」の意味で使われているのを見たのは初めてだ

  • もう遅すぎるのではないかと思う

    • しかもJPEG XLは、すでにあらゆる機能（非可逆/可逆圧縮、アニメーション、HDR、Exifなど）と高度な圧縮技術（有限状態エントロピー、ZStandardなど）を提供している

    • 別途PNGを更新する必要はなく、ただJPEG XLを使えばいいと思う

    • 「ただ採用すればいい」が成り立たない現実

      • JPEG XLブラウザー対応状況: 5年経っても対応ブラウザーは1つしかない
      • ブラウザー提供者が実装しなければ、開発者やユーザーは新フォーマットを使えないのが現実だ

    • 「高度な圧縮技術（ZStandardなど）」への言及について

      • ZStandardは、一定の変化幅を持つ数値（たとえばグラデーション）の圧縮には、むしろ向いていないことがある
      • Bzip2のほうがこの点では優れており、例のように2つの変数（内側と外側の繰り返し）がカラーチャンネルに対応する場合により適している
      • 現実のデータはノイズのため単純ではないが、こうしたアルゴリズム比較はそれでも実際とは差がある

    • 「PNGの更新は不要で、JPEG XLを採用すればいい」

      • それならGoogleに言うべきだ
      • 実際、GoogleはChromeでのJPEG XL対応を断念しており（関連イシュー）、そのせいでエコシステムの拡大が阻まれている

    • なぜまた別の標準（派生形）を作るのか理解できない

      • すでに十分混乱しているのに、独自の売りもない新標準ばかり増え続けることを嘆いている

  • これでGIFをAPNG（アルファブレンディング + 透明背景 + 可逆圧縮）で置き換えられるようになり、2000年代のWeb感が復活できるかもしれない

    • Animated SVGにも標準があるのか気になる

      • 以前JavaScriptベースのSVGアニメーション（チャットボットのアバターのようなもの）を見たことがあるが、標準フレームワークがあるのかよく分からない

    • Animated SVGは存在する

    • 最近はGIFの代わりに音声なし動画（たとえばmp4）のほうが圧縮効率がよく、多く使われていると理解している

      • Animated PNGがAV1などの動画フォーマットに対して競争力があるのか気になる

    • GIFアップロードに対応する大半のサービスでは、APNGやanimated WEBPの対応がほとんどない

      • バックエンド対応がほぼゼロに近く、とてももどかしい

    • 短い動画をアニメーショングラフィックに変換するなら、もともとWEBPのほうがAPNGより優れていた

      • GIFを中間フォーマットとして使うなら、まだAPNGにも競争力はある
      • 今ではAVIFが最良の選択肢だ

    • 数年前にLottie（Bodymovin）ライブラリを使った経験がある

      • Adobe After Effectsでアニメーションを作り、svgとjsonに書き出してから、lottie JSでWeb上に簡単にアニメーションを適用できた
      • ベクターWebアニメーションでは、まともなツールやDX（開発者体験）が不足していると感じた
      • animated PNG側のツールやDXの情報も気になる

  • PRで「多くのプログラムが新しいPNG仕様をすでにサポートしている」と主張されている件で

    • PhotoshopがAPNGをサポートしているという言及は誤りだ

      • APNG認識がWhat's newの2番目の項目だったにもかかわらず、実際にはPhotoshopで対応しておらず残念だった

    • PhotoshopはHDR部分はサポートしているが、APNG部分はサポートしていない

  • 誰かが、人々は時間/日付の不確実性をソフトウェア上で一貫して管理できるべきだと言及していた

    • 「写真は2025年にスキャン、内容は復活祭ごろ、1920〜1940年の間」といった曖昧な時刻情報を扱う必要性がある

    • EXIFにはDateTimeDigitizedフィールドがある

    • GoogleフォトやApple Photosでは直接日付を指定できるが、実際にはEXIFへ保存しない

      • プラットフォームを移ると、EXIFのない画像は日付情報も一緒に失われる問題が発生する