Ditherpunk 2 – beyond 1-bit
This post covers a topic I've spent some time with in the past, and is generally a good overview but unfortunately gets the idea of "linear RGB" wrong.  That means all of the results need some attention, including the Go implementation.  Maybe for a part II post?<p>Each color value (e.g. red) is represented by a value from zero to full intensity.  It's easiest to think of it as a number between 0 and 1 in a linear space.  You could use a floating point number for that, or a quantized/fixed point value.  For example the 10-bit quantized value round(r_linear*1023) in the range 0 to 0x3ff.<p>8-bit RGB color components are "encoded" from their linear version with a transfer curve (aka gamma compression).  For sRGB, the curve is a piecewise linear and exponential combination.  A good overview is [1].  There are many different encodings, including sRGB, BT.601, BT.709, etc. Then there's "full range" vs. "video range"... it can get complex pretty quickly.<p>Because of gamma encoding, an 8-bit R_sRGB red value is not equal to round(r_linear*255).  You have to first compress r_linear via the gamma curve, then quantize that 0..1 value to 8-bits.  When going in reverse (expanding an 8-bit sRGB value to linear), you generally take R_sRGB/255 to produce a value in the 0..1 range and then use the inverse gamma curve to get the linear value.  These computations can be done in floating point, fixed point, or using lookup tables.<p>The takeaway is that you can't represent 8-bit sRGB color components in linear with just 8-bits, without losing precision.  You need at least 12-bits for linear sRGB and many implementations just go straight for 32-bit float values for simplicity.<p>These conversions are required whenever you combine (blend) pixels encoded into sRGB: so for each pixel operation X, you decode sRGB to linear, perform X, then encode back to sRGB.  It's expensive!  That's why GPUs offer texture formats that specify a gamma encoding like sRGB, so a pixel shader can blissfully work in linear color, with the conversions done for it in hardware as a pre- and post-shader operation.  On the CPU?  You have to do it all yourself...<p>Because of that, many software libraries don't bother with the proper gamma conversion and just compute everything in the logarithmic (gamma encoded) domain.  And most of the time, it looks OK! But it really is just a "cheap" approximation -- sometimes it can look quite bad compared to the (proper) linear computation...<p>As far as I can tell, none of the Go standard library does linear blending; and all of the image formats are assumed to be sRGB encoded.  There are some 3rd party packages like [3] that can do some of color management on a 16-bit linear image format (RGBA64 == 16bits/component RGBA).<p>The other thing the author might consider is revising the "Why?" footnote to the "Random Noise (grayscale)" section.  What the author is actually doing there is just using a cheap approximation to a rounding function: round(x) ~= floor(x + 0.5).  In general, doing a round like that introduces a bias [2].  That section can be summarized as: after every pixel operation, round and clamp back to the valid range.<p>[1] <a href="https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/" rel="nofollow">https://blog.johnnovak.net/2016/09/21/what-every-coder-shoul...</a>
[2] <a href="http://www.cplusplus.com/articles/1UCRko23/" rel="nofollow">http://www.cplusplus.com/articles/1UCRko23/</a>
[3] <a href="https://github.com/mandykoh/prism" rel="nofollow">https://github.com/mandykoh/prism</a>