【问题标题】:I believe I converted between sRGB and linear RGB correctly, so why do the results look worse for dark colors?我相信我在 sRGB 和线性 RGB 之间正确转换,那么为什么深色的结果看起来更差?
【发布时间】:2022-11-27 00:39:40
【问题描述】:

在研究了 the Wikipedia entry on 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("Half of sRGB 255 calculated in linear RGB is %d", Standardb(Linearb(255)/2))
打印Half of sRGB 255 calculated in linear RGB is 188

然后我做了这个:

上半部分:棋盘格红色 (255, 0, 0) 和绿色 (0, 255, 0) 像素。
左下角:使用 2 (128, 128, 0) 划分的原始混音。
右下:(188, 188, 0)

下半部分显示了两种不同的尝试,当在两个轴上按比例缩小 50% 时,上半部分会是什么样子。由于上半部分是交错的全绿色和全红色像素,因此缩小比例必须将一半红色和一半绿色加在一起,其值是我之前计算的值 (188)。

右下角与我的普通消费者显示器上的上半部分完全吻合,所以看起来整个转换数学都在起作用。

但是深色呢?

log.Printf("Half of sRGB 64 calculated in linear RGB is %d", Standardb(Linearb(64)/2))
打印Half of sRGB 64 calculated in linear RGB is 44

我和以前一样:

上半部分:棋盘格深红色 (64, 0, 0) 和深绿色 (0, 64, 0) 像素。
左下角:使用 2 (32, 32, 0) 划分的原始混音。
右下角:(44, 44, 0)

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

我做错了吗?或者这只是消费者显示设备上预期的错误程度?

【问题讨论】:

    标签: go colors rgb srgb


    【解决方案1】:

    我做错了吗?

    是和不是。您的代码是正确的,但您的测试方法有疏忽:

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

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

    通过从棋盘像素模式到交替着色的水平像素线,可以降低问题的严重性。数学结果是一样的,但结果看起来可能大不相同。

    第一张带水平线的图片:

    第二张带有水平线的图片:

    奖励:带有垂直线的第二张图片(试着眯着眼睛;对我来说它看起来更准确):

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2015-09-25
      • 2020-08-09
      • 1970-01-01
      • 2013-08-11
      • 2018-10-26
      • 2021-05-05
      • 2022-01-25
      • 2016-10-17
      相关资源
      最近更新 更多