アプリ内でのHDR画像のサポート

♪ ♪

こんにちは！ Jacksonです Davidです 本セッションでは HDRに関する情報や その分野で最近発表された 規格について説明します

そして 新旧のAPIを使ってアプリの中で HDRの画像をどのようにサポートするか 説明します

DavidがHDRパイプラインの 取り扱い方の詳細を説明して 最後に私が HDRコンテンツ表示の 更に高度なトピックを話ます

では HDRの仕組みから始めましょう

現実世界では 人間の目が持つ 適応能力のおかげで 我々は膨大な範囲の光レベルが 知覚できます

対照的に 典型的なスタンダード ダイナミックレンジ つまりSDR表示では 映し出す光の範囲が限られています つまり あるシーンの画像が キャプチャされた場合 幅広い光のレベルがSDRの狭い範囲に 圧縮されてしまうという事です

ハイダイナミックレンジ つまり HDR表示なら はるかに幅広い光レベルを 圧縮せずに表示できます それにより 画像は オリジナルのシーンに近くなり もっと明るく生き生きとします

HDRをキャプチャするのは 何年も前から可能でしたが これまでは キャプチャしたレンジを SDR表示のレンジに 圧縮しなければなりませんでした 今では HDRディスプレイに表示すれば オリジナルに近い状態に シーンをレンダリングできます

例えば 雪の上に陽が昇る このシーンの画像では 現実世界における光レベルの 広いレンジにあたる部分があります SDRディスプレイではシーンの一部しか 正確には表現できません HDRディスプレイでは コントラストを損なわずに もっとシーンを表現できます

つまり HDRのディスプレイなら SDRで最も明るい白よりも 明るくレンダリングできます これは 一般的にヘッドルームと 呼ばれるものです

このパラダイムでは 基準白が SDRの出せる最も明るい白です その点より上はすべて ヘッドルームになります

過去のトークで 紹介した EDR エクステンデッドダイナミックレンジは HDR対応ディスプレイの ヘッドルームでレンダリングできる コンテンツとインタラクトする ためのものでした

EDRパラダイムでは基準白は1.0で ピークがディスプレイの出せる最高値です 今日 紹介するHDR APIはEDRを使って HDRコンテンツのために 更に完成されたパイプラインを実行します

EDRについての詳細は 「Explore HDR Rendering with EDR」のセッションでどうぞ

HDRを実行した例がこちらです 窓の前に座っている人のSDR画像は 本の紙の白が基準白よりも ほんの少しだけ下です それより明るい物はすべて窓のように 切られるかクリップされます

ところが この画像をHDRで表示すると ハイライトの中でもはるかに 詳細を表示する事ができて シーン全体でのコントラストも 確実に保たれます HDRをサポートする事で このような利点があります

HDR画像をサポートする理由ですか？ 構築中のアプリにおいて ユーザー作成のコンテンツや 提供されたコンテンツが重要なら HDRのサポートで その体験が 更に素晴らしいものになります

HDRのサポートは ほぼすべての Appleプラットフォームで利用可能で 我々の導入したAPIで 素晴らしいディスプレイのAppleハードウェアが 十分活用できます

HDRのサポートを考えるべき もう1つの重要な理由は Appleはこれまで 国際標準化機構ISOと協働し 写真技術委員会を通して HDR画像のための新たな技術仕様を 今年発表しました この仕様は TS22028-5と呼ばれ 既存の静止画像フォーマットに その品質を損なう事なく HDRコンテンツをエンコードする 構造を提供します

このISO仕様に従うHDR画像を 「ISO HDR」と呼ぶ事にして HDR動画やキャプチャやディスプレイなどの 他のHDR形式との混同を避けます

先ほどのスケールに戻ると sRGBやDisplay P3を含む 典型的なSDR画像は 黒と白の定義を 0.2及び 80カンデラ毎平方メートルとします 一方 ISO HDRは黒と デフォルトの基準白を それぞれ0.0005及び203と定義しています 203を超えるものはすべてヘッドルームです

新しい画像ファイルの中身とは？

この仕様は HLG つまりハイブリッドログガンマか PQ つまり知覚量子化器を エンコーディングの 伝達関数として要求します これらはSDR画像で使われた ガンマカーブと機能的に類似しています

