1 概念与基础
1.1 RGB 与线性化的含义
RGB 是以红（R）、绿（G）、蓝（B）三个通道来描述颜色的方式。线性 RGB 指的是：当 R、G、B 通道的数值发生等比例变化时，这种变化能近似对应到相应通道所代表的光能量或光强响应的等比例变化。换言之，通道值与“亮度/能量”之间的关系接近线性，而不是被显示设备或编码规则做过非线性的压缩。
在实际应用中，“线性化”通常意味着：把从某个编码空间读入的非线性 RGB，经过反变换还原为与物理亮度更接近的线性表示；随后再进行混合、插值或光照等计算。
1.2 线性与非线性（伽马）差异
非线性 RGB（常见于显示端的编码形式）会把较暗区域的数值分辨率安排得更“细”，以适配人眼对亮度变化的敏感性或设备传输特性。伽马校正/传递函数的存在，会导致“数值相加或插值”的结果不再对应真实的亮度相加或线性混合。
因此，相同的数值运算在不同空间含义不同：在非线性空间直接进行混合，得到的视觉效果往往偏暗、偏灰或对比度异常；在线性空间进行同类运算，结果更符合直觉与物理规律。
1.3 物理意义：从光强到编码值
从物理角度看，发光或反射的能量在光学意义上可以近似用光强描述。线性 RGB 试图让编码值与光强（或与其成正比的响应量）保持接近的比例关系。相对地，显示设备或标准可能采用传递函数，把线性量映射到更适合传输和显示的编码量。
需要注意的是，“近似线性”并不等同于完全等价于所有真实光学过程：不同系统对光谱分布、设备响应、以及色度基准的处理仍会造成偏差。但在线性化的工作空间里，至少在常见计算步骤（加法混合、能量累积）上能显著改善一致性。
1.4 典型使用场景：计算而非直接显示
线性 RGB 常作为“计算空间/工作空间”使用：例如渲染时对纹理进行采样后做光照累积、在后处理阶段进行亮度相关的滤波和增强、以及在图像处理流程中进行更可靠的插值与融合。
而当结果要输出到显示器或需要与常见文件格式一致时，通常还需进行从线性到目标编码空间的变换（例如变回 sRGB 类的非线性编码），以便显示端以正确的方式解释这些数值。
2 颜色空间与编码
2.1 典型相关空间：sRGB、Rec.709 等概述
sRGB 与 Rec.709 是常见的非线性编码/色彩传输相关标准（在不同上下文中可能还伴随特定的色度基准与传递函数）。它们的编码值在传输与显示链路中表现稳定，但不适合作为直接做能量守恒式计算的“物理量”。
在工程实践里，经常出现“输入来自文件/纹理是 sRGB 风格编码”“渲染计算使用线性空间”“输出再转回显示/文件所需的非线性编码”的链路结构。
2.2 线性化的来源：伽马/传递函数
线性化的依据是某种传递函数。该函数定义了：在线性量与编码量之间如何进行非线性映射。线性 RGB 需要执行与其对应的反变换，从编码量恢复到更接近线性光强的量。
在实现上，线性化可以是查表、分段函数或解析形式的函数求值。关键在于：使用与输入编码一致的传递函数，否则线性化会不正确，进而影响混合和亮度运算。
2.3 编码与解码流程（简述）
一个常见流程可以概括为：
- 读取/采样得到的 RGB，默认处于某个标准编码空间（通常带非线性）。
- 对 R、G、B 分通道执行解码，得到线性 RGB（线性化）。
- 在渲染、混合、插值、光照等步骤中使用线性 RGB。
- 在输出阶段，对计算结果进行编码（与目标显示/文件编码一致），并写入帧缓冲或图像文件。
虽然不同平台、API 或引擎细节不同，但“解码—计算—编码”的思想较为普遍。
2.4 白点与色度基准对线性 RGB 的影响
线性化讨论常聚焦“伽马/传递函数”，但线性 RGB 也与色度基准相关。白点（色温/亮度基准）以及色彩原色基准会影响同一组数值在可见颜色空间中的对应位置。换言之，即使做到线性，若颜色空间基准不匹配，仍可能出现偏色。
因此在严格色彩管理中，线性化通常与色彩变换（例如从一个色度基准到另一个色度基准）共同考虑。单独只做伽马反变换而忽略色度基准，可能导致灰度不中性、肤色偏移或整体色偏。
3 数学与图像处理操作
3.1 线性空间中的加法与混合
在线性 RGB 中，通道数值可更接近地视作与能量相关的量，因此加法混合和叠加更符合直觉。例如多项光贡献叠加时，线性空间的累积能更准确地体现“亮度随能量增加”的规律。
这也是线性 RGB 在渲染里受到偏爱的原因之一：当不同光源、反射项或纹理层的贡献需要以“物理意义的方式”累积时，线性空间更不容易引入额外的非线性偏差。
3.2 插值策略：颜色插值与亮度插值
插值常用于缩放、旋转、纹理采样过滤等操作。若直接在非线性空间插值，暗部与过渡区域可能出现不期望的灰化或对比度扭曲。在线性 RGB 中进行插值，过渡往往更顺滑，亮度的变化也更接近物理直觉。
同时需区分：有些艺术效果可能希望在非线性空间或特定感知空间里进行插值以获得特定风格；但在追求一致的能量与亮度行为时，线性插值通常更可靠。
3.3 归一化与缩放：数值范围处理
线性 RGB 的数值范围处理与“数据类型”密切相关。常见情况包括：
- 标准动态范围（SDR）纹理/帧缓冲可能在 0 到 1 之间表示线性光强的某种归一化量。
- 高动态范围（HDR）管线可能允许超出 0 到 1 的值，以容纳高亮区域的能量。
- 不同格式的位深（8-bit、16-bit、浮点）决定了可表示的精度与动态范围。
归一化不仅影响显示结果，也影响计算的数值稳定性：在需要保持能量守恒或避免截断时，应避免过早的钳位与错误缩放。
3.4 舍入误差与动态范围注意事项
线性化会把原本非线性的编码精度分布“重新映射”到线性量上。若数据位深较低，线性空间中暗部可能更容易受到量化误差影响，导致微妙的噪声或条带。
此外，线性空间的运算链路更依赖动态范围。若中间结果被限制在较窄范围或使用低精度格式，可能出现溢出、截断或累计误差，从而让最终画面发灰、发暗或出现亮度异常。
4 渲染与计算管线中的角色
4.1 渲染管线：从纹理到帧缓冲
在渲染管线里，线性 RGB 通常扮演“中间计算的语言”。纹理采样可能从带编码的资源中读取（例如标记为 sRGB 的纹理），此时引擎往往会自动或显式进行解码，得到线性 RGB；随后在着色器中进行光照、材质响应和混合。
当渲染结果写入帧缓冲并准备显示时，还会根据目标输出编码（以及可能的显示伽马）进行相应的编码或转换。
4.2 光照计算为何偏好线性 RGB
光照模型中的许多步骤都可被看作对“能量贡献”的组合：例如漫反射与镜面反射项的累加、多个光源的叠加、以及基于材质参数的调制。若在非线性空间直接进行这些操作，贡献的相加关系会被传递函数扭曲，导致亮度不符合预期。
在线性空间中，相关计算更接近“输入与输出随能量按比例变化”的假设，从而减少偏差并提升一致性。
4.3 后处理（Bloom、Tone Mapping）中的空间要求
后处理往往对亮度或对数/感知映射敏感。例如 Bloom 需要从高亮区域提取并模糊再叠加；若提取阈值或权重在非线性空间执行，阈值对应的实际亮度可能被改变，导致效果偏弱或偏强。
Tone mapping 属于从高动态范围到显示可用范围的映射步骤。通常会在光照累积后的线性（或更高精度的）空间进行，再根据具体映射策略转入目标显示范围。不同实现细节虽不同，但“在合适的空间做合适的变换”是共同原则。
4.4 索引/查表在不同空间中的选择
查表（LUT）用于加速映射或精确还原复杂函数。在伽马转换、色彩校正或特定后处理里常见。是否在 LUT 中处理线性或非线性取决于 LUT 的定义与输入数据的含义：
- 若 LUT 的设计目标是把编码值映射到编码值（例如替换传递函数），它可能期望输入是非线性的编码量。
- 若 LUT 用于模拟物理或线性量的变换（例如某些亮度相关曲线或校正策略），则更可能基于线性输入构建。
因此工程上应确认 LUT 的输入输出语义，避免“用错空间导致曲线看起来怪异但又不易立刻察觉”。
5 色彩管理与工作空间
5.1 工作空间的选择原则
选择工作空间时通常考虑：
- 计算目标：是做能量/亮度相关运算，还是仅做感知风格调整。
- 输入资源的编码：纹理、视频流、图像文件往往来自不同标准。
- 输出设备：显示器、打印或导出格式要求的色域与传递函数。
- 精度与动态范围：位深与浮点精度影响误差累积。
对多数需要物理一致性的渲染与处理而言，线性 RGB 常是理想的中间空间；但在最终呈现时仍需回到目标的色彩与编码规范。
5.2 ICC/色彩管理与线性化关系（概述）
ICC 色彩管理框架描述了设备之间如何通过配置文件进行色彩转换。ICC 配置通常涵盖色度基准、传递函数以及色域映射。在线性化与色彩变换的关系上，可以概括为：线性化解决“传递函数/伽马带来的非线性问题”，而 ICC 转换强调“色度与设备响应差异带来的颜色映射”。
在完整的色彩管理流程里，往往会先把输入解码到与转换模型匹配的表示，再执行跨设备的色彩变换，最后编码到输出端需要的形式。是否严格遵循取决于系统实现，但原理上是分层解决两个问题：能量语义与颜色语义。
5.3 在设备之间的转换链路
设备之间的转换链路可以很抽象地理解为“从输入设备语义到统一表征，再到输出语义”。在这一链路里，线性 RGB 通常出现在“中间阶段”的概率较高，因为它利于进行更符合物理/数学性质的运算与插值。
转换过程中可能涉及多步处理：色度映射、基于传递函数的编码/解码、以及色域裁剪或重映射。链路越长、使用的中间精度越低，越可能引入偏差或损失细节。
5.4 校准与一致性：从显示到离线计算
一致性的关键在于：离线计算、线上渲染、以及最终显示之间的差异要尽可能被模型化并对齐。校准不仅涉及亮度与对比度，也涉及色彩基准和传递函数的解释方式。
实践中常见挑战包括：同一资源在不同软件里被当作不同编码（例如被误当作线性或误当作 sRGB），导致亮度与色相同时偏移。通过明确资源标记、统一工作空间策略、并在导出/显示阶段使用正确编码，能显著降低这种不一致。
6 实践建议与常见陷阱
6.1 “把伽马当线性”的典型错误
一个高频错误是：在非线性编码的图像上直接做线性空间的运算。表现通常为：
- 混合看起来发灰或对比度异常；
- 暗部过暗或高光过亮（取决于具体混合与映射）；
- Bloom、滤波等亮度相关效果强度不符合预期。
解决方式往往是：确保在进行能量相关运算前将数据线性化，并在输出前再进行正确编码。
6.2 什么时候必须线性化、什么时候不需要
一般而言，以下情况更需要线性化（或在语义上等价的线性工作空间）：
- 光照计算与材质响应累积；
- 多层透明叠加、能量加法类的混合；
- 需要更准确亮度插值的缩放/采样；
- 进行亮度阈值或基于亮度权重的后处理。
而在以下场景中可能不“必须”，但仍需谨慎：
- 纯粹的艺术风格曲线、仅为视觉效果而非能量一致性服务的操作；
- 已明确在感知空间或专门设计的色彩工具中进行的处理；
- 某些已经保证输入输出语义匹配的特效流程。
判断核心在于：你要的计算是否遵循“亮度/能量按比例”的直觉。若是，就应在线性空间进行。
6.3 渲染结果发灰/发暗的排查思路
当结果出现整体偏灰或偏暗，可从以下方向排查：
- 纹理/输入是否被正确解码为线性：资源标记（如 sRGB 标志）是否正确，解码步骤是否被执行。
- 混合与透明度是否在正确空间：透明叠加常对空间敏感。
- 是否出现过早钳位或错误的数值缩放：例如中间结果被截断到过窄范围。
- Tone mapping 或色调映射前后顺序是否匹配预期：某些步骤应基于更合理的动态范围输入。
- 颜色基准是否一致：白点或色域差异会让“灰”不再是中性灰。
这类问题通常不是单一原因，而是“语义错位”造成的连锁反应。
6.4 性能与精度权衡：速度、带宽、位深
线性化与再编码会引入额外计算或额外存储需求。若使用 LUT 或硬件加速，开销通常可控；但在大规模渲染或高分辨率视频处理里仍需权衡。
精度方面，浮点或更高位深能减少量化误差，但也带来更高带宽和存储成本。工程上常采用折中：在中间关键阶段使用足够精度，在非关键阶段保持较低成本。目标是：在可接受的性能预算内，把线性化带来的收益发挥出来，同时避免舍入误差变成可见瑕疵。
7 术语与相关技术
7.1 Gamma correction（伽马校正）
伽马校正指根据传递函数对编码/解码进行的非线性调整。其目的是把编码量与期望的亮度响应关联起来，使显示或传输后的视觉效果更符合设定目标。
在讨论线性 RGB 时，伽马校正的反变换通常用于从非线性编码恢复到线性量，或在输出阶段把线性结果重新编码到显示期望的形式。
7.2 色调映射（Tone mapping）
色调映射是把较高动态范围的颜色与亮度映射到适合显示设备的范围与分布的过程。它既涉及亮度的压缩，也可能涉及对比度与高光细节的重分配。
Tone mapping 与线性空间通常关系密切：因为输入的亮度累积更符合能量语义，后续映射的参数也更容易获得一致的视觉行为。
7.3 HDR 与线性空间的关系（概述）
HDR 通常意味着更宽的亮度范围与更高的可表达精度。在这种语境下，线性或接近线性的计算空间更有利于正确表达高亮能量如何衰减、如何叠加以及如何通过映射到显示端。
线性空间不自动等同于 HDR，但它为 HDR 计算提供了更稳健的基础语义，使得亮度跨范围运算更少偏差。
7.4 颜色缓冲与位深（8-bit、16-bit、浮点）
颜色缓冲位深决定了量化精度与动态范围。常见类型包括：
- 8-bit：体积小、速度快，但量化误差更明显，线性化后暗部可能更易出现噪声或条带。
- 16-bit：提升精度与动态范围，常用于更严谨的图像处理中间结果。
- 浮点（如 half/float）：动态范围更大，能更自然地承载线性空间中的高亮值与负值（取决于具体约定），便于 HDR 与复杂后处理。
在选择时，需要结合管线需求、目标平台性能以及可接受的误差范围。
8 轻量化“梗”式理解
8.1 “线性 RGB：能更诚实地做光照”——直观比喻
可以把线性 RGB 想成“把灯光当作能量来算”的工作方式：你多加一点光，它就按比例变亮，而不是被某个非线性规则先“藏起来”。因此光照叠加、混合的结果更不容易和直觉打架。
8.2 “别让伽马偷走你的亮度”——常见吐槽句式
伽马校正的作用本来是让显示更合理，但如果你在没线性化的情况下就开始混合和插值，就相当于把计算放进了“翻译不完整的剧本”：角色（数值）看起来说的是同一件事，实际上每句台词对应的亮度含义早就变了，于是亮度就被“偷走”或被改写。
8.3 线性化流程的“打怪升级图”（流程梗化说明）
从纹理读取开始，先确认它是不是带着“非线性外衣”（编码空间）；再把它脱掉（解码到线性）进入主战场（计算空间）。完成光照与后处理等“打怪”后，再给它穿回目标“展示皮肤”（编码到输出空间）。这套流程一旦顺起来，很多“怎么越改越怪”的bug就会明显少很多。