我第一次看到OKLAB时说实在话有点不耐烦。这几年颜色空间冒出来不少CIELAB用了几十年也没什么大毛病。直到我有一次在渐变里做高饱和插值看到中间那坨发黑的紫灰色才意识到老空间的问题比我想象的严重。这篇接着上一篇聊OKLAB颜色空间重点落在两件事颜色空间转换怎么做以及如何在OKLAB里确定一个RGB空间的色域边界。如果你正在做色彩插值、色域映射或者自己写颜色库这篇会非常对路如果你刚接触颜色科学、被各种Lab/LCH搞晕也能从里面找到可以直接抄的代码。1. OKLAB到底解决了什么问题先搞懂这个空间为什么值得用1.1 老空间的通病无处不在的“不均匀”色彩空间本质上是一个数学坐标系但人眼对不同颜色的敏感度差异很大。CIELAB通常叫Lab或Lab*当年被设计成感知均匀空间理论上坐标距离相等人眼感知的色差也相等。问题在于这个“理论上”折扣很大蓝色区域的距离感知被压缩得厉害饱和度越高越明显。实际做颜色混合或渐变时用CIELAB插值出来的中间色经常发灰、发闷尤其在红蓝之间、紫绿之间颜色会从一条“浑浊地带”穿过去。另一个常用空间HSL/HSV问题更严重。它的色相H只是一个简单角度但人眼对色相环不同位置的分辨能力完全不同。同一步长在不同色相上带来的视觉变化不相等这导致你在“调整色相”的时候颜色不是平滑过渡而是跳跃式移动。早期做前端取色器的时候靠着HSL拖拽色相看起来还行一旦拿去做连续渐变或色域映射就会露出马脚。OKLAB的设计目标就是把这些“不均匀”尽量压平。它希望做到欧几里得距离尽量等于感知色差色相环上的角度尽量对应真实的色相变化亮度轴单独分离出来。这样你在OKLAB里做插值、混合、色域映射都比在老空间里靠谱得多。1.2 OKLAB的核心思想模仿人眼的通路OKLAB建在LMS锥体响应之上。人眼有三种视锥细胞分别对长波、中波、短波敏感LMS就是模拟这三类响应的数值。OKLAB的转换路径大致是先把RGB线性化再通过一个矩阵转到LMS空间接着对LMS做立方根压缩最后用另一个矩阵把压缩后的值旋转到L、a、b三个轴上。立方根这一步很关键。人的视觉对亮度的感知不是线性的而是接近幂函数关系立方根就是对这个非线性的一种近似。很多老空间用对数或者说复杂的幂函数做压缩OKLAB直接用一个立方根简单而且效果不错。三个轴的语义也直观L是感知亮度a轴是红绿对立b轴是蓝黄对立。后面加上角度和长度就得到了OKLCHL是亮度C是饱和度的计量H是色相角。1.3 为什么“色域确定”在OKLAB里是刚需色域是设备能显示或捕捉的颜色范围。sRGB的色域在RGB空间里就是个正方体但经过OKLAB的非线性变换后它变成了一个扭曲的立体形状。你不能用简单范围判断了。而且人们使用OKLAB最频繁的两个场景——色彩插值和色域映射——都绕不开色域边界问题。插值时你要知道中间色有没有超出目标空间色域映射时你要知道超了多少、往哪个方向压。上一篇文章讲概念这一篇所有内容都围绕“怎么算出来”展开。2. 颜色空间转换全流程sRGB如何干净地进出OKLAB2.1 第一步sRGB非线性值必须先线性化进入OKLAB之前最容易被忽略的一步是gamma线性化。sRGB存储的数值不是物理亮度而是经过gamma编码的非线性值。你不做线性化直接把0-255或0-1的sRGB值扔进矩阵结果会偏离非常多尤其红色和蓝色通道偏移肉眼可辨。标准线性化公式分两段处理def srgb_to_linear(c): # c 是 0~1 范围内的非线性 sRGB 数值 if c 0.04045: return c / 12.92 return ((c 0.055) / 1.055) ** 2.4 def linear_to_srgb(c): # c 是线性 RGB if c 0.0031308: return 12.92 * c return 1.055 * (c ** (1 / 2.4)) - 0.0558bit颜色转到0-1区间时先用v / 255归一化再做线性化。注意阈值方向别搞反从sRGB到线性用0.04045从线性回到sRGB用0.0031308。网上有简写版本直接c ** 2.2或c ** 2.4精度差一些做专业颜色处理时还是用标准分段公式更稳。2.2 第二步线性sRGB转到LMS再转到OKLAB线性化之后进入官方矩阵。我第一次看到这三个矩阵时头很大实际上你可以把它们当作黑盒常量只需要保证使用精度足够的版本。下面这段是完整的正向转换函数import math def srgb_to_oklab(r, g, b): # r, g, b 是 0~1 的非线性 sRGB 值 r, g, b srgb_to_linear(r), srgb_to_linear(g), srgb_to_linear(b) # 线性 sRGB - LMS l 0.4122214708 * r 0.2119034982 * g 0.0883024619 * b m 0.2119034982 * r 0.6806995451 * g 0.1073969566 * b s 0.0883024619 * r 0.1073969566 * g 0.8115052253 * b # LMS 开立方根 l_ l ** (1 / 3) m_ m ** (1 / 3) s_ s ** (1 / 3) # 立方根 LMS - OKLAB L 0.2104542553 * l_ 0.7936177850 * m_ - 0.0040720468 * s_ a 1.9779984951 * l_ - 2.4285922050 * m_ 0.4505937099 * s_ b 0.0259040371 * l_ 0.7827717662 * m_ - 0.8086757660 * s_ return L, a, b这里有个细节值得留意官方给出的矩阵是直接从线性sRGB到LMS的合并矩阵不是先转XYZ再转LMS的中间形式。你不要拿标准sRGB转XYZ矩阵和某些XYZ转LMS矩阵自己拼拼出来的结果和官方矩阵对不上。直接用上面的常量就行。2.3 从XYZ或任意RGB空间进入OKLAB如果你的颜色不在sRGB里比如来自Display P3或Rec.2020那就不能直接套sRGB专用矩阵了。通用路径是线性RGB - XYZD65白点- LMS - 立方根 - OKLAB。XYZ到LMS的官方矩阵是def xyz_to_oklab(x, y, z): l 0.8189330101 * x 0.3618667424 * y - 0.1288597137 * z m 0.0329845436 * x 0.9293118715 * y 0.0361456387 * z s 0.0482003018 * x 0.2643662691 * y 0.6338517070 * z l_ l ** (1 / 3) m_ m ** (1 / 3) s_ s ** (1 / 3) L 0.2104542553 * l_ 0.7936177850 * m_ - 0.0040720468 * s_ a 1.9779984951 * l_ - 2.4285922050 * m_ 0.4505937099 * s_ b 0.0259040371 * l_ 0.7827717662 * m_ - 0.8086757660 * s_ return L, a, b注意OKLAB的矩阵是以D65白点为基准标定的。如果你处理的是D50白点的颜色比如很多打印流程要先做色适应转换把XYZ调整到D65否则亮度轴会偏。工程里大部分屏幕流程都是D65这个坑主要出现在印刷和ICC流程里。2.4 OKLCH色域边界讨论最顺手的坐标系OKLAB的L、a、b是直角坐标讨论色域时更适合转换成圆柱坐标OKLCH。C表示色度对应距离灰轴的长度H表示色相角。转换很简单def oklab_to_oklch(L, a, b): C math.sqrt(a * a b * b) H math.degrees(math.atan2(b, a)) % 360 return L, C, H def oklch_to_oklab(L, C, H): h math.radians(H) a C * math.cos(h) b C * math.sin(h) return L, a, b有了OKLCH色域边界可以这样描述固定亮度L和色相角H色度C从0开始往外走走到哪一步出界那个临界C就是该方向上的最大色度。这正是后面二分搜索法的理论基础。3. 逆转换从OKLAB回sRGB以及精度与边界处理3.1 逆转换也是三步矩阵、立方、再矩阵从OKLAB回到sRGB就是刚才流程的反向操作。先把L、a、b转回立方根LMS三个公式是l_ L 0.3963377774 * a 0.2158037573 * b m_ L - 0.1055613458 * a - 0.0638541728 * b s_ L - 0.0894841775 * a - 1.2914855480 * b然后对三个值分别立方得到线性LMSl l_ ** 3 m m_ ** 3 s s_ ** 3再用逆矩阵回到线性sRGBr_lin 4.0767416621 * l - 1.2684380046 * m - 0.0041960863 * s g_lin -1.2684380046 * l 2.6097574011 * m - 0.0417033603 * s b_lin -0.0041960863 * l - 0.0417033603 * m 1.3122414413 * s最后把线性值做gamma压缩就得到sRGB显示值。完整函数def oklab_to_srgb(L, a, b): l_ L 0.3963377774 * a 0.2158037573 * b m_ L - 0.1055613458 * a - 0.0638541728 * b s_ L - 0.0894841775 * a - 1.2914855480 * b l, m, s l_ ** 3, m_ ** 3, s_ ** 3 r_lin 4.0767416621 * l - 1.2684380046 * m - 0.0041960863 * s g_lin -1.2684380046 * l 2.6097574011 * m - 0.0417033603 * s b_lin -0.0041960863 * l - 0.0417033603 * m 1.3122414413 * s r linear_to_srgb(r_lin) g linear_to_srgb(g_lin) b linear_to_srgb(b_lin) return r, g, b这段代码里的矩阵是官方提供的近似值不同语言的库之间可能有小数点后几位差异不影响正常使用。但抄写时尽量复制完整的常量不要手敲省略位否则高饱和区域可能有轻微色差。3.2 一个最容易踩的坑负数开立方根正向转换时线性RGB都在0到1之间LMS组合后应该是非负值开立方根没有风险。逆转换时就不一定了。如果某个OKLAB颜色超出了sRGB色域逆转换得到的线性RGB可能带负值而负值的sRGB gamma压缩在数学上会出问题。假如你用的语言是Python(-0.1) ** (1/3)会返回一个复数后面再运算直接乱掉。JavaScript的Math.pow(-0.1, 1/3)会返回NaN。要处理这个问题可以统一用Math.cbrtJS或numpy.cbrtPython它们正确处理负数。我建议在逆转换后检查线性RGB的范围而不是在gamma压缩后检查因为gamma压缩本身对负数不友好。3.3 写一个“是否在sRGB色域内”的判断函数判断一个OKLAB颜色是否在sRGB色域内最可靠的方法就是逆转换到线性RGB然后检查三个通道是否都在0到1之间。注意要加上浮点容差边界上的颜色由于计算误差可能会在1.0000000001附近抖动。def oklab_in_srgb_gamut(L, a, b, eps1e-7): l_ L 0.3963377774 * a 0.2158037573 * b m_ L - 0.1055613458 * a - 0.0638541728 * b s_ L - 0.0894841775 * a - 1.2914855480 * b l, m, s l_ ** 3, m_ ** 3, s_ ** 3 r 4.0767416621 * l - 1.2684380046 * m - 0.0041960863 * s g -1.2684380046 * l 2.6097574011 * m - 0.0417033603 * s b -0.0041960863 * l - 0.0417033603 * m 1.3122414413 * s return -eps r 1 eps and -eps g 1 eps and -eps b 1 eps这个判断函数是整个色域边界分析的核心。判断点在不在边界内不需要采样整个RGB立方体也不需要算凸包一个逆变换就够了。4. 在OKLAB中确定sRGB色域四种方法对比4.1 色域在OKLAB里是个歪瓜裂枣线性sRGB空间是0到1的正方体OKLAB映射把它变成一个扭曲的多面体状物体。这个扭曲后的形状没有解析表达式边界只能靠计算逼近。四种常见思路分别是点判定法、网格采样法、凸包法、二分数值法。点判定法就是前面那个判断函数适合“这个颜色超没超出色域”的场景。网格采样法适合做三维可视化。凸包法实现快但精度差一些。二分数值法适合色域映射和边界曲线生成是我实际项目里用得最多的方案。4.2 网格采样法把六个面铺成网格再转换sRGB立方体的边界在RGB空间里就是六个面每个面固定一个通道为0或1另外两个通道在0到1之间变化。OKLAB映射是连续可逆的所以立方体内部映射后仍然是内部色域边界一定来自这六个面。做法很简单对每个面采样比如把两个自由通道各取129个点固定通道取边界值组成一个16x16或更大的网格然后把每个网格点转成OKLAB坐标。把六个面全部洗完得到一组边界点云。接着把每个网格小方格拆成两个三角形就能得到一个完整的三角网格。这种方法适合生成OBJ模型或者用于计算色域体积。缺点是要管理好六个面的三角形索引不然会出现破洞或重叠面。想省事的话可以先收集点云再用网格重建库处理但会损失边界精度。4.3 凸包法快但真的可能过冲另一个快速方案是把采样点云做三维凸包。代码很简单Python里scipy.spatial.ConvexHull一行就出来了。问题在于OKLAB色域并不是严格凸的。高饱和的蓝色区域和部分紫色区域真实边界是向内凹的。凸包算法默认把所有点包在外侧这会导致边界被高估。实测下来在L接近0.8的蓝色区域凸包边界可能比真实边界向外偏移好几个百分点。如果你用这个凸包做色域映射原本超过边界几个点的颜色会被判定为不超映射结果就错了。所以凸包法适合快速预览不建议用在要求精确的色域映射算法里。4.4 二分搜索法固定L和H找最大C最实用的是二分搜索。思路很直接在OKLCH空间里固定亮度L和色相角H色度C从0开始往外走。C0是中性灰落在sRGB色域内C增大到某个值后颜色超出sRGB色域。这个临界C值就是该方向上的色域边界。二分搜索每次取中间值判断当前点是否在色域内在则向右移动边界不在则向左移动。迭代40次后精度已经远超实际需要。边界判断用上一节写的oklab_in_srgb_gamut函数。需要处理一个边界条件C的上限预估值可能不够大。比如某些色相在很亮或很暗的区域C1可能仍然没有超界我在实际测试中很少遇到但严谨起见代码里要加一个保护如果初始上限还在色域内就翻倍后再试。5. 实操用二分搜索生成OKLCH色域边界5.1 核心代码几十行搞定边界求解把判断函数和二分逻辑合在一起完整代码如下def max_chroma_for_oklch(L, H_deg, max_iter48, eps1e-7): h math.radians(H_deg) lo 0.0 hi 1.0 # 保护如果 C1 还在色域内继续扩大上限 while oklab_in_srgb_gamut(L, hi * math.cos(h), hi * math.sin(h), eps): hi * 2 if hi 10: break for _ in range(max_iter): mid (lo hi) / 2 a mid * math.cos(h) b mid * math.sin(h) if oklab_in_srgb_gamut(L, a, b, eps): lo mid else: hi mid return (lo hi) / 2这个函数输入亮度L和色相角H返回该方向上最大允许的色度C。注意这里假定指定方向上的色域是星形的也就是射线从灰轴出发向外只穿越一次边界。OKLAB的色域形态基本满足这个性质二分会稳定收敛。如果遇到极端非凸区域你可以在二分之前先检查一下hi和lo的行为做防御。5.2 扫一圈画出边界曲线有了max_chroma_for_oklch扫一圈色相角就能得到边界数据。下面这段代码输出L0.7时每隔5度一组的边界点results [] for H in range(0, 360, 5): C max_chroma_for_oklch(0.7, H) a C * math.cos(math.radians(H)) b C * math.sin(math.radians(H)) results.append((0.7, H, a, b, C)) print(fL0.7 H{H:3d} C{C:.4f} a{a:.4f} b{b:.4f})我本机跑出来的数字大致是在L0.7、H150度附近C最大值约0.38这是sRGB在OKLAB空间里最“胖”的方向对应黄绿色在H30度附近C大约0.24对应橙红色方向在H300度附近C大约0.18对应蓝色方向。这些数值不是绝对标准不同实现里由于矩阵尾数略有差异但在百分位级别是一致的。你可以把全角度、全亮度的边界存成一张二维查找表横轴是H纵轴是L表值是C_max。这张表做色域映射时会非常实用查找比实时二分快得多。5.3 扩展到Display P3或Rec.2020换色彩空间时只需要改变判断函数里的“目标RGB到XYZ”这一环。以Display P3为例流程变成OKLAB - 线性LMS - 立方 - XYZ - P3线性RGB - 检查范围。难点在于需要P3的XYZ到线性RGB矩阵。你可以用线性代数库直接求逆或者去CSS Color 4规范附录里抄标准矩阵。我建议在代码里用numpy之类的库求逆避免手动抄错import numpy as np # sRGB 线性值 - XYZ 矩阵以 D65 白点为基准 srgb_to_xyz np.array([ [0.4124564, 0.3575761, 0.1804375], [0.2126729, 0.7151522, 0.0721750], [0.0193339, 0.1191920, 0.9503041] ]) # 需要时求逆得到 XYZ - 线性 sRGB xyz_to_srgb np.linalg.inv(srgb_to_xyz)P3线性值到最后显示时也要做gamma压缩sRGB和P3的OETF基本一致可以直接沿用linear_to_srgb。Rec.2020的曲线略有不同用的时候单独处理。5.4 性能优化别在渲染循环里跑二分二分搜索一次要调用几十次判断函数每次判断函数又做了一堆矩阵运算。如果你在网页里实时给一张图片做色域映射逐像素二分肯定扛不住。两个优化方向第一个方向是缓存。离线预计算一张边界查找表运行时只查表表里没有的用双线性插值。第二个方向是粗扫加精修先用16个迭代把范围缩小再用一个抛物线拟合把边界位置估计出来通常能把迭代次数压到10次以内。如果你发现自己手写的色域映射很慢先别急着优化矩阵大概率是二分次数太多而不是矩阵本身的问题。6. 常用场景与问题排查实录6.1 实际应用渐变、色彩混合、色域映射OKLAB最常见的使用场景之一是把渐变的中间色变干净。在线性RGB里从红色渐变到蓝色中间会经过暗紫灰色这是RGB物理亮度线性插值的必然结果。换成OKLAB插值后再转回sRGB中间色会自然地从红经过品红再到蓝符合人眼对色彩连续变化的预期。色彩混合也是同理。CSS Color 4规范里已经有oklch()函数浏览器做color-mix()混色时会参考这一类空间。我在实现自己的混色函数时就是把两个颜色转成OKLAB然后直接对L、a、b做线性加权最后逆转换。虽然严格说还要做alpha预乘但大多数场景下直接加权已经足够。色域映射是最能体现OKLAB价值的地方。传统做法是直接把超出边界的RGB通道clamp到0或255这会把超色域的颜色拉向白色或灰色导致鲜艳颜色变浅、色相偏移。改用OKLAB的做法是保持亮度和色相不变沿着C轴往回压缩到边界值。这样处理出来的颜色虽然饱和度降低但色相稳定亮度不塌视觉上舒服很多。6.2 问题排查速查表问题现象可能原因对策转换后整体发灰、发亮没做sRGB线性化先调用srgb_to_linear再做矩阵转换个别通道出现NaN负数进行了小数次幂逆变换后用math.cbrt或先保护非负二分搜索结果抖动浮点误差导致边界反复横跳提高或降低eps用固定迭代次数代替while条件比较换到P3后色域判断明显不对还在用sRGB专用矩阵改成通过XYZ中转换的标准链路边界判断误判超色域gamma压缩后的值在0-1但线性值已超在线性RGB阶段检查不要检查显示值高性能场景卡顿逐像素二分搜索预计算查找表或粗扫后插值6.3 小技巧边界数据也能导出成三维模型如果你想把sRGB在OKLAB中的色域模型导出成OBJ网格采样法最合适。六个面的采样网格都生成后三角化索引是规律性的每个采样单元由四个角点组成分成两个三角形。把这些三角形集合起来就能得到完整的封闭网格既可以可视化也可以算体积。sRGB和Display P3的体积比是一个很有说服力的数据做广色域方案汇报时经常用得上。我个人在实际操作中的体会是OKLAB的矩阵虽然看起来多但真正核心的代码量很少。你只要把正向、逆向、色域判断、二分求边界这四个函数写对就能覆盖绝大多数日常需求。最后再分享一个小技巧把那些矩阵常量集中放在一个单独模块里注释标注好对应色彩空间和参考实现不要到处复制粘贴。等到你某天发现某个矩阵抄错了小数点要全局替换的时候就会感谢这个决定。
我第一次看到OKLAB时说实在话有点不耐烦。这几年颜色空间冒出来不少CIELAB用了几十年也没什么大毛病。直到我有一次在渐变里做高饱和插值看到中间那坨发黑的紫灰色才意识到老空间的问题比我想象的严重。这篇接着上一篇聊OKLAB颜色空间重点落在两件事颜色空间转换怎么做以及如何在OKLAB里确定一个RGB空间的色域边界。如果你正在做色彩插值、色域映射或者自己写颜色库这篇会非常对路如果你刚接触颜色科学、被各种Lab/LCH搞晕也能从里面找到可以直接抄的代码。1. OKLAB到底解决了什么问题先搞懂这个空间为什么值得用1.1 老空间的通病无处不在的“不均匀”色彩空间本质上是一个数学坐标系但人眼对不同颜色的敏感度差异很大。CIELAB通常叫Lab或Lab*当年被设计成感知均匀空间理论上坐标距离相等人眼感知的色差也相等。问题在于这个“理论上”折扣很大蓝色区域的距离感知被压缩得厉害饱和度越高越明显。实际做颜色混合或渐变时用CIELAB插值出来的中间色经常发灰、发闷尤其在红蓝之间、紫绿之间颜色会从一条“浑浊地带”穿过去。另一个常用空间HSL/HSV问题更严重。它的色相H只是一个简单角度但人眼对色相环不同位置的分辨能力完全不同。同一步长在不同色相上带来的视觉变化不相等这导致你在“调整色相”的时候颜色不是平滑过渡而是跳跃式移动。早期做前端取色器的时候靠着HSL拖拽色相看起来还行一旦拿去做连续渐变或色域映射就会露出马脚。OKLAB的设计目标就是把这些“不均匀”尽量压平。它希望做到欧几里得距离尽量等于感知色差色相环上的角度尽量对应真实的色相变化亮度轴单独分离出来。这样你在OKLAB里做插值、混合、色域映射都比在老空间里靠谱得多。1.2 OKLAB的核心思想模仿人眼的通路OKLAB建在LMS锥体响应之上。人眼有三种视锥细胞分别对长波、中波、短波敏感LMS就是模拟这三类响应的数值。OKLAB的转换路径大致是先把RGB线性化再通过一个矩阵转到LMS空间接着对LMS做立方根压缩最后用另一个矩阵把压缩后的值旋转到L、a、b三个轴上。立方根这一步很关键。人的视觉对亮度的感知不是线性的而是接近幂函数关系立方根就是对这个非线性的一种近似。很多老空间用对数或者说复杂的幂函数做压缩OKLAB直接用一个立方根简单而且效果不错。三个轴的语义也直观L是感知亮度a轴是红绿对立b轴是蓝黄对立。后面加上角度和长度就得到了OKLCHL是亮度C是饱和度的计量H是色相角。1.3 为什么“色域确定”在OKLAB里是刚需色域是设备能显示或捕捉的颜色范围。sRGB的色域在RGB空间里就是个正方体但经过OKLAB的非线性变换后它变成了一个扭曲的立体形状。你不能用简单范围判断了。而且人们使用OKLAB最频繁的两个场景——色彩插值和色域映射——都绕不开色域边界问题。插值时你要知道中间色有没有超出目标空间色域映射时你要知道超了多少、往哪个方向压。上一篇文章讲概念这一篇所有内容都围绕“怎么算出来”展开。2. 颜色空间转换全流程sRGB如何干净地进出OKLAB2.1 第一步sRGB非线性值必须先线性化进入OKLAB之前最容易被忽略的一步是gamma线性化。sRGB存储的数值不是物理亮度而是经过gamma编码的非线性值。你不做线性化直接把0-255或0-1的sRGB值扔进矩阵结果会偏离非常多尤其红色和蓝色通道偏移肉眼可辨。标准线性化公式分两段处理def srgb_to_linear(c): # c 是 0~1 范围内的非线性 sRGB 数值 if c 0.04045: return c / 12.92 return ((c 0.055) / 1.055) ** 2.4 def linear_to_srgb(c): # c 是线性 RGB if c 0.0031308: return 12.92 * c return 1.055 * (c ** (1 / 2.4)) - 0.0558bit颜色转到0-1区间时先用v / 255归一化再做线性化。注意阈值方向别搞反从sRGB到线性用0.04045从线性回到sRGB用0.0031308。网上有简写版本直接c ** 2.2或c ** 2.4精度差一些做专业颜色处理时还是用标准分段公式更稳。2.2 第二步线性sRGB转到LMS再转到OKLAB线性化之后进入官方矩阵。我第一次看到这三个矩阵时头很大实际上你可以把它们当作黑盒常量只需要保证使用精度足够的版本。下面这段是完整的正向转换函数import math def srgb_to_oklab(r, g, b): # r, g, b 是 0~1 的非线性 sRGB 值 r, g, b srgb_to_linear(r), srgb_to_linear(g), srgb_to_linear(b) # 线性 sRGB - LMS l 0.4122214708 * r 0.2119034982 * g 0.0883024619 * b m 0.2119034982 * r 0.6806995451 * g 0.1073969566 * b s 0.0883024619 * r 0.1073969566 * g 0.8115052253 * b # LMS 开立方根 l_ l ** (1 / 3) m_ m ** (1 / 3) s_ s ** (1 / 3) # 立方根 LMS - OKLAB L 0.2104542553 * l_ 0.7936177850 * m_ - 0.0040720468 * s_ a 1.9779984951 * l_ - 2.4285922050 * m_ 0.4505937099 * s_ b 0.0259040371 * l_ 0.7827717662 * m_ - 0.8086757660 * s_ return L, a, b这里有个细节值得留意官方给出的矩阵是直接从线性sRGB到LMS的合并矩阵不是先转XYZ再转LMS的中间形式。你不要拿标准sRGB转XYZ矩阵和某些XYZ转LMS矩阵自己拼拼出来的结果和官方矩阵对不上。直接用上面的常量就行。2.3 从XYZ或任意RGB空间进入OKLAB如果你的颜色不在sRGB里比如来自Display P3或Rec.2020那就不能直接套sRGB专用矩阵了。通用路径是线性RGB - XYZD65白点- LMS - 立方根 - OKLAB。XYZ到LMS的官方矩阵是def xyz_to_oklab(x, y, z): l 0.8189330101 * x 0.3618667424 * y - 0.1288597137 * z m 0.0329845436 * x 0.9293118715 * y 0.0361456387 * z s 0.0482003018 * x 0.2643662691 * y 0.6338517070 * z l_ l ** (1 / 3) m_ m ** (1 / 3) s_ s ** (1 / 3) L 0.2104542553 * l_ 0.7936177850 * m_ - 0.0040720468 * s_ a 1.9779984951 * l_ - 2.4285922050 * m_ 0.4505937099 * s_ b 0.0259040371 * l_ 0.7827717662 * m_ - 0.8086757660 * s_ return L, a, b注意OKLAB的矩阵是以D65白点为基准标定的。如果你处理的是D50白点的颜色比如很多打印流程要先做色适应转换把XYZ调整到D65否则亮度轴会偏。工程里大部分屏幕流程都是D65这个坑主要出现在印刷和ICC流程里。2.4 OKLCH色域边界讨论最顺手的坐标系OKLAB的L、a、b是直角坐标讨论色域时更适合转换成圆柱坐标OKLCH。C表示色度对应距离灰轴的长度H表示色相角。转换很简单def oklab_to_oklch(L, a, b): C math.sqrt(a * a b * b) H math.degrees(math.atan2(b, a)) % 360 return L, C, H def oklch_to_oklab(L, C, H): h math.radians(H) a C * math.cos(h) b C * math.sin(h) return L, a, b有了OKLCH色域边界可以这样描述固定亮度L和色相角H色度C从0开始往外走走到哪一步出界那个临界C就是该方向上的最大色度。这正是后面二分搜索法的理论基础。3. 逆转换从OKLAB回sRGB以及精度与边界处理3.1 逆转换也是三步矩阵、立方、再矩阵从OKLAB回到sRGB就是刚才流程的反向操作。先把L、a、b转回立方根LMS三个公式是l_ L 0.3963377774 * a 0.2158037573 * b m_ L - 0.1055613458 * a - 0.0638541728 * b s_ L - 0.0894841775 * a - 1.2914855480 * b然后对三个值分别立方得到线性LMSl l_ ** 3 m m_ ** 3 s s_ ** 3再用逆矩阵回到线性sRGBr_lin 4.0767416621 * l - 1.2684380046 * m - 0.0041960863 * s g_lin -1.2684380046 * l 2.6097574011 * m - 0.0417033603 * s b_lin -0.0041960863 * l - 0.0417033603 * m 1.3122414413 * s最后把线性值做gamma压缩就得到sRGB显示值。完整函数def oklab_to_srgb(L, a, b): l_ L 0.3963377774 * a 0.2158037573 * b m_ L - 0.1055613458 * a - 0.0638541728 * b s_ L - 0.0894841775 * a - 1.2914855480 * b l, m, s l_ ** 3, m_ ** 3, s_ ** 3 r_lin 4.0767416621 * l - 1.2684380046 * m - 0.0041960863 * s g_lin -1.2684380046 * l 2.6097574011 * m - 0.0417033603 * s b_lin -0.0041960863 * l - 0.0417033603 * m 1.3122414413 * s r linear_to_srgb(r_lin) g linear_to_srgb(g_lin) b linear_to_srgb(b_lin) return r, g, b这段代码里的矩阵是官方提供的近似值不同语言的库之间可能有小数点后几位差异不影响正常使用。但抄写时尽量复制完整的常量不要手敲省略位否则高饱和区域可能有轻微色差。3.2 一个最容易踩的坑负数开立方根正向转换时线性RGB都在0到1之间LMS组合后应该是非负值开立方根没有风险。逆转换时就不一定了。如果某个OKLAB颜色超出了sRGB色域逆转换得到的线性RGB可能带负值而负值的sRGB gamma压缩在数学上会出问题。假如你用的语言是Python(-0.1) ** (1/3)会返回一个复数后面再运算直接乱掉。JavaScript的Math.pow(-0.1, 1/3)会返回NaN。要处理这个问题可以统一用Math.cbrtJS或numpy.cbrtPython它们正确处理负数。我建议在逆转换后检查线性RGB的范围而不是在gamma压缩后检查因为gamma压缩本身对负数不友好。3.3 写一个“是否在sRGB色域内”的判断函数判断一个OKLAB颜色是否在sRGB色域内最可靠的方法就是逆转换到线性RGB然后检查三个通道是否都在0到1之间。注意要加上浮点容差边界上的颜色由于计算误差可能会在1.0000000001附近抖动。def oklab_in_srgb_gamut(L, a, b, eps1e-7): l_ L 0.3963377774 * a 0.2158037573 * b m_ L - 0.1055613458 * a - 0.0638541728 * b s_ L - 0.0894841775 * a - 1.2914855480 * b l, m, s l_ ** 3, m_ ** 3, s_ ** 3 r 4.0767416621 * l - 1.2684380046 * m - 0.0041960863 * s g -1.2684380046 * l 2.6097574011 * m - 0.0417033603 * s b -0.0041960863 * l - 0.0417033603 * m 1.3122414413 * s return -eps r 1 eps and -eps g 1 eps and -eps b 1 eps这个判断函数是整个色域边界分析的核心。判断点在不在边界内不需要采样整个RGB立方体也不需要算凸包一个逆变换就够了。4. 在OKLAB中确定sRGB色域四种方法对比4.1 色域在OKLAB里是个歪瓜裂枣线性sRGB空间是0到1的正方体OKLAB映射把它变成一个扭曲的多面体状物体。这个扭曲后的形状没有解析表达式边界只能靠计算逼近。四种常见思路分别是点判定法、网格采样法、凸包法、二分数值法。点判定法就是前面那个判断函数适合“这个颜色超没超出色域”的场景。网格采样法适合做三维可视化。凸包法实现快但精度差一些。二分数值法适合色域映射和边界曲线生成是我实际项目里用得最多的方案。4.2 网格采样法把六个面铺成网格再转换sRGB立方体的边界在RGB空间里就是六个面每个面固定一个通道为0或1另外两个通道在0到1之间变化。OKLAB映射是连续可逆的所以立方体内部映射后仍然是内部色域边界一定来自这六个面。做法很简单对每个面采样比如把两个自由通道各取129个点固定通道取边界值组成一个16x16或更大的网格然后把每个网格点转成OKLAB坐标。把六个面全部洗完得到一组边界点云。接着把每个网格小方格拆成两个三角形就能得到一个完整的三角网格。这种方法适合生成OBJ模型或者用于计算色域体积。缺点是要管理好六个面的三角形索引不然会出现破洞或重叠面。想省事的话可以先收集点云再用网格重建库处理但会损失边界精度。4.3 凸包法快但真的可能过冲另一个快速方案是把采样点云做三维凸包。代码很简单Python里scipy.spatial.ConvexHull一行就出来了。问题在于OKLAB色域并不是严格凸的。高饱和的蓝色区域和部分紫色区域真实边界是向内凹的。凸包算法默认把所有点包在外侧这会导致边界被高估。实测下来在L接近0.8的蓝色区域凸包边界可能比真实边界向外偏移好几个百分点。如果你用这个凸包做色域映射原本超过边界几个点的颜色会被判定为不超映射结果就错了。所以凸包法适合快速预览不建议用在要求精确的色域映射算法里。4.4 二分搜索法固定L和H找最大C最实用的是二分搜索。思路很直接在OKLCH空间里固定亮度L和色相角H色度C从0开始往外走。C0是中性灰落在sRGB色域内C增大到某个值后颜色超出sRGB色域。这个临界C值就是该方向上的色域边界。二分搜索每次取中间值判断当前点是否在色域内在则向右移动边界不在则向左移动。迭代40次后精度已经远超实际需要。边界判断用上一节写的oklab_in_srgb_gamut函数。需要处理一个边界条件C的上限预估值可能不够大。比如某些色相在很亮或很暗的区域C1可能仍然没有超界我在实际测试中很少遇到但严谨起见代码里要加一个保护如果初始上限还在色域内就翻倍后再试。5. 实操用二分搜索生成OKLCH色域边界5.1 核心代码几十行搞定边界求解把判断函数和二分逻辑合在一起完整代码如下def max_chroma_for_oklch(L, H_deg, max_iter48, eps1e-7): h math.radians(H_deg) lo 0.0 hi 1.0 # 保护如果 C1 还在色域内继续扩大上限 while oklab_in_srgb_gamut(L, hi * math.cos(h), hi * math.sin(h), eps): hi * 2 if hi 10: break for _ in range(max_iter): mid (lo hi) / 2 a mid * math.cos(h) b mid * math.sin(h) if oklab_in_srgb_gamut(L, a, b, eps): lo mid else: hi mid return (lo hi) / 2这个函数输入亮度L和色相角H返回该方向上最大允许的色度C。注意这里假定指定方向上的色域是星形的也就是射线从灰轴出发向外只穿越一次边界。OKLAB的色域形态基本满足这个性质二分会稳定收敛。如果遇到极端非凸区域你可以在二分之前先检查一下hi和lo的行为做防御。5.2 扫一圈画出边界曲线有了max_chroma_for_oklch扫一圈色相角就能得到边界数据。下面这段代码输出L0.7时每隔5度一组的边界点results [] for H in range(0, 360, 5): C max_chroma_for_oklch(0.7, H) a C * math.cos(math.radians(H)) b C * math.sin(math.radians(H)) results.append((0.7, H, a, b, C)) print(fL0.7 H{H:3d} C{C:.4f} a{a:.4f} b{b:.4f})我本机跑出来的数字大致是在L0.7、H150度附近C最大值约0.38这是sRGB在OKLAB空间里最“胖”的方向对应黄绿色在H30度附近C大约0.24对应橙红色方向在H300度附近C大约0.18对应蓝色方向。这些数值不是绝对标准不同实现里由于矩阵尾数略有差异但在百分位级别是一致的。你可以把全角度、全亮度的边界存成一张二维查找表横轴是H纵轴是L表值是C_max。这张表做色域映射时会非常实用查找比实时二分快得多。5.3 扩展到Display P3或Rec.2020换色彩空间时只需要改变判断函数里的“目标RGB到XYZ”这一环。以Display P3为例流程变成OKLAB - 线性LMS - 立方 - XYZ - P3线性RGB - 检查范围。难点在于需要P3的XYZ到线性RGB矩阵。你可以用线性代数库直接求逆或者去CSS Color 4规范附录里抄标准矩阵。我建议在代码里用numpy之类的库求逆避免手动抄错import numpy as np # sRGB 线性值 - XYZ 矩阵以 D65 白点为基准 srgb_to_xyz np.array([ [0.4124564, 0.3575761, 0.1804375], [0.2126729, 0.7151522, 0.0721750], [0.0193339, 0.1191920, 0.9503041] ]) # 需要时求逆得到 XYZ - 线性 sRGB xyz_to_srgb np.linalg.inv(srgb_to_xyz)P3线性值到最后显示时也要做gamma压缩sRGB和P3的OETF基本一致可以直接沿用linear_to_srgb。Rec.2020的曲线略有不同用的时候单独处理。5.4 性能优化别在渲染循环里跑二分二分搜索一次要调用几十次判断函数每次判断函数又做了一堆矩阵运算。如果你在网页里实时给一张图片做色域映射逐像素二分肯定扛不住。两个优化方向第一个方向是缓存。离线预计算一张边界查找表运行时只查表表里没有的用双线性插值。第二个方向是粗扫加精修先用16个迭代把范围缩小再用一个抛物线拟合把边界位置估计出来通常能把迭代次数压到10次以内。如果你发现自己手写的色域映射很慢先别急着优化矩阵大概率是二分次数太多而不是矩阵本身的问题。6. 常用场景与问题排查实录6.1 实际应用渐变、色彩混合、色域映射OKLAB最常见的使用场景之一是把渐变的中间色变干净。在线性RGB里从红色渐变到蓝色中间会经过暗紫灰色这是RGB物理亮度线性插值的必然结果。换成OKLAB插值后再转回sRGB中间色会自然地从红经过品红再到蓝符合人眼对色彩连续变化的预期。色彩混合也是同理。CSS Color 4规范里已经有oklch()函数浏览器做color-mix()混色时会参考这一类空间。我在实现自己的混色函数时就是把两个颜色转成OKLAB然后直接对L、a、b做线性加权最后逆转换。虽然严格说还要做alpha预乘但大多数场景下直接加权已经足够。色域映射是最能体现OKLAB价值的地方。传统做法是直接把超出边界的RGB通道clamp到0或255这会把超色域的颜色拉向白色或灰色导致鲜艳颜色变浅、色相偏移。改用OKLAB的做法是保持亮度和色相不变沿着C轴往回压缩到边界值。这样处理出来的颜色虽然饱和度降低但色相稳定亮度不塌视觉上舒服很多。6.2 问题排查速查表问题现象可能原因对策转换后整体发灰、发亮没做sRGB线性化先调用srgb_to_linear再做矩阵转换个别通道出现NaN负数进行了小数次幂逆变换后用math.cbrt或先保护非负二分搜索结果抖动浮点误差导致边界反复横跳提高或降低eps用固定迭代次数代替while条件比较换到P3后色域判断明显不对还在用sRGB专用矩阵改成通过XYZ中转换的标准链路边界判断误判超色域gamma压缩后的值在0-1但线性值已超在线性RGB阶段检查不要检查显示值高性能场景卡顿逐像素二分搜索预计算查找表或粗扫后插值6.3 小技巧边界数据也能导出成三维模型如果你想把sRGB在OKLAB中的色域模型导出成OBJ网格采样法最合适。六个面的采样网格都生成后三角化索引是规律性的每个采样单元由四个角点组成分成两个三角形。把这些三角形集合起来就能得到完整的封闭网格既可以可视化也可以算体积。sRGB和Display P3的体积比是一个很有说服力的数据做广色域方案汇报时经常用得上。我个人在实际操作中的体会是OKLAB的矩阵虽然看起来多但真正核心的代码量很少。你只要把正向、逆向、色域判断、二分求边界这四个函数写对就能覆盖绝大多数日常需求。最后再分享一个小技巧把那些矩阵常量集中放在一个单独模块里注释标注好对应色彩空间和参考实现不要到处复制粘贴。等到你某天发现某个矩阵抄错了小数点要全局替换的时候就会感谢这个决定。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
