从传感器到屏幕，从 RAW 到 JPEG，从直线到曲线

把相机传感器记录下的数值原封不动地铺到屏幕上，你会得到一张又暗又绿的照片。中灰被压成深灰，阴影几乎死黑，整个画面还蒙着一层青绿。从那张又暗又绿的原始图到相册里的显示正常照片，中间隔着一串曲线。有的叫 gamma，有的叫 Log，有的叫 tone curve，有的叫 transfer function，有的叫 LUT。

从传感器到线性工作空间

传感器数光子

传感器上的每个光电二极管，在曝光时间内积累入射光子。光子撞击硅，激发出电子-空穴对；电子被势阱收集；曝光结束后，电荷量通过模数转换器（ADC）变成数值。在有效量程内，减去黑电平之后，输出数字值和入射光子数成正比¹。两倍的光 => 两倍的光子 => 两倍的电荷 => 两倍的数值，这是所谓线性。

线性不是数学上的自说自话。只有在线性空间里，两个光源叠加才是加法，模糊才是加权平均，缩放才是乘法，以符合物理定律。所有严肃的合成管线，Photoshop 的 32-bit 模式、Nuke，均在线性空间里做运算，只在最后才转到非线性显示编码。

50% 灰

一个黑像素 0、一个白像素 1，平均结果直觉的答案是 sRGB 码值 0.5，对应 8-bit 的 128。但码值不是光。把 0.5 按 sRGB 解码回线性光：

$$\left(\frac{0.5+0.055}{1.055}\right)^{2.4}\approx0.214$$

只有白的 21%。真正「一半的光」是线性值 0.5，编码回去是

$$1.055\times0.5^{1/2.4}-0.055\approx0.735$$

也就是 8-bit 的 188。直接平均码值，结果比正确答案暗了约 1.2 档。

在码值上做平均，等于按错误的比例混合光。细密的亮暗纹理缩小后整体发暗，模糊后的高光边缘发灰。「线性」有多种意思。scene-linear 正比于场景光，对于传感器数据而言。display-linear 正比于屏幕发出的光，对于 tone mapping 之后、显示编码之前的数据而言。

14-bit：浪费的码值

人眼不是线性的。韦伯定律表示人分辨的是亮度的比例而不是绝对值。人能分辨 1 和 2 的差别（翻倍），却很难分辨 100 和 101 的差别（1%）²。Poynton 用一个简单的计算说明了线性存储的浪费。假设场景对比度 100:1，要求相邻码值的亮度差不超过 1%。线性编码每步加固定的绝对亮度，需要

$$\frac{100-1}{0.01}=9900 \text{ 码值}\ \Rightarrow\ \lceil\log_2 9900\rceil=14 \text{ bit}$$

感知均匀的非线性编码每步加固定的比例，需要

$$\frac{\ln 100}{\ln 1.01}\approx463 \text{ 码值}\ \Rightarrow\ \lceil\log_2 463\rceil=9 \text{ bit}$$

同样的感知质量，线性要 14-bit，非线性只要 9-bit。RAW 动辄 12/14-bit 也正因为线性编码把大量码值浪费在人眼分辨不出的高光里。一个 14-bit 线性 RAW，上半部分（8192–16383）全部用来编码最亮的一档曝光。到第 10 档只剩 16 个码值可用、到第 13 档只剩 2 个。

线性工序

从传感器到工作空间，中间有几道工序：黑电平减法、白平衡、去马赛克、色彩矩阵、工作空间转换。

• 黑电平：减去暗电流和读出电路的偏置。
• 白平衡：用 R/G/B 乘数缩放三个通道，让白色看起来是白色。
• 去马赛克：从单通道马赛克插值出每个像素的 RGB；2/3 的颜色是猜的。
• 色彩矩阵：从相机 RGB 转到 XYZ，再转到工作空间（见下）。
• 工作空间：ProPhoto、ACEScg；宽色域的目的是不丢信息。

这些工序的出发点，大多是补偿传感器和光学系统的缺陷。暗电流和读出偏置、CFA 的单通道采样、光源色偏、相机光谱响应与人眼的差异。补偿的对象各不相同，但补偿的手段都是线性的，减法、乘法、加权平均、矩阵。

