SDR→HDR 変換を実測：タグ書き換え、一律の明るさアップ、静的カーブを同じ 1 フレームで比較

要点

SDR→HDR 変換とは、100 ニトのディスプレイ向けに作られた標準ダイナミックレンジの映像を、ITU-R BT.2100 に従ってエンコードした HDR 映像に変えることです。伝達関数は PQ または HLG に、原色は BT.2020 に、ビット深度は各チャンネル 10 ビット以上になります。

正しく変換すれば、ハイライトは HDR 基準白より明るくなり、暗部と肌の色はほとんど動きません。この記事では、オープンムービーの同じフレームで計算できる 3 つの方法を試し、疑似 HDR のどこがおかしいのかを示したうえで、KwaFlux の AI モデルが PQ と HLG を計算する手順と、自分で変換・確認する方法を解説します。PQ と HLG の選び方は後の節で説明します。

• 本当の SDR→HDR 変換には 2 つの条件があります。信号が正しいこと（PQ または HLG、BT.2020、10 ビット、正しいタグ）と、内容が拡張されていること（ハイライトは伸び、暗部と肌はそのまま）です。片方だけなら疑似 HDR です。
• 同じ SDR フレームを計算できる 3 通りで HDR に変換し、全画素の表示輝度を計算しました。タグを書き換えるだけで空は 6,207 ニトと読まれ、線形に明るくすると顔は 346〜373 ニトになりました。BT.2408 が示す明るい肌の範囲（65〜110 ニト）の上限の 3 倍以上です。
• ITU の BT.2446 レポート自体が、線形スケーリングは輝度の拡張に適さないこと、収録された 3 つの方法はどれもコンテンツに依存しない静的な方法であることを明記しています。
• KwaFlux の SDR→HDR は自社開発の AI モデルです。リニア化、BT.2020 への変換、PQ または HLG のエンコードをすべてモデル内で行い、輝度と色は別々の経路で処理します。明るさはすべての層が参照する入力で、内部は 16 ビット、書き出しは 10 ビットです。
• HDR ファイルの良し悪しを目だけで判断する必要はありません。ffprobe でタグを読み、signalstats でピークと顔の明るさを測れます。コマンドと換算表は後半にあります。

本当の HDR 変換とは？

本当の SDR→HDR 変換は、信号と内容の両方が正しいものです。信号はフォーマットの問題で、ファイルが PQ または HLG、BT.2020 原色、10 ビット以上で、タグと画素が一致していることです。内容は画の問題で、ITU-R レポート BT.2446 が変換に求める条件を挙げています。要約すると次のとおりです。

• 暗部と中間調は元の映像に近づけ、明るいハイライトの隣で暗部のディテールが見えなくならないようにする。
• 中間調を上げすぎない。上げすぎると平均輝度が上がり、見ていて疲れる映像になる。
• ハイライトは基準白より上へ伸ばす。HDR で増えた輝度は主にここに使う。
• 輝度が変わったら色の見え方も合わせ、色相がずれないようにする。
• 元の圧縮ノイズは増幅されるので、圧縮の強い素材は明るくしすぎない。

信号の条件だけを満たしたファイルは、プレーヤーが HDR に切り替わっても、まぶしい、白っぽい、あるいは元と変わらない画になることがあります。HDR としてエンコードせず、明るく派手にしただけの映像は SDR のままです。どちらも疑似 HDR です。

4 つの方法を一覧で比較

①と②は作るのがいちばん簡単な方法です。あるツールの HDR 書き出しが全体に明るくなっただけに見えるなら、第 8 節の確認方法を使えば②かどうかすぐにわかります。

同じフレームを 1 画素ずつ測定

SDR のウェブページでは HDR は見えません。どれだけ明るいスクリーンショットでも 100 ニト前後が上限です。そこで別の方法で可視化しました。各方法が出力する全画素を表示輝度（ニト）に換算し、輝度帯ごとに色分けしました。青と緑は SDR ディスプレイで表示できる範囲、黄は HDR 基準白の 203 ニトまで、橙と赤は 203〜1,000 ニトのハイライト、マゼンタと白は 1,000 ニト超です。