ISO HDRファイルの原色は BT.2020の原色です これは広色域で これまでは動画でのみ 一般的に使われていました バンディングの問題を避けるために HDR画像は 1コンポーネントにつき 10ビット以上が要求されます つまり HEIFのような形式は HDRをエンコードできますが 従来のJPEGのような形式は 毎コンポーネント8ビットしか サポートしないため 22028-5には対応できません 要求されるメタデータは 従来のICCプロファイルも CICPタグも有効です これらの要求項目を合わせて 新しいISO HDRファイルになります ISO HDRファイルに関係する 追加のメタデータファイルで みなさんに関連のあるオプションが あるかもしれません 参照環境タグは コンテンツの参照条件の 環境条件を定義します

拡散白色輝度は このコンテンツに対し基準白が どの位置にあるかを定義します 先ほどのように デフォルトは203です

シーン参照タグは HLGが伝達カーブの時に使えます 画像コンテンツが 参照対象の シーンかディスプレイであるか どうかを定義します このタグのデフォルト値は Display Referredです

Mastering and Content Color Volumeタグは 既存のHDR動画で一般的なものであり 画像中に表されている 色の範囲の情報を定義します

最後に Content Light Levelタグは 画像におけるシーンの光レベルについて 情報を提供します

ISO HDRについての詳細情報は ISOウェブサイトに出ている 仕様を見てください

ISO HDRに加え 今回 初めてiPhoneで撮影する画像を 最高品質にする方法について みなさんに説明します 2020年以来 何兆ものiPhone画像が 追加データ付きでキャプチャされ SDR画像からHDR表示に 再構築できるようになっています このタイプのHDRを 「Gain Map HDR」と呼びます

今日 Davidと一緒に紹介する 新しいAPIは アプリで このHDR表示にアクセスし 既に写真ライブラリにある あらゆる世代のGain Map HDRから 目を見張るようなHDR画像を 表示するオプションを与えてくれます では この新しいAPIを使って アプリにHDR画像を取り込む 方法を見ていきましょう

これから見るAPIは SwiftUIや UIKitやAppKitで利用可能です SwiftUIとUIKitのAPIを見ましょう この例では URL経由でアクセス可能な ISO HDR画像ファイルがあり それを表示したいと思います そのためには UIImageを作成し HDRを有効にするための 新しいallowedDynamicRange modifierと 一緒にImage Viewに与えるだけです それだけです

同様にUIKit アプリでも 新しいUIImageViewプロパティの 「preferredImageDynamicRange」を セットすれば それで HDRになります

HDRコンテンツを取り扱う ダイナミックレンジプロパティには 3つのオプションが含まれます これらのプロパティは SwiftUI Imageや UIImageやNSImageビューで機能します

highのオプションは HDRコンテンツを表示したい事を システムに知らせて そのコンテンツを現状のディスプレイに マッピングするような重労働は 我々に任せる事になり 表示状態が変化した時の更新も それに含まれます 画像がHDRでない場合は dynamicRangeフラグの無い場合と 同じ体験を取得します HDRでないコンテンツにも安全に これらのオプションが使えます

標準のオプションは HDRのレンダリングを無効にし 代わりに すべてのコンテンツを SDRで表示します つまり SDRレンジの外側にある コンテンツのトーンマッピングです HDR機能のないディスプレイでの 画像の表示方法でもあります

最後のconstrainedHighオプションは HDRにしたいけれど コンテンツの全範囲ではない場合に 使うべきオプションです 一部だけをHDRにしたいとは どういう事でしょうか？ 理由は幾つか考えられます

この例では 多くの画像のサムネイルを持つ Stackビューがあります そのいくつかはHDR画像ですが そうでないものもあります high DynamicRangeオプションを使うと こうなってしまいます 非常に明るいHDRの画像もありますが SDRは暗くなってしまい 非アクティブかもしれません

今度はconstrainedHighオプションを 使ってみましょう HDRコンテンツが使える ヘッドルームを制限する事で フィルムストリップに随分と 一貫性が出ました HDR画像とSDR画像の差は まだ区別がつきますが SDR画像が暗かったり 非アクティブになる問題はありません 特定の画像ビューには constrainedHighか標準を 使いたいもう1つの理由は 時には HDRコンテンツは 非常に明るくなるため アプリのほかの部分から 注意を奪ってしまうかもしれない事です 例えば ここでは小さな画像が 完全にHDRで表示されていて アプリで最も重要な部分のように見えて 重要なコントロールや情報から 注意を奪っています

次に移る前に みなさん恐らく 画像のトーンマッピングに関する オプションが無いと気づいているでしょう OSにトーンマッピングを やらせたくないというような 状況にある場合は もっと低いレベルのAPIを 使う必要がありますが のちほど説明します