显示 gamma

CRT 的物理非线性

图像处理管线历史上首次引入曲线是为了克服硬件缺陷。1897 年，Karl Ferdinand Braun 发明了阴极射线管（CRT）。到了电视时代，CRT 成了唯一的显示技术。但 CRT 的亮度和输入电压是幂函数：

$$L \propto V^{\gamma},\qquad \gamma \approx 2.5$$

这个非线性来自电子枪阴极和栅极之间的静电学特性³。意味着送一个线性信号进去，中间调会被压暗，暗部几乎死黑。摄像机端必须预先施加一个反向的曲线来补偿。模拟电视时代的约定相当宽松，摄像机端大约用 0.45 次幂（$\approx1/2.2$），显示端的 CRT 大约 2.5，每台设备都略有出入。

幸运的巧合

这里发生了一件 Poynton 称之为「an amazing coincidence」的事⁴──CRT 的 gamma 恰好近似于人眼亮度感知的倒数。

CIE $L^*$ 明度公式用立方根逼近人眼 $L^* \propto Y^{1/3}$。Stevens 的亮度感知指数约为 $1/3$。CRT gamma 的倒数是 $1/2.5=0.4$。这两个数工程上足够接近，意味着摄像机端施加的补偿曲线（约 $V^{0.45}$）本来只是为了对冲 CRT 的非线性，却同时实现了感知均匀的编码。前文已提到，感知均匀编码只需要 9-bit 就能做到线性 14-bit 的效果。于是摄像机端的 gamma 压缩一石二鸟，既补偿 CRT，又获得更高效的传输编码。

而到了 CRT 端，显示器自身的 $V^{2.5}$ 特性自然地把信号解码回线性光，不需要任何额外的解码电路。整个系统只需要在摄像机端放一个编码函数。这在模拟电视时代是一个巨大的工程优势。

BT.709

1980 年代末，高清电视从模拟走向数字。数字意味着信号要被量化，不能再靠「大家的 gamma 都差不多」这种约定俗成。1990 年，ITU 发布了 BT.709，为 HDTV 定义了统一的原色、D65 白点和传输函数⁵。

BT.709 的 OETF 是一个分段函数：

$$V'=\begin{cases} 4.5V, & 0\le V<0.018,\\ 1.099V^{0.45}-0.099, & 0.018\le V\le 1. \end{cases}$$

暗部要加一段线性段是因为纯幂函数 $V^{0.45}$ 在原点处的导数趋于无穷，暗部的微小光照变化会被放大成极端的信号变化，摄像机的暗部噪声会爆炸。用一段斜率固定为 4.5 的线性段替代暗部把增益限制住⁶。

接缝的位置需要满足两段在接缝 $\beta$ 处既要值相等、也要斜率相等，线性段恰好与幂函数段相切：

$$4.5\beta=\alpha\beta^{0.45}-(\alpha-1),\qquad 4.5=0.45\,\alpha\beta^{-0.55}$$

数值解出 $\beta\approx0.018054$、$\alpha\approx1.099297$，标准把它们取整为 0.018 和 1.099。

此 Gamma 非彼 gamma

「Gamma」细究起来至少有三层意思：

1. 编码 gamma：摄像机 OETF 的指数，BT.709 是 0.45。
2. 显示 gamma：显示器 EOTF 的指数，通常在 2.2–2.4 之间。
3. 系统 gamma：编码和显示两级曲线合起来的效果，即场景光 => 屏幕光的 OOTF（opto-optical transfer function），通常在 1.0–1.2 之间。它取决于观看环境：环境越暗，画面需要的反差越强。

LCD/OLED 还甩不掉 gamma

LCD 的物理响应由液晶分子的偏转决定，OLED 由有机材料的电致发光决定，两者都与 CRT 并不相似，它们的驱动电路却被刻意设计成模拟 CRT 的 gamma 响应。事实上整个影像生态已经建立在 gamma 编码上。从摄像机端的 BT.709，到 JPEG/H.264/HEVC 的假设，到操作系统的 ICC TRC，到全世界数十亿张网络图片——所有这些都假设显示端会对信号施加一次近似 $V^{2.2}$ 的非线性响应。如果某家厂商出一块「物理线性」的屏幕，所有现存图片在上面都会显示非预期效果。行业的「惯性」在此尤为突出。

