JPGをgain map付きのUltra HDRファイルに変換

gain mapとは実際には何か

通常のJPEGは、白で行き止まりになる尺度で明るさを表します。ハイダイナミックレンジに対応した画面は、その白よりかなり明るくできます。小さな領域なら数倍明るくできますが、どの部分がその余裕を使うべきかを形式から伝える方法はありません。

gain mapは、その欠けている指示です。最初の画像と一緒に保存される、2つ目の小さなグレースケール画像で、それぞれの値は対応する写真の部分にどれだけ余分な明るさを与えるかを、段数で示します。余裕のあるレンダラーはそれを乗算し、余裕のないレンダラーは全体を無視してベース画像を表示します。それがすべてです。この仕組みのよさは、ファイルがきれいに劣化することにあります。2012年の画面では、単なるJPEGです。

GoogleはこれをAndroid 14でUltra HDRとして提供しました。コンテナは、2つの画像を示すXMPディレクトリと、2つ目の画像のバイトオフセットを指定するMulti-Picture Formatインデックスで構成されます。これはもともと立体カメラ向けに書かれたCIPA規格です。AppleのHDR写真も同じ基本的な考え方を使っており、その後ISO 21496-1がこれを正式化しました。

「SDRをHDRに変換」の正直な内容

この言葉で検索すると、完成した写真にダイナミックレンジを追加すると約束するソフトウェアが数多く見つかります。追加されるのは情報ではなく、解釈です。

カメラがハイライトをクリップしたとき、そのピクセルのすべてのチャンネルは255になり、その背後には何もありません。後から行う処理で、センサーが記録しなかったものを復元することはできません。アップスケーラーや生成モデルにできる最大限のことは、もっともらしいものを発明することです。壁紙なら問題ありませんが、写真が証拠として使われる場所では認められません。

このツールが代わりに行うのは、存在するハイライトに、画面の余裕をどれだけ与えるかをピクセルごとに決め、その判断を現在のHDRパイプラインが読み取る形式で書き込むことです。HDR画面では、同じ写真をより明るく、立体的にした結果になります。窓が白い長方形ではなく窓らしく見え、水面の反射にきらめきが加わります。それ以外の画面では、開始時の写真とバイト単位で同じ画像です。

これは実際の改善ですが、控えめなものです。そのことを伝えるのと、「写真を本物のHDRに変換」と言うことの違いが、このセクションが存在する理由のすべてです。

なぜハイライトだけなのか

gain mapを悪く作る最も一般的な方法は、どこにでもgainを適用することです。簡単で、画像が明らかに変わり、画面の明るさを上げたように見えます。実際、それが起きています。ダイナミックレンジは暗い部分と明るい部分の距離なので、両端を同じように持ち上げてもダイナミックレンジは増えません。

ここで使うカーブは、線形輝度で約35％未満ではゼロで、そこからsmoothstepによって滑らかに立ち上がります。そのため中間調とシャドウにはgainがまったく加わらず、効果は鏡面ハイライトのある場所に集中します。窓、水面に当たる太陽、金属の縁、フレーム内の光源などです。レシートには、画像が実際に要求した最大gainが表示されます。通常はプリセットの上限を大きく下回ります。明るいハイライトのない写真は、どのプリセットを選んでもgainがほとんどありません。それが正しい動作であり、不具合ではありません。

3つのプリセットは穏やか at 1段, 標準 at 2段, 強い at 3段です。3段は現在のスマートフォンカメラが本来記録する量としておおむね妥当なので、合成するmapの正直な上限です。それを超えると、結果は写真らしく見えなくなります。

ファイルの中身

出力は1つのJPEGです。先頭から読むと、画像開始マーカー、JFIFヘッダー、PrimaryとGainMapという2つの項目を持つコンテナディレクトリを宣言するXMPパケット、正確なバイト長、それから2項目のインデックスを格納したMulti-Picture Formatセグメントが続き、その後にSDR写真の通常の圧縮画像データが入ります。その画像の画像終了マーカーの後には、2つ目の完全なJPEGが続きます。これがgain mapで、線形解像度は半分です。レンダラーに必要なパラメータ、つまり段数で表した最大gain、gamma、offset、capacity rangeを持つ独自のXMPも含まれています。

この構造にある2つの数値は、全体を機能させるために現実と一致していなければなりません。gain mapの宣言長と、MPFインデックス内のバイトオフセットです。このオフセットはファイルの先頭からではなく、MPFセグメント内の起点から測定されます。その相対的な起点は、どの実装でも少なくとも一度は間違える部分です。

そのため、このツールは提供前に自分の出力を読み戻します。XMPを再解析して両方の項目が宣言されていることを確認し、MPFオフセットをたどってJPEGの画像開始マーカーに到達することを確認し、宣言された長さと実際に存在するバイト数を比較し、gain mapがバージョンと最大値を持つことを確認します。これらの結果はすべてレシートに表示されます。どれか1つでも失敗すれば、何も生成されません。自分の内容についてヘッダーが嘘をつくファイルは、後で別の場所で問題になり、誰もここまで原因をたどりません。

どこで表示され、どこでは表示されないか

効果は、Android 14以降のGoogle PhotosとChrome、ディスプレイに余裕がある場合の最近のiOSとmacOSのPhotosとSafari、そしてデスクトップのHDRモニター上のChromeで表示されます。一般的なオフィスモニターには利用できる余裕がないため、ベース画像が正しく表示され、何も起きていないように見えます。

ここで検証できるのもそこまでです。ブラウザーのタブで動作するものは、ディスプレイのピーク輝度を測定したり、別のデバイスのレンダラーをテストしたりできません。そのため、ツールが確認したもの、つまりコンテナについてだけ説明し、確認していないものについては意味を持たせません。このサイトのページで確認できない主張については、そのことを明記します。これは、QR generatorが特定のカメラで特定の印刷物を読めると約束しないのと同じ方針です。

gain mapを理解しないソフトウェア、古いデスクトップビューア、印刷ワークフロー、ほとんどのコンテンツ管理システムなどは、見慣れないメタデータセグメントが2つ付いたJPEGとして認識し、ベース画像を表示します。これは形式が設計どおり動作しているということです。再保存時に追加のセグメントを削除し、HDRを何も知らせずに取り除くツールもあります。ファイルをパイプライン内で維持する必要があるなら、最後の場所で確認してください。

コストと、作成しなくてよい場合

gain mapによって、ファイルは約15〜30％大きくなります。gain mapは本質的に滑らかで圧縮しやすく、線形解像度を半分にしても見た目は完全解像度と区別できません。mapが完全解像度の画像に対して乗算されるためです。

明るいハイライトのない写真に作成する価値はありません。均一に照らされた室内、平坦な灰色の空、書類のスキャンなどです。余裕を使う対象がなく、レシートにはピークgainがほぼゼロだったと表示され、ファイルサイズだけを支払うことになります。夕焼け、窓、光源のある夜景、水や金属がフレームにあるものには、作成する価値があります。

本当に暗い写真は別の問題であり、brightenerが適しています。これは対応する画面が何をするかではなく、誰が見ても同じピクセルを変更します。また、ここにある再エンコードを行うすべてのツールと同様に、出力には元ファイルのメタデータは引き継がれません。位置情報、カメラ情報、シリアル番号は含まれません。ファイルが何を保持しているかを確認してから対応を決めるには、metadata toolを使ってください。