測定方法。 素材は Blender Foundation のオープンムービー『Tears of Steel』（CC BY 3.0）の 1280 × 534 の H.264 版で、BT.709 としてデコードしました。元の映像は BT.1886（ガンマ 2.4、白 100 ニト）で表示した輝度です。①はコード値を PQ、原色を BT.2020 として読みます。②はリニア化して 10 倍し、白を 1,000 ニトに合わせます。③は BT.2446-1 第 4.2 節の方法 A の式を 1 画素ずつ適用し、ピークは 1,000 ニトです。輝度はすべて BT.2020 の輝度係数で計算しました。図と下の表はこの 3 つの方法だけです。

枠で囲んだ領域の中央値は次のとおりです。

レポート BT.2408 は HDR 制作の目安として、明るい肌 65〜110 ニト、中間の肌 40〜85 ニト、HDR 基準白 203 ニトを示しています。これを物差しにすると、次のようになります。

• タグの書き換えのみでは、空が 6,207 ニトと読まれます。ほとんどの HDR テレビが出せる明るさを大きく超えています。顔は 513〜636 ニトで、基準白（白い紙 1 枚に相当）の 2〜3 倍です。一方、黒い手すりはほとんど変わりません。暗いところはそのまま、明るいところだけが跳ね上がり、BT.709 の色を BT.2020 として読むため、全体がまぶしく派手になります。
• 線形の明るさアップではすべてが 10 倍になります。顔は 346〜373 ニトで明るい肌の目安の上限の 3 倍以上、黒い手すりは 2 ニトから 20 ニトになり、黒が灰色に浮きます。「HDR にしたら白いもやがかかったようで、肌がプラスチックみたい」の正体はこれです。BT.2446 は、線形スケーリングは平均輝度を上げすぎ、中間調が明るすぎて快適に見られなくなるため、輝度の拡張には適さないと明言しています。
• BT.2446 方法 A はずっと控えめです。顔は 163〜180 ニト、空は 762 ニト、暗部は 6 ニトまでしか上がりません。この作品はもともと暗めにグレーディングされており、元の顔は 35 ニトです。そのため顔は目安より明るくなりますが、それでも線形の明るさアップの約半分に収まっています。

次は、曇り空が大きく写ったフレームです。

タグを書き換えるだけで、50% の画素が 1,000 ニトを超え、フレーム平均は 1,141 ニトと元の 29 倍になります。線形の明るさアップでは、曇り空全体が 400〜1,000 ニトの光る壁になります。BT.2446 もまさにこの点を指摘しています。最大値に近い大きな領域は強く拡張すると不快なほど明るくなるため、方法 B ではピークをさらに低く抑えています。

補足： この図が答えるのは「各画素が何ニトで表示されるか」だけで、見た目の良し悪しは評価していません。それは最終的に HDR ディスプレイで確かめる必要があります。

これらの方法をカーブで比べる

SDR 信号を黒から最大白まで動かし、各方法が何ニトを返すかを描きました。

• タグ書き換えの線は信号 63% あたりで線形の明るさアップを追い越し、最大白で 10,000 ニトに達します。PQ のコード値は 1 つずつ決まったニト値を表すので、SDR のコード値を PQ として読むと意味がまるで変わります。
• 線形の明るさアップは、対数グラフ上では元のカーブをそのまま上に平行移動したものです。暗部も 10 倍になるため、黒が浮きます。
• BT.2446 方法 A は、暗部では BT.2408 の「拡張しない」配置よりわずかに上にあり、ハイライトに向かって急になります。よく考えられたカーブですが、やはり 1 本しかありません。同じ輝度値なら、顔でも白い壁でも雲でも結果は同じです。

レポートは冒頭でこの点を認めています。収録した 3 つの方法はどれも静的で、コンテンツや視聴環境に関係なく同じ処理をすること、そして適応的、動的、領域ごとに変わる方法も存在し、適切な動的方法ならより多くのコンテンツでよい結果を出せる可能性があることです。AI による逆トーンマッピングはまさにこの方向です。対応関係はあらかじめ書かれたカーブではなく、SDR と HDR の大量のペア画像からモデルが学んだものです。

KwaFlux の AI モデルが HDR を作る仕組み

KwaFlux の SDR→HDR は自社開発のモデルで動いています。カーブで HDR を推測してからネットワークで手直しする、というやり方ではありません。色彩科学をモデルの計算グラフに組み込み、最終層から出てくるのはそのままエンコードできる HDR 信号です。