Log

胶片在做 Log

Log 属于第二条曲线，它的作用稍微抽象，它不把场景变成屏幕显示，而是把场景光装进一个更均匀的容器。1890 年，Hurter 和 Driffield 定义了摄影浓度 $D$：底片透射率 $T$ 的倒数取以 10 为底的对数，$D=\log_{10}(1/T)$。透过 1/10 的光是浓度 1，透过 1/100 是浓度 2。他们发现，在胶片的直线部分，浓度和曝光量 $H$（照度 $I$ 乘时间 $t$）的对数成正比：

$$D=\gamma\left(\log_{10}H+C\right),\qquad H=I\cdot t$$

这里的 $\gamma$ 就是摄影里「gamma」一词的最初来源——它描述胶片对曝光量对数的响应斜率⁷。换言之胶片天然就在做 Log 编码。胶片把巨大的动态范围压缩到浓度值的较小范围内，而浓度本身是对数的。胶片的密度曲线和后来数字电影里的 Log 曲线形状非常相似；富士的胶片模拟（Film Simulation）更是直接以自家胶片命名，以胶片的影调和色彩为参照。

Cineon：把胶片浓度数字化

1993 年，柯达推出 Cineon，第一个完整的数字电影后期流程⁸。该流程用 10-bit 数字编码胶片浓度——浓度本身是对数的，所以 Cineon 本质上是 log 空间的线性采样。10-bit 给出 1024 个码值，码值 95 对应参考黑，685 对应参考白，每个码值 0.002 密度，整个范围约 2.046 log-D。这套编码成了数字电影后期的 Rosetta Stone。SMPTE 后来把它标准化为 DPX。现如今在 DaVinci Resolve 里打开一个 DPX，其编码逻辑和 1993 年的 Cineon 一脉相承。

现代 Log 曲线

当数字摄影机取代胶片扫描，传感器输出的是线性数据，但后期工作流仍然需要 Log 编码，依然由于行业惯性──调色师的直觉和工具都建立在 Cineon 的 log 空间上。

曲线	厂商	典型动态范围	备注
LogC3	ARRI	~14.5 档	EI 相关
LogC4	ARRI	~17+ 档	EI 无关，2022 年随 ALEXA 35 推出
S-Log2/S-Log3	Sony	~15.5 档	S-Log3 更接近 Cineon 密度映射
V-Log	Panasonic	~14 档	基于 Cineon 曲线
Log3G10	RED	~16 档	以 $\log_{10}$ 为基，0.18 映射到 1/3
C-Log3	Canon	~16+ 档	Cinema EOS 系列
F-Log2	Fujifilm	~14+ 档	GFX / X-H2S 系列

不同 Log 曲线之间并没有简单意义上优劣之分，每家传感器的动态范围、噪底、ADC 位深都不同。Log 曲线的本质是在有限的编码空间里，把码值高效地分配给特定传感器的特定动态范围。以 ARRI LogC4 为例⁹，它是一个分段函数：

$$E'=\begin{cases} \dfrac{\log_2(aE+64)-6}{14}\,b+c, & E\ge t,\\[6pt] \dfrac{E-t}{s}, & E<t, \end{cases}$$

其中

$$a=\frac{2^{18}-16}{117.45},\qquad b=\frac{1023-95}{1023},\qquad c=\frac{95}{1023},$$

这里和 BT.709 的特殊处理如出一辙。对数段加一段线性 toe，$t$ 和 $s$ 同样由接缝处值相等、斜率相等解出。幂函数在 0 处斜率无穷，对数在 0 处干脆是负无穷。所以每条实用曲线在最暗的地方都要接一段直线。中灰 $0.18$ 映射到 $0.2784$。

Log 不是 gamma，不是色彩空间

Log 是 scene-referred 编码，它编码场景光，但并不得到显示光。它不是显示 gamma，不是色彩空间。一个色彩空间至少包含原色、白点和传输函数。Log 只是传输函数/编码。Log 还有一个副作用恰好是一个很好的 LUT Shaper。

