Complementary <IMG> tag propositions.

Here are a number of proposed attributes to the <IMG> tag.
These provide very simple image processing facilities to HTML.
These complement the algorithmic texture proposals outlined elsewhere.

In the past, low client-side processing power may have meant that the performance advantages of performing image processing at the clients end, rather than storing multiple copies of the image on the server, were small.

Now however, due the the shapes of the curves describing the bandwidth improvement rate (especially over the POTS), and the those describing the rate of increase in processing power, it is very clear that now bandwidth problems are nearly always the bottleneck, and in the future this effect will become even more pronounced.

There is a current trend towards thin clients, and it may seem that performing complicated processing tasks at the server's end is more in keeping with modern trends.

However, most image processing operations are trivial in comparison with (for example) decompressing JPEGs, executing Java applets, and speech recognition, and no-one is proposing that these should be performed by the server.

In order to break the image processing ice that seems to be present, two very simple attributes to the <IMG> tag are proposed.

These are the HFlip and VFlip attributes. Their function is trivial and obvious. Their use is mainly to halve or quarter the data required to represent symmetrical images, or reflected images.

As an example of the use of symmetrical images, readers are referred to an image on the author's main pages. As this image is one of the first things new visitors to the site see, it is important that it be loaded as quickly as possible, unless passers by decide to go elsewhere. The time taken for it to download could be halved if HTML allowed the use of the HFlip attribute.

It should not be thought that by describing the HFlip and VFlip as trivial and obvious, that it is believed that implementing code that plots transformed JPEGs, GIFs, and movies is trivial, as it is not. To start with it would be possible to create new identical images which are mirror images of their sources. This is genuinely trivial (in comparison to rendering the images in reverse), but it is wasteful local resources (though no worse that dealing with two images, or an image of double the size).

It is true that old browsers will display two identical images when instead of an image and its flipped version. This should not delay the incorporation of these commands into browsers for a moment. Indeed as they are currently lacking, it should hasten their implementation, as their eventual incorporation is almost inevitable, and the sooner it happens, the smoother the transfer will be.

With millions of dollars of wasted bandwidth being involved annually, surely the only opponents to these obvious proposals can be the telecos.

The ideas presented here are assumed not to be original due to their extreme simplicity. Little research has currently been undertaken to establish what developments are occurring elsewhere on this front, and as a consequence of this, this document may well be out of date as you read it. These points are made here as they complement some of the algorithmic texture proposals.