4 ms·

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

by tobr 5y ago

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

marcedwards 5y ago
That’s a great example. I wish I used it in the article.
dahart 5y ago
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.
- marcedwards 5y ago
  >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.
  - dahart 5y ago
    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.

by tobr 5y ago

marcedwards 5y ago

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

dahart 5y ago

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.

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