现在场景光已经被装进一个容器了，接下来解决这个容器里的光怎样变成屏幕上显示的光。

色调映射

从场景到显示

场景没有天然的「白」，太阳、路灯、窗外的天空可以「比亮更亮」，但是屏幕有可显示亮度上限。第三条曲线要决定场景里的 14 档（动态范围，或更多）光，如何合理映射到屏幕的 10 档（或者 HDR 的更多档）里。Scene-referred 的数据保留的是场景光，display-referred 的数据描述的是屏幕光，连接两者需要一条 tone curve。

tone curve 要决定高光在哪里 roll-off、黑点在哪里、中间调的斜率、整体反差有多强。这些都是审美决定，不是物理定律，没有绝对的 ground truth。tone curve 可以是参数化函数（filmic、ACES），也可以是一张 1D LUT。它的形状决定画面的「风格」。

Filmic 与 ACES

胶片的特性曲线是一条 S 形，暗部有 toe，中间接近直线，高光有 shoulder，不同的胶片型号有不同的 S 曲线。数字时代的 filmic 曲线在模仿这个形状。ACES 是其中最完整的一套：IDT => LMT => RRT => ODT。RRT 负责把场景光渲染成显示参考，ODT 负责适配具体显示设备。ACES 1.1 把 RRT 和 ODT 合并成 Output Transform；ACES 2 又把它拆成 Rendering Transform 和 Display Encoding Transform¹⁰。

曲线在哪里

上面那张银杏图里，被压扁的不只是明暗，还有颜色。

最直接的 tone mapping，是把同一条曲线分别套在 R、G、B 三个通道上（ACES 1）。灰色的三个通道相等，套完仍然相等。一个亮而饱和的黄色，R 和 G 已经爬上曲线的肩部但 B 还在中段，三个通道被压缩的比例无法一致，因而色相也随之改变。

举例来说，把这张图里亮而饱和的银杏像素挑出来。场景光约 85°，直接裁切后跳到约 109°，偏向黄绿。逐通道的 Hable 也偏了约 10°。倘若只对亮度套同一条 Hable、保持 RGB 比例不变，色相纹丝不动，则会有约四分之一的像素有通道超出 1，越出了显示色域。

所以 tone mapping 不只要决定曲线的形状，还要决定曲线套在哪个坐标上。ACES 2 换到一个把明度、视彩度和色相分开的感知空间 JMh 里。只压明度 J，视彩度 M 另行处理，色相 h 原样保留¹¹。这又引出一个问题，哪个空间才能把明度和色相真正分开？

OKLab

最容易想到的是 HSL/HSV，但它们在感知上不均匀。同样标着 L = 50%，黄和青很亮、蓝很暗。CIE Lab 改善了亮度均匀性，但在蓝色区域有著名的「蓝色噩梦」，降低 chroma 会看到色相偏紫。OKLab 用 LMS 立方根加两个矩阵以解决这个问题¹²。它被 CSS Color Level 4 采纳为 oklab() / oklch()，也被 Figma 和很多调色工具用于插值和选择性色彩。

Gamma 不是 tone curve

• gamma 是编码：它把线性光映射成码值，目的是高效存储/传输；它是坐标变换，由标准规定，编码和解码必须互逆。
• tone mapping 是渲染：它把场景光映射成显示光，目的是决定画面看起来像什么；它是审美/工程选择，没有唯一答案。

两者都可以是曲线，都可以用 LUT 实现。Log 也是曲线，但它只负责把场景光装进容器，不负责「好看」。区分它们仅仅取决于处理管线上的位置和目的。

局部 tone mapping

全局 tone mapping 对整张图用同一条曲线，局部 tone mapping 会根据像素周围的内容调整曲线，比如提亮阴影、压暗高光、增加局部对比。局部算子能救回更多细节，但也容易产生 halo。HDR 显示让 tone mapping 多了一个维度，同一段场景光，可以渲染到 SDR，也可以渲染到 HDR。

显示编码与色域映射

EOTF 与 OETF

