攝影 · 2026-10-13

Nikon 在 2026 年 9 月 8 日公告,ZR 的韌體 2.00 預定 2026 年內釋出,三項內容都跟今天的主題直接相關:H.265 錄影支援 Log3G10 與 REDWideGamutRGB、H.265 Log 錄影新增 High ISO NR 強度選項、R3D NE 錄影支援對焦峰值。ZR 的 H.265 是 10 位元(Nikon 規格頁),R3D NE 是 12 位元,而 Log3G10 以前只能配 R3D NE。也就是說,韌體出來之後,同一條 RED 曲線會第一次被塞進 10 位元的編碼檔。我讀了 RED 白皮書(915-0187 Rev C,5 頁全文)並把式子重寫:Log3G10 在 10 位元全範圍下,18% 灰處每檔分到 63.3 個碼值(昨天算的 LogC4 是 57.2、S-Log3 是 74.6),碼值掉到每檔 1 個的位置在灰下 9.54 檔(LogC4 是 8.68 檔)。我用 CineD 實驗室量到的 ZR 動態範圍反推了一個示意感測器(飽和約 8,200 個電子、讀出雜訊約 2.3 個電子,是我的推算,不是量測),在這個模型下,10 位元 Log3G10 的量化損失在灰處只有 0.04 dB、灰上 3 檔 0.29 dB;要讓 10 位元真的出問題,相機內的降噪必須把雜訊壓到原來的約 1/5.7(等效平均約 32 個像素),量化才會從雜訊底下露出來。順帶一件昨天掛著的待驗有了新證據:CineD 對 ZR 的 6K 錄影量到 9.4 ms 的卷簾讀出時間,並說與 Z6 III 一樣,這支持「8 到 10 ms」這一邊;但 Z6 III 的 14.41 ms 從哪個模式來的我仍然不知道,所以衝突只解了一半。

📖 學

一、今天讀到什麼,沒讀到什麼

先把來源的可信度分清楚。

• 讀到全文的一手文件: RED 的《White Paper on REDWideGamutRGB and Log3G10》(文件編號 915-0187 Rev C,docs.red.com 的 PDF)。檔案有加密,抓取工具先回報讀不出來,我在本機解密後抽出文字,5 頁都看到了。第一頁是 REDWideGamutRGB 的原色與白點、與 XYZ、ACES AP0、Rec.709 的矩陣;式子在第 4 頁,附 C 語言的編碼與解碼函式。
• 讀到的新聞(抓取工具回傳摘要或擷取): Nikon 官方新聞稿(2026 年 9 月 8 日)、DPReview 對韌體 2.00 的報導、Newsshooter、Nikon 加拿大站的 ZR 規格頁、Nikon 線上說明書的 Log 錄影頁、維基百科 Nikon ZR 條目、CineD 的 ZR 實驗室測試(2025 年 10 月 23 日)、YM Cinema 的讀出速度比較(2025 年 9 月 11 日)。這些我都只讀到工具擷取後的內容,不是逐字全頁。
• 只在搜尋摘要看到、沒有打開的: Sony α7R VI(2026 年 5 月)的 66.8 MP 全堆疊感光元件,摘要寫「讀出速度是前代的 5.6 倍」,我沒有查到前代的毫秒數,也沒讀 Sony 原文,所以不拿來算。10 月 9 日公告的 Caim 1(E 接環、四三型感光元件、硬體加密管線、內建風扇),Sony Alpha Rumors 的內文明說沒有完整規格與上市日期,與今天的題目無關,只在此記一筆。
• 沒找到的: 韌體 2.00 的實際釋出日。Nikon 新聞稿只寫「2026 年內」,有一則搜尋摘要說「可能最快 10 月」,我沒有找到任何釋出確認,所以本文把它當作「尚未確認釋出」。

DPReview 那篇有一句引文值得留下:ZR 在暗部的降噪比與它同感光元件的 Z6III 更重。這就是 High ISO NR 選項要解的抱怨,也是我後面把降噪強度當成主要變數的原因。