覚えておきたい HDRの重要点は HDRデータを劣化させないために クランプしないパイプラインが 必要だという事です 今日 紹介しているAPIはすべて 完全にサポートされていますが 廃止予定のAPIはHDR対応の パイプラインが無いかもしれません 例えば 画像のサイズ変更で 廃止予定のUIGraphicsBeginImage ContextWithOptionsを使うと HDRも広色域の色も失います HDR対応のアプリを作成する場合 これは避けるべきです

サムネイルを作成するのであれば UIKitが iOS 15でのUIImageに サムネイルAPIを導入しました 精密なサイズコントロールが不要なら これはHDRサムネイルを取得するのに お勧めの方法です もっとコントロールが必要だったり iOS 15以前のサポートが必要なら UIKitの提供する UIGraphicsImageRendererです imageRendererFormatを使うと UIKitは 再描画の際に画像のHDR情報を 損なわないようなレンダラーの 構築方法が分かっています

アプリに画像データを取り入れる 一般的な方法の1つを見ましょう

PhotoKitが写真ライブラリにアクセスする インターフェイスをアプリに与えます 私のアプリは メインビューに Photo Pickerを追加して ユーザーが選んだ画像への アクセスを簡単にしてあります PhotosPickerが画像を HDRデータを保持しない形式に トランスコードしようとする かもしれないので 「current」のエンコードポリシーと 汎用の「images」matching typeを 使う事にします

Photos Pickerの仕組みについての詳細は 「PEmbed the Photos picker in your app」の セッションでどうぞ ISO HDR画像では DataRepresentationから UIImageを作成して 追加コード無しで 直接それを どの画像ビューでも使えます

Gain Map HDRもサポートしているなら HDR表現が利用可能な時に 新しいUIImageReaderを使って HDR表現を取得できます このAPIは HDRディスプレイでは デフォルトでHDR表現を戻し HDRディスプレイ以外ではSDR版を戻します

ここまで説明したAPIは 画像がHDRである事に依存せず 画像がHDRである事も知りません 画像ビューにHDRで表示すべきだと 教える時には その画像がHDRなのかどうかは 関係ありませんね ですが 画像がHDRであると確認したがる パイプラインやアプリを 持っている場合もあります

UIKitで isHighDynamicRange プロパティをチェックして コンテンツがISO HDRと 互換性があるかを確認できます

AppKitやCoreGraphicsやCoreImageでは 画像のCGColorSpaceを チェックする必要があります CGColorSpaceUsesITUR_2100TF関数が trueを戻せばISO HDR画像です

HDR画像は 幅広いヘッドルームが 使用できます 例えば 現在のiPhoneが作成する画像は 最大8倍のヘッドルームを使います しかし HDR表示は一部のディスプレイのみで それぞれのディスプレイも違います

iPhone 14はHDRハイライトを 標準白より最大8倍まで 明るく表示できますが 12.9" iPad ProやMacBook Proは 最大16倍の表示ができ Pro XDR Displayは 最大400倍まで表示できます

ほかのAppleディスプレイの大半は 最大2倍のヘッドルームが表示できます ですが これは大半のHDRコンテンツには 不十分かもしれません HDR機能がサポートされている 外部ディスプレイもあります 利用可能なこれらのディスプレイを 完全に網羅するリストはありませんが 自分のアプリが現在表示されている ディスプレイの 機能を確かめるためのAPIがあります

iOSとiPad OSでは potentialEDRHeadroomを macOSではmaximumPotentialExtendedDynamic RangeColorComponentValueをクエリして アプリが表示されているディスプレイの 機能を確認できます

更に高度なトピックに移る前に HDR表示が相応しいのは どのような場合かを考えましょう 繰り返しますが HDRは見た目が良く 画像表示がアプリの主要な要素なら HDRのサポートを取り入れる事を 考えべきだと思います ですが それが邪魔になる事もあります ですから HDRが与える パワーが必要でないと考えるなら constrainedHighか標準オプションを 使うといいでしょう

では 復習です ここまで見たのは ISO HDR画像の識別の方法と HDR画像のディスプレイの方法と 写真ライブラリのISO HDRと Gain Map HDRへのアクセス方法と ディスプレイがHDRであるかどうか 確かめる方法です では これからDavidが HDR画像の読み込みや書き込み そして取り扱い方について話します ありがとう Jackson HDR画像を扱う際には アプリがサポートしている 一般的な作業がいくつかあります

