5 ms·

Opacity Precision

36 points by zdw 5y ago

tshaddox 5y ago
In CSS you can add 2 more hex digits to an RGB hex code to access 256 possible opacity levels, like background-color: #RRGGBBAA. It's difficult to verify, but it seems that browsers also accept opacity values with arbitrary decimal precision in both percentages and real numbers from 0 to 1. I would imagine those get rounded at least to the closest value from 0 to 256.
- marcedwards 5y ago
  Yep, that’s my understanding as well.
notinty 5y ago
>For an opacity slider to provide 101 steps, it needs to be at least 101 pixels wide. There's no reason this needs to be the case: slider elements could trap the cursor and give realtime feedback of input. The iPad Pro trackpad does this with all UI elements and I believe it's an important step for UX.
- marcedwards 5y ago
  Yep, that’s an option as well, and some tools do it. Figma’s only layer opacity slider is via holding a modifier and dragging the text input field. I personally like having opacity sliders as well. They provide a nice visual representation of the state that’s easier to parse than reading a number, and you can also do things like set 100% with a single click. Layer opacity is important enough that it should have a text field, a draggable value with a modifier, and a slider. The other main point of the article is that these tools don’t seem to even realise their precision sucks.
  - notinty 5y ago
    Agreed; immediate analog feedback of a slider is important. Thanks for the great article, the images you created are especially fantastic. Edit: my friend just checked and Clip Studio Paint also has 0-100 with no decimal support. Crazy that it's ubiquitous.
    - marcedwards 5y ago
      Sure is! Interestingly, Acorn can show the full 0-255 range.
cmiller1 5y ago
Can anyone really tell the difference between these fractional steps of opacity?
- lnanek2 5y ago
  I can't, but at least the article did add a paragraph claiming designers can: " Does it matter? Quite often, shadows are incredibly sensitive to opacity changes, and many shadows use values from around 5% to 20%. That means there’s only 15 or so steps in the usable range, and single step jumps can be quite noticeable. This is not the most pressing issue in the design tools we use, but it is a real problem. "
  - marcedwards 5y ago
    There can also be cumulative rounding issues if you’d stacking lots of layers on top of each other. It’s a subtle issue, but a strange one. There’s no deep technical reason for it — the inputs are just losing data.
- marcedwards 5y ago
  Yep, for shadows and in other places, single percentage changes can definitely be visible.
egypturnash 5y ago
My illustration practice relies on a ton of transparency, and I get by fine with a much lower-precision control of it. Illustrator lets me set up keyboard shortcuts to 0/10/20/30/40/50/60/70/80/90/100% opacity and this is how I assign the vast majority of my opacity levels. Effectively I'm "losing" a lot more steps than just the difference between 100 and 255. I'm also usually using some kind of blur on my shading, possibly filling them with a gradient that has different opacity levels on its stops, so there's a lot of subtler opacity happening in my work. Sometimes there's an additional modifier created by changing the opacity level of a group of translucent shapes, or an entire layer. Or a complex appearance stack of multiple fills and strokes applied to single paths, each of which has their own opacity level (and mode!) that's modified by the path's overall opacity. But in terms of my interaction with the whole system it's largely just eleven levels spread out across 0%-100%. More precision would be nice now and then I suppose, I wouldn't complain if it existed, but in practice it's something I rarely need. Bjango does a bunch of super-fiddly UI work so maybe they need it more, I dunno.
- marcedwards 5y ago
  I use those shortcuts as well, and often change things in 5% or 10% jumps. This is a really deep topic though, and some of the issues are from cumulative rounding errors, which can happen if you stack lots of layers or stack layer effects. It’ll also depend if you’re just moving sliders around until things look good (which is great!), or if you’re doing something that require exact values (building LUTs to process map tiles etc). My main concern is that information is being thrown out at the input UI. As far as I can tell, Illustrator stores opacity as 8bit values internally. This can be tested by using the blend tool on objects with similar opacities. I just want our tools to be better.
  - egypturnash 5y ago
    With Illustrator, getting any change sure is an uphill battle. I wonder how many years it’ll be before selection rectangles are drawn properly when the canvas is rotated?
    - 5y ago
dahart 5y ago
The topic that this article raises, resolution of opacity, is pretty interesting IMO, but I feel like the argument itself could use some help. > Figma accepts up to two decimal places in its opacity text fields, providing 10,001 possible steps (0.00 to 100.00). That’s plenty for most uses. That’s overkill. Because the author assumed 8-bit color channels at the start, it’s worth noting that anything above 255 steps is guaranteed to be unnecessary. Having 10k steps to control the opacity of an 8-bit overlay is wasting a minimum of 5 bits. One thing the author doesn’t mention is that when you’re blending between two values, you only need as many steps as the difference between them. So if you’re putting transparent pink over red, you won’t need 255 steps, you might only need 50 steps. 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 are some such examples out there. One that comes to mind is color correcting after doing transparency work. Another might be workflows that involve recovering transparent colors from baked colors. (There is a technical term for this called “un-premultiplying”, which is well known to have horrible precision issues.) Another huge reason to consider transparency is with High Dynamic Range workflows, where the source colors have high precision, and may exceed the range of displayable colors.
- marcedwards 5y ago
  >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.

