如何在没有预乘alpha的情况下获得真正的RGBA或ARGB颜色值？ [英] How to get the real RGBA or ARGB color values without premultiplied alpha?
问题描述
我正在使用 CGBitmapContextCreate 使用 kCGImageAlphaPremultipliedFirst 选项创建位图上下文。
I'm creating an bitmap context using CGBitmapContextCreate with the kCGImageAlphaPremultipliedFirst option.
我制作了一个5 x 5测试图像，其中包含一些主要颜色（纯红色，绿色，蓝色，白色，黑色），一些混合颜色（即紫色）和一些alpha变化。每当alpha分量不是255时，颜色值都是错误的。
I made a 5 x 5 test image with some major colors (pure red, green, blue, white, black), some mixed colors (i.e. purple) combined with some alpha variations. Every time when the alpha component is not 255, the color value is wrong.
我发现当我做类似的事情时，我可以重新计算颜色：
I found that I could re-calculate the color when I do something like:
almostCorrectRed = wrongRed * (255 / alphaValue);
almostCorrectGreen = wrongGreen * (255 / alphaValue);
almostCorrectBlue = wrongBlue * (255 / alphaValue);
但问题是，我的计算有时会减少3甚至更多。所以例如我得到的值为242而不是245的绿色，我100％确定它必须正好是245. Alpha是128。
But the problem is, that my calculations are sometimes off by 3 or even more. So for example I get a value of 242 instead of 245 for green, and I am 100% sure that it must be exactly 245. Alpha is 128.
然后，对于在PNG位图中只有不同的alpha不透明度的完全相同的颜色，我得到alpha = 255和绿色= 245应该是。
Then, for the exact same color just with different alpha opacity in the PNG bitmap, I get alpha = 255 and green = 245 as it should be.
如果alpha为0，则为红色，绿色和蓝色也是0.这里所有的数据都丢失了，我无法弄清楚像素的颜色。
If alpha is 0, then red, green and blue are also 0. Here all data is lost and I can't figure out the color of the pixel.
如何避免或撤消这个alpha预乘总之，以便我可以根据真实的RGB像素值修改图像中的像素，就像在Photoshop中创建图像时一样？如何恢复R，G，B和A的原始值？
How can I avoid or undo this alpha premultiplication alltogether so that I can modify pixels in my image based on the true R G B pixel values as they were when the image was created in Photoshop? How can I recover the original values for R, G, B and A?
背景信息（可能不需要问题）：
Background info (probably not necessary for this question):
我正在做的是：我采用UIImage，将其绘制到位图上下文，以便执行一些简单的图像处理算法它，根据之前的颜色改变每个像素的颜色。没什么特别的。但我的代码需要真正的颜色。当一个像素是透明的（意味着它的alpha小于255）时，我的算法不应该关心这个，它应该根据需要修改R，G，B，而Alpha保持不管它是什么。有时虽然它会向上或向下移动alpha。但我认为它们是两个不同的东西。 Alpha控制透明度，而RGB控制颜色。
推荐答案
这是整数类型中的预乘的基本问题：
This is a fundamental problem with premultiplication in an integral type:
- 245 *（128/255）= 122.98
- 122.98 截断到一个整数= 122
- 122 *（255/128）= 243.046875
- 245 * (128/255) = 122.98
- 122.98 truncated to an integer = 122
- 122 * (255/128) = 243.046875
我不确定你为什么得到242而不是243，但这个问题仍然存在，并且随着alpha的降低而变得更糟。
I'm not sure why you're getting 242 instead of 243, but this problem remains either way, and it gets worse the lower the alpha goes.
解决方案是使用浮点组件而不是。 Quartz 2D Programming Guide提供了您需要使用的格式的完整详细信息。
The solution is to use floating-point components instead. The Quartz 2D Programming Guide gives the full details of the format you'll need to use.
重点：您需要使用浮点数来自创建原始图像（我认为甚至不可能将这样的图像保存为PNG;您可能必须使用TIFF）。已经以整数形式预乘的图像已经失去了这种精度;没有得到它。
Important point: You'd need to use floating-point from the creation of the original image (and I don't think it's even possible to save such an image as PNG; you might have to use TIFF). An image that was already premultiplied in an integral type has already lost that precision; there is no getting it back.
零alpha的情况是这个的极端版本，甚至浮点也无法帮助你。零（alpha）的任何时间都为零，并且没有从该点恢复原始的未预乘的值。
The zero-alpha case is the extreme version of this, to such an extent that even floating-point cannot help you. Anything times zero (alpha) is zero, and there is no recovering the original unpremultiplied value from that point.
这篇关于如何在没有预乘alpha的情况下获得真正的RGBA或ARGB颜色值？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
