But that reasoning only works if you’re close up. If you stand back sufficiently far from the screens, adjacent pixels will blur into each other so this is no longer necessarily true. Suppose we have a pattern that repeats every 4 high-resolution pixels (or half an 80-column character, or 1/160th of the screen width, or one colour carrier cycle) and we stand sufficiently far back that this looks like a solid colour. On the RGB monitor this will just be an average of the 4 colours making up the pattern. So, for example, black-black-white-black and white-black-black-black will look the same on the RGB monitor, but they will look different on the composite monitor because these two patterns have different phases with respect to the color carrier, so they will have different hues.

That explains how we can get details on the composite monitor but not on the RGB monitor, but what about the other way around? This is a bit more complicated, because it requires knowing some more details about how the CGA generates (non-artifact) colour on the composite output. For each of the 8 basic colours (black, blue, green, cyan, red, magenta, yellow and white) there is a different waveform generated on the card. The waveform for the current beam colour is sent to the composite output. The waveforms for black and white are just constant high and low pulses, but the waveforms for the 6 saturated colours are all square waves of the colour carrier frequency at different phases. The green and magenta lines switch between high and low on pixel boundaries, the other 4 at half-pixel boundaries (determined by the colour adjust trimpot on the motherboard).

What this means is that if you’re displaying a green and black or magenta and black image, the pixels are essentially ANDed with this square wave. The pixels corresponding to the low parts of these waves have no effect on the composite output. So you can use these pixels to make the image on the RGB monitor lighter or darker whilst having no effect on the composite image.

Here’s what the finished result is supposed to look like (with another image on an MDA display as well):

Note that I’ve allowed the composite image to show through on the RGB monitor a little in order to improve contrast.

Along similar lines, here is an interesting article about the interactions between gamma correction and image scaling. I hadn’t thought about that before (my own image resizing routines always just assumed a linear brightness scale) but this has definitely opened my eyes.

I think the way out of this is to make the virtual screen very small and close to the eye. This doesn’t affect the rendering in flat space (since only the directions of the rays matter) and effectively eliminates the need to take into account curvature between the screen and the eye (essentially it makes the observer into a locally Euclidean reference frame).

Another complications of simulated relativity is the inability to simulate time dilation. Well, you can simulate it perfectly well if you’re the only observer in the simulated universe but this would be a big problem for anyone who wanted to make a relativistically-accurate multiplayer game – as soon as the players are moving fast enough with respect to each other to have different reference frames, they will disagree about their expected relative time dilations.