第四条曲线站在色彩管线的另一端。第一条曲线讲的是 gamma 从哪里来。摄像机端的 OETF 把场景光编码成码值（光 => 码值），CRT 的物理特性再把它解回屏幕光。到了管线末端，方向也随之相反，tone mapping 之后已经得到显示线性的光，要按特定标准写成屏幕读得懂的码值。显示标准规定的是 EOTF（码值 => 显示光），编码时用的是它的反函数。

sRGB

1996 年，HP 和 Microsoft 联合提出了 sRGB¹³。它的思路不是设计一套理想的新空间，而是描述当时 CRT 显示器的平均行为。如果所有人都同意「没有标注色彩空间的 RGB 数据默认是 sRGB」，那大多数图片在大多数显示器上看起来大致正确。

sRGB 和 BT.709 共享完全相同的原色和 D65 白点¹⁴，但传输函数略有不同，而且站在管线的两端。BT.709 规定的是摄像机端的 OETF，它的显示端直到 2011 年才由 BT.1886 补上，sRGB 规定的是显示端。sRGB 的编码方向（EOTF 的反函数）同样是分段函数：

$$V'_{\text{sRGB}}=\begin{cases} 12.92V, & 0\le V<0.0031308,\\ 1.055V^{1/2.4}-0.055, & 0.0031308\le V\le 1. \end{cases}$$

指数是 $1/2.4$，而不是 BT.709 的 $0.45\approx1/2.22$，但这不意味着 sRGB 更「弯」。0.055 的偏移把幂函数段整体抬了起来，合起来的曲线贴着一条纯 2.2 次幂，码值 0.5 按 sRGB 解码是 0.214，按纯 2.2 次幂是 0.218。这组式子的效果，是紧贴一条 gamma 2.2 曲线，再加一点偏移，让它在整数运算里可逆¹⁵。

衔接位置还是 BT.709 类似处理。让线性段与幂函数段相切，解出的斜率是 12.92，接缝在线性值 0.00304、码值 0.03928，这正是 1996 年提案里的数字。1999 年 IEC 61966-2-1 标准化时修正了一个取整误差，把斜率 12.92 当作定值，重新求它与幂函数段的交点，得到码值 0.04045，再除以 12.92 得到 0.0031308。两段的值接上了，斜率却留下一个几乎看不见的折角¹⁶。

PQ 与 HLG

SDR 的曲线都是相对的，码值 1.0 就是「这块屏幕的白」，具体多少 nit 由屏幕决定。但是 HDR 由于屏幕水平实在参差不齐，换了另外两种思路。PQ（SMPTE ST 2084）是绝对亮度编码，每个码值对应一个确定的 nit 数，最高 10000 nit，曲线按人眼在不同亮度下的辨别阈值设计。HLG（BT.2100）沿用相对编码，下半段是平方根、接近传统 gamma，上半段换成对数，峰值随着显示器影响。

色域映射

工作空间可能比显示色域大。ProPhoto、ACES AP0 都包含人眼看不到的「想象色」。把它们直接送到 sRGB 屏幕，超出三角形的颜色必须被映射。常见策略有裁切（clip）、相对色度（relative colorimetric）、感知（perceptual）。裁切最简单，但会把超出的颜色压到边界，色相可能偏移。感知映射会压缩整个色域，保留颜色之间的关系。很多 RAW 管线采用更直接的策略，在宽色域线性空间里计算，最后做矩阵变换，把负值截到 0，套上 sRGB 曲线，再逐通道 clamp。代价是饱和度极高的颜色在越界时会被逐通道截断，色相可能偏移。

标准	年代	背景	xy 三角形面积（sRGB = 1）
NTSC	1953	第一代彩色电视	1.41
PAL / EBU	1970 年代	标清电视	1.01
BT.709 / sRGB	1990 / 1996	高清电视 / 计算机	1.00
DCI-P3	2005	数字电影放映	1.36
BT.2020 / BT.2100	2012 / 2016	超高清 / HDR	1.89
ProPhoto RGB	约 2000	摄影工作空间	2.47
ACES AP1	2012	电影工业工作空间	2.01
ACES AP0	2012	电影工业交换空间	3.53