ファイルやデータからメモリへ ISO HDRやGain Map HDR画像を読み込み HDRコンテンツを保持しながら メモリで画像を修正し HDRを失わずに1つの画像クラスから 別のクラスに変換し 最後に HDR画像を ISO HDRファイルに書き込みます 関数型HDR画像パイプラインの 極めて重要なプロパティは 画像オブジェクトが関連する 色空間を持つという事です 例えば CGImageオブジェクトも CIImageオブジェクトも このためにCGColorSpace APIを使います 画像は様々なサポート対象の 色空間を持てますが ISO HDR画像が持つのはCGColorSpaceで ITUR 2100 HLGかPQのどちらかです これを念頭に ISO HDR画像の 読み込みから始めましょう UIImageとNSImageは自動的にISO HDR画像の 読み込みをサポートするようになりました Appleのカラーマネジメントインフラ ColorSyncが HDR ICCプロファイルを扱い ディスプレイに適した 画像オブジェクトを付与します

Gain Map HDR画像を読む時は HDRを好むUIImageReader構造を 作成する事で HDR表現をリクエストできます ですが この新ビヘイビアは Gain Map HDR画像にのみ影響します NSImageやUIImageと同じように Core Imageも自動的にISO HDRファイルの 読み込みをサポートします それには CIImage contentsOfURL APIを使えばいいだけです 結果として生じるCIImageオブジェクトは ファイルの色空間を Core Imageの拡張された 作業空間領域へと変えるための 正しいレシピを自動的に含みます 画像オブジェクトのレシピを検査するには コードをデバッグする時に XcodeのQuick Look機能を使います この例では 画像がPQ ISO HDR色空間から 変換されている事が Quick Lookのポップオーバーに出ています

また コードで .colorspaceプロパティを取得し ファイルの色空間を検査できます

これは sRGBやDisplay P3のような SDR色空間の場合も HDR色空間の場合もあります

CoreGraphics APIを使いたい場合は 新しいDecodeRequestキーを DecodeToHDRにセットし CGImageSourceCreateImageAtIndexを使って 同等のビヘイビアを取得できます

つい先ほどJacksonが HDR画像を SDRに制限したい理由を説明しました

同様に Core Imageを使うアプリは 自動的なHDRサポートを無視し 画像がSDRにトーンマップされていることを 確認した方がいいでしょう 特徴抽出などの特定のシナリオで HDRの使用を避けたい場合には これは便利な対処法です そのためには CIImage作成時に toneMapHDRtoSDRのオプションを 付与すればいいだけです この場合 戻されたCIImageオブジェクトには ほかのどの作業よりも先に HDRソースをSDRのレンジに トーンマップするための レシピのステップが含まれます

このオプションが効果的なのは 画像がHDR色空間を持っている場合のみです

その結果のCIImageは 画像ビューが dynamicRange.standardオプションを 使うように特定されているのと 同じ見た目になります また これはdecodeRequestを decodeToSDRにセットしてCGImage SourceCreateImageAtIndexを使うのと 同等のビヘイビアを有します

従来 Gain Map HDR画像は 写真アプリでフルダイナミックレンジの 表示をするものでしたが Core ImageやImageIOなどのSDR表現しか APIには使えませんでした これから説明する新しいAPIでは アプリがGain Map HDR画像の最大レンジに アクセスできるようになります

非常に簡単に使えるAPIです CIImageを初期化する時に expandToHDRオプションを付与するだけです

この場合 戻されたCIImageオブジェクトには 元画像とGain Mapを組み合わせて HDR画像を作成するレシピが 含まれています

画像の.colorspaceプロパティは 写真ライブラリが サポートとなる追加の Gain Mapデータを含む場合 HDR色空間になります

このビヘイビアはdecodeRequestキーを decodeToHDRにセットして CGImageSourceCreateImageAtIndexを 使うのと同等です

これらのオプションは RAWファイルでも使えるもので 今からその詳細を話します

iPhoneのProRAW画像や カメラのRAW画像は フレキシブルな画像フォーマットで 撮影者にクリエイティブコントロールが 著しく与えられます シーンの一部をHDRヘッドルームに レンダリングするのもその1つです RAW形式の多くは 非常に幅広い ダイナミックレンジを含んでいて 無拘束な形式になるよう 処理されなければなりません その仕組みを説明します まず アプリが表示したいのが単に RAWファイルのための デフォルトのSDRの外見であれば いつも通り URLから画像を作成します アプリが表示したいのが デフォルトの HDRレンダリングの外見なら 新しいexpandToHDRを 追加すればいいだけです

