this post was submitted on 02 Aug 2026
43 points (97.8% liked)
Programming
28027 readers
487 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I don't think we're going to agree on any points whatsoever, I'm afraid.
I think their method is pointless, that introducing new formats that are indistinguishable from well established ones is actively harmful, that their reasoning is flawed and raises mainly irrelevant points, and their only valid point is that fractions with denominator 256 are stored exactly, but then if the whole point of converting your colours to floats is to do interesting transformations of the colour space that you can't do with integers, that's all gone as soon as you start manipulating the floats, and all your carefully designed exactness went down the pan. If you want exact, keep it to the integers 0-255.
Neither[-0.5/255) nor [0,0.5/255) are some sort of disadvantaged and discriminated against group of humans that need more representation and I don't understand why on earth anyone would care even a tiny little bit if they were under represented nor why you would describe it as unfair.
The whole thing is really, genuinely deficient in benefits and has obvious drawbacks.
I'm trying to understand where this rage and hatred is coming from. This isn't some canonical interchange format here.
It breaks convention to solve an entirely nonexistent problem.
If you read the conclusion, it is very clear that you should not ever break convention. You should not apply this if it would affect any other program.
That is, if your input is in u8, your output should be in u8 too. Otherwise you are "exposing" your different quantization.
I don't think this post is telling you that you should use the 256 method. I think it is pretty clear that it is just explaining it, not advocating for it. At various points of the article it is written something like "I struggle to see a situation where it would be beneficial".