从rec的正确转换。 709 转 sRGB答案

【问题标题】：Correct conversion from rec. 709 to sRGB从rec的正确转换。 709 转 sRGB
【发布时间】：2013-07-06 08:42:15
【问题描述】：

如何正确地将存储为 Y'CrCb（使用 rec. 709）的颜色转换为 sRGB？

我正在处理 HDTV 视频，并且正在使用 libavcodec 提取原始数据。虽然我成功地进行了转换，但我还没有确信我做对了。 VLC 提供了一个结果，在 Gimp 中使用“compose”进行转换会导致另一个结果，并且使用来自网络的代码也不一致。所以我还没有找到可靠的参考来比较。

我的研究和当前最好的选择如下。（值是浮点数，范围为 0.0-1.0）我最不确定的是伽马校正。它使它比我预期的要轻一些，但我也不能说它看起来不对...

工作室秋千移除

对于 8 位，Y' 的范围从 16 到 235。 Cr 和 Cb 的范围为 16 到 240，以 128 为中心。

y = (y - (16 / 255.0)) * ( 1 + 16.0 / 255.0 + (256-235) / 255.0 );
u = (u - (16 / 255.0)) * ( 1 + 16.0 / 255.0 + (256-240) / 255.0 );
v = (v - (16 / 255.0)) * ( 1 + 16.0 / 255.0 + (256-240) / 255.0 );

//Move chroma
u -= 0.5;
v -= 0.5;

我不确定是否可以安全地假设您永远不会获得超出范围的值，或者您是否需要限制它。

对于更高的位深度，规范说 LSB 被忽略。那是什么意思？我也在处理以 10 位编码的材料，所以这对我很感兴趣。

从 Y'CrCb 到 RGB

推荐。 709 规范告诉如何将 RGB 转换为 Y'CrCb：

E'y = 0.2126 * E'r + 0.7152 * E'g + 0.0722 * E'b
E'cb = 0.5389 * ( E'b - E'y )
E'cr = 0.6350 * ( E'r - E'y )

Wikipedia 为 Cb 和 Cr 提供了一个似乎更准确的定义：

Pb = 0.5 * (B' - Y') / (1 - Kb)
Pr = 0.5 * (R' - Y') / (1 - Kr)

其中 Kb 和 Kr 是 E'b 和 E'r 的因子。规范中的值。似乎从这些等式四舍五入。

RGB 可以通过反转方程式找到（使用维基百科版本）：

double r = y + 2*(1.0-kr) * v;
double b = y + 2*(1.0-kb) * u;
double g = ( y - kr * rr - kb*rb ) / kg;

G 可以直接使用 Cr 和 Cb 完成：

double g = y - 2*kr*(1-kr)/kg * v - 2*kb*(1-kb)/kg * u;

(y的因数为(1-kr-kb)/kg，即kg/kg为kr+kb+kg=1)

RGB 转 sRGB

我还没有看到任何包含此步骤的代码示例。我们需要转换rec指定的颜色空间。 709 到 sRGB 中指定的那个。 AFAIK，两者之间的唯一区别是传递函数（即伽玛）。 rec 指定的 XY 坐标。 709 匹配 sRGB，但我不知道为什么 sRGB 在 rec 时包含“Z”坐标。 709没有。这有什么不同吗？（我对 CIE XYZ 一无所知。）

推荐。 709 指定如何对线性 RGB 进行伽马编码：

V = 1.099 * L^0.45 - 0.099    for    1 >= L >= 0.018
V = 4.500 * L                 for 0.018 > L >= 0

我们需要反转它，但是线性截止值 0.018 在两个方程中没有给出相同的 V 值。那么反转版本的范围是多少？：

L = ( ( V + 0.099 ) / 1.099 ) ^ (1/0.45)    for  1 >= V >= ?
L = V / 4.5000                              for  ? >  V >= 0

sRGB 也有同样的问题，但修改为更准确的 0.0031308。我记得有人设计了一个分数来精确代表 sRGB，但我再也找不到它了……

我目前正在使用以下内容：

