This is a stupid debate. Of course you should use 255. Everybody uses 255.
The standard algorithm means that if you go from int(0-255) to float, black stays black and white stays white. The silly new one turns the extremes very slightly grey.
This needs stomping on, because inventing a conflicting standard where there’s currently only one is really really stupid.
If you actually want an even distribution of random colours (who on earth wants that?) then instead of generating random floats, generate random int(0-255). It’s not hard. It really isn’t.
I bet you that float values that round to 0 come up in float colour data way, way, way more frequently than values that round to 0.5/256, nullifying the silly mathematical point that you might get 0 less often. No. No you won’t. Not in real data.
If you’re generating random numbers you apply the correction to your random numbers: [0, 1) is a bin for zero, and [255,256) maps to 255. If you are sampling as such, you are responsible for applying the correction as part of your quantization.
256 never comes up, because it cannot in the 8bit quantization.
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”.
This is a stupid debate. Of course you should use 255. Everybody uses 255.
The standard algorithm means that if you go from int(0-255) to float, black stays black and white stays white. The silly new one turns the extremes very slightly grey.
This needs stomping on, because inventing a conflicting standard where there’s currently only one is really really stupid.
If you actually want an even distribution of random colours (who on earth wants that?) then instead of generating random floats, generate random int(0-255). It’s not hard. It really isn’t.
I bet you that float values that round to 0 come up in float colour data way, way, way more frequently than values that round to 0.5/256, nullifying the silly mathematical point that you might get 0 less often. No. No you won’t. Not in real data.
If you’re generating random numbers you apply the correction to your random numbers: [0, 1) is a bin for zero, and [255,256) maps to 255. If you are sampling as such, you are responsible for applying the correction as part of your quantization.
256 never comes up, because it cannot in the 8bit quantization.
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”.