HDRを使用してアプリのダイナミックイメージ体験を向上

こんにちは Davideです 本セッションは 昨年のセッションの 「Support HDR Images in Your App」の続きです 今年Appleは HDR画像に関連する 優れた技術をいくつか開発しました このセッションでは これらの技術をご紹介します このセッションではまず ヘッドルームとトーンマッピングの概念を 説明します 次に Adaptive HDRについて 解説します これは SDRアプリ デコーダ ディスプレイと下位互換性のある 新しい技術です そのあと DavidがAdaptive HDR画像を ファイルから読み込む方法を説明します HDRコンテンツを保持しながら 画像を編集するプロセスを 解説してもらいます 新しいAPIの導入により OSやほかのアプリとの シームレスな統合が可能になります 例えば 背景と前景の 切り替えが可能になります 最後に Davidが HDR画像をファイルに書き込む際に 推奨される方法を説明して 締めくくります

まず HDRの概念と技術について説明します ハイダイナミックレンジ（HDR）とは 何でしょうか HDRとは基本的に 私たちの周りの視覚世界を より忠実に表現するために開発された 一連の技術です

HDRでは 現実世界の光を より広範囲な強度でキャプチャし 表示できます スタンダードダイナミックレンジ（SDR）より 高い深度の色を表示できます HDR画面で コンテンツを より明るく深みのある色で表示するための 一連のルールや変換方式も定義されています これらの変換の処理は トーンマッピングと呼ばれます トーンマッピングとは何でしょうか それを理解するには ヘッドルームの概念を 理解する必要があります

ヘッドルームを理解するためには 写真のダイナミックレンジについて お話しする必要があります 人間の視覚システムの 驚くべき特性の一つは 実に広範な入力刺激に適応できることです 人間の眼は 夜の星のほのかな光から 太陽光の極度の明るさまでに適応できます

ダイナミックレンジという用語は 画像の最も明るい色調と 最も暗い色調のコントラストを指します SDRディスプレイでは 実際の光の範囲の一部しか 正確に表現できません 正確に見える画像であっても 画像の範囲に対して 色調の圧縮が行われています 一方 HDRディスプレイはSDRに比べて 暗い色調も明るい色調も 損失が少なく より適切に表現できます 例えば 鏡面ハイライトや 発光する物体からの光が 適切に保持されます スライド下部のプロットを 拡大してみましょう

ご覧のように HDRが表現できる ピーク輝度は SDRのピークよりもはるかに高くなります ISOの画像規格では 最も明るいSDR信号は 基準白とも呼ばれます 基準白の輝度は 屋内環境での 本のページの輝度や Keynoteプレゼンテーションの 白い背景の輝度とほぼ同じです

一方 HDRディスプレイでは 鏡面ハイライトや 発光する物体からの光を 基準白よりも明るくレンダリングできます

この追加の輝度をヘッドルームと呼びます

数学的に言うと ヘッドルームは HDRのピークと基準白の比率です ヘッドルームは値の対数として 表すこともできます 対数形式で ヘッドルームが基準白より 1ストップや2ストップ高いという場合 そのHDRの輝度が それぞれ 2倍および4倍であることを意味します ヘッドルームの概念が説明できたので 次は 基本的で重要な区別について お話しします これは後で役立ちます

データに 基準白を超える輝度レベルが 含まれるようにエンコードされている ファイルについて その追加輝度の容量を コンテンツヘッドルームと呼びます 基準白を超える輝度レベルを表示する ディスプレイについて その表示できる追加輝度の容量を ディスプレイヘッドルームと呼びます この違いをさらに詳しく確認しましょう

この例では 美しい風景がHDRで 表示されています 右のヒストグラムは このコンテンツに 基準白より輝度が 約2ストップ高いヘッドルームが 含まれていることを示しています エディタや iPhoneなどのキャプチャ デバイスではより高輝度のレンディションが 作成される場合があります この例では約3ストップ高くなっています