色の計算はモデルの中にあります。 ネットワーク内の最初のステップで SDR のガンマをリニア光にデコードするので、以降の演算はすべて実際の光量に対応します。続いて BT.709 から広い BT.2020 のコンテナへ移し、最後の段で PQ または HLG にエンコードします。後付けの LUT も書き出し時に足すカーブもないため、BT.2020 の原色、PQ の固定された輝度、HLG の相対輝度は、学習の段階からモデルが守るべき制約になっています。

輝度と色は別々の経路で処理します。 HDR でよくある失敗は、全体を持ち上げて顔がプラスチックのようになり、ネオンの周りに白い輪ができることです。KwaFlux は仕事を分けています。輝度の経路は光を担当し、ハイライトを SDR の 100 ニトの天井から解放しつつ、暗部と中間調は元の位置に残します。色の経路は光が強くなっても色相を保ち、空は同じ青、口紅は同じ赤のままです。前節の測定が、なぜ分ける必要があるかを示しています。輝度だけを見るカーブでは、顔と雲の両方にうまく対応できません。

明るさは後から掛ける係数ではなく、モデルの入力です。 映像によって合う HDR は違います。人物は明るくしすぎると不自然になり、風景はより開放感を出せ、夜景は灯りを輝かせつつ看板を真っ白にしてはいけません。KwaFlux の明るさは 2.0〜5.0 の連続値で、モデルのすべての層がその値を参照します。スライダーを動かすと、光の感じと鮮やかさが一緒になめらかに変わり、LUT を差し替えたような段差も、全体に 1 つの数を掛けただけの平板さもありません。

同じ重みで PQ も HLG も出せます。 PQ と HLG の違いは最後に使う伝達関数だけなので、KwaFlux は同じモデルの重みで両方の形式を出力します。形式ごとに別のモデルを用意する必要はなく、2 つの書き出しの画も揃います。

内部は 16 ビット、書き出しは 10 ビット。 モデルは 16 ビットの BT.2020 リニア光で計算し、選んだ色空間で 10 ビットの H.265 または AV1 にエンコードします。ハイライトを伸ばすとグラデーションに必要な階調が増えるため、途中の結果を 8 ビットに丸めないことが、空や壁のバンディングを防ぎます。

軽いので、作品 1 本を通して処理できます。 このモデルが扱うのは光と色だけで、アップスケールも構図の変更もテクスチャの追加もしません。ネットワーク自体は小さく、GPU メモリが足りないマシンでは自動的にタイル分割で処理し、画質の目標は変えずに安定して最後まで処理します。

PQ と HLG のどちらを選ぶか

PQ と HLG の選び方は上の「PQ と HLG のどちらを選ぶか」で説明しています。YouTube や HDR10 で渡すときは PQ で書き出してください。

KwaFlux で SDR を HDR に変換する方法

ステップ 1：AI カラー調整を開き、SDR→HDR を選ぶ。 AI カラー調整 にクリップを読み込み、モードで SDR→HDR を選びます。動画専用です。写真には スマートカラー か フィルター調色 を使います。

ステップ 2：シーンを選ぶ。 シーン には 風景（既定）、夜景、カスタム があります。風景と夜景はプリセットの明るさ（3.8 と 3.5）を使い、カスタムを選んだときだけ 明るさ スライダー（2.0〜5.0）が表示されます。下の表の開始点は私たちの提案です。素材に合わせて調整してください。

ステップ 3：先にプレビューする。 クリップの中でいちばん明るい部分と顔が多い部分を、1・3・5 秒でプレビューします。SDR モニターでは SDR に戻した版が表示されますが、階調と肌の分離は確認できます。HDR モニターがあれば、先に OS の HDR をオンにしてください。

ステップ 4：書き出す。 書き出し設定の 色空間 では HDR PQ (Rec.2020)（既定）、HDR HLG (Rec.2020)、SDR (BT.709) を選べます。コーデックは H.265（推奨）か AV1、コンテナは MKV が推奨です。HDR の書き出しは 10 ビットで、KwaFlux は対応する伝達関数、BT.2020 の原色と行列、リミテッドレンジのタグを書き込みます。

ヒント： 素材がぼやけている、ノイズが多い、ブロックノイズが目立つときは、先に画質修復で整えてから SDR→HDR をかけます。HDR は元の欠点も一緒に拡大するので、修復してから拡張するほうが、拡張してから修復するよりずっときれいに仕上がります。