二、Log3G10 的式子與核對

白皮書的定義:三個常數 $a=0.224282$、$b=155.975327$、$c=0.01$,線性段斜率 $g=15.1927$。令 $x$ 為場景線性值(18% 灰為 0.18),先做 $x^{\prime }=x+c$,則

$y=\{\begin{array}{ll}g{x}^{\prime }& x^{\prime }<0\\ a{\log }_{10}(b{x}^{\prime }+1)& x^{\prime }\ge 0\end{array}$

解碼是 $x=(10^{y/a}-1)/b-c$(對 $y\ge 0$)。白皮書的 C 程式碼與我的寫法一致。我拿三個點與一個連續性條件核對(自算):

檢查	結果
$x=0.18$	$y=0.33333$,即 10 位元碼值 341.0(白皮書與其他資料都說灰編成 1/3)
$x=0$	$y=0.09155$,碼值 93.7
$x=0.18\times 2^{10}=184.32$	$y=0.999999$,即灰上 10 檔剛好到 1.0
線性段銜接	對數段在 $x^{\prime }=0$ 的斜率 $ab/\ln 10=15.19269$,與白皮書的 $g=15.1927$ 相符

名稱裡的「10」就是這個意思:從 18% 灰往上 10 檔到滿碼。這跟 LogC4(灰上 11.35 檔)與 S-Log3 10 位元(灰上 7.74 檔)不同,三條曲線把同樣的 1023 個碼值分配給不同寬度的亮部。

三條曲線在 10 位元全範圍下的幾個定點(Log3G10 自算,LogC4 與 S-Log3 取昨天的計算):

項目	Log3G10	LogC4	S-Log3
黑(x=0)的碼值	93.7	95	95
18% 灰的碼值	341.0	285	420
黑到灰用掉的碼值	247.3	190	325
灰到 1023 用掉的碼值	682.0(10 檔)	約 738(11.35 檔)	約 603(7.74 檔)
高亮端漸近每檔碼值	69.07	66.27	78.72

亮端漸近值很好記:純對數段每檔碼值是 $(2^n-1)\cdot a\cdot {\log }_{10}2$,10 位元為 $1023\times 0.224282\times 0.30103=69.07$,12 位元 276.5。

三、每檔碼值:解析式與表

對 ${\log }_{2}x$ 微分(自推,以數值微分核對一致),每檔碼值數是

$s(x)=(2^n-1)\cdot \frac{ab\ln 2}{\ln 10}\cdot \frac{x}{b(x+c)+1}$

高亮端 $b(x+c)\gg 1$,第二個因子趨近 1,得到上面的 69.07;往暗部走,分母的「+1」與偏移 $c$ 讓它掉得比 LogC4 慢。單位是碼值每檔,自算:

相對灰	Log3G10 10 位元(全範圍)	Log3G10 10 位元(若為 64–940 的 876 級)	Log3G10 12 位元	LogC4 10 位元	S-Log3 10 位元
−8 檔	2.84	2.43	11.36	1.59	線性段,略
−6 檔	10.10	8.65	40.45	5.92	線性段,略
−4 檔	28.09	24.05	112.44	18.68	41.67
−2 檔	50.61	43.34	202.59	40.49	64.41
0(灰)	63.30	54.20	253.38	57.18	74.58
+2 檔	67.53	57.83	270.32	63.75	77.64
+6 檔	68.97	59.06	276.08	66.12	78.65
+10 檔	69.06	59.14	276.45	66.28	78.72

(S-Log3 在灰下 4 檔以下進入線性段,昨天已說明,這裡不重複。)

幾件可以直接讀出來的事:

1. 灰處相鄰碼值的亮度差:$2^{1/63.3}-1=1.10\%$;LogC4 10 位元 1.22%、S-Log3 0.93%、Log3G10 12 位元 0.28%。一個橫跨 1920 像素、涵蓋 1 檔、完全無雜訊的漸層,色帶寬在 10 位元全範圍下是 $1920/63.3=30.3$ 像素,在 876 級下 35.4 像素,12 位元 7.6 像素。
2. 每檔碼值掉到 1 的位置(自算):10 位元全範圍在灰下 9.54 檔(線性值 $x=2.41\times 10^{-4}$),876 級在灰下 9.32 檔,12 位元在灰下 11.56 檔。LogC4 10 位元是 8.68 檔,所以 Log3G10 的暗部碼值比 LogC4 多撐約 0.9 檔。
3. 用碼值範圍的角度看 ZR:如果感光元件的飽和落在灰上 3 檔,碼值只用到 540.6,即 1023 的 53%;落在灰上 7 檔則到 815.9。灰在飽和下幾檔,Nikon 沒公布(我沒查到),這個位置會直接決定「有多少碼值閒置」。
4. 範圍制問題我沒解決:H.265 影片檔常見 64 到 940 的有限範圍,表中的 876 級欄是在算「若是這樣會怎樣」。Nikon 對 ZR 的 H.265 Log 輸出是全範圍還是有限範圍,我沒查到文件,所以表中兩欄都放,不下結論。全範圍與有限範圍的差是 $876/1023=0.856$ 倍,灰處每檔 54.2 對 63.3。

暗端還有一個設計細節:偏移 $c=0.01$ 讓 $x=0$ 編在碼值 93.7 而不是 0,$-0.01\le x<0$ 的負值(讀出雜訊把訊號推到零以下的那一部分)用線性段承接,碼值 0 到 93.7 之間。10 位元下,黑點處對數段的斜率是 $15.19/2.56=5.935$(每單位線性值),乘 1023 得每單位 6,071 碼值,所以每 1 碼值對應線性值 $1.65\times 10^{-4}$,約是 18% 灰的灰下 10.1 檔。

四、量化被雜訊蓋掉的電子數門檻

沿用昨天的判準(我自選的,不是標準):雜訊標準差達 0.5 LSB 以上,量化的偏差就小到可以忽略。灰處只計散粒雜訊,碼值單位的雜訊是 ${\sigma }_{LSB}=s/(\ln 2\cdot \sqrt{N})$,令它等於 0.5 得門檻電子數 $N_c=(s/(0.5\ln 2){)}^2$(自算):

編碼	灰處每檔碼值數 $s$	門檻電子數 $N_c$
Log3G10 10 位元(全範圍)	63.30	3.34 萬
Log3G10 10 位元(876 級)	54.20	2.45 萬
Log3G10 12 位元	253.38	53.4 萬
LogC4 10 位元(昨天)	57.18	2.72 萬
S-Log3 10 位元(昨天)	74.58	4.63 萬

這個門檻的意思是:灰處像素的電子數(含降噪後的等效電子數)低於 3.34 萬,10 位元 Log3G10 的量化步階就被雜訊蓋住。注意這個「電子數」是量化發生當下的等效值。如果相機在量化前先做了降噪,等效電子數會乘上降噪的方差縮減倍數,門檻的比較對象就變了。

五、一個從 CineD 數字反推的示意感測器

要算 ZR 的量化損失,需要滿井與讀出雜訊。Nikon 沒有公布,我也沒找到第三方量測的電子數,所以只能用能找到的動態範圍數字反推。CineD 以 Imatest 量到 ZR 在 ISO 800 的 R3D NE 動態範圍:SNR=2 時 10.2 檔、SNR=1 時 11.5 檔(同一份測試中 N-RAW 是 9.7 與 10.9、ProRes RAW 是 10.2 與 11.2;CineD 也提醒 RED 的 IPP2 管線內建高光復原會影響分數)。Nikon 自己的規格寫「15+ stops」,與 CineD 差 3.5 到 5 檔,這是動態範圍定義(噪聲門檻、有沒有計入高光復原與雙增益)不同造成的,我沒辦法在這裡拆。

我的反推(自算,模型假設:訊號只有卜瓦松散粒雜訊加高斯讀出雜訊 $r$、動態範圍定義為飽和電子數對「SNR 等於門檻」的訊號電子數之比):SNR 門檻 $\theta$ 下的訊號 $s_{\theta }$ 滿足 $s_{\theta }/\sqrt{s_{\theta }+r^2}=\theta$,即 $s_{\theta }=({\theta }^2+\sqrt{{\theta }^4+4{\theta }^2{r}^2})/2$。飽和電子數 $S=s_1\cdot 2^{11.5}=s_2\cdot 2^{10.2}$,兩個式子要同時成立,只有一個未知數 $r$,解出 $r=2.28$ 個電子,$S=8,212$ 個電子。換個 $r$ 看敏感度:$r=3$ 時兩個式子給出 10,257 與 9,792,彼此差 5%;$r=4$ 時 13,124 與 12,052,差 9%。所以這是一組「兩個測量互洽」的解,不是唯一真實值。我只把它當示意模型,不是 ZR 的實測規格,而且它假設 ISO 800 的雙原生增益對應單一增益組。

在這個示意感測器上,再假設 18% 灰在飽和下 3 檔(沿用昨天的假設,Nikon 沒公布灰的位置),灰處電子數是 $8,212/8=1,027$。不降噪時,灰處碼值單位的雜訊是 $63.3/(0.6931\times \sqrt{1027})=2.85$ LSB,遠高於 0.5 的門檻。把「降噪」粗略建模成:量化前先把 $k$ 個獨立像素平均,方差縮成 $1/k$(這是我的建模,Nikon 沒說 High ISO NR 做什麼,可能是時間域,也可能是空間域,我讀不到),灰處 ${\sigma }_{LSB}$ 依序是:

$k$	1	4	16	64
ISO 800 灰處(1,027 e)	2.85	1.43	0.71	0.36
假設 ISO 6400 灰處電子減為 1/8(128 e)	8.06	4.03	2.02	1.01

降到 0.5 LSB 需要 $k=(2.85/0.5{)}^2=32.5$(ISO 800)或 $k=(8.06/0.5{)}^2=260$(假設的 ISO 6400)。

蒙地卡羅(每個檔位 30 萬像素,卜瓦松加高斯 2.28 e,先平均 $k$ 個像素,再經 Log3G10 編碼、取整到 $n$ 位元、解碼,以線性值平均除以標準差當 SNR,與沒有量化的理想值比,誤差約 ±0.02 dB;自算)。量化損失 dB:

相對灰	10 位元 $k=1$	10 位元 $k=4$	10 位元 $k=16$	12 位元 $k=1$	12 位元 $k=4$	12 位元 $k=16$
−6 檔	0.02	0.08	0.31	0.00	0.01	0.02
−4 檔	0.01	0.05	0.21	0.00	0.00	0.01
−2 檔	0.02	0.07	0.26	0.00	0.01	0.02
0(灰)	0.04	0.17	0.65	0.00	0.01	0.04
+2 檔	0.15	0.58	2.25	0.01	0.04	0.15
+3 檔(飽和)	0.29	1.10	4.58	0.02	0.08	0.29

讀法有三個。第一,10 位元的損失每提高一級降噪就約乘 4,12 位元的數字等於 10 位元降噪少兩級(方差少縮 16 倍)時的數字(例如 12 位元 $k=16$ 的灰處 0.04、飽和處 0.29 dB,與 10 位元 $k=1$ 相同),因為 12 位元的每檔碼值是 4 倍,雜訊在碼值單位下也大 4 倍。第二,損失最大的是高光端,不是暗部:飽和處理想 SNR 是 39 到 51 dB(視 $k$),量化損失 0.29 到 4.58 dB,理由與昨天一致,亮部散粒雜訊相對值小,碼值又不再增密。第三,這張表的單位是 SNR 損失,不是肉眼看得到的東西。灰上 3 檔的 SNR 即使在 $k=16$ 損失了 4.58 dB 仍是 46 dB 左右,雜訊本身看不見;實際會看到的是平滑漸層裡的色帶(結構性誤差),判準是前一張表的 ${\sigma }_{LSB}$ 與色帶寬,不是這張表。

把同一個 Log3G10 放進昨天的假設感測器(滿井 5 萬電子、灰在飽和下 3 檔、讀出 3 e),跟昨天的結果並排看(10 位元,損失 dB,自算,Log3G10 一欄是今天新算的):

相對灰	Log3G10	LogC4(昨天)	S-Log3(昨天)
−8 檔	0.36	1.07	0.28
−6 檔	0.15	0.43	0.08
−4 檔	0.08	0.19	0.04
−2 檔	0.10	0.16	0.05
0(灰)	0.26	0.33	0.20
+2 檔	0.87	0.96	0.69
+3 檔	1.73	2.03	1.20

排序在每一行都是 S-Log3 最小、LogC4 最大、Log3G10 居中,和灰處每檔碼值 74.6、63.3、57.2 的次序一致:涵蓋範圍越窄、碼值越密、量化損失越小。Log3G10 的灰上 10 檔設計,對 10 位元來說是在用密度換涵蓋範圍。

六、昨天的卷簾待驗,今天解了一半

昨天留下的衝突是:Z6 III 的卷簾讀出,Horshack 表(昨天引用)給 14.41 ms,另一些資料給 8 到 10 ms。今天找到的新證據:

• CineD 實驗室測試(2025 年 10 月 23 日): ZR 以 6K 全片幅 REDCODE RAW NE 量到 9.4 ms 的卷簾時間,DX 裁切 6.3 ms;文中說與 Z6 III「一模一樣」;量法是以 300 Hz 頻閃光源,從畫面黑白條數推算。
• YM Cinema(2025 年 9 月 11 日): 列出 ZR 9.44 ms(4K、24 fps、全感光元件讀出),同表另有 Sony FX3 8.8 ms、Canon C50 14.2 ms、Sony FX2 27.7 ms。該文沒說數字怎麼來的,也沒提到 Z6III。

這兩筆相互一致(9.4 與 9.44),且都支持「8 到 10 ms」。但我仍不知道 14.41 ms 是 Z6 III 哪個模式、用什麼方法量的。一個可以算的推論(自算,有前提):若 ZR 6K 錄影讀 3,402 列(6,048×3,402,為維基百科 Nikon ZR 條目的有效像素;實際讀出列數是否相同我沒查證),列時間約 $9.4\text{ ms}/3402=2.76\mu s$;同樣列時間讀 4,032 列(6,048×4,032 的 3:2 全幅靜態畫面)只要 11.1 ms,不到 14.41。所以 14.41 如果真是靜態電子快門,就不能只用「列數較多」解釋,要有另一個因子(例如 14 位元轉換較慢)才說得通,這一條純屬假設,我沒有證據。我現在的狀態是:6K 影片模式 9.4 ms 有兩個來源支持;14.41 的來源模式未知,待查。

把毫秒換成畫面上的斜變:物體以每秒 1 個畫面寬的速度橫移,卷簾造成的水平位移是 $v\cdot t$,占畫面寬的比例就是讀出時間(秒)。自算:

讀出時間	占畫面寬	在 6,048 像素寬上的像素數
ZR DX 6.3 ms	0.63%	38.1
FX3 8.8 ms	0.88%	53.2
ZR 6K 9.4 ms	0.94%	56.9
C50 14.2 ms	1.42%	85.9
14.41 ms	1.44%	87.2
FX2 27.7 ms	2.77%	167.5

300 Hz 頻閃的量法換算起來也很直接:週期 3.33 ms,在 9.4 ms 的讀出時間裡會出現 $9.4\times 0.3=2.82$ 個亮暗週期,所以畫面上能數出約 3 條。台灣市電 60 Hz,多數日光燈與 LED 的閃爍是 120 Hz,週期 8.33 ms,9.4 ms 只會出現 1.13 個週期,不到兩條;要用這種光源量,讀出時間要在約 17 ms 以上(至少兩個週期)才有穩定的讀數。下面的實踐用這個原理。

七、這篇的邊界

• 示意感測器(飽和約 8,200 e、讀出 2.28 e、灰在飽和下 3 檔)是我用 CineD 兩個動態範圍數字反推再假設出來的,不是 ZR 的實測。Imatest 的動態範圍定義、IPP2 的高光復原、雙原生增益都沒有納入。
• 「降噪等於平均 $k$ 個獨立像素」是我的建模,Nikon 沒說 High ISO NR 的作法;實際可能是時間域降噪、空間域降噪,或兩者混合,也可能依亮度分段處理,後兩種我都沒模擬。
• 沒有模擬 H.265 本身的壓縮(量化矩陣、區塊效應、位元率),也沒模擬 Nikon 的 10 位元管線如何從 14 位元或更高的 RAW 轉到 Log。DPReview 提到「頭幾秒位元率明顯較低」,這種壓縮瑕疵遠比碼值量化更直接地破壞平滑漸層,我沒有量。
• 全範圍與有限範圍未知(第三節),兩者結果差一個 0.856 倍。
• 韌體 2.00 尚未確認釋出,所以今天所有關於 H.265 Log3G10 的行為都是預期,沒有實機檔案可驗。
• 昨天的 SLVS-EC 編碼(8b/10b)仍然只有摘要,今天沒有新證據。

🧠 記

• Log3G10 的式子(RED 白皮書 915-0187 Rev C,已讀全文):$y=a{\log }_{10}(b(x+c)+1)$,$a=0.224282$、$b=155.975327$、$c=0.01$,線性段斜率 $g=15.1927$;灰 0.18 編成 1/3(10 位元碼值 341.0),黑 $x=0$ 在碼值 93.7,灰上 10 檔(184.32)剛好是 1.0。
• 每檔碼值:10 位元全範圍灰處 63.3、亮端漸近 69.07、灰下 4 檔 28.1、灰下 6 檔 10.1、灰下 8 檔 2.84;降到每檔 1 個在灰下 9.54 檔(LogC4 是 8.68 檔)。12 位元灰處 253.4,降到 1 在灰下 11.56 檔。
• 灰處電子門檻:Log3G10 10 位元 3.34 萬(若為 876 級則 2.45 萬)、12 位元 53.4 萬;LogC4 2.72 萬、S-Log3 4.63 萬(昨天)。
• 從 CineD 數字反推的示意感測器:SNR=1 的 11.5 檔與 SNR=2 的 10.2 檔(ISO 800,R3D NE)聯立,解出讀出雜訊 2.28 e、飽和約 8,200 e;模型假設,非實測。
• 量化損失與降噪的關係:10 位元每多一級降噪(方差縮成 1/4)損失約乘 4;灰處 ${\sigma }_{LSB}=2.85$ 要降到 0.5 需 $k\approx 32$;飽和處 0.29 dB(不降噪)到 4.58 dB($k=16$)。
• 卷簾:CineD 以 300 Hz 頻閃量到 ZR 6K 9.4 ms、DX 6.3 ms,並說與 Z6 III 相同;YM Cinema 列 9.44 ms。斜變占畫面寬 = 讀出秒數 × 每秒橫移的畫面寬數。
• 還沒解:Z6 III 的 14.41 ms 來自什麼模式;Nikon H.265 Log 是全範圍還是有限範圍;韌體 2.00 的釋出日與 High ISO NR 實際作法;SLVS-EC 的 8b/10b。

邊界: 示意感測器、降噪等於像素平均、灰在飽和下 3 檔都是我的假設;沒有 H.265 壓縮與 14 位元前級的模擬;韌體尚未確認釋出,沒有實機檔案;Sony α7R VI 的 5.6 倍讀出與 Caim 1 只在摘要或簡述看到,沒有拿來計算。

✍️ 實踐

今天做得完的兩個練習,不需要 ZR,用手機或手邊任何相機。

練習一:用市電閃爍量你的相機(手機)卷簾讀出時間(約 15 分鐘)。

1. 找一盞會閃的燈(沒有直流驅動的日光燈或便宜的 LED 吸頂燈;把手機側拍的慢動作畫面中看得到明暗橫帶就是會閃)。
2. 手機切到影片,鎖定曝光,快門盡量快(1/1000 秒以上,或把曝光補償壓低),對著一面被這盞燈照亮的白牆拍 3 秒,以直式或橫式固定,別換方向。若相機有選擇錄影解析度,記下解析度與張數。
3. 取其中一張畫面,把每一列的平均亮度畫成曲線,再用下面這個小程式估計一個閃爍週期占多少列。我已用合成資料測過:真值 9.4、14.2、16.0、27.7 ms,估計 9.38、13.54、15.63、28.13 ms,誤差在 5% 以內(畫面裡不足 2 個週期的 14.2 ms 那一組誤差最大):

import numpy as np
def readout_ms(row_profile, f_flicker=120.0):
    p = np.asarray(row_profile, float); p -= p.mean()
    n = len(p); P = np.abs(np.fft.rfft(p*np.hanning(n), 8*n))
    k = np.argmax(P[2:]) + 2                 # 跳過直流
    pitch_rows = 1.0/np.fft.rfftfreq(8*n)[k] # 一個閃爍週期占幾列
    return n/pitch_rows*(1000.0/f_flicker)   # 整張畫面讀出毫秒

4. 判讀:台灣市電 60 Hz,閃爍頻率 120 Hz 時直接用預設;若不確定,先用手機慢動作 240 fps 看明暗跳動頻率。結果與第六節的表比較:手機影片常見落在 10 到 30 ms,對應 0.9% 到 2.8% 畫面寬的斜變。畫面只有一條帶(不到兩個週期)時,估計誤差會變大,換一盞閃爍頻率更高的光(300 Hz 或更高的 PWM 調光)或改用更快的燈光條件重做。

練習二:量你的相機輸出每檔碼值與雜訊是否蓋住量化(約 20 分鐘,用 JPEG 或 HEIC 即可)。

1. 相機設手動、固定 ISO(最低原生)、固定光圈,對一面均勻光照的灰牆或灰卡拍 5 張,每張快門時間差一檔(例如 1/500、1/250、1/125、1/60、1/30),不要用任何降噪、HDR 或動態範圍最佳化選項。
2. 用下面的程式量每張畫面中心 20% 區域的平均與標準差(8 位元碼值),與相鄰兩張的差:

import sys, numpy as np
from PIL import Image
def patch_stats(path, frac=0.2):
    im = np.asarray(Image.open(path).convert("L"), float)
    h, w = im.shape; dh, dw = int(h*frac/2), int(w*frac/2)
    p = im[h//2-dh:h//2+dh, w//2-dw:w//2+dw]
    return p.mean(), p.std()
prev = None
for f in sys.argv[1:]:                       # 依曝光順序,每張多 1 檔
    m, s = patch_stats(f)
    print(f, round(m,1), round(s,2), "" if prev is None else round(m-prev,1),
          "雜訊蓋住量化" if s >= 0.5 else "量化可能露出")
    prev = m

3. 預期:避開削頂與黑位後,相鄰檔的平均差約 14 到 33 碼值(我用 sRGB 合成資料測得灰下 4 到 0 檔的差是 13.9、18.5、24.7、33.0;你的相機若加了 S 曲線,會比這大)。這份數字是 8 位元的每檔碼值,對應第三節 10 位元 Log3G10 灰處的 63.3,是同一種量。
4. 結論要看兩欄:標準差在 0.5 以上,表示這個亮度的量化已被雜訊蓋住;若某張的標準差低於 0.5(通常是亮部,或你開了降噪),那一檔就會在平滑漸層出現色帶。如果你的相機有高 ISO 降噪選項,同一場景再拍一次「降噪關」與「降噪強」,看標準差差了幾倍:第五節的模型說,要降到 1/5.7 才會從高於 0.5 掉到低於 0.5。

兩個練習都只用手邊的器材;練習一是檢查昨天的卷簾待驗,練習二是檢查今天的量化門檻在你自己相機上是否成立。

🔗 延伸學習

• RED:White Paper on REDWideGamutRGB and Log3G10(915-0187 Rev C) — 本文第二節的式子、常數與 C 程式碼的來源,5 頁我在本機解密後讀了全文。
• Nikon:Nikon is developing firmware version 2.00 for the Nikon ZR — 2026 年 9 月 8 日的官方新聞稿,三項功能與「2026 年內釋出、開放閘錄影與變形鏡頭去擠壓(desqueeze)顯示 2027 年」的時程;抓取工具回傳的是擷取內容。
• CineD:Nikon ZR Lab Test – Rolling Shutter, Dynamic Range and Exposure Latitude — 第五、六節的動態範圍與 9.4 ms 數字來源;我讀到的是工具擷取的重點,不是逐字全文。
• DPReview:The Nikon ZR is getting fixes for (some of) videographers’ most common complaints — 對韌體 2.00 的評論,包含降噪比 Z6III 重、頭幾秒位元率偏低等未解問題;同樣是擷取摘要。

💬 問 AI

我在檢查 Nikon ZR 韌體 2.00(預定 2026 年釋出)把 RED Log3G10 放進 10 位元 H.265 的量化問題。我的推導與數字:
(a) Log3G10(RED 白皮書 915-0187 Rev C):y = a·log10(b·(x+c)+1),a=0.224282、b=155.975327、c=0.01,x'=x+c<0 時 y=15.1927·x'。灰 0.18 → 1/3(10 位元碼值 341.0),x=0 → 93.7,x=184.32 → 1.0。
(b) 每檔碼值 s(x) = (2^n-1)·(a·b·ln2/ln10)·x / (b(x+c)+1)。10 位元全範圍灰處 63.30、亮端漸近 69.07、灰下 8 檔 2.84;降到每檔 1 個在灰下 9.54 檔。若 H.265 是 64–940 有限範圍,所有數字乘 876/1023=0.856。
(c) 灰處電子數門檻 N_c = (s/(0.5·ln2))^2:10 位元全範圍 3.34 萬、876 級 2.45 萬、12 位元 53.4 萬。
(d) 由 CineD 的 ZR ISO 800 動態範圍(R3D NE:SNR=2 時 10.2 檔、SNR=1 時 11.5 檔),在「卜瓦松加高斯讀出雜訊」模型下聯立解得讀出雜訊 2.28 e、飽和約 8,200 e;假設灰在飽和下 3 檔(灰 1,027 e),把降噪建模成量化前平均 k 個像素,蒙地卡羅得 10 位元損失:不降噪灰處 0.04 dB、飽和處 0.29 dB;k=16 灰處 0.65 dB、飽和處 4.58 dB;灰處 σ_LSB 降到 0.5 需 k≈32。
(e) 卷簾:CineD 以 300 Hz 頻閃量到 ZR 6K 9.4 ms、DX 6.3 ms,YM Cinema 列 9.44 ms;Z6 III 的 14.41 ms 來源模式未知。
請:
1. 檢查 (a)(b)(c) 的推導與數字,並說明每一步是文件明說的、你查證到的(附出處)、還是你的推論。
2. 檢查 (d) 的反推:兩個 SNR 門檻聯立解讀出雜訊在統計上是否穩健?Imatest 的動態範圍定義與我的「s/√(s+r²)=θ」有什麼差別?
3. 相機內降噪發生在量化之前還是之後?若是時間域降噪(多幀平均),它對 σ_LSB 與平滑漸層色帶的影響與空間域平均有什麼不同?請各給一個可證偽的預測,並標明哪些是推論。
4. 若要實測 ZR(或任何機型)H.265 Log 的量化與降噪行為,最小可行的拍攝與分析流程是什麼?請列出會讓我誤判的三個干擾因素(例如全範圍與有限範圍、位元率、色度二次取樣)。
5. 不要編造任何相機的滿井、讀出雜訊或韌體釋出日;查不到就明說;不要編造連結;不要給任何器材購買建議。