一方 この画像は 様々なディスプレイで 表示される可能性があります ディスプレイヘッドルームの容量が 十分であれば 画像がデコードされ フル忠実度でレンダリングされます この例では ディスプレイに 3ストップのヘッドルームがあるので 3ストップのコンテンツヘッドルームを すべて表示できます しかし ディスプレイが コンテンツヘッドルームのすべてを 表示できない場合もあります これは例えば 現在の画面輝度設定が原因で生じます このセッションの後半で ディスプレイヘッドルームが減少する その他の原因について説明します この場合 クリエイターの意図を尊重し クリッピングを回避するために まずデータを操作する必要があります その方法としては

トーンマッピングという技法を使用します トーンマッピングでは 画像の輝度と色の値を調整して 当該のメディアやディスプレイで処理できる 範囲内に収まるようにすることで 画像の正確な描写を実現します デジタル写真のトーンマッピングは 写真の撮影時や編集時 および 画像をデコードして表示する時に 実行できます 第1段階は 一般に 芸術的または創造的な調整と呼ばれます 例えば アーティストは Apple ProRAWアセットなどの 画像をインポートし リファレンス用のディスプレイと表示環境で それを分析した上で クリエイティブな意図に基づいて SDR または定義済みのHDRヘッドルームに 合わせて トーンマッピングを適用します iPhoneなどのキャプチャデバイスでは 画像をファイルに保存する前に 機械学習技術を使用して 適用するトーンマッピングを 自動的に決定することもできます

第2段階は 一般に ディスプレイ調整と呼ばれます デコードされたHDR画像は 様々なデバイスで 表示される可能性がありますが デバイスの中には ヘッドルームが 限られているものもあります

また 各デバイスは様々な物理的環境で 使用される可能性があります

いずれの場合も ディスプレイにおける 画像のレンダリングを 状況に応じて調整する必要があります

コンテンツの調整は 次のような理由で行われます

まずはディスプレイの性能 つまり ハードウェアが物理的に表示できる ニト数に基づく場合があります 次に 現在の画面輝度設定と その結果として利用可能な ヘッドルームが理由となる場合があります デバイスのバッテリー残量も理由となります 低バッテリー状態の場合 電力を節約して デバイスの稼働を維持するために ディスプレイを暗くする必要が あるかもしれません

画像の併存も理由になります 例えば オペレーティングシステムが 前景の画像をHDRに引き上げ 背景の画像をSDRに トーンマッピングする場合です さらに デベロッパが写真のHDR効果を 異なる方法で適用したい場合も コンテンツを調整します 以上 ヘッドルームと トーンマッピングについて説明しました 次のセクションでは 新機能とAPIの基礎となる 3つの技術と それぞれの規格について説明します 1つ目は 昨年導入されたもので ISO HDRと呼ばれます ISO HDR規格は HDR写真の規格としては初めてのものです Appleはその開発に積極的に関わっており 規格は2023年に発表されました ISO HDR画像は昨年から Appleエコシステムでサポートされています

ISO HDRの主な要素には 次のようなものがあります 10ビットのPerceptual Quantizerと Hybrid Log Gammaのエンコーディングを 保存する機能 HDRリファレンスディスプレイの定義 クリエイターの芸術的意図を 損なわないために必要なメタデータ ISO HDR画像を HEIF、 AVIF PNG、JPEG、XLなどの 様々なファイル形式で保存する機能 この事項の詳細については こちらの 番号の文書を参照してください

もう一つ重要な点は SDRディスプレイで表示する際 ISO HDRファイルをSDR向けに 調整する必要があることです この調整には通常 デフォルトの トーンマッピング演算子を使用します この演算子は ITU仕様2408 2446 2390などに記載されています ITUトーンマッパーについては 後ほど説明します HDR画像に関する2つ目の技術は 今年新しく導入されたもので Adaptive HDRと呼ばれます すでにISO HDRがあるにも関わらず なぜ新しい規格が必要なのでしょうか Adaptive HDRは ISO HDRがベースですが 3つの重要な分野でさらに進化しています