这张表里的面积是按原色坐标算的 xy 三角形面积¹⁷。NTSC 1953 比 sRGB 还大；sRGB 和 BT.709 共享同一个三角形；ProPhoto 包含想象色；ARRI AWG4 的蓝色原色甚至有一个负的 $y$ 坐标。

JPEG

曲线到了文件里，还要变成离散的码值。8-bit 只有 256 级，平滑的渐变会被量化成阶梯，暗部容易出现 banding 断层。dither 可以打散阶梯，但会增加噪声。JPEG 最后一站 RGB => YCbCr、色度 subsampling（常见 4:2:0）、8×8 DCT、量化、Huffman 编码¹⁸。

LUT

LUT 本身作为打表插值优化曲线计算的手段，可以成为上述任何曲线乃至组合的实际运算方式。1D LUT 是一条曲线；3D LUT 是一个三输入三输出的向量函数。3D LUT 把 RGB 立方体切成网格，每个节点存一个输出 RGB，节点之间用三线性或四面体插值。1D LUT 常用来做曲线，3D LUT 常用来做跨通道的色彩变换。LUT 可以装下前面四条曲线：它可以是一条显示编码曲线（1D），可以是一段 Log 转换（1D/3D），可以是一条 tone curve（1D），也可以是一个完整的 3D 色彩变换。

Shaper 是 LUT 的一个前置 1D 曲线，用来重新分配节点。Log 是一个好 Shaper，它大致按感知均匀分配节点，每一档分到的数量差不多，到了噪底附近，LogC4 的 toe 反而让节点变稀，因为不值得为噪声花节点。我会在下一篇博客中着重解释 LUT。

后

借助 Claude Opus 5.5 完成部分文章配图。绝大部分知识由我与 ChatGPT 反复对话、使用 Codex 实现 LumaForge 过程与复盘中习得，最终行文由我独立梳理。

参考文献

• Poynton, C. (1998). Rehabilitation of Gamma. Proc. SPIE 3299.
• Poynton, C. Gamma FAQ. https://www.poynton.ca/faq/gammafaq/GammaFAQ.pdf
• Poynton, C. & Funt, B. (2014). Perceptual uniformity in digital image representation and display. Color Research and Application, 39(1), 6–15.
• Hurter, F. & Driffield, V.C. (1890). Photo-Chemical Investigations and a New Method of Determination of the Sensitiveness of Photographic Plates. J. Soc. Chem. Ind., IX(5).
• Rowlands, D. A. (2020). Color conversion matrices in digital cameras: a tutorial. Optical Engineering, 59(11), 110801.
• Adobe (2023). Digital Negative (DNG) Specification, Version 1.7.0.0.
• ITU-R BT.709-6 (2015). Parameter values for the HDTV standards for production and international programme exchange.
• ITU-R BT.1886 (2011). Reference electro-optical transfer function for flat panel displays used in HDTV studio production.
• ITU-R BT.2020-2 (2015). Parameter values for ultra-high definition television systems for production and international programme exchange.
• ITU-R BT.2035-0 (2013). A reference viewing environment for evaluation of HDTV program material or completed programmes.
• ITU-R BT.2100-2 (2018). Image parameter values for high dynamic range television for use in production and international programme exchange.
• SMPTE ST 2084:2014. High Dynamic Range Electro-Optical Transfer Function of Mastering Reference Displays.
• Stokes, M., Anderson, M., Chandrasekar, S. & Motta, R. (1996). A Standard Default Color Space for the Internet — sRGB, Version 1.10. https://www.w3.org/Graphics/Color/sRGB.html
• IEC 61966-2-1:1999. Multimedia systems and equipment — Colour measurement and management — Part 2-1: Default RGB colour space — sRGB.
• Khronos Group. Khronos Data Format Specification, v1.4, §13 Transfer functions. https://registry.khronos.org/DataFormat/specs/1.4/dataformat.1.4.html
• W3C (2023). Web Content Accessibility Guidelines (WCAG) 2.2, definition of relative luminance. https://www.w3.org/TR/WCAG22/
• ARRI (2022/2023). ARRI LogC4 Specification. https://www.arri.com/resource/blob/278790/db65b86066de1f74852edb8f15acf082/2023-05-arri-logc4-specification-data.pdf
• Academy of Motion Picture Arts and Sciences. ACES Output Transforms. https://draftdocs.acescentral.com/system-components/output-transforms/
• Ottosson, B. (2020). A perceptual color space for image processing. https://bottosson.github.io/posts/oklab/
• ITU-T Recommendation T.81 (1992). Information technology — Digital compression and coding of continuous-tone still images.
• CIE 015:2018. Colorimetry, 4th Edition.

