• BlackLaZoR@fedia.io
    link
    fedilink
    arrow-up
    44
    ·
    5 days ago

    “It’s a bit technical,” begins Birdwell, "but the simple version is that graphics cards at the time always stored RGB textures and even displayed everything as non linear intensities, meaning that an 8 bit RGB value of 128 encodes a pixel that’s about 22% as bright as a value of 255, but the graphics hardware was doing lighting calculations as though everything was linear.

    Jesus Christ, I knew this was a problem with image editing software back then, but I never knew, that GPU manufacturers fucked it up as well. How did this happen?

    • Mistic@lemmy.world
      link
      fedilink
      English
      arrow-up
      14
      ·
      edit-2
      5 days ago

      I have a good guess on how this would actually happen:

      PM: We need this

      Specialist: makes this (doesn’t check results)

      QC: Looks good (but doesn’t actually check)

      Some updates later may further break the functionality. And as long as numbers aren’t blatantly wrong (think 0s everywhere, for example) and nobody checks thoroughly enough, the issue will remain.

      I have unfortunate experience of being a part of such a story, haha. There are ways to counter it. Mainly, their project documentation either wasn’t up to par or wasn’t used as a reference during creation and tests. Either way, it’s negligence.

      • BlackLaZoR@fedia.io
        link
        fedilink
        arrow-up
        3
        ·
        5 days ago

        I imagine in case of GPU design, there should be a bunch of tests for image correctness at some point, which would require pixel perfect reproduction to pass.

        But it’s plausible that tests were running incorrect math too.

    • leds
      link
      fedilink
      English
      arrow-up
      2
      ·
      4 days ago

      Linear is probably a lot faster?