SDR 轉 HDR 實測：只改標籤、整體拉亮和靜態曲線，同一格畫面差在哪

重點速覽

SDR 轉 HDR，是把依 100 尼特顯示器製作的標準動態範圍影片，轉成依 ITU-R BT.2100 編碼的 HDR 影片：傳遞函數換成 PQ 或 HLG，原色換成 BT.2020，位元深度至少 10 位元。

做得對的話，高光還會真的亮過 HDR 參考白，暗部和膚色幾乎不動。本文用一格開源電影畫面，把三種能按公式算清的做法放在同一格畫面上實測，看清楚假 HDR 假在哪裡，再一步步說明 KwaFlux 的 AI 模型怎麼算出 PQ 和 HLG，最後教你自己操作與檢查。PQ 和 HLG 怎麼選，見下文。

• SDR 轉 HDR 要過兩關：訊號要對（PQ 或 HLG、BT.2020、10 位元、標籤齊全），內容也要真的擴展（高光放開，暗部和膚色留在原處）。只過其中一關的，都是假 HDR。
• 我們拿同一格 SDR 畫面，用三種做法轉成 HDR，逐像素算出顯示亮度。只改標籤，天空被讀成 6,207 尼特；整體線性拉亮，人臉到了 346 到 373 尼特，是 BT.2408 淺膚色參考範圍（65 到 110 尼特）上限的 3 倍多。
• ITU 的 BT.2446 報告自己寫明：線性拉亮不適合用來擴展亮度；報告裡的三種方法都是靜態的，與畫面內容無關。
• 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。

四種做法，先看一張表

①和②是做起來最省事的兩種。如果某個工具的 HDR 匯出看起來只是整體變亮，用第 8 節的方法量一下，很快就能看出是不是第②種。

同一格實測：每個像素亮多少尼特

HDR 的效果在 SDR 網頁上看不出來，截圖再亮也只有 100 尼特上下。所以我們換個方式看：把每種做法輸出的每個像素換算成顯示亮度（尼特），再依亮度區間上色。藍色和綠色是 SDR 螢幕顯示得出的範圍，黃色到 HDR 參考白 203 尼特為止，橙紅是 203 到 1,000 尼特的高光，紫紅和白色是 1,000 尼特以上。

怎麼算的。 素材是 Blender 基金會的開源電影《Tears of Steel》（CC BY 3.0），1280 × 534 像素的 H.264 版本，依 BT.709 解碼。原片亮度依 BT.1886（Gamma 2.4，白場 100 尼特）計算。①把碼值直接當 PQ 讀，原色當 BT.2020 讀；②先線性化，再乘 10，讓白場落在 1,000 尼特；③依 BT.2446-1 報告第 4.2 節方法 A 的公式逐像素計算，目標峰值 1,000 尼特。所有亮度都用 BT.2020 的亮度係數計算。圖和下面的表只包含這三種做法。

框選區域取中位數，結果如下：

BT.2408 報告給 HDR 製作的參考值：淺膚色 65 到 110 尼特，中等膚色 40 到 85 尼特，HDR 參考白 203 尼特。拿這把尺來量：

• 只改標籤，天空被讀成 6,207 尼特，遠超過多數 HDR 電視打得出的亮度；人臉 513 到 636 尼特，是參考白（相當於一張白紙）的兩三倍。黑色欄杆卻幾乎沒變。暗的不動、亮的衝天，再加上 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 的每個碼值本來就對應一個固定的尼特數，SDR 的碼值被它一讀，意思全變了。
• 線性拉亮在對數座標上是原片曲線整體平移：暗部也被拉高 10 倍，所以黑位發灰。
• BT.2446 方法 A 在暗部只比 BT.2408 的「不擴展」略高，越往高光越陡。這條曲線設計得很周到，但它終究只有一條：同一個亮度值，不論落在人臉、白牆還是雲上，結果都一樣。

BT.2446 報告開頭就承認這點：報告收錄的三種方法都是靜態的，處理方式與內容和觀看環境無關；自適應、動態、依區域變化的方法也存在，合適的動態方法可能在更多內容上表現更好。AI 反向色調映射就是往這個方向走：映射不再是一條事先寫好的曲線，而是模型從大量 SDR 與 HDR 配對畫面中學出來的。

KwaFlux 的 AI 模型怎麼產生 HDR

KwaFlux 的 SDR 轉 HDR 使用自行研發的模型。它不是「先用曲線猜一個 HDR，再讓網路修一修」，而是把色彩科學直接做進模型的計算圖，模型最後一層交出來的就是可以直接編碼的 HDR 訊號。

色彩數學在模型裡面。 進入網路的第一步，是依 SDR 的 Gamma 把訊號解碼成線性光，後面每一次運算都對應真實的光量；接著從 BT.709 轉進 BT.2020 的廣色域容器；最後在模型末端依 PQ 或 HLG 編碼輸出。中間沒有外掛的 LUT，也沒有匯出時才補上的曲線，所以 BT.2020 原色、PQ 的固定亮度、HLG 的相對亮度，在訓練時就已經是模型必須滿足的約束。

亮度與色彩分兩路。 HDR 最常見的翻車，是整體拉亮之後人臉變成塑膠、霓虹燈周圍一圈泛白。KwaFlux 把任務拆開：亮度分支專管光，讓高光離開 SDR 那 100 尼特的天花板，同時把暗部和中間調留在原處；色彩分支負責在光變強時守住色相，天空還是那片藍，口紅還是那支紅。上一節的實測說明了為什麼要這樣拆：只依亮度走的曲線，沒辦法同時照顧人臉和雲。

亮度強度是模型的輸入，不是事後乘上的係數。 不同影片要的 HDR 不一樣：人像怕過亮，風景可以更開闊，夜景要讓燈亮起來，又不能把招牌衝成一片白。KwaFlux 的亮度強度是 2.0 到 5.0 的連續值，模型每一層都看得到你選的數值。拖動它時，光感和鮮豔度一起平滑變化，不像換了一張 LUT，也不會變成「只是整體乘了一個數」的效果。

同一套權重，PQ 和 HLG 都能輸出。 PQ 和 HLG 只差在最後編碼用的傳遞函數，KwaFlux 用同一套模型權重交付兩種格式，不必為每種格式各訓練一個模型，兩種匯出的畫面也就一致。

內部 16 位元，匯出 10 位元。 模型以 16 位元精度、BT.2020 線性光計算，再依你選的色彩空間編碼成 10 位元的 H.265 或 AV1。高光被拉開後，漸層需要更多色階，中間結果不在 8 位元上捨入，天空和牆面的過渡才不容易出現色帶。

輕量，所以跑得完整部片。 這個模型只處理光和色彩：不做超解析度、不改構圖、不往畫面裡加紋理。網路本身很小。顯示卡記憶體吃緊的電腦會自動分塊處理，畫質目標不變，只是用更穩的方式跑完。

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 顯示器的話，先開啟系統的 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，像素格式是 10 位元（例如 yuv420p10le）。

再量峰值。 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′），帶顏色的高光會和實際亮度有些出入，用來判斷數量級已經足夠。如果多數畫格的 YMAX 都貼著 940，代表滿白被讀成 10,000 尼特，多半只改了標籤。

最後量一張臉。 要判斷是不是整體拉亮，看人臉比看峰值更準。挑一格有正臉的畫面，把臉框起來量平均碼值（crop 的四個數字依序是寬、高、左上角的橫座標和縱座標，依你的畫面修改）：

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 螢幕上才看得到。
• 不會產生杜比視界的動態中繼資料。 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 · 查看方案