補足： SDR→HDR では現在、スタイルフィルターを重ねられません。重ねると書き出しが全体に暗くなります。設定済みのフィルターは保持され、スマートカラーかフィルター調色に切り替えると再び適用されます。

目に頼らず HDR ファイルを確認する方法

まずタグを確認します。 次のコマンドで色のタグを一覧できます。

ffprobe -v error -select_streams v:0 -show_entries stream=pix_fmt,color_range,color_space,color_transfer,color_primaries -of default=nw=1 output.mkv

PQ のファイルなら smpte2084、HLG なら arib-std-b67、原色と行列は bt2020 と bt2020nc、画素形式は yuv420p10le のような 10 ビットになっているはずです。

次にピークを測ります。 signalstats はフレームごとに輝度成分の最大コード値を出します。

ffmpeg -i output.mkv -vf "signalstats,metadata=print:key=lavfi.signalstats.YMAX:file=ymax.txt" -f null -

10 ビット・リミテッドレンジの PQ ファイルでは、次の表でコード値をニトに戻せます（SMPTE ST 2084 の式から計算）。

PQ のテストファイルでこのコマンドを実行すると YMAX は 715、約 920 ニトで、スクリプトが画素ごとに計算したピーク 910 ニトと一致しました。YMAX は輝度成分（Y′）を測るため、色の付いたハイライトでは実際の輝度と多少ずれますが、桁を判断するには十分です。ほとんどのフレームで 940 に張り付いているなら、最大白が 10,000 ニトと読まれており、タグを書き換えただけの可能性が高いです。

最後に顔を測ります。 全体を持ち上げたかどうかは、ピークより顔のほうが正確にわかります。正面を向いた顔が写っているフレームを選び、顔を囲んで平均コード値を測ります（crop の 4 つの数字は幅、高さ、左上の x 座標と y 座標です。映像に合わせて変えてください）。

ffmpeg -ss 10 -i output.mkv -frames:v 1 -vf "crop=30:40:712:100,signalstats,metadata=print:key=lavfi.signalstats.YAVG:file=-" -f null -

本記事の人物フレームでは、線形の明るさアップ版が 618（約 330 ニト）、BT.2446 方法 A 版が 549（約 155 ニト）でした。元のグレーディングが暗いか明るいかで顔の位置は上下しますが、顔が基準白より明らかに明るければ、画全体が持ち上げられていると考えてほぼ間違いありません。

よくあるトラブルと対処

AI でもできないこと

• 白飛びしたディテールを取り戻すこと。 SDR の空や灯りがすでに 255 で平らになっていれば、どんな方法でも中身は推測するしかなく、元には戻せません。
• 元の圧縮の問題をついでに直すこと。 逆トーンマッピングは既存のブロックノイズやノイズを拡大します。強く圧縮された素材は先に修復してください。
• HDR ディスプレイの代わりになること。 100 ニトの画面では HDR は SDR に戻して見るしかなく、増えた明るさは HDR 画面でしか見えません。
• Dolby Vision の動的メタデータを作ること。 KwaFlux が書き出すのは PQ（HDR10 系）または HLG です。

まとめ

疑似 HDR は簡単に作れます。タグを変えるか全体を明るくすれば、プレーヤーに HDR のマークが付きます。本当の HDR は信号と内容の両方を正しくする必要があります。次に「HDR」の映像を受け取ったら、上のコマンドで測ってみてください。ピークがどこにあり、顔がどれだけ明るいかで、どちらなのかがわかります。

ご自身の素材で効果をテスト

KwaFlux はご自身の GPU でAI カラー調整を実行します。PQ または HLG での SDR→HDR の書き出しにも対応しています。AI 処理はご自身の GPU 上で実行され、メディアファイルが処理のためにアップロードされることはありません。Windows 10（64 ビット、バージョン 1809 以降）、Windows 11、Apple Silicon 搭載の macOS 12 以降で動きます。プレビューにアカウントは不要です。どのクリップでも 1・3・5 秒のプレビューを出せます。ログインと有料プランが必要なのは、書き出し、変換、ファイル修復、リンクからのファイルダウンロードだけです。

KwaFlux を入手 · プランを見る