ウルトラ HDR 画像形式 v1.1

はじめに

このドキュメントでは、対数範囲ゲインマップ画像を JPEG 画像ファイルにエンコードする新しいファイル形式の動作を定義します。新しい形式をサポートしていないレガシー リーダーは、画像ファイルから従来の低ダイナミック レンジ画像を読み取り、表示します。この形式をサポートするリーダーは、プライマリ画像とゲインマップを組み合わせて、対応するディスプレイに高ダイナミック レンジ画像をレンダリングします。

このドキュメントの残りの部分では、この形式を使用するために必要なプロセスのメソッドについて説明します。この形式に準拠する画像のライフサイクルは、大まかに次のとおりです。

1. エンコード

   1. 獲得地図の生成
   2. 地図の圧縮率を高める
   3. マップコンテナの生成を獲得する

2. デコード

図 1. ファイル レイアウトと関連メタデータの例。

目的

このファイル形式の目的は、ディスプレイ手法と組み合わせて最適な HDR レンダリングを生成するために使用できる追加情報を SDR 画像ファイルにエンコードすることです。

これを実用的にするには、ファイル形式に次の要件を満たす必要があります。

• 下位互換性を確保して、単純な視聴者には従来の SDR 画像が表示されるようにする。
• 余分なスペースを占有しません。

また、表示手法は次の要件を満たす必要があります。

• デコードに負荷の高い処理は不要です。
• ディスプレイの HDR ホワイト ポイントと SDR ホワイト ポイントの比率に適応できる。この比率は、デバイス間で大きく異なる場合や、単一のデバイスで時間的に大きく異なる場合もあります。

最後に、この手法は、次のいずれも行うことなく、上記のすべてのアクションを実行できる必要があります。

• ハイライトの切り抜き。
• シャドウの圧縮。
• ローカル コントラストの変更または圧縮。
• 相対的な色調の関係（シーン内のオブジェクト間）を変更する。

依存関係

この仕様の引用規格は次のとおりです。

• Adobe XMP Specification Part 3: Storage in Files
• ISO 16684-1:2019 XMP Specification Part 1
• ISO/IEC 14496-12 ISO ベース メディア ファイル形式
• T.81（09/92）Digital compression and coding of continuous-tone still images（連続階調静止画像のディジタル圧縮および符号処理）
• CIPA DC-x 007-2009 Multi-Picture Format のホワイトペーパー

定義

• SDR ディスプレイ

  • HDR コンテンツの表示用に設計されていない従来のディスプレイ。これらのディスプレイは通常、約 400 cd/m² 以下の公称ピーク輝度を生成します。

• HDR ディスプレイ

  • HDR コンテンツ用に設計されたディスプレイ。これらのディスプレイは通常、SDR ディスプレイよりも高い公称ピーク輝度（通常は 800 cd/m² 以上）を実現し、コントラスト比も SDR ディスプレイよりも優れています。

• メイン画像

  • 副次的なメディア ファイルが付加された GContainer ファイル内の画像の最初のインスタンス。メイン画像には、ファイル コンテナ内の後続のセカンダリ メディア アイテム ファイルの順序とプロパティを定義する GContainer XMP メタデータが含まれます。

• セカンダリ画像

  • GContainer ファイル内のメイン画像に追加される後続のメディア アイテム ファイル。

• 範囲圧縮

  • 写真では、現実のシーンには SDR ディスプレイで表現できるよりも広いダイナミック レンジが存在することがよくあります。画像のダイナミック レンジを縮小するには、ローカル トーン マッピングとも呼ばれる範囲圧縮などのオペレーションが必要です。この縮小では、局所的なコントラストを可能な限り維持しながら、ハイライトやシャドウを圧迫しないようにする必要があります。画像内の大きな輝度エッジのサイズを小さくして全体的なコントラストを高め、細部の小さな輝度エッジのサイズを維持します。実装方法はさまざまですが、このような操作は、ほとんどの最新デジタルカメラで標準となっています。

• SDR ホワイト ポイント

  • 特定の時点でディスプレイ上の SDR コンテンツの最大リニア輝度。

• HDR ホワイト ポイント

  • 特定の時点でディスプレイ上の HDR コンテンツの最大リニア輝度。この値は通常、SDR ホワイト ポイントよりも大きくなります。

• ブースト

  • HDR ホワイト ポイントを SDR ホワイト ポイントで割った値。