ですが アプリがRAWの機能性を すべて開放したい場合は コードでURLから CIRAWFilterを作成します

そのフィルタに 単に出力画像を要求すれば デフォルトの外見をした CIImageを取得します ですが このAPIの主な利点は フィルタが簡単に修正できる事です

各CIRAWFilterインスタンスには 出力画像を修正するために アプリが変更できるプロパティが いくつかあります これらのプロパティの詳細は 「Capture and process ProRAW images」の セッションで学べますが その中でHDRに関連する1つを ここで見てみましょう

RAW画像のダイナミックレンジの幅は 0から1のどの値にでも調整できます extendedDynamicRangeAmountプロパティは Jacksonが言ったように viewDynamicRangeと類似しています

このプロパティのデフォルト値は0で 出力画像がSDRである事を示しています このプロパティの最大値は1で 出力画像はファイルにある ヘッドルームの大半を 使うはずだという事を示しています 以上が ISO HDR画像を読む 様々な方法についてでした 次は HDR画像を修正する 奨励方法について話しましょう

Core ImageはHDR画像を扱うための パワフルで柔軟性のある APIを提供してくれて そこにはHDRをサポートする 150以上のビルトインフィルタが 含まれています

これらのフィルタはすべて HDRコンテンツを含む画像を 生成または処理できます

これらすべてのフィルタが機能するのは Core Imageが作業する色空間は クランプされず線形なので RGB値が0から1の範囲外まで広がるからです

アプリの開発中に 与えられたフィルタが HDRをサポートするかチェックできます そのためには フィルタの インスタンスを作成し フィルタの属性に そのカテゴリを要求し その配列がHDRのカテゴリを 含んでいるかチェックします 是非 「Display EDR content with Core Image, Metal, and SwiftUI」の セッションを見て ビルトインCIフィルタやカスタムの CIカーネルの詳細を学んでください 次は HDR画像をISO HDRファイルに 書き込む事についてです アプリは メモリの画像オブジェクトを しばしば新しいファイル表現に 書き込もうとします 従来では UIImageやjpegData そしてpngDataのAPIを使用し 8-bit精度のSDR画像を保存していました

今年新たに UIImageは自動的に ISO HDR画像を書き込むようになり オブジェクトにHDRコンテンツが 含まれる時には 16-bit PNG あるいは 10-bit HEIF形式を使って書き込みます また 元画像が Gain Map HDR画像である場合も ISO HDRに変換します

同様に Core Imageも HDR PNGファイルの書き込みが可能で それは HDR色空間を特定し RGBA16フォーマットを要求する writePNGRepresentationOfImageを 呼び出せばいいのです

Core ImageもHDR TIFFファイルが書け それは HDR色空間を特定し writeTIFFRepresentationOfImageを呼んで RGBA16フォーマットを要求します PNGもTIFFも可逆圧縮を使うので 元のファイルサイズより かなり大きくなります

その結果 一番お勧めなのは HEIFファイルを書くことで writeHEIF10RepresentationOfImageを使い HDR色空間を特定します

場合によっては フレームワークを 別のものに変えたり 色空間を別のものに変えたり しなければならないでしょう

画像クラス間での変換プロセスは UIImageやCIImageやCGImageやIOSurface そしてCVPixelBufferでも ほぼ同じです ですが HDRパイプラインでは 気をつけたい事があります

まずは IOSurfaceかCVPixelBuffer オブジェクトへの変換です この画像タイプは非常に便利で 例えばCALayerのコンテンツとして 使えます また クロマサブサンプリングされた バイプラナ画像も保持できるので 非常にメモリ効率が良いです CVPixelBufferを使う前に ISO HDRと互換性のあるコンテンツだと 必ず宣言しましょう まずは 10-bitバイプラナ フルレンジのような 適切なフォーマットの ピクセルバッファを作成します

ベストパフォーマンスのために IOSurfacePropertiesKeyを提供して バッファがsurface-backedである事を 必ず特定しましょう

次に 必ずCVPixelBuffer に アタッチメントを加えて ISO HDR対応の色空間プロパティを 含んでいるとシステムに教えます CVPixelBufferができれば CIImageへの変換は簡単です CIImage withCVPixelBuffer APIを 呼び出すだけでいいのです また バッファへのレンダリングに CIContextを使えば CIImageをCVPixelBufferに 変換できます

