>Because the author assumed 8-bit color channels at the start The tools tested predominately use 8bit per channel. Photoshop and Affinity Designer can use 16bi

>Because the author assumed 8-bit color channels at the start The tools tested predominately use 8bit per channel. Photoshop and Affinity Designer can use 16bit int or 32bit float, but those modes are typically more for photo editing. >Having 10k steps to control the opacity of an 8-bit overlay is wasting a minimum of 5 bits. The article does allude to why more may be important: “There’s no real reason to not support the full range of possible 8bit opacities, or even more steps to cover wide gamut colour spaces and higher bit depths.” CSS, iOS, and Android dev all typically just use floats with a normalised range for opacity. The future is likely using normalised floats for all colour values, like many platforms already do. This also allows for extended ranges beyond 1.0 for wide gamut support while still using sRGB. Wide gamut displays are prevalent, as is sending 10bit per channel to the display (often with a 16bit float per channel window manager). It just seems weird for our tooling to clip this stuff at the input. That’s such an easy thing to fix. >It would be nice to have more examples where single bit precision is necessary, and a demonstration of a visible problem that crops up if the precision is too coarse. I think there’s lots of examples, but some are going to sound contrived. Here’s one that didn’t make the cut: Illustrator’s blend tool creates intermediate objects by morphing the paths and properties. This is a common way to make gradient-like effects. Object opacities are also interpolated. What’s interesting is that Illustrator has 0-255 precision when doing the blend, but if you edit the objects, you’re the values display as 0-100 and edits will snap to 0-100. I didn’t include it, because it got messy explaining the finer details.