1つ目は SDRシステムやデコーダ そしてアプリとの 下位互換性です 2つ目は HDRとSDRの両方に 最適化された画像を 1つのファイルに保存する機能です 3つ目は HDRとSDRの間の トーンマッピングを簡単に実行し 表示環境のディスプレイヘッドルームに 対応する機能です Adaptive HDRでこの3つがどのように 実装されているのか見ていきましょう

Adaptive HDRテクノロジーの基本的な コンセプトは フルに下位互換性のある SDRベースライン表現を保存した 画像ファイルを作成することです このファイルには 特定のメタデータと シーンの明るい部分の空間的な 位置情報を保持するマップも保存されます このマップを使用すると SDR画像の一部の輝度を増幅して 明るさを増すことができるため 一般に「ゲインマップ」と呼ばれます ゲインマップを ベースラインの レンディションに適用することで 美しいHDR画像が生成されます 鋭い方はこのスライドの奇妙な点に お気づきかもしれません タイトルが「Adaptive HDR」ではなく 「Apple gain map」になっています これは間違いではありません 2020年以降 iPhoneのカメラでは より美しい画像を撮影できるよう 画像にゲインマップを適用しています このフォーマットで撮影された画像は 1兆枚を超えています

Apple Gain Mapの詳細については Apple Developerポータルをご覧ください

今年の最新情報は ゲインマップ技術の標準化に向けた取り組みを Appleが推進していることです ゲインマップを作成し ベースラインSDRに適用するための 数式の標準化を進めています Adaptive HDRでは HDR信号とSDR信号の比率の対数として マップをエンコードします また 新しいメタデータとの定義と HEIFやJPEGなどの一般的なファイル形式に 新しい情報を保存する方法の定義も 行われています

Adaptive HDRは現在 ISOの委員会草案の段階にあり 最終段階である国際規格案の作成に向けて 作業が進んでいます 詳細を知りたい場合 ISOメンバーであれば このスライドに表示した番号の文書を 参照できます この規格はソフトウェアとハードウェアの プラットフォーム間で 統一された体験を保証するものであり 映像業界で広く採用されることが 予想されます 次に 前述のISO HDRと比較して Adaptive HDRでは3つの改善をどのように 実現しているのかについて説明します 第1の改善である下位互換性の保証は 古いシステムやSDR専用のアプリでも 完全にデコードできるSDRベースラインを ファイルに含めることで 実現しています 第2の改善については SDRとHDRの画質を 損なわず表現するデュアルレンダリングが ファイルに含まれています この機能は 画像の各ピクセルの情報を含む ゲインマップにより実現されます 第3の改善については ゲインマップが SDRとHDRの比率として定義されているため ディスプレイヘッドルームに基づいて 入力コンテンツのトーンマッピングを 簡単に実行できます

実際 SDR入力に重みが1未満の ゲインマップを乗算することで あらゆる出力のヘッドルームに対応できます 非常に簡単です

Adaptive HDRにより ゲインマップ信号の表現が 強化されることは注目に値します RGBの3チャンネルのマップも 使用できるようになり 画像の表示品質を より細かく制御できるようになりました

Adaptive HDRでは対称変換も可能です つまり HDRのベースラインレンディションを SDRにトーンマッピングするための情報を ゲインマップに含めることができます

iOS 18のリリースに伴い Adaptive HDRのゲインマップと 関連メタデータへの移行を進めています この新世代のiOSは 最新の規格草案に基づいています

iPhone 15および15 Proでは Adaptive HDRに準拠したHDR画像を 撮影できるようになります

新しいAdaptive HDRファイルの 構造を見てみましょう iOS 18で撮影した新しいHEICファイルには 従来と同様に 画像が1つしか含まれていません 実際 CGImageSourceで CGImageSourceGetCountを呼び出すと 1が返されますが デベロッパは 画像の別の形式を リクエストできるようになりました デフォルトでは 画像はSDRでの表示用にデコードされます これは 従来使用されている 下位互換性のある画像です この場合に提供されるメタデータは SDRの表現に必要なもののみであり ファイル内のその他の情報は無視されます アプリがリクエストすると 別の表現形式の画像 つまりHDR画像を 取得できます この場合 ゲインマップなどの ファイル内の追加情報が使用され アプリに報告されます

