• [object Object]@lemmy.ca
    link
    fedilink
    arrow-up
    5
    ·
    1 day ago

    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.

    • Log in | Sign up@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      1 day ago

      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.

      • calcopiritus@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        13 hours ago

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