• コンテンツの最大ブースト（式では max_content_boost）

  • この値により、コンテンツ クリエイターは、HDR ディスプレイに表示される画像の明るさを SDR レンダリングと比較して制限できます。
  • この値は、特定の画像の定数です。たとえば、値が 4 の場合、任意のピクセルについて、表示される HDR レンダリングの線形輝度は、SDR レンダリングの線形輝度の 4 倍以下である必要があります。実際には、シーンの明るい部分を最大 4 倍明るく表示できます。
  • 実際には、この値は通常 1.0 より大きくなります。
  • 常に [コンテンツ ブーストの最小値] 以上である必要があります。

• コンテンツの最低ブースト（式では min_content_boost）

  • この値により、コンテンツ クリエイターは、HDR ディスプレイに表示される画像が SDR レンダリングと比較してどれくらい暗くなるかを制限できます。この値は、特定の画像の定数です。
  • たとえば、値が 0.5 の場合、任意のピクセルについて、表示される HDR レンダリングのリニア輝度は、SDR レンダリングのリニア輝度の 0.5 倍（少なくとも）にする必要があります。
  • 実際には、この値は通常 1.0 以下になります。
  • 常に [コンテンツの最大ブースト] 以下にする必要があります。

• ディスプレイの最大ブースト（式では max_display_boost）

  • 特定の時点でディスプレイがサポートする最大ブースト。この値は、デバイスの設定や、周囲の明るさ、画面上の明るいピクセル数などの要因によって、時間の経過とともに変化することがあります。
  • たとえば、この値が 4.0 の場合、ディスプレイは SDR ホワイトポイントの最大 4 倍の明るさのピクセルを表示できます。ディスプレイは常に SDR ホワイトと同じ明るさ以上の HDR ホワイトを表示できるため、この値は常に 1.0 以上になります。

• ディスプレイ ブースト

  • コンテンツの最大ブーストとディスプレイの最大ブーストのどちらか小さい方に等しい。この値は常に 1.0 より大きい値です。
  • たとえば、最大コンテンツ ブーストが 4.0 で、最大ディスプレイ ブーストが 3.0 の場合、ディスプレイ ブーストは 3.0 になります。ディスプレイ機能が制限要因であるため、ピクセルは SDR よりも最大 3 倍明るく表示されます。
  • 別の例として、コンテンツ ブーストの最大値が 4.0、ディスプレイ ブーストの最大値が 5.0 の場合、ディスプレイ ブーストは 4.0 になります。コンテンツの意図が制限要因となるため、ピクセルは SDR よりも最大 4 倍明るく表示されます。

• ターゲット HDR レンダリング

  • コンテンツ クリエイターが理想とする HDR レンダリング。

• 適応型 HDR レンダリング

  • 現在のディスプレイのブーストに合わせてターゲット HDR レンダリングを適応させた後、ディスプレイに表示される最終的な HDR レンダリング。

• ゲインマップ（式では recovery(x, y)）

  • ターゲット HDR レンダリングを生成するために、SDR レンダリングで各ピクセルをどの程度明るくするかを示すマップ。この地図は、単一チャンネルまたはマルチチャンネルにできます。マルチチャンネル マップでは、赤、緑、青などのカラーチャネルごとに個別のゲインが示されます。このドキュメントでは、単一チャネル マップのケースについて説明します。

• clamp(x, a, b)

  • 値 x を範囲 [a, b] にクランプします。

• exp2(x)

  • 2 を底とする指数演算（2^x）。

• floor(x)

  • x 以下の最も近い整数を返します。

• log2(x)

  • 2 を底とする対数 log₂(x)

• pow(b, x)

  • 指数。b^x。

• XMP

  • 拡張メタデータ プラットフォーム。メタデータを画像コンテナにエンコードする方法を指定する標準。ISO 16684-1:2011(E) XMP Specification Part 1 で定義されています。

• マルチ画像形式

  • マルチピクチャ形式は、複数の JPEG エンコード画像を 1 つの JPEG ファイルに保存するために、カメラおよびイメージング プロダクト協会（CIPA）によって開発された手法です。
  • 詳細については、関連する依存関係の White Paper of CIPA DC-x 007-2009 Multi-Picture Format をご覧ください。

• GContainer

  • GContainer は、複数の画像を 1 つのイメージ コンテナに保存する方法です。1 つの画像がメイン画像と見なされます。追加の画像は、代替バージョンまたは補助画像と見なされます。XMP メタデータは、追加イメージの存在と意味を伝達するために使用されます。詳細については、GContainer の詳細をご覧ください。

