iOSのEDRの詳細

♪ メロウなヒップホップ音楽 ♪ ♪ こんにちは Denisです AppleのDisplay and Color Technologies チーム担当です 本日はEDRのアップデートと iOS開発者への影響について説明します EDRについては 昨年 紹介しましたが 簡単に言うと Extended Dynamic Rangeの略で AppleのHDR技術です EDRはレンダリング技術と ピクセル表現の両方を指しますが 特にEDRのピクセル表現は 標準コンテンツとハイダイナミックレンジ コンテンツの両方を表現できる点で重要です 露出のよいコンテンツでは 被写体のキャンパーは 画像の標準ダイナミックレンジ内に収まり 焚き火のように光を放つ 放射性の物体はハイレンジに入ります 一般のレンジ表現では これらの要素は再現できませんが EDRでは表現可能です 他の画素表現が 一定の輝度の範囲を表現するのに対し EDRは任意の値を再現でき ダイナミックな表現を可能にします さらに未使用のバックライトを 活用することで EDRは ディスプレイのピークに関係なく ハイダイナミックな コンテンツを表現可能です HDRコンテンツの普及と アクセス性の向上により macOSでEDRを採用するAppも増えています 「Baldur’s Gate 3」 「Divinity: Original Sin 2」 「Shadow of the Tomb Raider」はすでに macOSでEDRを搭載しています EDRの採用によって ゲームはより明るく 彩度の高い色を表現可能になり リアルな照明な反射など カラフルなコンテンツを生成可能です SDRのピークホワイトでは 輝度が制限されてしまいますが EDRでは作者が意図したとおりの 鮮やかさと深みを取り戻せます EDRはSafariやQuickTime Playerなど Appleのエコシステム全体に統合されています その結果 Apple TVやNetflixなどの ビデオ・オン・デマンドAppやサービスは HDR10　ドルビー・ビジョンProResコンテンツの 豊富なコンテンツを消費者に 配信可能になります EDRを採用したプロ用Appは HDR静止画や動画の正確な編集 グレーディング マスタリング レビューのための プロ用ワークフローを提供し ユーザーはHDRコンテンツを作成可能になります macOSのEDR採用と共にEDRに 複数の新たなアップデートが提供されます まず第一に私たちのEDR APIが iOSとiPadOSで利用可能になりました さらに プロユーザーをサポートする Appleの取り組みの一環として今年は 12.9インチ iPad ProのLiquid Retina XDR ディスプレイに2つの プロカラー機能を導入します リファレンスモードと SidecarでのEDRレンダリングです リファレンスモードは カラーグレーディング　編集 コンテンツレビューなどの カラークリティカルな ワークフローを実現するために macOSのリファレンスプリセットと同様に 一般的なビデオフォーマットに対して リファレンスレスポンスを提供します そのために リファレンスモードでは SDRピーク輝度を100ニト HDRのピーク輝度を1000ニトに固定し EDRの10倍のヘッドルームを確保しています また リファレンスモードでは メディアとディスプレイの マッピングを1対1で行います また True Toneや輝度自動調節 Night Shiftなどの周囲の環境に 対する動的な表示調整をすべて無効にし 代わりにユーザが手動で 白色点を細かく調整できます これによりディスプレイは 仕様で記述された通りの 色を表示することができます この表はリファレンスモードが サポートするフォーマットの一覧です macOSのリファレンスプリセットと異なり リファレンスモードは最も一般的な5つの HDRやSDRビデオフォーマットをサポートし メディアの種類を問わず リファレンスレスポンスを提供します この表に無いフォーマットのコンテンツを お持ちの方もご安心ください サポートされていない フォーマットはデフォルトの ディスプレイモードと 同様にカラーマネジメントされます 例として リファレンスモードの LumaFusionを見てみましょう iOSでリファレンスモードを有効にすることで LumaFusionはビデオポストプロダクションの 強力なツールになります HDRビデオを表示する際 最大1000ニトまでのP3色域内の色が 正確に描画されるためユーザは常に 正しく安定したビデオ表示が できていることを確認できます リファレンスモードとLumaFusionの 新機能 Video Scopesを組み合わせることで カラークリティカルな ワークフローがiPadで可能になりました リファレンスモードを無効にすると EDRヘッドルームがダイナミックに変化します ここではiOSがビデオの明るさを 調整していることを確認できます LumaFusionのプロジェクトは XMLでエクスポート可能です Macの他の ポストプロダクションAppで読み込めるので コンテンツ制作者は両方のプラットフォームで 簡単に共同作業が行えます LumaFusionが リファレンスモードを採用し プロコンテンツ制作者に価値と 柔軟性をもたらします 新機能はリファレンスモード だけではありません 2019年にMacユーザがiPadを 2台目のディスプレイとして 使えるようにする技術Sidecarを紹介しました リファレンスモードの導入によって SidecarでのEDRレンダリングに対応し リファレンスモードモード有効時の Sidecarの機能を拡張して リファレンスグレードのSDRとHDRコンテンツを サポートすることでプロコンテンツ制作者は iPad ProをAppleシリコンMacの 2台目のディスプレイとして使えます Sidecarでレンダリングされたコンテンツは リファレンスモードですべてのビデオ形式で ネイティブiOSと同じ リファレンスレスポンスを提供します 例えばHDR10のテストパターンを MacでHDRビデオプリセットを使って レンダリングし iPad Proで Sidecarを使ったものと比較しましょう この構成では両方のデバイスが P3カラー D65白色点のリファレンス ディスプレイとして機能します 両方のディスプレイの 仕様がそうなっているためです P3のカラーバーを比較すると MacとiPadは期待通りの 同じようなレスポンスを示しています さらに どちらの構成も ピーク輝度1000ニトに対応し グラデーションを見ると その値に忠実に描画されており 1000ニト以上の値は描画されていません SidecarでのEDRレンダリングが プロユーザにもたらす未来と 新たな可能性が楽しみです また より多くの開発者が 自身のAppにEDRを採用することで 機能が活用できることを期待しています では 皆さんのiOSやiPadOS Appに EDRレンダリングを統合する方法を紹介します まず EDRのピクセル表現と レンダリングパイプラインの 意味について考えます 従来 SDRを浮動小数点で表現すると 0から1の範囲の値で 0が黒1がSDRの白でした EDRでは SDRコンテンツは0～1の範囲で表現され 1以上でSDRより明るいコンテンツを表現します EDRはリニアな空間表現のため 2.0 EDRは 1.0の2倍の明るさとは認識されません EDRは他のHDR フォーマットと異なり0～1の範囲に値を トーンマッピングせず レンダリングに影響を与えます その点EDRはSDRコンテンツ つまり0～1の値を常にレンダリングしています 1以上の値は現在のEDRヘッドルームまで トーンマッピング無しで 適切にレンダリングされます ただし より明るい値はクリップされます この動作は理想的ではありませんが HDRでオーサリングされたコンテンツは できるだけ意図された形で レンダリングされます 明るすぎるハイライトは 従来のレンダリングと 同様にクリップされます ヘッドルームが高いほど コンテンツは明るくダイナミックになります ではヘッドルームはどれくらいでしょうか EDRヘッドルームは デバイス特有のディスプレイ技術や ディスプレイの 現在の輝度など多くの要因に 基づく 動的な値となります しかし 単純化すると 現在のEDRヘッドルームは ディスプレイの最大輝度を 現在のSDR輝度で割った値にほぼ等しくなります 先ほどのリファレンスモードの解説では EDRを1.0に固定しました つまりSDR輝度を100ニトに固定して HDRのピーク輝度を1000ニトに 固定したわけです したがって 1000ニトを100ニトで割り EDRの10倍というヘッドルームになります この表はさまざまなデバイスと その最大可能ヘッドルームの例です これは最大可能ヘッドルームであり 実際のヘッドルームは 現在のディスプレイ輝度など その他の様々な要因に依存します 本動画の後半では ヘッドルームについて詳しく説明し ヘッドルームを照会してレンダリングに 関する情報を得る例を紹介します ひとまずは EDRとその必要性について ご理解いただけたと思います では実際のEDRコンテンツの レンダリングについて話します HDRコンテンツをレンダリング可能な形式で 読み込む方法について説明します 今回は Image I/Oの ワークフローを例に説明します 別のフレームワークをお探しの方は 今年の他のEDRに関する動画をご覧ください 静止画メディアの場合 まず読み込むファイルを用意します 通常はBiplanar YUV空間で エンコードされています 最初に読み込む時 画像とそのバッファは元の形式になっています 残念ながら そのままの 形式では 画像を解釈し意味のある 作業が困難な場合もあります そこでCGBitmapContextを使い 画像をデコードし より使いやすい形式に変換します この時点でコンテクストの バッキングピクセルデータから MTLTextureを作成し Metalエンジンでレンダリングが可能です 具体的には 次の4つの ステップで行います まずHDR静止画用のCGImageを作成し それをビットマップコンテキストに描画して Metalテクスチャを作成し最後に ビットマップのデータを 新しいテクスチャに読ませます まず画像を読み込み 少し設定を行います URLからCGImageSourceへ画像を読み込み そのソースからCGImageを作成します 今回はnilのオプションディクショナリを 渡すことで画像を作成しました ただし 特定のHDR形式で 浮動小数点バッファを 使用したい場合は 新しい kCGImageSourceShouldAllowFloat オプションを設定する必要があります 次に CGBitmapInfoをインスタンス化します この場合 あらかじめアルファが乗算された 16ビット浮動小数点コンテキストを作成します これは Metalテクスチャに 同じ形式を使用するためです 先ほど作成したビットマップ情報と CGImageの幅と高さを使用して CGBitmapContextを構築します コンテキストの色空間は レンダリング先のCAMetalLayerと 一致させる必要があります それ以外の場合は 適切なカラーマネジメントを ご自身で行ってください 最後にCGImageをビットマップ コンテキストに描画します この時点でコンテキストから Metalテクスチャの作成に進むことができます Metalテクスチャを作成するために MTLTextureDescriptorをインスタンス化します 先ほど ビットマップコンテキストに Half floatを使用しましたが EDRのレンダリングでは 10ビットの青 緑 赤と2ビットのアルファを持つ 32ビット パックドピクセル形式の 2Dテクスチャも作成可能です 後ほど詳しく説明しますが テクスチャのピクセル形式を コンテンツの形式と 一致させる必要があることを ご理解いただければ十分です 今回はhalf floatで進めます この時点でMetalレイヤーの デバイスと 新たに作成した テクスチャ記述子を使って インスタンス化します 最後にビットマップコンテキストから データを取得してテクスチャにコピーします これでEDR値を含むMetalテクスチャが完成し レンダリング用の Metalパイプラインに送信できます ここではURLから始まり Metalテクスチャに至るまでHDR静止画の ソーシングのワークフローの例を説明しました 次に iOSとiPadOSでこのようなテクスチャの レンダリングに必要な最小限の コード変更について説明します 新しいiOSとiPadOS APIを使用して EDRにオプトインする手順はmacOSと同じです macOSビルドのAppでEDRをすでに サポートしている場合は 何も変更する必要はありません EDRにオプトインするには CAMetalLayerを使用していること そのレイヤーに適切なフラグと タグが設定されていること サポートされているEDR形式の 明るいコンテンツが必要です まずコンテンツのレンダリング先の CAMetalLayerを取得します そのレイヤーで wantsExtendedDynamicRangeContent フラグを有効にします 次に その同じレイヤーでサポートされている ピクセル形式とCGColorSpaceの 組み合わせを設定します コンテンツの種類や ソースによって 具体的なピクセル形式や色空間は異なります 今回は 画像を16ビット 浮動小数点バッファに読み込み 拡張リニア ディスプレイP3色空間と 一致させるよう選択します iOSはリニア色空間と組み合わせた 16ビット浮動小数点ピクセルバッファ EDRレンダリングをサポートしています これらの組み合わせを選択する場合は 色空間の拡張バリアントを使用してください さもなければ コンテンツは SDRにクリップされます iOSは先ほど触れた10ビットパックドBGRA ピクセルバッファもサポートしています この図は PQまたはHLG色空間の レンダリングに対応するバッファの概要です ここでは EDRレンダリングを サポートするために レンダリングレイヤーで 必要な最小限のコード変更 wantsExtendedDynamicRangeContentフラグ EDRをサポートする各種ピクセルフォーマットと 色空間について説明しました ここで 先ほど用意したMetalテクスチャを CAMetalLayerを使い レンダリングすると EDRでレンダリングできます しかし他にもできることがあります 先ほど述べた通りEDRのデフォルト動作では 現在のヘッドルームにクリップします しかしEDRコンテンツの レンダリングには ヘッドルームが足りない場合 SDRを使用するケースもあります また 現在のヘッドルームを使用して 表示前に コンテンツをトーンマッピング したい場合もあります どちらの場合でもiOSにはヘッドルームの クエリーをサポートする 新しいAPIがありますここでは その呼び出しとmacOSとの 違いを説明し 適切に判断できるようにします macOSでは ヘッドルームクエリーに NSScreenを使用します NSScreenでは ディスプレイがサポートできる 最大EDRヘッドルーム 現在のリファレンスプリセットの 最大EDRヘッドルーム 現在のEDRヘッドルームのクエリーが可能です また macOSではEDRヘッドルームが 変更されるたびに通知が表示されます 一方 iOSではクエリーはUIScreenで行い NSScreenとは異なりディスプレイが サポートする最大のEDRヘッドルームと 現在のEDRヘッドルームのクエリーが可能です さらに UIScreenは リファレンスディスプレイモード ステータスを提供し リファレンスモードが サポートされ有効かを示すために使用可能です UIScreenはEDRヘッドルームの 変更に関する通知を提供しませんが リファレンスモードの ステータスが通知されるたびに 通知を送信します また 最大リファレンスヘッドルームクエリーが リストから外れています 専用のクエリーを使用する代わりに リファレンスモードステータスが リファレンスモードが有効と示しているときに 最大可能なヘッドルームを クエリーすることでその値を決定できます サンプルコードを見て ヘッドルームのクエリー方法を さらに理解しましょう UIScreenではpotentialEDRHeadroomを クエリーして ディスプレイの最大可能な ヘッドルームを確認できます 値が低すぎると判断した場合 代わりにSDRでレンダリング することで処理能力を節約できます 次に EDRを使用する場合 レンダリングデリゲート または定期的なドローコールが使用可能です このコールでは crrentEDRHeadroomをクエリーして コンテンツがヘッドルームを超えないよう トーンマッピングしてクリップを防ぎます リファレンスモードのステータスを 把握したい場合は UIScreen.referenceDisplayMode StatusDidChangeNotificationを使い 状態が変化した時に通知を 受け取るようにできます そして ステータスが変わるたびに 新ステータスと新しい最大可能ヘッドルームを 取得し レンダリングに関する さらなる決定を行えます リファレンスモードについては 4つのステータスを知っておく必要があります StatusEnabledはリファレンスモードが有効で 期待通りにレンダリング されていることを示します StatusLimitedはリファレンスモードが 有効でも 何らかの理由で リファレンスレスポンスを 実現できない状態を示します このステータスが発生すると リファレンスレスポンスが 損なわれていることを 知らせるために out-of-reference UI通知が行われます StatusNotEnabledはサポートされている リファレンスモードが 有効化されていないことを示します StatusNotSupportedは リファレンスモードが サポートされてないことを示します これらの新しいAPIにより開発者は ディスプレイの現状をより深く理解し EDRコンテンツのレンダリング 方法について十分な情報を 提供できるツールの使用が可能になります 先ほど 現在の EDRヘッドルームを含む 様々なヘッドルームパラメータの クエリー方法を説明しましたが これはコンテンツのトーンマップや クリップの回避に使用可能です しかし独自のトーンマップ アルゴリズムを掘り下げたり 実装したくない場合はどうすべきでしょうか ビデオコンテンツの場合は Appleに実装されている トーンマッピングの活用が可能です Appleのトーンマッピングを有効にする場合は HDR10とHLGの両方の メタデータコンストラクタを 含む CAEDRメタデータ インターフェイスを 使用することで有効にすることが可能です トーンマッピングは すべてのプラットフォームで サポートされているわけでは ありませんがクエリーを使って確認可能です トーンマッピングの サポート状況を確認するには CAEDRMetadata.isAvailableをクエリーします 利用可能な場合は CAEDRMetadataのインスタンス作成が必要です 具体的なコンストラクタについては 後ほど説明しますので今はスキップします EDRメタデータの取得後 レンダリングしているレイヤーに適用します これでレイヤーは提供された メタデータに基づき システムの トーンマッパーで処理されます 先ほど触れた通り EDRメタデータコンストラクタには HDRビデオ形式に特化したものが多数存在します ここで使用しているHLGメタデータ用の コンストラクタはパラメータがありません 次は 1つ目のHDR10コンストラクタです 3つのパラメータがあります マスタリングディスプレイ 最小輝度（単位：ニト） マスタリングディスプレイの 最大輝度（単位：ニト） EDR 1.0の明るさへのコンテンツ マッピングをニトで示す光出力スケール 通常 100ニトに設定します 2つ目のHDR10コンストラクタですが MasterDisplayColour Volume SEIメッセージ ContentLightLevel Information SEIメッセージ opticalOutputScaleのパラメータがあります 先ほど述べたように通常は100ニトに設定します これらのコンストラクタを使い CAEDRMetadataオブジェクトを作成したら AppのCAMetalLayerに設定します これで このレイヤーにレンダリングされた すべてのコンテンツは システムのトーンマッパーで 処理され マッピングを 自分で行わなくてもクリップを回避できます どのコンストラクタを使用するかは コンテンツがどのようにソースされ オーサリングされたかによりますが 通常 コンテンツがHLG色空間の場合 HLGコンストラクタの使用をおすすめします また PQ色空間の場合は HDR10コンストラクタの使用をおすすめします コンテンツにSEIメッセージが すでに添付されている場合 制作者の意図に最も近くなるように 2つ目のHDR10コンストラクタをおすすめします それ以外の場合は最初の コンストラクタの使用をおすすめします リニア色空間を使用している場合 どのコンストラクタを使用するかは コンテンツのオーサリング方法に 完全に依存します Appleのトーンマッピングを使用する場合は HDR10とHLGメタデータに関する 開発者向けドキュメントを 読むことを強くおすすめします では Pixelmatorでの EDRの採用例を見てみましょう EDRのおかげで より鮮明で より忠実な画像レンダリングが 可能になりました 例えば RAW形式の写真を開いて 露出とハイライトを上げると 標準的なSDRディスプレイの ダイナミックレンジでは明るい部分の ディテールを表現できません そこでEDRをオンにすると SDRの白を超えたディテールが 見えるようになります SDRカラーのキャンバスに対して EDRコンテンツがより鮮やかに見えます EDRをオフにすると SDRとEDRの視覚的な違いがより鮮明になります これで本セッションは終了です 今回は iOSとiPadOSに 搭載される 素晴らしい新機能を紹介しました EDRの簡単なおさらいを行い Image I/OでHDR画像を読み込んで Metalテクスチャに変換する ワークフローを紹介し SDRにクリップせずに テクスチャをレンダリングする EDRについて解説しました また ヘッドルームクエリーAPIと EDRレンダリングについて 十分な情報を得て決定する意義と 一般的なHDR形式用に Appleのシステムが提供する トーンマッピングを使う方法を 簡単に説明しました EDRについての理解を深めていただき iOSやiPadOSのAppへの 導入を検討していただければ幸いです HDRやEDRコンテンツ全般の 扱いについてさらに学びたい方は 過去のセッションや今後の セッションの視聴をおすすめします 以上「Exploring EDR on iOS」 セッションへのご参加に感謝します WWDCをお楽しみください ♪