double cutoff = 1.099 * pow( 0.018, 0.45 ) - 0.099;
v = ( v < cutoff ) ? 1.0/4.5 * v : pow( (v+0.099)/1.099, 1.0/0.45 );
v = ( v <= 0.0031308 ) ? 12.92 * v : 1.055*pow( v, 1.0/2.4 ) - 0.055;

【问题讨论】：

看看martinreddy.net/gfx/faqs/colorconv.faq 中的第 6.5 节我目前在我的手机上只有边缘连接，所以现在提供正确的答案有点困难......
我对随机转换函数不感兴趣，我有很多。我想要一个可以争论为什么一个特定的人是正确的人。（顺便说一句，这个看起来不对。看看 Y' 的方程，它使用的系数与建议 709 中指定的系数不匹配。此外，它们甚至不等于 1.0，这会改变 Y' 的范围。）
很明显，Y'CbCr 已经经过伽玛校正，无需再做第二次。如果您想获得超级准确，您可能需要先转换为线性，然后再转换回校正后的 sRGB，但这对于大多数应用程序来说太过分了。
我确实希望非常准确，因为我的应用程序主要进行图像处理。然而，我看到（在我看来）与线性 RGB 之间的转换存在显着差异，尤其是在深色方面。也许我做错了，这就是我问这个问题的部分原因。另一个原因是我认为您应该知道正确的方法，然后才能对例如进行近似。实时应用。这是您准确测量误差的唯一方法。（对我来说，速度并不是一个大问题。）
限制不是 0 和 255 的原因是因为他们期望值超出这些限制并且他们想要一些空间。

标签： image-processing colors yuv gamma

【解决方案1】：

为了从线性 sRGB 到非线性 sRGB（压缩扩展过程）和反向过程（反向压缩扩展）的正确转换，我使用以下函数：

public double Companding(double channel)
{
    double v = channel;
    double V = v <= 0.0031308 ? 12.92 * v : 1.055 * Math.Pow(v, 1 / 2.4d) - 0.055;
    return V;
}

public double InverseCompanding(double channel)
{
    double V = channel;
    double v = V <= 0.04045 ? V / 12.92 : Math.Pow((V + 0.055) / 1.055, 2.4);
    return v;
}

注意：v是线性的，V是非线性的。

这些函数基于此处找到的公式： http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html

还可以选择使用 simplified sRGB 和压缩扩展函数 v = V ^ gamma，其中 gamma 为 2.2，如上所述网站。

【讨论】：

尽管 sRGB 公式经过精心设计以模拟 2.2 的简单 gamma，但官方公式如此简单，因此无需使用简化公式。

【解决方案2】：

rec 指定的 XY 坐标。 709匹配sRGB，

那些是xy，不是XY，它与XYZ中的XY不同。

唉，首先，XYZ 是线性化之后的一步，你不需要去那里，因为 sRGB 已经使用 BT.709 原色，正如你所说。 RGB 线性，R'G'B' 是非线性的。 Y'Cb'Cr' 也是非线性的。

我也在处理以 10 位编码的材料，所以这对我很感兴趣。

这意味着您可以将其四舍五入以获得 8 位的正确值。如果 10 位值的最后两位是 10 或 11，则向上舍入到下一个 8 位值，否则向下舍入（00、01 向下舍入）。 LSB 表示最低有效位。只是不要忘记 1023 应该四舍五入到 255，而不是溢出。

我们需要反转它，但是线性截止值 0.018 在两个方程中给出的 V 值不同。

不，您不需要反转任何内容。 REC.601/REC.709/REC.2020 的 EOTF 不是 OETF 的相反，EOTF 在 BT.1886 中指定，在 200 勒克斯环境光下，对于理想的 OLED 显示器来说是 2.4 完美伽马值，对于不完美的 LCD 来说几乎是 sRGB EOTF。这就是为什么 Chrome 只对 BT.709 使用 sRGB EOTF，这意味着“没有”EOTF，因为 windows 默认是这样的。

我记得有人设计了一个分数来精确表示 sRGB，

只是 0.04045/12.92 == 0.003130804954, 809/258400。

【讨论】：