エンコード

このセクションでは、準拠する JPEG ファイルをエンコードする方法について説明します。JPEG 形式の詳細については、依存関係セクションの T.81（09/92）Digital compression and coding of continuous-tone still images をご覧ください。

獲得地図の生成

カメラ画像処理パイプラインでは、通常、範囲圧縮オペレーションを実行して、高ダイナミック レンジの輝度データを従来の SDR ディスプレイの低い範囲に圧縮します。ゲインマップは、元の高ダイナミック レンジの輝度データを復元するのに十分なデータを保存するメカニズムを提供します。

このセクションの次の計算では、浮動小数点演算を前提としています。

次の関数は SDR 画像を記述します。

• SDR'(x, y) は、3 チャンネルの非線形（通常はガンマ エンコード）プライマリ イメージです。
• SDR(x, y) は、プライマリ画像の色空間を線形に変換して得られる、3 チャンネルのプライマリ画像の線形バージョンです。たとえば、sRGB 転送関数を持つ色空間から、sRGB 原色を保持する線形色空間に移行します。

Ysdr(x, y) 関数は 0.0～1.0 の範囲で定義され、標準ダイナミック レンジのプライマリ画像の線形輝度です。

Ysdr(x, y) = primary_color_profile_to_luminance(SDR(x, y))

HDR 画像にも同様の定義があります。

• HDR'(x, y) は、3 チャンネルの非線形（PQ または HLG でエンコードされた画像）です。
• HDR(x, y) は、3 チャンネルの線形 HDR 画像です。

Yhdr(x, y) は、HDR 画像の特定の点の輝度です。

Yhdr(x, y) = primary_color_profile_to_luminance(HDR(x, y))

Yhdr(x, y) は、0.0 ～最大コンテンツ ブーストの範囲で定義されます。

SDR 画像と HDR 画像の解像度は同じである必要があります。SDR 画像のカラー プロファイルによって、HDR 画像の色空間が定義されます。

たとえば、SDR プライマリ イメージに Display-P3 カラー プロファイルがある場合、HDR 画像はそのプロファイルのプライマリ カラーを基準に定義されます。つまり、HDR 画像には Display-P3 プライマリも含まれています。

ゲインマップは、目的の HDR 画像輝度 Yhdr(x, y) と標準範囲輝度画像 Ysdr(x, y) を含む 2 つのリニア画像から計算されます。

pixel_gain(x, y) 関数は、Yhdr(x, y) 関数と Ysdr(x, y) 関数の比率として定義されます。

pixel_gain(x, y) = (Yhdr(x, y) + offset_hdr) / (Ysdr(x, y) + offset_sdr)

Ysdr(x, y) と offset_sdr の両方がゼロの場合の pixel_gain(x, y) 関数の動作は実装定義です。

たとえば、実装では pixel_gain(x, y) を 1.0 として定義することで、Ysdr(x, y) と offset_sdr の両方がゼロの場合を処理できます。また、実装ではゼロ以外の offset_sdr を使用して、このシナリオを回避することもできます。

実装では、offset_sdr と offset_hdr の値が選択されることがあります。

ゲインマップは、最大コンテンツ ブーストと最小コンテンツ ブーストに対して、対数空間で pixel_gain(x, y) をエンコードするスカラー関数です。

map_min_log2 = log2(min_content_boost)
map_max_log2 = log2(max_content_boost)

log_recovery(x, y) = (log2(pixel_gain(x, y)) - map_min_log2)
                   / (map_max_log2 - map_min_log2)
clamped_recovery(x, y) = clamp(log_recovery(x, y), 0.0, 1.0)
recovery(x, y) = pow(clamped_recovery(x, y), map_gamma)

log2(0) は未定義であるため、pixel_gain(x, y) がゼロの場合の recovery(x, y) 関数の動作は実装定義です。

map_gamma は浮動小数点数で、0.0 より大きく、実装によって選択されます。

コンテンツ ブーストの最大値と最小のコンテンツ ブーストの値は実装定義で、コンテンツ作成者が任意に決定できます。コンテンツの最大ブーストは 1.0 以上である必要があります。コンテンツの最低ブーストは (0.0, 1.0] の範囲内にする必要があります。

recovery(x, y) の値は [0.0, 1.0] の範囲に制限されます。

ゲインマップはセカンダリ画像 JPEG に保存されるため、8 ビットの符号なし整数値（[0, 255] の範囲）を使用してエンコードする必要があります。各値は recovery(x, y) 値を表し、セカンダリ イメージの 1 ピクセルに格納されます。