36 points by zdw 5y ago

In CSS you can add 2 more hex digits to an RGB hex code to access 256 possible opacity levels, like background-color: #RRGGBBAA. It's difficult to verify, but it seems that browsers also accept opacity values with arbitrary decimal precision in both percentages and real numbers from 0 to 1. I would imagine those get rounded at least to the closest value from 0 to 256.

marcedwards 5y ago
Yep, that’s my understanding as well.

notinty 5y ago

>For an opacity slider to provide 101 steps, it needs to be at least 101 pixels wide. There's no reason this needs to be the case: slider elements could trap the cursor and give realtime feedback of input. The iPad Pro trackpad does this with all UI elements and I believe it's an important step for UX.

marcedwards 5y ago
Yep, that’s an option as well, and some tools do it. Figma’s only layer opacity slider is via holding a modifier and dragging the text input field. I personally like having opacity sliders as well. They provide a nice visual representation of the state that’s easier to parse than reading a number, and you can also do things like set 100% with a single click. Layer opacity is important enough that it should have a text field, a draggable value with a modifier, and a slider. The other main point of the article is that these tools don’t seem to even realise their precision sucks.
- notinty 5y ago
  Agreed; immediate analog feedback of a slider is important. Thanks for the great article, the images you created are especially fantastic. Edit: my friend just checked and Clip Studio Paint also has 0-100 with no decimal support. Crazy that it's ubiquitous.
  - marcedwards 5y ago
    Sure is! Interestingly, Acorn can show the full 0-255 range.

cmiller1 5y ago

Can anyone really tell the difference between these fractional steps of opacity?

lnanek2 5y ago
I can't, but at least the article did add a paragraph claiming designers can: " Does it matter? Quite often, shadows are incredibly sensitive to opacity changes, and many shadows use values from around 5% to 20%. That means there’s only 15 or so steps in the usable range, and single step jumps can be quite noticeable. This is not the most pressing issue in the design tools we use, but it is a real problem. "
- marcedwards 5y ago
  There can also be cumulative rounding issues if you’d stacking lots of layers on top of each other. It’s a subtle issue, but a strange one. There’s no deep technical reason for it — the inputs are just losing data.
marcedwards 5y ago
Yep, for shadows and in other places, single percentage changes can definitely be visible.

egypturnash 5y ago

My illustration practice relies on a ton of transparency, and I get by fine with a much lower-precision control of it. Illustrator lets me set up keyboard shortcuts to 0/10/20/30/40/50/60/70/80/90/100% opacity and this is how I assign the vast majority of my opacity levels. Effectively I'm "losing" a lot more steps than just the difference between 100 and 255. I'm also usually using some kind of blur on my shading, possibly filling them with a gradient that has different opacity levels on its stops, so there's a lot of subtler opacity happening in my work. Sometimes there's an additional modifier created by changing the opacity level of a group of translucent shapes, or an entire layer. Or a complex appearance stack of multiple fills and strokes applied to single paths, each of which has their own opacity level (and mode!) that's modified by the path's overall opacity. But in terms of my interaction with the whole system it's largely just eleven levels spread out across 0%-100%. More precision would be nice now and then I suppose, I wouldn't complain if it existed, but in practice it's something I rarely need. Bjango does a bunch of super-fiddly UI work so maybe they need it more, I dunno.

marcedwards 5y ago
I use those shortcuts as well, and often change things in 5% or 10% jumps. This is a really deep topic though, and some of the issues are from cumulative rounding errors, which can happen if you stack lots of layers or stack layer effects. It’ll also depend if you’re just moving sliders around until things look good (which is great!), or if you’re doing something that require exact values (building LUTs to process map tiles etc). My main concern is that information is being thrown out at the input UI. As far as I can tell, Illustrator stores opacity as 8bit values internally. This can be tested by using the blend tool on objects with similar opacities. I just want our tools to be better.
- egypturnash 5y ago
  With Illustrator, getting any change sure is an uphill battle. I wonder how many years it’ll be before selection rectangles are drawn properly when the canvas is rotated?
  - 5y ago

dahart 5y ago

The topic that this article raises, resolution of opacity, is pretty interesting IMO, but I feel like the argument itself could use some help. > Figma accepts up to two decimal places in its opacity text fields, providing 10,001 possible steps (0.00 to 100.00). That’s plenty for most uses. That’s overkill. Because the author assumed 8-bit color channels at the start, it’s worth noting that anything above 255 steps is guaranteed to be unnecessary. Having 10k steps to control the opacity of an 8-bit overlay is wasting a minimum of 5 bits. One thing the author doesn’t mention is that when you’re blending between two values, you only need as many steps as the difference between them. So if you’re putting transparent pink over red, you won’t need 255 steps, you might only need 50 steps. 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 are some such examples out there. One that comes to mind is color correcting after doing transparency work. Another might be workflows that involve recovering transparent colors from baked colors. (There is a technical term for this called “un-premultiplying”, which is well known to have horrible precision issues.) Another huge reason to consider transparency is with High Dynamic Range workflows, where the source colors have high precision, and may exceed the range of displayable colors.

marcedwards 5y ago
>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.