Yes, indeed. If you’re randomly generating colours and you want to evenly cover the {0,1,…,255} integer space, then generate a random integer in that range directly, or truncate a random float in [0,256). Generating a random float in [0,1) and converting it afterwards, then complaining you’re not getting enough 0 or 255 is silly.
The random number generation is not the source of the complaint. That is just made to easily prove the point in the article.
The argument is not to use another method when randomly sampling from [0,1). The argument is that f32 color channels are already in the [0,1) range, and following the alternate method results in a “fair-er” representation of the range.
The plot that was generated with the random sampling is just to show that the standard method is not “fair”.
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.
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”.
Yes, indeed. If you’re randomly generating colours and you want to evenly cover the {0,1,…,255} integer space, then generate a random integer in that range directly, or truncate a random float in [0,256). Generating a random float in [0,1) and converting it afterwards, then complaining you’re not getting enough 0 or 255 is silly.
The random number generation is not the source of the complaint. That is just made to easily prove the point in the article.
The argument is not to use another method when randomly sampling from
[0,1). The argument is that f32 color channels are already in the[0,1)range, and following the alternate method results in a “fair-er” representation of the range.The plot that was generated with the random sampling is just to show that the standard method is not “fair”.
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”.