Go color.NRGBA 的 Alpha 通道参与混合时如何换算

我在把一组半透明颜色交给 image/draw 时，最容易误判的地方不是 Alpha 值本身，而是同一个颜色在不同 API 里的表示方式。color.NRGBA 保存的是非 Alpha 预乘的 8 位分量；但它实现的 RGBA() 会返回 16 位、已经乘过 Alpha 的分量。因此 color.NRGBA{R: 100, A: 128} 的红色分量经过 RGBA() 后不会仍是 100 。

记住一句话：读取 NRGBA 的字段看“原始颜色”，调用 Color.RGBA 看“参与合成的预乘颜色”。在 draw.Over 前不要把 Alpha 再乘一遍。

先把 NRGBA 的存储值和 RGBA() 返回值分开

Go 标准库把 color.NRGBA 定义为非 Alpha 预乘的 32 位颜色，字段顺序是 R、G、B、A，每个字段都是 uint8。所以当你直接读取 c.R 时，得到的是颜色本身的 0 到 255 范围，不会因为透明度变小。

但是 color.Color 接口的 RGBA() 有另一条约定：返回 0 到 65535 范围的 Alpha 预乘通道。源码采用“8 位复制到高低字节，再乘以 A，除以 0xff”的做法。这样不同颜色模型交给绘图和合成代码时，就能使用统一的 16 位接口。

用一个固定输入算出 Alpha 参与后的数值

拿 color.NRGBA{R: 100, G: 50, B: 0, A: 128} 做推导。8 位颜色扩展到 16 位时使用 x | x，因此红色先变成 100 × 257 = 25700，绿色先变成 50 × 257 = 12850。随后每个颜色分量都乘以 128，再除以 255。

package main

import (
	"fmt"
	"image/color"
)

func main() {
	// NRGBA 保存未预乘的颜色，A=128 表示约一半透明度。
	c := color.NRGBA{R: 100, G: 50, B: 0, A: 128}

	// RGBA 返回的是 16 位、已经按 Alpha 预乘的通道。
	r, g, b, a := c.RGBA()
	fmt.Printf("r=%d g=%d b=%d a=%d\\n", r, g, b, a)
}

按实现计算，结果约为 r=12900 g=6450 b=0 a=32896。其中 Alpha 是 128 | (128 ，红色则是 25700 × 128 ÷ 255 的整数除法结果。这里的除法会截断小数，所以不要用浮点数结果去要求逐位相同。

交给 draw.Over 时不要再次手动乘 Alpha

image/draw 的 Over 是 Porter-Duff 的 source-over 合成操作。它通过 color.Color.RGBA() 获取统一的预乘通道，再结合目标像素的 Alpha 计算结果。对调用方来说，常规做法是准备源图和目标图，直接让 draw.Draw 完成合成，而不是先把 NRGBA 的字段手工乘一次，再把同一个值交给绘图包。

package main

import (
	"image"
	"image/color"
	"image/draw"
)

func blend() *image.RGBA {
	// 目标图使用不透明的浅色背景，便于观察半透明源色的叠加效果。
	dst := image.NewRGBA(image.Rect(0, 0, 1, 1))
	dst.Set(0, 0, color.RGBA{R: 240, G: 240, B: 240, A: 255})

	// 源色保持 NRGBA 的原始字段，Alpha 由 draw.Over 参与合成。
	src := image.NewNRGBA(image.Rect(0, 0, 1, 1))
	src.SetNRGBA(0, 0, color.NRGBA{R: 100, G: 50, B: 0, A: 128})

	// draw.Over 会按 color.Color 的预乘约定完成 source-over。
	draw.Draw(dst, dst.Bounds(), src, image.Point{}, draw.Over)
	return dst
}

这段代码的关键不是某个最终颜色数值，而是职责边界：源图保留非预乘字段，draw.Over 负责读出预乘值并组合目标。如果在传入前先把 R、G、B 乘过一次 Alpha，再让 RGBA() 或绘图包继续按 Alpha 处理，就会出现“透明度被算了两遍”的暗化问题。

三个边界最容易让结果看起来“不对”

第一，全透明颜色的 RGB 字段即使非零，也不会对合成结果产生可见贡献；如果要把一个颜色转换成非预乘模型，Alpha 为零时应避免直接做除法。第二，全不透明时 A=255，预乘结果与 16 位扩展后的原色一致。第三，从预乘值恢复 NRGBA 时要做反预乘，不能把 RGBA() 返回的 16 位值简单右移后当成原始字段。

常见问题

为什么 NRGBA 的 R 字段和 RGBA() 的 r 不一样？

因为前者是非预乘的 8 位存储值，后者是扩展到 16 位后按 Alpha 预乘的接口返回值，两者服务于不同边界。

能不能把 RGBA() 的 r 直接右移 8 位还原 R？

只有在 Alpha 为 255 时才可以近似这样做。半透明颜色需要先按 Alpha 反预乘，否则还原出来的颜色会偏暗。

自己写像素混合时应该使用哪种数值？

如果混合算法接近 image/draw，优先使用 Color.RGBA() 的 16 位预乘值，并明确输出仍是预乘还是要转换回 NRGBA；不要混用两套坐标系。

把 NRGBA 看成“原始颜色输入”，把 RGBA() 看成“供合成算法使用的统一接口”，Alpha 的换算就不再神秘。真正需要警惕的是在模型转换和绘图合成之间重复做同一件事。