HEIF関連の用語では この表現形式はTMAP代替 または トーンマップ済み画像と呼ばれます このファイルには HDR画像は一切含まれないことを 理解しておくことが重要です 含まれるのは一連の「材料」と 「レシピ」であり それらが組み合わされることで HDR画像が生成されます

AppleはMPEGと共同で HEIFのAdaptive HDRファイル形式の 正式化と標準化を進めており このファイル形式は現在 HEIF仕様の第2修正案の 作業草案に記載されています また International Color Consortiumとも協力し ICCプロファイルの一部として Adaptive HDRの利用を促進しています

JPEGファイルも Adaptive HDRをフルサポートしていますが HEIFとは構文が少し異なります Adaptive HDRの規格草案に 詳細が記載されています

ProRAWファイルも Adaptive HDRをサポートしており フルサイズのサムネールに ゲインマップと新しいメタデータが 含まれます

前述の通り iPhone 15および15 Proは iOS 18以降では 新しいAdaptive HDRに移行します この表の詳細を すべて確認することはしませんが 変更点と想定される影響を確認したい場合は セッションを一時停止して チェックしてください HDRの専門知識を習得できたので ボーナストピックに移りましょう オペレーティングシステムが ファイル形式に基づいて HDR画像をレンダリングする仕組みを 説明します

SDRや低いディスプレイヘッドルーム向けに HDR画像をトーンマッピングする方法は 入力コンテンツに応じて2つあります ISO HDR画像の場合 iOS 17およびmacOS 14以降では ITUのデフォルトの グローバルトーンマッピング技術を使用して HDRから低いヘッドルーム向けへの 調整を行っていました

今年Appleは デフォルトの方法よりも 出力品質を高く維持できる 新しいReference White Tone Mapping Operatorを開発しました ハイライトのクリッピングが大幅に減少し 色再現性がより適切に維持されます この新しいグローバルトーンマッパーを ISO HDRファイルで使用するのは 新しいiOS macOS tvOS watchOS visionOSです 一方 Adaptive HDR画像の場合 ディスプレイのヘッドルームに 対応するための調整に ファイル内のゲインマップに応じて 最適化されたカーブを使用します

次はDavidによる新しいAPIの説明ですが その前に 今後提供開始される技術を活用できるよう 今年アップデートされた システムアプリをご紹介します iOS 17とmacOS 14では ディスプレイヘッドルームをフルに使用して HDR画像をレンダリングできるアプリは 写真アプリだけでした

iOS 18とmacOS 15では メッセージ クイックルック およびプレビューの 各アプリが追加されました また 新しいAPIを利用できるよう 写真アプリが変更されたことも重要です ここからはDavidにバトンタッチします 概要の説明をありがとう Davide 私からは 今説明してもらった概念を アプリのコードに変換する方法を説明します HDR画像を扱う場合 アプリがサポートすると考えられる 一般的な処理があります

包括的なHDRパイプラインには 画像の 読み込み 編集 表示 書き込みが含まれます このセッションでは このすべてについて説明します 最初のステップは メモリへの ファイルの読み込みです

Adaptive HDRファイルの素晴らしい点は その柔軟性です ゲインマップと関連するメタデータを 利用できるため 画像をSDRとして読み込み 最適な下位互換性を実現することも HDRとして読み込み 忠実度を最大限に高めることもできます デフォルトでは ゲインマップ画像を読み込むと SDRの表現がメモリに読み込まれます 必要な操作は CIImageオブジェクトを URLまたはデータで初期化することのみです しかし 画像のインパクトを強めるには HDRにすることが効果的です

昨年 Apple Gain Map画像フォーマットを サポートするために CIImageのexpandToHDRオプションが 導入されました この同じAPIを Adaptive HDRファイルの 読み込みでも利用できるようになりました 必要な操作は CIImageを初期化する際 このオプションを指定することのみです

このオプションは ImageIO APIの kCGImageSourceDecodeToHDRを介して 使用することもできます Davideがすでに説明したように 画像オブジェクトに contentHeadroomプロパティが 関連づけられていることが重要です このプロパティは 以降のHDR画像の表示に 必要となります 今年 主要なシステム画像クラスに このプロパティが追加されました

