0x0d0a's Journal: Fixing the Workstation Color Model

Currently, the color model used on workstation computers is very lacking in dynamic range. It cannot reach levels that are nearly bright enough. The real world contains sun sparkling on the water, car headlights, and the outdoors. Currently, a normal computer environment can only reproduce the brightness of a sheet of paper. This is a blocking issue to producing realistic virtual worlds and images.

This is a legacy problem dating back to old monochrome monitors, where there were only two shades of color to work with. Naturally, text was represented as full white (or black) and the text's background as the opposite color. This meant that white's brightness could be turned far up, but it would be very uncomfortable for the user -- if the monitor had a white as bright as car headlamps, then anyone reading a sheet of text would have an entire page of incredibly strong brightness blasting at them.

This color model continued to be used in the era of 16 color and 256 color workstation environments. In each case, all existing software was written with the expectation that white was the expected color for paper backgrounds. As a result, anyone that produced a new software package that used a darker color for a paper color would appear dingy and unusable on any monitor calibrated for the masses of existing software. It was impossible for software vendors to move away from an old color model, since they would run into visual compatibility problems with old software.

The only way to fix this is to introduce a compatibility mode into graphic display systems (like Xorg and the console framebuffer) where a lower brightness is used for all software that does not flag itself as understanding that it is running on a "full dynamic range" display. Then the monitor brightness may be turned up by, say, 50% (perhaps aided by a software calibration utility displaying patterns on the screen). All old software would have the brightness of its images reduced by the display system by an amount chosen to bring the brightness of 100% white down to the level of a piece of paper. All new software would be allowed to use the "extended" range of colors, with more brightness available. Common interface images and the like would not be extremely bright, but games could have bright explosions.

Images are all currently calibrated for the traditional "white is paper" setting. Image formats would need to be extended to contain a "use extended colorspace" flag, much like PNG contains a gamma setting.

Since this takes some work to implement, and there are two other changes to the workstation color model that need to be made, I would suggest that all three changes should be made at once.

The first additional change is the move to calibrated color systems. Currently, desktops are almost never callibrated to a particular level, unless they are being used by graphic designers. This results in an inability of designers to produce images that may be viewed by end users (if they so desire) at a correct brightness/contrast level. I strongly suspect that this is because even basic color calibration is made difficult (and often expensive) rather than the normal operation that it could be. There is a need for operating system display configuration tools (like the Monitors control panel on Mac OS, the Display control panel on Windows, the Screen Resolution capplet on GNOME, and the KDE Control Center Display tab) to contain a set of callibration images like the ones here to help ensure that the majority of monitors are properly callibrated (again, if the user so desires).

The second additional change is the move to 64-bit color. 64-bit color has been talked about for some time (at least for framebuffer use inside video cards), but hasn't yet caught on. 64-bit color will probably the last color move ever made, as it should pretty much max out the human visual system's ability to distinguish colors. 32-bit color (at least with 8 bits used for each channel) produces banding faintly visible to most people even with a conventional "paper is white" calibration. If you want to see if this affects you, use an image editing program (such as the GIMP) to create a fullscreen gradient, black to white, upper left to lower right, and see if you can see bands of brightness appearing in the image, despite the use of every 256 levels of gray available on your monitor. I can easily see bands (especially in the dark part of the gradient) on my monitor. Moving to a larger dynamic color range will exacerbate this problem if the number bits used for each channel do not incrase, since each brightness level will be further apart. Since apps must be updated to use 64-bit color, the 32-bit to 64-bit transition is an excellent time to introduce a broader range of brightness levels -- one would simply map old 32 bit colors to a range running from, say, 0 to 2^63 (or half of the available brightness range).

By simultaneously adding calibration images to display control panels, increasing the dynamic range, and increasing the bit depth available, end users can be given truly realistic (rather than the equivalent of ink-on-paper) visual reproductions of the outdoors, visually-identical images across workstations, and freedom from banded, perceptibly-imperfect images. There is no reason that users should be able to say "that looks like it's on a computer monitor" -- a computer monitor, properly set up, can properly reproduce everything that is seen in the real world.

All very well.

[Eivind]

Color-calibration is obviously needed if we want to reproduce colours more accurately. I'm not sure *how* important this is to John Doe though. Fact is, aslong as the image on the screen looks appealing to him, he has little reason to care if the image looks exactly as the graphic designer intended it.

Greater colour-depth migth be benefiscial too, allthough that migth also run into the same problem which the new super-audio-cds do -- while the new format is undeniably higher resolution and more advanced (

Re:All very well.

[0x0d0a]

Can you give me a few examples of situations where I migth reasonably want objects on screen much brigther than todays white *OTHER* than exploding things in video-games ?

Other than more realistic image reproduction -- not at the moment.

But remember that this was also the case when there was a push to move to 256 colors, 16-bit (and even 24/32 bit).

Re:All very well.

[Eivind]

This is true, sort of. But the rather large difference is that the contrast between 256 colours and 16-bit is humongous, that is, even the half-blind grandmother will agree that the 16-bit picture looks enormously much better.

The difference is clear enough that it's relevant in daily work. Perhaps not directly increasing productivity, but certainly a a 16-bit desktop is a lot more pleasant to look at than a 256-colour one.

16-bit to 24-bit I agree is sorta in the same category in that 16-bit pictures are

Wait 'til the ad guys see this

[Sloppy]

I wonder if the people who make web banners and other ads will decide that "paper white" is "white enough." Somehow I doubt it. Your idea is sound, but I can't say I look forward to ads that are bright as the sun, embedded inside relatively dim web pages. ;-)

Re:Wait 'til the ad guys see this

[0x0d0a]

Your idea is sound, but I can't say I look forward to ads that are bright as the sun, embedded inside relatively dim web pages. ;-)

It *is* possible for web browsers to filter/preprocess data that is coming in. Currently, very little of this is done.

The web browser dillo [dillo.org], which I've hacked on in the past, has a rudimentary, similar such feature, allowing 100% white backgrounds (which bother some folks) to be ignored. It would be pretty easy to extend this to cover a range of such values. A further evol

64 bit color

[brer_rabbit]

how useful would a color depth of 64 bits be on a typical LCD? If I remember correctly, most LCDs only have a color depth of about 14 bits of color. I have no doubt LCD technology will advance, but getting it up to where 64 bits is useful will certainly take a long while.

OT: relating to your .sig

[gmhowell]

I've seen you post in many discussions on /., and have always wanted to reply about your current .sig (a link to a site that talks about corporations that fund Bush). I figure an OT discussion in your JE is better than on the front page.

It was interesting reading, but didn't go 'all the way'. If you view the US as inherently two party, you would have to see if a given corp is disproportionately funding one candidate or the other. AFAIK, most of the corps linked to from that page fund both major party candi

Re:OT: relating to your .sig

[BandwidthHog]

I'd followed the link in his .sig as well, and found the information a bit less useful then I'd hoped for. And as someone who does completely boycott MS (lifelong, not even an indirect penny) and Wally World (a little over a year), that'd be a damn tough range of products to avoid.

A group called the Center for Public Integrity [publicintegrity.org] put out a large paperback called The Buying of the President 2004. (They also did one for 2000 and a few other books). It's a pretty even handed, fairly well researched breakdown of