今度は アプリがCore Imageと CGImageRefのAPIとの間で 変換を行いたいという場合が あるかもしれません

この変換において HDRコンテンツを 維持したい場合は HDR色空間を選んで RGBA16かRGBAh形式のような ディープピクセル形式を要求します

今年新たに CoreImageに RGB10形式が加えられ デープながらもメモリ使用量は半分です

CIImageをCGImageに変換するのが 非常に便利なのは CGImageは幅広い種類のAPIで サポートされているからです ですが ユーザーインタラクティブな レンダリングのベストパフォーマンスには これは奨励できません 最速のパフォーマンスにはCoreImageが 直接MTKViewにレンダリングするか PixelBuffer経由でCALayerに レンダリングするのが良いでしょう

そのCALayerですが 今度はJacksonに 更に複雑なワークフローに必要な Lower-Level APIについて 話してもらいましょう ありがとう David！ ベストなレンダリングパフォーマンスや コンテンツをアプリに合成する方法への コントロールを増やしたい場合に CALayerはパワフルなツールです CALayerでHDRレンダリングを 有効にするには wantsExtendedDynamicRangeContent プロパティがセットできます これは CAMetalLayersが ディスプレイのヘッドルームでの コンテンツ表示を有効にするために 使ったプロパティと似ています

この2つのメソッドの主な違いは CALayerプロパティはレイヤーコンテンツの トーンマッピングを有効にしますが CAMetalLayerはしません 実際には どういう事でしょうか？

この画像とプロットはコンテンツに 10倍のヘッドルームがあると示しています 最低でも10倍のヘッドルームを持って ディスプレイにレンダリングされると 両レイヤーのビヘイビアは同じです では ディスプレイのヘッドルームが ５倍だけだと想定しましょう

CAMetalLayerの場合 5倍より上の画像データは ディスプレイが表示できる範囲に クランプされて 画像に目立った不連続性が生じています

CALayerでは 不連続性を避けるために 画像がトーンマップされます まったく同じトーンマッピングの アルゴリズムの使用も その画像で使われる変換曲線によって 変わってきます これらのアルゴリズムに関する詳細は HLGおよびPQに関するITU規格を 参照してください

CALayerではHDRコンテンツを画面に 素早く簡単に貼る事ができる一方 CAMetalLayerでは自分のトーンマッピング パイプラインを自由に作成できます CALayerを直接使って HDRをレンダリングするには これらの利用可能なクラスを どれか使わなければなりません CGImageかCVPixelBufferか IOSurfaceのオブジェクトで ISO HDRとして適切に タグ付けされているものは CALayerによってレンダリングと トーンマッピングが行われます 直接CALayerを使いたいけれど これらのクラスのどれも使っていない場合は Davidが説明したメソッドの どれかを使って変換できます

HDRワークフローでは 正しいピクセル形式を使う事が大切です こちらのピクセル形式は HDRデータの取り扱いにも安全です 16および32-bit floatフォーマットは 常にHDRをサポートします 16-bit integerフォーマットも 適切なファイル形式やコンテンツでは HDRコンテンツをサポートします そして メモリやファイルサイズが 重要な場合は 10-bitピクセル形式が使えます 圧縮されたISO HDR画像の大半は これがデフォルトのビットデプスです また CoreGraphicsのフラグも HDRコンテンツに使えるCGImageを 作成する時に使えます 前出のリストのように 使えるのは floatとhalf floatと 16-bit integerと10-bit RGBです

このような新機能を紹介する中で 重要な最後のトピックは 下位互換性です HDR画像を扱う際に 古いバージョンのiOSやmacOSを どうサポートすれば良いでしょう？ ISO HDR画像には CoreImageは toneMapHDRtoSDRオプションを提供し HDRをSDRに変換します CoreGraphics CGContextを使って レンダリングする時も同様に SDR CGColorspaceをターゲットにすれば 画像はその空間に トーンマッピングされます Gain Map HDRには バージョンチェックを使用して 新しいexpandToHDRオプションが 使用されていれば制御します これらのオプションが除外された場合 常にファイルのSDRバージョンが HDRバージョンの代わりにロードされます まとめると HDR画像の読み書き および表示のための新しいAPIを紹介し Gain Map HDR表現への アクセスの仕方を説明し 完全HDR対応のパイプラインで 作業するためのAPIを紹介しました

みなさんがHDRで何を生み出すか とても楽しみです！ ご視聴ありがとうございました！ ♪ ♪