新しいcontentHeadroomプロパティの 読み込みと同様に CIImageのヘッドルームのクエリは シンプルです 一般的なSDR画像の場合 返されるヘッドルームは1のみです iPhoneのHDR写真の場合 この値は1より大きくなり シーンの内容に応じて最大で8になります 画像によっては ヘッドルームが不明であることを示す ゼロが返される場合があります

同様に CGImageRefには ヘッドルームを取得する 新しい CGImageGetContentHeadroom APIがあります

IOSurfacesにも同等のプロパティがあります CVPixelBufferからヘッドルームを 簡単に取得するには そこからCIImageを作成し contentHeadroomを取得します 次に Adaptive HDR画像の編集方法に関する 推奨事項について説明します Adaptive HDR画像ファイルには 柔軟性があるため これらの画像を編集 表示 保存する際に 戦略を複数の選択肢から選択できます 最もわかりやすいのは ファイルをSDR画像として扱うことでしょう このアプローチはみなさんもよく ご存知だと思うので 今回はお話しません

昨年のセッションで説明したように ファイルをHDRとして扱うこともできます ファイルをSDR画像とゲインマップ画像の 組み合わせとして扱うこともできます さらに アプリでファイルを 2つの画像として扱うこともできます 1つはSDRで もう1つはHDRです このセッションの残りの部分では この3つの戦略について説明します

HDRのアプローチでは expandToHDRオプションで画像を読み込み 画像が読み込まれたらすぐに HDR画像を作成します

その後 HDR範囲を保持するフィルタを使って HDR画像を編集できます HDRを保持するCIFiltersの詳細については 「Support HDR Images in Your App」を ご覧ください 考慮すべき点の一つは 画像の編集による contentHeadroomプロパティへの影響です 一部の変更については Core Imageはヘッドルームが 変更されないことを認識しています スケーリング トリミング ワーピングや 特定の畳み込みの適用などが該当します ほかの変更の場合 ヘッドルームに及ぶ影響を Core Imageは認識できません このような変更があった場合 ヘッドルームプロパティは 不明であることを示すゼロになります

SDRとゲインマップのアプローチでは ファイルのSDRとゲインマップの 両方のコンポーネントを 2つのメモリ内 画像オブジェクトとして読み込みます auxiliaryHDRGainMapオプションを使用して ゲインマップをCIImageオブジェクトとして ファイルから読み込みます

ベース画像はSDRであるため コンテンツヘッドルームは1になります

SDR画像を編集すると 必要に応じてゲインマップにも 同様の編集が適用されます 例えば SDR画像をトリミングすると ゲインマップ画像もトリミングされます 通常 ゲインマップ画像はSDR画像の 半分のサイズであるため 編集ではスケールの違いを 考慮する必要があります

SDRとHDRのアプローチでは このようなコードを使用して ファイルの 両方の表現をImageオブジェクトとして 読み込みます

留意すべき点は SDR画像のヘッドルームは1になり HDR画像のヘッドルームは 1より大きくなることです

SDR画像を編集すると HDR画像にも同様の編集が適用されます その編集がHDRをサポートしていれば 両方の画像に適用できます この3つの戦略には それぞれ利点と欠点があります HDR戦略はコードで1つの画像を 追跡するだけでよいため 実装がシンプルになります この戦略には ゲインマップのないISO HDR画像で 使用できるという利点もあります

欠点は 一部の編集操作 特に写真のブレンドモードで HDRがサポートされていないため 代替手段を使用する必要があることです 組み込みのCIFilterが HDRをサポートしているかどうかは フィルタ属性のカテゴリを 確認すればわかります

また 編集がHDRで適用されると SDRや別のディスプレイヘッドルームに 対応するためのトーンマッピングに 元のゲインマップを使えなくなります

SDRとゲインマップの戦略には 元のゲインマップが保持されるという 利点があります これは 最適な下位互換性を持つ画像の トーンマッピングや 保存を行う時に便利です この戦略は 回転 ワーピング トリミングなどの 単純な編集を行う際に最適です SDRのみでサポートされている 編集を行う場合も有効です

