Comment by dahart | Hacker News Reader

Comment by dahart | Hacker News Reader

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.

>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.

> Having 10k steps to control the opacity of an 8-bit overlay is wasting a minimum of 5 bits.

It’s a user interface. The highest priority is how it helps the user understand what they are doing, not how many bits of data it takes. For example, if you want to express 1/3rd opacity in percent, you want to be able to type 33.33% and have it stay that way. It would be very frustrating if it was rounded to whatever the closest “actual” value was.

I also seem to recall that Figma supports typing mathematical expressions rather than literal values in many fields, which makes it even more important that the value of the expression isn’t rounded destructively.

That’s a great example. I wish I used it in the article.

Great point about UI; I’m simply responding to the argument that was made, which was based on the number of steps available between two 8-bit values.

> It would be very frustrating if it was rounded

To your point, 33.33% is rounded, it isn’t 1/3. But, at the end of your operation, the result is going to be rounded and clamped, so there are many workflows where professionals are going to want to see the rounded “actual” values. Being able to input 1/3 is valuable, and being able to see the precise result is also valuable.

>professionals are going to want to see the rounded “actual” values

Ideally, a generalised design tool should cater for rounding to 8bit and other meaningful precisions, or keeping source data intact.

All we’re talking about is _allowing_ for a user to type in a fractional number, and for it to be kept. It’s not a difficult request, and it doesn’t negatively affect normal use for people who don’t even know the feature exists. They can continue typing in integers.

If we’re talking about software design, it’s likely that in many situations the buffer being rendered into will be deeper than 8bit per channel, so even covering 0-255 is not enough.

Fully agree with the UI suggestion of being able to input exact numbers and furthermore: symbolic math expressions. I would personally use expressions even more often than exact numbers, and expressions would as a byproduct allow a true 1/3 rather than a rounded 33.33%. I was agreeing with this idea above, did it seem like I was arguing? Sorry about that.

The UI inputs are a somewhat separate topic from how much resolution is needed for transparency. I think a thorough investigation of necessary transparency resolution would be really interesting, something along the same lines as how perceptual color spaces have been developed, by examining things like the “just noticeable difference” in transparency values and mapping that across the space of all possible color mixtures and transparency values to get an understanding of how stretchy the space is.

Reply on news.ycombinator.com