8 ビットの符号なし整数ストレージの場合、エンコードされた値は次のように定義されます。

encoded_recovery(x, y) = floor(recovery(x, y) * 255.0 + 0.5)

エンコード関数の計算は浮動小数点数で行われ、最後に、指定されたように丸められて 8 ビットの符号なし整数結果に変換されます。

このエンコードでは、recovery(x, y) 値が 0.0 ～ 1.0 の 8 ビットの符号なし整数で表されます。エンコードされたゲインマップは、セカンダリ画像アイテムに JPEG として保存する必要があります。実装では、JPEG エンコード時に使用する圧縮量を選択します。

ゲインマップがセカンダリ画像に保存された後、MPF と GContainer XMP メタデータを含むプライマリ画像に追加されます。メイン画像の GContainer ディレクトリに、ゲインマップ画像のアイテムが含まれている必要があります。

保存されたゲインマップの解像度は実装で定義され、プライマリ画像の解像度と異なる場合があります。ゲインマップがストレージ用プライマリ イメージとは異なる解像度にスケーリングされている場合、サンプリング方法はバイリニア以上で、実装で定義する必要があります。

ゲインマップの向きは、メイン画像の向きと一致する必要があります。存在する場合、EXIF のように、保存されているゲインマップ画像内の向きのメタデータは使用されません。

存在する場合、ゲインマップのカラー プロファイルは使用されません。

マップコンテナを取得する

カラープロファイル

画像のカラー プロファイルは、プライマリ画像の ICC プロファイルで指定する必要があります。

XMP 属性

メインの画像には、HDR ゲインマップ形式の追加のセマンティック情報を含む 2 つ以上の画像を定義する XMP メタデータが含まれています。

次のサブセクションでは、この形式に固有の詳細について説明します。GContainer への一般的な準拠に関する追加情報については、GContainer の詳細のセクションをご覧ください。

次の表に示す属性値は、指定された XMP 基本値型の XMP 単純値として保存されます。

アイテムのセマンティック値

Item:Semantic プロパティは、コンテナのディレクトリ内にある各メディア アイテムのアプリケーション固有の意味を定義します。

HDR ゲインマップ メタデータ

ゲインマップ メタデータは、ゲインマップを解釈して適用し、プライマリ画像の HDR 表現を生成する方法に関する情報をエンコードします。

ゲインマップ メタデータ XMP 拡張機能の XMP 名前空間 URI は http://ns.adobe.com/hdr-gain-map/1.0/ です。デフォルトの名前空間の接頭辞は hdrgm です。

このメタデータは、ゲインマップ画像の XMP パケットに保存されます。ゲインマップ画像の XMP の rdf:Description には、次のプロパティが表示される必要があります。

ゲインマップの XMP の例

有効なゲインマップ XMP パケットの次の例には、概要セクションで説明したサンプルファイルから取得したメタデータが含まれています。

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.5.0">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about=""
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0"
     hdrgm:GainMapMin="-0.57609993"
     hdrgm:GainMapMax="4.7090998"
     hdrgm:Gamma="1"
     hdrgm:OffsetSDR="0.015625"
     hdrgm:OffsetHDR="0.015625"
     hdrgm:HDRCapacityMin="0"
     hdrgm:HDRCapacityMax="4.7090998"
     hdrgm:BaseRenditionIsHDR="False"/>
  </rdf:RDF>
</x:xmpmeta>

ゲインマップの MPF ストレージ

ゲインマップ画像は、依存関係セクションで参照されている CIPA DC-x 007-2009 マルチ画像形式で定義されているように、追加の画像として保存する必要があります。

Decode

このセクションでは、準拠している JPEG ファイルからゲインマップをデコードする方法について説明します。

フォーマットのシグナル

この形式に準拠した JPEG ファイルは、プライマリ画像の XMP パケットに hdrgm:Version="1.0" が存在することで識別できます。ここで、hdrgm は名前空間 URI http://ns.adobe.com/hdr-gain-map/1.0/ です。

ゲインマップの画像を見つける

画像の解析とデコードの詳細については、次のGContainer の詳細をご覧ください。XMP rdf:Directory 内の「GainMap」セマンティック アイテムは、ゲインマップ画像の場所を通知するために使用されます。あるいは、MPF インデックス IFD とスキャン画像の XMP を使用して、ゲインマップの位置が決定されます。

無効なメタデータを処理する

