The real world versus the computer screen

Computer graphics and painting both suffer from similar limitations in that each point on the canvas / computer-screen can only let of a finite amount of light. If you assume the painting to be in a room with fixed lights then the cavas and the computer screen have exactly the same problem. A TV or computer screen has red, green and blue values that range between say 0 and 255 and once you hit 255 you can't go any brighter. The brightest colour that you can represent is white, with red, green and blue values of 255. The painter is also unable to represent anything brighter than white paint. But in the real world you could see yellowish white paper and the yellow whiteness of the sun and while they might be painted with similar paint they have absolutely different levels of brightness, and the brain can feel these differences very clearly. How do we represent these differences?

Approaches for representing extreme brightness

There are four approaches to solving this problem of representing very bright objects in computer graphics. The first one is to manufacture a computer monitor that can represent red, green and blue values that are almost unlimited, or more practically, ten or so times brighter than the mainstream monitors. It would then be the responsibility of the software developers to keep most applications in the lower range and only use the bright values where appropriate. This is akin to a digital recording engineer keeping the digital signal low so that they do not produce clipping. I could write a whole essay about how such a monitor would revolutionalize the graphics, games and film industries.

The second approach is to use strong negative gamma correction so that the 255 values of red, green and blue are virtually never touched. A normal brightness value of 100 might be mapped to 100, 200 mapped to 180, 300 mapped to 220 and 100000 mapped to 254, for example. This solution results in the highest quality production with current monitors from a theoretical perspective however it is not practical because everything would look far too dull.

The third approach is to provide some sort of colour saturation so that if a red brightness value exceeds 255 then it is clipped at 255 but the remainder is used to increase the green and blue values slightly, bringing the colour closer to white. This is somewhat similar to what the brain does when it receives a very bright red signal - although there might be no green or blue in the signal, the brain will still register the signal as somewhat white - adding in the green and blue signals intrinsically. By clipping the red, green and blue values in this way, we cannot represent the differences between something bright and something extremely bright because once part of the scene is shown as white then it cannot become brighter. The other problem is that if you have two parts of the scene that have an rgb colour of 255, 120, 120 then it is possible for one area to have been produced by a saturation formulae applied to 400, 50, 50 while another part of the scene might of the genuinine 255, 120, 120 colour - yet the viewer will not be able to know. In any case this is the most practical technique that we must resort to using with current technology. The saturation formulae that I created for the 3D Matrix product is shown below. The reason for having so many 'if' statements is that the mapping needs to be very fast when calculated for tens of thousands of polygons each frame.

      float whiteIncrease;
      if (red > 255) {
        if (blue > 255) {
          if (green > 255) {                                         // rgb
            red = 255;
            green = 255;
            blue = 255;
          } else {
            whiteIncrease = (1 + blue / 256f * red / 256f) / 2f;     // rb
            blue = 255; red = 255;
            green *= whiteIncrease; if (green > 255) green = 255;
          }
        } else {
          whiteIncrease = (1 + red / 256f) / 2f;                     // r
          red = 255;
          green *= whiteIncrease; if (green > 255) green = 255;
          blue *= whiteIncrease; if (blue > 255) blue = 255;
        }
        if (green > 255) {                                           // rg
          whiteIncrease = (1 + green / 256f * red / 256f) / 2f;
          green = 255; red = 255;
          blue *= whiteIncrease; if (blue > 255) blue = 255;
        }
      } else if (green > 255) {
        if (blue > 255) {
          whiteIncrease = (1 + green / 256f * blue / 256f) /2f;      // gb
          green = 255; blue = 255;
          red *= whiteIncrease; if (red > 255) red = 255;
        } else {
          whiteIncrease = (1 + green / 256f) / 2f;                   // g
          green = 255;
          red *= whiteIncrease; if (red > 255) red = 255;
          blue *= whiteIncrease; if (blue > 255) blue = 255;
        }
      } else if (blue > 255) {
        whiteIncrease = (1 + blue / 256f) / 2f;                      //  b
        blue = 255;
        red *= whiteIncrease; if (red > 255) red = 255;
        green *= whiteIncrease; if (green > 255) green = 255;
      }
      if (red > 255 || green > 255 || blue > 255) {
        System.out.println("Error with calculating colour.");
      }

The same sphere beside light of varying brightness, lens flare saturation built into 3D Matrix modeler

The fourth technique attempts to follow what happens in cameras and to some extent the human eye when they are exposed to a very bright object. Various distortions and artifacts appear around the bright objects and these distortions can be studied from camera images and rendered as images that can be superimposed within the scene. For example, if you wanted to represent a red, green, blue value of 1000, 50, 50 then you might map this to 255, 200, 200 using a saturation algorithm similar to the one above, but also render a lens flare over that point because the red value was clipped so extremely from 1000 to 255. The style and intensity of the lens flare should be associated with how strongly the colour was clipped.

In D-Zone II explosions are created automatically by just adding bright lights

I used this technique in the computer game D-Zone II (Destruction Zone) and it made an enormous impact. Previously bright explosions were represented by releasing strong light sources and debris into the scene but this created a lot of white areas and little sense of the extreme brightness of the debris. After applying lens flares around highly clipped colour values, the game suddenly looked about twice as good. The innovation with D-Zone II was to only consider the brightest polygon in each model and add a lens flare around this polygon, rather than adding lens flares around all bright polygons which would be far too slow. This gave some extra emphasis in brightness to smaller models but this suited the game.