Alpha Blending in Software with Gamma Correction

Question

How does one efficiently implement alpha blending, without botching gamma?

Alpha blending is basically the following expression:

result_color = (dst_color*src_alpha - dst_color*src_alpha*dst_alpha + src_color - src_color*src_alpha)/(1 - src_alpha*dst_alpha)
result_alpha = src_alpha*dst_alpha

The formula is unusual because I use inverted alpha, where 0 means opaque and 1 - completely transparent. Rationale: many CPUs have instruction to compare with zero, but no instruction to compare with 0xff000000. Also, I can pass just 0xRRGGBB to set_pixel instead of 0xffRRGGBB for opaque color.

For gamma-packed 8-bit RGB I've managed to implement that expression somewhat efficiently in early 90ies style code:

void ablend(int dr,int dg,int db,int da, int *sr,int *sg,int *sb,int *sa) {
  int ya = (da * *sa)>>8;
  uint32_t d = idiv_lut[255 - ya];
  uint8_t *st = ab_lut[255 - *sa];
  uint8_t *dt = ab_lut[*sa - ya];
  *sr = ((dt[dr] + st[*sr])*d)>>8;
  *sg = ((dt[dg] + st[*sg])*d)>>8;
  *sb = ((dt[db] + st[*sb])*d)>>8;
  *sa = ya;
}

Obviously working with RGB, without unpacking it first, produces incorrect result (it is the most common graphics programming pitfall), so they must be unpacked (i.e. pow(x,2.2)), and now one can't use ab_lut anymore, because it would require 2^30 bytes, and replacing division with multiplication would be impossible on a 32-bit system either.

Give that, this question implies some side questions:

1. Is using float the only solution for unpacked RGB processing?

2. How can I perform alpha blending with gamma correction?

3. Is it worth it (L1 cache-wise) to still use gamma packed sRGB, instead of a simple array of 4 32-bit float R,G,B,A components, or would memory access become a bottleneck on a majority of CPUs?

So maybe I just have this 90's mindset, where keeping data size small meant difference between 1 and 60 frames per second, and today we can safely use as many additional bytes as required?

Answer 1

Most games don't do blending in gamma space.

Instead, on read, we'll unpack a gamma-encoded source into linear RGB. Our calculations, blending, and intermediate storage are all in linear space.

Then, once we've fully composited the frame we want to display, then at that time we'll perform gamma encoding to convert it into the right curve for display.

This can cut down on the total number of gamma calculations you need to do in a blending-heavy scene with lots of overdraw, making the calculations you do frequently cheap and saving the expensive stuff for a batch at the end. I'd expect this to typically be faster than adapting all of your blending operations to occur in gamma space.

If we're using a low bitdepth format for intermediate storage - like 8 bpc / 4 Bpp - then this linear working space does entail some information loss. Two different gamma-encoded colour values could decode and quantize to the same value when stored in 8 bits of linear space, then recompress back to the same value, and some gamma-encoded values might be skipped (have no 8-bit pre-image in linear space), leading to subtle banding artifacts. You'll see this in some older games in particular.

As you say, you can store your colours as floats to maintain high precision throughout all your intermediate calculations and storage, at the cost of quadrupling the data size up to 16 Bpp and needing floating point math (something we tend to take for granted on GPUs made to chew through floats). Whether that's a desirable trade-off for your use case is something you'll need to profile and evaluate for yourself.

You can also go halfway, say decoding to 16 bpc / 8 Bpp. This is a halfway step, giving you a compromise of storage efficiency between 8 bpc and float, while still gaining 256 times the precision - enough to eliminate most banding.

Or, since you're doing this in software and aren't bound by conventionally-supported GPU types, you can use custom solutions. Like for instance decoding your sRGB into linear YCbCr to use as your intermediate. This is a linear transformation of linear RGB space, so it's fast to convert back and forth, and it doesn't introduce non-linearity into any of our familiar colour blending operations. Its main feature is that it concentrates the luminance information to which the eye is most sensitive in the Y channel. So you could store 2 bytes for luminance and just one for each chromaticity channel (and either one or two for alpha, for a 5-6 Bpp total), to get back in the ballpark of 8 bpc / 4 Bpp storage compactness. This is the same trick that JPEG and video compression codecs use to concentrate their limited data payload on the signals with the most perceptual impact.