必須フィールドが存在しない場合、またはフィールドに無効な値が含まれている場合、メタデータは無効と見なされます。指定された型に解析できないか、想定範囲外であるため、値が無効な可能性があります。

無効なメタデータが検出された場合は、ゲインマップは無視され、SDR 画像が表示されます。

ディスプレイ

HDR ゲインマップ形式でエンコードされたファイルは、従来の SDR ディスプレイまたは高輝度出力に対応した HDR ディスプレイのいずれかでレンダリングできます。

ゲインマップを使用して、適応 HDR レンダリングを作成します。

このセクションの次の計算では、浮動小数点演算を前提としています。

encoded_recovery(x, y) は、ゲインマップ画像の単一チャネルの 8 ビット符号なし整数値です。

ゲインマップの解像度がプライマリ画像と異なる場合、encoded_recovery(x, y) は、プライマリ画像の幅と高さの範囲で、x と y のゲインマップ画像のフィルタリングされたサンプリングによって決定されます。フィルタリング方法はバイリニア以上で、実装で定義されます。

map_gamma は hdrgm:Gamma メタデータ フィールドによって決定されます。

log_recovery(x, y) は、対数空間における正規化された浮動小数点ピクセル ゲインです。

recovery(x, y) = encoded_recovery(x, y) / 255.0
log_recovery(x, y) = pow(recovery(x, y), 1.0 / map_gamma)

最大ディスプレイ ブーストは、現在の HDR ホワイト ポイントと現在の SDR ホワイト ポイントの比率として定義されるスカラー浮動小数点値です。この値はディスプレイ システムから提供され、時間の経過とともに変化する可能性があります。

hdr_capacity_max は hdrgm:HDRCapacityMax メタデータ フィールドによって決定されます。hdr_capacity_min は hdrgm:HDRCapacityMin メタデータ フィールドによって決定されます。

hdrgm:BaseRenditionIsHDR が「False」の場合、weight_factor は次のように決定されます。

unclamped_weight_factor = (log2(max_display_boost) - hdr_capacity_min)
                        / (hdr_capacity_max - hdr_capacity_min)
weight_factor = clamp(unclamped_weight_factor, 0.0, 1.0)

hdrgm:BaseRenditionIsHDR が「True」の場合、2 番目の式は次のように変わります。

weight_factor = 1.0 - clamp(unclamped_weight_factor, 0.0, 1.0)

gain_map_max は hdrgm:GainMapMax メタデータ フィールドによって決定されます。gain_map_min は、hdrgm:GainMapMin メタデータ フィールドによって決まります。offset_sdr は、hdrgm:OffsetSDR メタデータ フィールドによって決まります。offset_hdr は hdrgm:OffsetHDR メタデータ フィールドによって決定されます。

線形適応 HDR レンダリングは次のように計算できます。

log_boost(x, y) = gain_map_min * (1.0f - log_recovery(x, y))
                + gain_map_max * log_recovery(x, y)
HDR(x, y) = (SDR(x, y) + offset_sdr) * exp2(log_boost(x, y) * weight_factor)
          - offset_hdr

必要に応じて、実装で HDR(x, y) に変換を適用し、ディスプレイで想定される空間にデータを配置できます。このような変換は色彩的に正確である必要があります。

GContainer の詳細

このセクションでは、この形式が GContainer XML メタデータに準拠するための追加要件を指定します。メタデータは ISO 166841:2011(E) XMP Specification Part 1 に従ってシリアル化され、Adobe XMP Specification Part 3 Storage in Files の説明に従ってプライマリ画像ファイルに埋め込まれます。プライマリ画像ファイルには、RDF/XML 形式の次のアイテムが含まれています。

XMP パケットの要件

XMP パケットには、名前空間 URI http://ns.adobe.com/hdr-gain-map/1.0/ を介したゲインマップ メタデータの XMP 拡張機能が含まれます。デフォルトの名前空間の接頭辞は hdrgm です。

XMP パケットで hdrgm:Version="1.0" を定義する必要があります。

コンテナ要素

GContainer XMP 拡張機能の XMP 名前空間は http://ns.google.com/photos/1.0/container/ です。デフォルトの名前空間プレフィックスは Container です。

メイン画像の XMP メタデータには、ファイル コンテナ内の後続のメディア ファイルの順序とプロパティを定義する Container:Directory 要素が含まれています。コンテナ内の各ファイルには、Container:Directory 内に対応するメディア アイテムがあります。メディア アイテムには、ファイル コンテナ内の位置と、結合された各ファイルの基本プロパティが記述されます。