欠点は ゲインマップには 適用できない編集があることです 例えば SDR画像の輝度を 大きく変えるフィルタは ゲインマップに適用しても 適切な効果は得られません

SDRとHDRの戦略には SDRとHDRの両方を最適化するように アプリで編集を調整できるという 利点があります また SDRとHDRの両方を編集し ゲインマップを再計算できるため 画像ファイルを 極めて柔軟な方法で 保存できます

欠点は 2つの画像を編集し SDRとHDRのどちらの編集でも 見栄えを良くするために 作業の複雑さが増すことです

HDR編集戦略を使用するコードの例を ご紹介します まず .expandToHDRオプションを リクエストする画像を読み込みます 次に この例では HDRコンテンツをフルサポートするために vignetteEffectFilterを適用しています このコードで画像にフィルタを適用して 編集された新しい画像を生成します

次は SDRとゲインマップの 編集戦略を使用したコードの例です まず オプションなしで画像を読み込んで SDR画像を取得します auxiliaryHDRGainMapオプションを使用して 画像を再度読み込み CIImageとしてゲインマップを取得します ベースのSDR画像のサイズに合わせて この画像をスケーリングする必要があります

次に この例では stretchCropFilterを適用しています このフィルタは画像をワープするので SDR画像とゲイン画像の両方に適用されます

この行のコードで SDR画像にフィルタを適用して 編集されたSDR画像を生成します 最後に ゲイン画像にフィルタを適用して 編集されたゲイン画像を生成します 以上 Adaptive HDR画像を読み込んで 編集する方法を説明しました 次は 表示のための トーンマッピングを行う方法です

HDR画像を表示する際の重要な課題の一つは ディスプレイや環境が多種多様であるため 画像のトーンマッピングが 必要になる場合があることです これを最適に行うには 画像とディスプレイの両方のヘッドルームを 把握する必要があります 画像の見栄えを良くし アプリ間で一貫性を確保できるよう 今年 システムのトーンマッピングのための 新しいAPIが導入されました

UIImageViewまたはSwiftUIビューを 使用するアプリでは このトーンマッピングが自動的に行われます 次に そのコードについて説明します

この例では URLを介してアクセス可能な Adaptive HDR画像ファイルがあり SwiftUIを使用してそれを表示します 必要な作業は UIImageReaderを使用して UIImageを作成することのみです このリーダーでは HDRの様々な ファイル形式が正しくサポートされます SwiftUIの画像ビューを作成し allowedDynamicRangeモディファイアを 指定して 表示するファイルの ダイナミックレンジを決定します 簡単ですね

同様に アプリでUIKitを使用している場合は UIImageでUIImageViewを作成できます preferredImageDynamicRangeプロパティを 設定して 表示するダイナミックレンジを指定します

UIImageで提供できる以上のパフォーマンスや 制御が アプリで必要な場合は Core ImageとMetalを使用して表示できます これは 画像をインタラクティブに 変更したい場合に適しています Adaptive HDR画像を Core Imageで表示する場合 最適なアプローチは 使用された編集戦略によって異なります

どの戦略を使用したかに関わらず 目標は 画像のコンテンツヘッドルームと ディスプレイヘッドルームに基づく トーンマッピングによる 現在の表示状況に応じた画像の最適化です

アプリでHDR編集戦略を使用している場合は 表示前に 新しいtoneMapHeadroomFilterを 使用します ファイルがISO HDRファイルの場合は 新しいReference White Tone Mapping Operatorが使用されます ファイルがAdaptive HDRファイルの場合 フィルタは ファイル固有の ゲインマップに従って最適化された カスタムトーンマップ関数を適用します 次は toneMapHeadroomFilterを使用し 結果をMTKViewに表示する コードの例をご紹介します まず 拡張レンジコンテンツの MTKViewを設定します 次に CIFiltersを適用して 編集されたCIImageを作成します ビューの現在の ディスプレイヘッドルームの状態を取得し 新しいCIToneMapHeadroomフィルタを 適用します

