为什么我正确转换了 sRGB 和线性 RGB，却发现深色结果看起来更差？

一分耕耘，一分收获！既然都打开这篇《为什么我正确转换了 sRGB 和线性 RGB，却发现深色结果看起来更差？》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新Golang相关的内容，希望对大家都有所帮助！

研究了 srgb 的维基百科条目后，我实现了一组函数来帮助进行颜色转换：

import "math"

// https://en.wikipedia.org/wiki/SRGB#Transformation

var byteDecoded [256]float32 = func() (floats [256]float32) {
    for i := 0; i < 256; i++ {
        floats[i] = float32(i) / 255
    }
    return floats
}()

// Standard returns the sRGB color space value in range [0.0-1.0] for v, assuming v is in linear RGB in range [0.0-1.0].
func Standard(v float32) float32 {
    if v <= 0.0031308 {
        return v * 12.92
    }
    return float32(1.055*math.Pow(float64(v), 1.0/2.4) - 0.055)
}

// Standardb returns the sRGB color space value in range [0-255] for v, assuming v is in linear RGB in range [0.0-1.0].
func Standardb(v float32) uint8 {
    if v >= 1 {
        return 255
    }
    if v <= 0 {
        return 0
    }
    return uint8(Standard(v)*255 + 0.5)
}

// Linear returns the linear RGB color space value in range [0.0-1.0] for v, assuming v is in sRGB in range [0.0-1.0].
func Linear(v float32) float32 {
    if v <= 0.04045 {
        return v * (1.0 / 12.92)
    }
    return float32(math.Pow((float64(v)+0.055)/1.055, 2.4))
}

// Linearb returns the linear RGB color space value in range [0.0-1.0] for b, assuming b is in sRGB in range [0-255].
func Linearb(b uint8) float32 {
    return Linear(byteDecoded[b])
}

然后我得到了一些结果。

log.printf("线性 rgb 计算出的 srgb 255 的一半为 %d", standardb(linearb(255)/2))

打印 以线性 rgb 计算的 srgb 255 的一半是 188。

然后我做了这个：

上半部分：棋盘状红色 (255, 0, 0) 和绿色 (0, 255, 0) 像素。

左下：通过除以 2 (128, 128, 0) 进行简单混音。

右下：(188, 188, 0)

下半部分显示了两种不同的尝试，即在两个轴上缩小 50% 时上半部分的外观。由于上半部分是交错的全绿色和全红色像素，因此缩小范围必须将一半红色和一半绿色添加在一起，其值是我之前计算的 (188)。

当我眼睛交叉时，右下角与我的普通消费者显示器上的上半部分完全匹配，所以看起来整个转换数学正在发挥作用。

但是深色怎么样？

log.printf("线性 rgb 计算出的 srgb 64 的一半为 %d", standardb(linearb(64)/2))

打印 以线性 rgb 计算的 srgb 64 的一半是 44。

我做的和以前一样：

上半部分：棋盘状深红色 (64, 0, 0) 和深绿色 (0, 64, 0) 像素。

左下：通过除以 2 (32, 32, 0) 进行简单混音。

右下：(44, 44, 0)

这一次，在我的显示器上，天真的（不正确）方法几乎完美地匹配上半部分，而我在右下角努力计算的值看起来太亮了。

我是不是搞错了？或者这只是消费类显示设备上预期的错误程度？

正确答案

我是不是搞错了？

是和否。您的代码是正确的，但您的测试方法存在疏忽：

这只是消费类显示设备上预期的错误程度吗？

是的。特别是，这可能是由显示面板的控制驱动器引起的。看到有人在这里做出类似的观察：https://electronics.stackexchange.com/questions/401617/lcd-pixels-how-chess-board-pixel-fill-patterns-are-called

可以通过从棋盘像素图案改为交替彩色水平像素线来降低问题的强度。数学结果是一样的，但结果可能看起来截然不同。

第一张带有水平线的图像：

第二张带有水平线的图像：

奖励：第二张带有垂直线的图像（尝试眯着眼睛；它对我来说看起来更准确）：

另请注意，就显示器的准确度而言，“普通消费者显示器”的范围已经很广了。如果我将这里的 Stackoverflow 窗口拖到我更便宜的第二台显示器上，我完全无法确认您所做的任何断言，因为它的颜色输出非常不准确。

以上就是《为什么我正确转换了 sRGB 和线性 RGB，却发现深色结果看起来更差？》的详细内容，更多关于的资料请关注golang学习网公众号！