Footnotes

1. 真实传感器偏离理想线性的来源包括：暗电流、读取噪声、接近满阱的非线性、部分高 ISO 实现中的模拟增益非线性。但在标称动态范围内，线性假设是工程上成立的。 ↩

2. 韦伯分数在实际观看条件下约为 1–2%。Poynton 用保守的 1% 推导。 ↩

3. Poynton 的 Gamma FAQ 中明确指出：CRT 的非线性来自电子枪阴极和栅极的静电学，与荧光粉无关。 ↩

4. Poynton 后来修正了这个说法：印刷中的半色调网点增益也呈现类似的感知匹配，暗示这可能是系统性现象，而非纯粹的巧合。 ↩

5. ITU-R BT.709 的全称是 Parameter values for the HDTV standards for production and international programme exchange——定语就是为了解决互通性问题。 ↩

6. BBC RD 1991/6 报告（A. Roberts）记录了这个噪声最小化设计理由。精确值 $\beta=0.018053968510807$、$\alpha=1.099296826809443$ 见于 BT.2020 的 12-bit 参数；取整后的两段在接缝处有约 0.0002 的跳变，大约是 12-bit 的一个码值。 ↩

7. Hurter, F. & Driffield, V.C. (1890). Photo-Chemical Investigations and a New Method of Determination of the Sensitiveness of Photographic Plates. Journal of the Society of Chemical Industry, IX(5). ↩

8. Cineon 采用 10-bit 对数编码，覆盖约 2.046 个 log-D 范围的胶片浓度。ARRI 的 LogC 系列中「C」即代表 Cineon。 ↩

9. ARRI (2022/2023). ARRI LogC4 Specification. https://www.arri.com/resource/blob/278790/db65b86066de1f74852edb8f15acf082/2023-05-arri-logc4-specification-data.pdf ↩

10. ACES. Output Transforms. https://draftdocs.acescentral.com/system-components/output-transforms/ ↩

11. ACES 2 的 JMh 来自简化版的 Hellwig 2022 色貌模型，J 对应明度，M 对应视彩度，h 对应色相。文档的说法是：tone mapping 只作用于 J、M 单独调整，这样才能保持原始色相；ACES 1 则直接在 AP1 RGB 的各通道上做 tone mapping。 ↩

12. Ottosson, B. (2020). A perceptual color space for image processing. https://bottosson.github.io/posts/oklab/ ↩

13. https://www.w3.org/Graphics/Color/sRGB.html —— W3C 的 sRGB 规格页至今仍是互联网色彩空间的事实标准参考。 ↩

14. 这意味着从颜色范围（色域三角形）的角度看，sRGB 和 BT.709 是同一个色域。差异在传输函数和观看条件假设。 ↩

15. 原文：「The effect of the above equations is to closely fit a straightforward gamma 2.2 curve with an slight offset to allow for invertability in integer math.」Khronos Data Format Specification 量化过这个「紧贴」：按 8-bit 量化，sRGB 与纯 2.2 次幂在同一线性值上最多差 3 个码值。 ↩

16. 两组阈值在 8-bit 下没有实际差别，但旧值流传得很久：WCAG 的相对亮度公式一直沿用 0.03928，直到 2021 年 5 月才改为 0.04045。 ↩

17. CIE 1931 xy 色度图本身并不感知均匀，面积比只能粗略比较「三角形有多大」，不等于「能显示多少种可分辨的颜色」。 ↩

18. ITU-T Recommendation T.81 (1992), Information technology — Digital compression and coding of continuous-tone still images. https://www.itu.int/rec/T-REC-T.81/en ↩