The Web was never supposed to be a graphical medium - it was originally intended for academics to publish their research papers on, not for selling jeans. Consequently, HTML, the Web authoring language, is somewhat limited in its handling of graphics, and techniques which are laughably commonplace in print or on TV are absent from the Web. There is no way to overlay an image on top of a separate image file, for example, without resorting to Java
In order to get the best out of Web graphics, it is important to understand their limitations. With a little ingenuity you can do almost anything but before you can ram-raid the rules you have to know what they are.
The two foundation stones of Web graphics are GIFs and JPEGs. They account for virtually 100 per cent of still images and most of the moving ones as well.
GIFs (Graphic Interchange Format) were the first graphics that early Web browsers could view inline - as part of the page, without spawning an external viewer. The format was developed by online service CompuServe in the mid-eighties as a platform-independent, bandwidth-conscious way of moving graphics across networks. CompuServe originally gave away the format. It made the library routines needed to build the ability to encode and read GIFs into an application.
GIFs are limited to 256 colours but they are far from unsophisticated.
As well as simple graphic data, you can define one colour as transparent so that whatever is behind it will show through. You can interlace your graphic so that the browser will display it as a full image, ranging from low- resolution to high - the louvre-blinds effect - rather than sequentially.
GIFs can even display simple animations, as we'll see.
To get the best out of a GIF you have to know its limitations as well as its tricks. GIFs use an internal colour palette, an index, to define colours. Each colour in the palette is defined as a full 24-bit colour (or eight bits for each colour channel - red, green and blue). In theory, any application which can display a GIF should adjust the display so that these are the colours shown. If you have a 256-colour monitor, you will have noticed some applications redraw the rest of your screen in different colours - that's what happens when something uses an indexed colour palette (sometimes also called a colour look-up table or CLUT).
Of course, it doesn't always work like that. If you have two 256-colour GIFs on a page, the chances are they don't share the same palette, which means your browser will have to compromise somehow.
Netscape Navigator and Internet Explorer compromise by dithering colours they can't reproduce - stippling two colours close together to look like a third. Most browsers dither reasonably well but the results can be ugly, so it's worth avoiding.
There are two ways to get around the problem. One is to reduce the number of colours in your images by lowering the bit depth of the GIF. A 256-colour GIF uses eight bits per pixel to describe colour. Lowering the bits per pixel to seven or less reduces the number of colours in the indexed palette. This means Netscape needs to make fewer compromises to show off your graphics. It also has the benefit of making the images' file sizes that much smaller, which to most designers is the main incentive for playing around with bit depth.
The second method is to get hold of the internal colour palette which Navigator uses to display colours and only use these colours. This is practically a must if you plan to use a lot of bold colour in your designs.
There are links you can follow which explain this rather esoteric practice better or you can purchase a product such as Pantone's excellent ColorWeb, which gives you a swatch book of the "safe" Web colours and a software colour picker to use with your graphics editor.
Animated GIFs are a recent discovery which are now popping up virtually everywhere. It seems that when CompuServe drafted the original GIF standard, it included a way to layer images sequentially so that they could be displayed one after the other. It just forgot to tell anyone. It wasn't until eight years or so later that Netscape Navigator 2.0 included the ability to decode and play GIF animations. It's ironic that with so much talk about delivering video on demand with MPEG 2 or QuickTime, by far the most common animation format on the Web is nine years old.
To create an animated GIF you need a suitable editor. On the PC, most animated GIFs are created in Graphics Construction Set, which is shareware, while on the Mac the professional choice is GIFBuilder, which is freeware.
Both packages allow you to stack up sequential frames, and define how long they're on screen and in what order. You'll probably need to create your images elsewhere because neither offers a set of image creation or editing tools. A number of products, notably Director and Premiere, let you export animations as sequences of picture files for compiling into animated GIFs.
When you create an animated GIF, most of the options available to you are the same as with the static variety. You can define a transparent colour, bit depth (although this is more complicated as all the frames must share the same palette) and interlacing. The latter is not recommended unless you want your animations to look like an out-of-tune TV.
However, there are some options relating to animation which are important to understand. For a start, you can choose how to dispose of each frame.
You can just keep each one on sreen with each successive frame piled on top of it, which is fine if your animation consists of identically sized frames, but you can optimise your animation by choosing one of the other two options - restore to background or restore to previous.
An animated GIF does not have to be locked to the size of its largest frame. You can define any size for the logical frame and then plonk each frame wherever you want within it. Using the restore to background option, this would make a sprite run across your Web page, background image and all. On the other hand, the restore to previous option allows you to place sprites on top of the first image you use in your animation. We used this technique to take an animation of two balls spinning around a logo from 180Kb to 50Kb; the animation loaded more quickly, too. By simply creating the first image as background and then specifying the position of the balls, rather than using an entire image as we did previously, we optimised a 30-frame animation about as far as it would go.
JPEGs are still resisted by some Web designers. As they are always full 24-bit colour, anybody viewing one on a 256-colour monitor will see an unpredictably dithered image. JPEGs also lack the options of GIFs - they offer neither transparency nor built-in animation. There is an equivalent to interlacing, called progressive JPEG, but this puts such a strain on the browser to decode it that it often holds up the process of displaying the whole Web page.
But JPEGs can be incredibly small. Instead of the 2:1 compression which is pretty standard with GIFs, a JPEG can be compressed to up to one-twentieth of its size without unacceptable loss of quality - more if you're prepared to accept what happens to the image as it's squeezed.
And therein lies the main difference between the two formats. Unlike GIFs, which simply store all their data in a more efficient way, JPEGs work by throwing away the parts you're least likely to notice. At high quality, low compression, it takes a graphics expert to spot the difference - the standard was invented by photographic scientists as a way of transmitting news photographers' pictures efficiently over telephone lines. At low quality, high compression, a distinctive blockiness sets in and regions of an image take on striking false colour. To talk like a pro, call these leftovers of digital munching "artifacts".
Picture the future
There are many people out there who are convinced there are better ways to do this. Much current activity concerns the use of Netscape plug-ins to add new ways of displaying graphics. Infinet's Lightning Strike, for example, uses fractal compression to compress graphics further than JPEG would allow, with far less degeneration of quality. Fractal compression converts an image into a set of numbers best described as a complex maths sum consisting of millions of fractal equations added together. The compression is achieved by throwing away the fractal numbers which have least significance - the bits you'd least notice.
This may sound exotic, but in fact it works the same way as JPEGs, except that JPEGs use less efficient cosines and Fourier transforms. The disadvantage is the extra processing demand to display the image, but with today's skyward trends in processor power this shouldn't be a problem for too long. Fractal compression and its even more esoteric cousin, wavelet compression, should have a bright future - so long as the companies which create these standards can persuade enough people it's worth the bother.
Other plug-ins seek to make it possible to view vector graphics inside Web pages. All the graphics types we have seen so far have been bitmapped - each pixel is represented by a single number. Vector graphics use good old geometry to represent lines. They're much smaller and, because the curves which make them up are represented only as mathematical formulae, they have no real resolution limit. Corel and Macromedia have released plug-ins for CorelDraw and FreeHand respectively.
The last development is the least likely to come to anything. Overcoming the 256-colour limitation of GIFs is a long-standing aim of several graphics standards organisations and of CompuServe itself. There is already a freeware version of a 24-bit redundancy compression-based graphics format called PNG, but how often have you seen a PNG file? Meanwhile, CompuServe was committed to creating GIF24 until Unisys threw a spanner in the works by announcing it wanted royalties for the portion of the LZW patent, the compression mechanism GIF uses, which brought work to a standstill. CompuServe is still publicly committed to setting a new standard but it can hardly be blamed for lack of enthusiasm with litigation looming.
Creating Web graphics is as satisfying as anything inherently frustrating and fiddly can be. Add the fact that owning a Web browser seems to turn everyone into a vitriolic critic and you sometimes wonder why you bother.
The reason, of course, is the opportunity to do things no-one has done before, and that's worth it.
Size is everything
Creating attractive Web graphics which are small enough to download in seconds rather than hours is an art in itself. But you can take some simple steps to ensure your Web site doesn't end up as digital treacle:
1. Plan ahead. Work out what kind of person will be viewing your site and set a maximum "weight" for each page. Someone looking at a Web site over a leased line will be less concerned about download time than someone on a 14.4kbps modem, so design a corporate report differently from a fan club page.
2. Do consider JPEGs. If you have natural scenes such as faces or landscapes, the unpleasant dithering effect that people will see if they only have a 256-colour graphics card will be reduced by the natural complexity of the image. And 24-bit viewers will see the graphic in its true glory.
3. If it works in 256 colours, will it work in 128? Applications such as Photoshop and Paintshop Pro let you set the number of bits for a GIF.
It's worth experimenting with lower bit depths to see whether you can get away with less colours. Remember, each kilobyte saved is a second less downloading time.
4. Design for fewer colours. Use flat colour and avoid gradients. GIFs lap up simple flat colour; gradients reduce the compression available dramatically.
5. Use repeating elements. I remember seeing one magazine's site where the designer had neatly rendered a separate graphic for each star rating on a reviews page, where they could have used the same star, repeated as desired. This works especially well for multiple pages - Netscape's cache will hold the graphic in memory until it's needed again, in a separate layout.
10 ways to do graphics
1. Don't be afraid to cover lots of screen area. Correct use of GIFs or JPEGs can make a 400 x 400 pixel image no bigger than a simple icon.
2. If you have something you know people will beg to see at high quality, use a non-standard way of displaying pictures, such as Lightning Strike.
3. Don't overdo animation. The human eye is easily diverted and a flickering mailbox icon might distract people from the rest of your page.
4. Use and abuse Netscape's cache. If you want an image to load instantly on a following page, try hiding it on an earlier, text-heavy page as a 1 x 1 pixel image with Width=1 and Height=1 attributes. By the time the viewer has finished reading, the file will be waiting in memory.
5. Look for incompatibilities between Navigator and Explorer. They handle the Loop command in animated GIFs differently.
6. Other browsers can't display animated GIFs at all and only show the first or last frame. Make sure the first and last images add something to the page.
7. Learn the non-dithering HTML colours by checking out Victor Engel's Non-Dither pageor by hacking out Navigator's internal colour lookup table with a resource editor. And use them.
8. Don't get as precious about colours as you would in print. In our office an orange background on one Mac showed up as brown on another, while the token PC displayed it as bright red.
9. You can display a low-resolution version of your file before the real thing turns up by adding a LOWSRC="file name" to the main IMG tag. Use it to display a black and white (1-bit) version of your image or a vastly scaled-up version. The Height and Width attributes affect the LOWSRC image too, so an icon version of an image can be blown up to a blocky representation.
10. Cunning designers realise the LOWSRC command can be used to display any image. So you could use it to change one image into another, provided you don't use too many on the page.
Cotton seedling freezes to death as Chang'e-4 shuts down for the Moon's 14-day lunar night
Fortnite easily out-earns PUBG, Assassin's Creed Odyssey and Red Dead Redemption 2 in 2018
Meteor showers as a service will be visible for about 100 kilometres in all directions
Saturn's rings only formed in the past 100 million years, suggests analysis of Cassini space probe data
New findings contradict conventional belief that Saturn's rings were formed along with the planet about 4.5 billion years ago