コンテナ要素は、メイン画像の XMP メタデータにエンコードされ、コンテナ内のメディア アイテムのディレクトリを定義します。メディア アイテムは、ディレクトリ内のメディア アイテム要素と同じ順序で、隙間なくコンテナ ファイル内に配置されている必要があります。

ディレクトリに含めることができる「プライマリ」画像アイテムは 1 つだけです。これはディレクトリ内の最初のアイテムにする必要があります。

アイテム要素

アイテム要素には、アプリケーションで各メディア アイテムがどのように使用されるかが記述されます。

GContainer Item XMP 拡張機能の XMP 名前空間 URI は http://ns.google.com/photos/1.0/container/item/ です。デフォルトの名前空間プレフィックスは Item です。

最初のメディア アイテムはメイン画像にする必要があります。Item:Semantic = "Primary" と、アイテムの MIME タイプ値に記載されている Item:Mime を指定する必要があります。

メイン画像アイテムの長さは、ファイル コンテナの先頭から順に、MIME タイプに基づきメイン画像を解析することで決定されます。

メディア アイテムには、メディア アイテムの終了部分と後続のメディア アイテムの開始部分の間にある追加のパディングを指定する Item:Padding 属性を含めることができます。Container:Directory の最後のメディア アイテムに存在する場合、Item:Padding はアイテムの末尾とファイルの末尾の間にパディングがあることを示します。

各メディア アイテムには、Item:Mime 型と Item:Semantic 属性を含める必要があります。サブ画像メディア アイテムには Item:Length 属性を含める必要があります。

シーケンシャル メディア アイテムでは、ファイル コンテナ内のリソースデータを共有できます。最初のメディア アイテムでファイル コンテナ内のリソースの場所を決定し、後続の共有メディア アイテムでは Item:Length を 0 に設定します。リソースデータ自体がコンテナである場合、Item:URI を使用してリソース内のメディア アイテム データの場所を特定できます。

コンテナ内のメディア アイテム リソースの場所は、メイン画像エンコードの長さ、先行する付随メディア アイテム リソースの Item:Length 値、および先行するすべての Item:Padding 値の合計によって決定されます。Item:Padding は、値を指定しないメディア アイテム リソースでは 0 とみなされます。

アイテムの MIME タイプ値

Item:Mime 属性は、各メディア アイテム データの MIME タイプを定義します。

GContainer XMP の例

次の有効な GContainer XMP パケットの例には、概要セクションに示したサンプル ファイルから取得したメタデータが含まれています。

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.2">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description
     xmlns:Container="http://ns.google.com/photos/1.0/container/"
     xmlns:Item="http://ns.google.com/photos/1.0/container/item/"
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0">
      <Container:Directory>
        <rdf:Seq>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="Primary"
             Item:Mime="image/jpeg"/>
          </rdf:li>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="GainMap"
             Item:Mime="image/jpeg"
             Item:Length="66171"/>
          </rdf:li>
        </rdf:Seq>
      </Container:Directory>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>

ISO 21496-1 の互換性

ISO 21496-1 は、画像ファイルにゲインマップ メタデータをエンコードするための代替のカプセル化メカニズムを提供します。ファイル内の単一のゲインマップ画像を使用して、Ultra HDR メタデータと ISO 21496-1 メタデータの両方を 1 つの JPEG ファイルにエンコードできます。

図 2. ウルトラ HDR と ISO 21496-1 メタデータを使用したファイル レイアウトの例。

クロス プラットフォームの互換性を最大限に高めるため、ゲインマップを使用して JPEG ファイルの独自のエンコードまたはデコードを実装する Android 実装とアプリは、Ultra HDR v1 と ISO 21496-1 メタデータの両方のエンコードとデコードをサポートする必要があります。エンコード オペレーション中に、実装またはアプリは両方のメタデータ形式をエンコードする必要があります。デコード オペレーション中に両方のタイプのメタデータが存在する場合、実装またはアプリは ISO 21496-1 メタデータを使用することを優先する必要があります。

変更履歴

このセクションでは、この仕様のバージョン間の変更点について説明します。

v1.1

このバージョンのウルトラ HDR 仕様の変更はすべて情報提供を目的としており、ISO 21496-1 の互換性に関するものです。実際のファイル形式に変更はありません。

• 「ISO 21496-1 の互換性」セクションを追加しました。

v1.0

ウルトラ HDR 仕様の最初の公開。