Unfortunately, my Ubuntu desktop doesn’t do this correctly – some bits of text have a yellowish fringe and some bits of text have a bluish fringe, both of which are quite distracting. The problem is that while you can alter the horizontal position of something at sub-pixel intervals, you can only alter its width by whole pixels (otherwise the hue changes don’t cancel out and integrating over a region of the screen gives a yellow or cyan colour.

I’ve therefore had to switch my desktop to use grayscale anti-aliasing, which is a bit more blurry. Fortunately the pixels on my monitor are small enough that this doesn’t bother me very much. I do prefer the font rendering that Windows does, though. While FreeType does apparently include code to support Microsoft’s patented programmed hinting I can’t seem to get the font rendering on Linux to look as good as it does on Windows.

This worked great, but didn’t tell me why this was the right thing to do.

Later, reading about ray tracing I realized what was really going on. Your model is in 3D space but also in 3D space are some additional points – the entrance pupil of your eye and the pixels that make up your screen. If you imagine a straight line from your eye passing through a particular point of your model and going on to infinity, that line may also pass through the screen. If it does, the point on the screen that it passes through corresponds to the pixel on the physical screen at which that point should be drawn.

Since computer screens are generally rectangular, if the positions of the corners of the screen are a, b, c and d (a and d being diagonally opposite to each other) the position of the fourth corner can be determined from the first three by using the equation a+b=c+d. So to fix the position, orientation and size of the screen we only need to consider 3 corners (a, b and c). We also need to consider the position of the eye, e, which is independent of a, b and c. We thus have 12 degrees of freedom (3 coordinates each for a, b, c and e). Three of these degrees of freedom correspond to translations of the whole screen/eye system in 3D space. Two of them correspond to orientation (looking up/down and left/right). Two correspond to the horizontal and vertical size of the screen. Three more give the position of the eye relative to the screen. One more gives the “twist” of the screen (rotation along the axis between the eye and the closest point on the screen plane). That’s eleven degrees of freedom – what’s the other one? It took me a while to find it but eventually I realized that I was under-contraining a, b and c – the remaining degree of freedom is the angle between the top and left edges of the screen (which for every monitor I’ve ever seen will be 90 degrees – nice to know that this system can support different values for this though).

If you solve the equations, this system turns out to be exactly the same transformations as the original recipe, only a little more general and somewhat better justified. It also unifies the perspective and isometric views – isometric is what you get if the distance between the eye and the screen is infinity. Obviously if you were really infinitely far away from your computer screen you wouldn’t be able to see anything on it, which is why the isometric view doesn’t look as realistic as the perspective view.

Many 3D graphics engines allow you to set a parameter called “perspective” or “field of view” which effectively increases or decreases how “distorted” the perspective looks and how much peripheral vision you have. This is essentially the same as the eye-screen distance in my model. To get the most realistic image the FoV should be set according to the distance between your eyes and your screen.

Generation 1 – 256-480 pixels wide, 180-300 pixels tall (non-interlaced TV, handhelds)
Generation 2 – 512-960 pixels wide, 360-600 pixels tall (interlaced TV, older computer monitors)
Generation 3 – 1024-1920 pixels wide, 720-1200 pixels tall (most current computer monitors)
Generation 4 – 2048-3840 pixels wide, 1440-2400 pixels tall (“Q” standards – very high end monitors)
Generation 5 – 4096-7680 pixels wide, 2880-4800 pixels tall (“H” standards – no monitors exist yet)

Writing code to render these things is an interesting exercise. It’s easy to do with a ray tracer – if a ray intersects the disc inside one ring, just continue it to the equivalent point on the other ring.

Once that’s working, you can put the rings side-by-side so that light goes around in circles – if you put your eye point in the middle you can see an infinite tunnel.

A trick you can play is to reverse the orientation of one of the rings so that you look through one ring, out of the other to an object, the object will appear to you to be inverted, as in a mirror image.

Another trick is to make the rings different sizes, or shapes. As long as there is a 1:1 function equating points on one surface with points on the other, it works fine.

However, having rings of different sizes or non-circular shapes opens the possibility of putting one ring through the other. What happens then? It seems like the “infinite tunnel” then becomes a real thing rather than just an optical effect, but where does the second ring exist in real space? It seems that the only place it can appear is through the other side of the first ring, but that would mean that every point in space appears in an infinite number of places – this seems like it would have rather drastic consequences.

So it seems more likely that the second ring would be prevented from going through the first somehow (perhaps a ring edge would get in the way).

• Colour balance (2D slider)
• Exposure (slider)
• Dynamic range compression (slider)
• Tone mapping radius (slider)

The last two of these reproduce the functionality of current HDR applications, allowing creation of tone-mapped images for non-HDR output (like printing, or legacy monitors).

But such techniques will soon become unnecessary as the dynamic range that monitors can display increases. As I’ve mentioned before I’ve seen this technology in action and it’s seriously impressive – the pictures are incredibly realistic, like looking out of a window. As these monitors drop in price they will become ubiquitous and then we will want to take pictures that take full advantage of them.

Shooting RAW with a good digital SLR goes some way towards this, but I think that with the new generation of monitors will come a new generation of cameras optimized for taking HDR images. This might be as simple as reading the sensor several times over the course of the exposure, or it might be a completely new sensor design.

With new monitors and new cameras, the entire graphics pipeline will be re-engineered for HDR.

1. Copy the photos from the card to the computer and then delete them from the card.
2. Open the folder of photos in ACDSee and delete any obvious duds.
3. Open all the photos in Paint Shop Pro 4 (yes, I know it’s ancient but it works well, I know my way around all the tools and it’s fast).
4. I look for similar photos and close the ones that are redundant or unattractive, eventually whittling it down to the set of photos that will form a nice album page.
5. I rotate (sometimes by arbitrary angles) and crop. Sometimes I’ll adjust brightness and/or contrast to save a poor photo if there’s something in particular that I want to have a picture of. Sometimes I’ll use a more sophistical program like Photoshop to remove redeye or do other colour manipulations.
6. Very occasionally I will use the clone tool to erase something that I don’t want in the photo.
7. I’ll resample the photos to the appropriate size and save them as jpgs.
8. Finally I’ll manipulate the directory listing in a text editor to create the html file, add captions and upload the lot.

Someday I’ll trade in my trusty Olympus C3000Z and get a nice digital SLR. But I might wait a few years because the high dynamic range revolution is coming. More about that tomorrow.