得られたトーンマップ済み画像を CIRenderDestination APIを使用して レンダリングします MTKViewで CIImagesを 効率的に表示する方法の詳細については 「Display EDR Content With Core Image, Metal, and SwiftUI」をご覧ください

SDRとゲインマップの編集戦略を アプリで使用することもできます その場合 表示する時に2つを組み合わせて トーンマッピングする必要があります 新しいimageByApplyingGainMap: headroom APIを使用すれば 1つの処理でこれを実行できます 次に SDR画像とゲインマップ画像を 別々に編集し 合成した結果をMTKViewに表示する コードの例をご紹介します MTKViewを設定するコードは 前の例と同じです 次に CIFiltersを適用して 編集されたCIImageを作成し 適切なフィルタを適用して 編集されたゲインマップ画像を作成します ビューの現在の ディスプレイヘッドルームを取得し applyGainMap APIを使用して 2つの画像を合成します 前と同様に 結果として得られる トーンマッピングされたCIImageは CIRenderDestinationを使用して レンダリングできます

必要に応じて コードでHDR CGImageを EDR CGBitmapContextに レンダリングすることもできます まず ImageIOを使用し kCGImageSourceDecodeToHDRオプションで Adaptive HDRファイルを読み込みます その後 必要に応じて CGImageGetContentHeadroom APIを使います 例えば 1つのコンテキストに 複数の画像をレンダリングする場合は これを知っておくとよいでしょう 次に RGBA 16ビット浮動小数点ピクセルと 拡張色空間を持つ 拡張レンジCGContextを作成します CGContextSetEDRTargetHeadroomを 使用して 使用するコンテキスト範囲を Core Graphicsに指示します 最後に 画像をコンテキストに レンダリングします 最後に HDR画像をファイルに保存する際の 推奨方法について説明します 保存に関するベストプラクティスは 読み込みと編集に使用した 戦略によって異なります まず 画像をHDRとして 読み込んで編集した場合 最新の方法は PQ色空間で 10ビットのHEIFファイルを保存することです これにより 最適な精度とレンジで 画像を保存できます 画像をSDRおよびHDRとして 読み込んで編集した場合 最も互換性の高い方法は Adaptive HDRファイルを保存することです そのためには 2つのCIImagesで writeHEIFRepresentationを呼び出します まず 編集済みのSDR画像と 色空間を指定します 新しいHDRImageオプションを使用して 編集済みのHDR画像が渡されます Core Imageはこの2つの画像から ゲインマップを計算し ベースのSDR画像とともに 補助画像として含めます

SDRとゲインマップの編集戦略を アプリで使用している場合は writeHEIFRepresentationを呼び出して 両方の画像を保存できます SDR画像と色空間を渡すだけで実行できます HDRGainMapImageオプションを使用して 編集済みのゲインマップ画像も提供します ゲインマップ画像に 読み込み時の 元のメタデータプロパティが 設定されている場合は Adaptive HDRファイルに保存する時に それらが使用されます 最後に SDR CGImageとゲインマップデータを ImageIOを使用してアプリで保存します まず SDR CGColorSpaceと SDR CGImageを指定して CGImageDestinationAddImageを 呼び出します 次に ゲインマップを記述する 辞書を作成します これには ゲインマップの 実際のピクセルデータと そのデータの高さ 幅 形式を記述する サブ辞書と ピクセルデータをリニアゲイン値に 変換する方法を記述する CGImageMetadataを 含める必要があります ほとんどの場合 ソースファイルの CGImageMetadataを再利用できます あとは CGImageDestinationAddAuxiliaryDataInfoを 呼び出して 新しい kCGImageAuxiliaryDataTypeISOGainMapキーと 情報を含む辞書を渡すだけです 新しいAdaptive HDRファイル形式の 説明は以上です このセッションでは この新しいフォーマットの 背後にある特徴と原理のほか それらをアプリで サポートできるようにするための APIと戦略について詳しく説明しました 本セッションと このトピックに関連する その他のセッションを みなさんのアプリにおいて 優れたHDR写真を 提供する上でご活用いただけると幸いです