Graphics on the ARM
Another RISCWorld exclusive serialisation.
Most of the graphics incorporated into DTP documents and computer-based audio-visual presentations are pixel graphics (sprites). Of these only a few represent the result of painstaking artistic endeavour using Paint or other creative software. Most were produced electronically in a matter of seconds from artwork that already existed but in some other format.
If the source material is a photograph, a drawing or some other conventional document, its contents can be convened into digital data using a scanner, software converting the data from the scanner into pixel graphics format. If the source material is video, i.e. derived from a video camera, videotape, videodisc or a television receiver with video output, it can be converted using a video digitiser.
There are two other commonly used sources of ready-made pixel graphics. If the artwork you are creating is for a software manual, catalogue or advertisement, you may wish to include screens generated in the software being described. These may even have originated on a 'foreign' computer type. These too are sprites. Finally, collections of ready-to-use graphics (clip art) are sold by some software suppliers for the express purpose of adding interest to computer-generated documentation.
Scanners vary widely in size, shape, specification and cost. The simplest are hand-held devices that the operator rolls slowly over the document being scanned, On more sophisticated type's, a motor winds the document through the machine, much as it does in a printer. On the most advanced types such as the Epson GT-6000 and GT-8000 the document is placed face down on a window and the machine does the rest, under software control.
All, however, work on the same fundamental principle: as the scanner head moves past the document (or vice versa), it is illuminated and the light being reflected from it is repeatedly measured by an array of tiny light-sensitive cells. The output from these cells is converted to a digital signal which is sent to the computer for processing.
All scanners need scanner-driver software and most need a special card, a podule or expansion card, which fits into the computer's backplane and into which the lead from the scanner is connected. Software converts the data from the scanner into standard sprite format, although some scanner-driver software offers alternative formats which use compression and so require less storage space. Image processing options may also be available.
Some scanners are strictly monochrome, discriminating only between black and white; colours and intermediate shades are regarded as either black or white, a threshold control being provided. Some scanner-driver software can accommodate intermediate shades by converting them to dither patterns. RISC Developments' Scavenger, for instance, has an option that uses clustered dot dithers. In these the dots are made up from a matrix of pixels in which the size of the dot is varied to simulate the shade being reproduced. The dots are arranged diagonally since rectangular patterns are more conspicuous and distracting. This form of dithering is preferable to the dispersed dot dither used on the screen (in which shades are distinguished by varying the density of single-pixel dots) when the material is intended for printing. Indeed the process is very similar to the 'screening' used in the printing industry to convert half-tones such as photographs to a form in which they can be reproduced using black ink. An alternative option antialiased 2 colour sprites by arranging the pixels in groups of 4 x 4 and replacing each such group by a single pixel in a 16 colour mode with a special grey-scale palette. The resulting sprite, of course, has only one sixteenth the number of pixels as the original scanned image, but since each pixel is represented by 4 bits instead of 1, it requires one quarter of the storage space.
Other scanner systems recognise tints and some recognise colours, offering 2-, 4-, 8- and even 24-bit colour modes, almost like screen modes in reverse. Some colour scanners need to make three separate passes over the document, one for each primary colour; a filter is changed inside the scanner head before each pass. This of course lengthens the scanning time.
Probably the most sophisticated scanning package for the Acorn 32-bit machines is Proimage from Irlam Instruments Ltd. This includes an Epson GT6000 scanner, leads and software. Optionally a GT8000 can be supplied. Strictly speaking, no interface board is needed with the A5000 computer, the scanner connecting directly to the machine's printer port which is bi-directional, but you will be unable to connect a printer to this port at the same time as the scanner unless you use an additional Centronics switch box. For other computers you will need an interface card which provides its own port for the scanner, leaving the printer port available for other peripherals.
The scanner scans in monochrome or 24-bit colour with user-selectable resolutions from 50 to 600 dots per inch (800 dpi on the GT8000) and a maximum document size of 297 x 216 mm which accommodates both European A4 and US Letter sizes. The usual scanning procedure first makes a preview scan at low resolution and in monochrome. The user drags a box around the area of interest, selects colour or monochrome and required resolution and then starts the scan proper. This takes some time depending on document size and resolution. The image (in full 24-bit colour if colour was selected) is buffered internally to hard disc and subsequently processed to Acorn sprite standard using Floyd-Steinherg error diffusion (described in the next chapter). Colour rendering is excellent; plate 5 is an example of its output.
There is one vital point to remember. At a full 600 dpi and in 24-bit colour an A4 document generates an image of size approximately 100 Mbytes (uncompressed) which clearly cannot be loaded into an existing Acorn computer. For the time being this package is restricted to scanning small areas at higher resolutions or larger areas at lower resolutions. But even at 100 dpi a full colour image is impressive.
Choice of scanner resolution
Most scanners, like most printers, offer a choice of resolutions. Even the simpler hand-held monochrome scanners frequently offer resolutions of 100, 200, 300 and 400 dpi, The choice of scanner resolution is, however, not so simple as it might appear and there are occasions when you should resist the temptation to scan at the highest available resolution. Ultimately it depends entirely upon what you want to do with the scanned image.
If you only wish to display the scanned image on the monitor screen at its original size, 100 dpi should be quite adequate: little would be gained from scanning at a higher resolution.
If you intend to import the scanned image into a DTP or drawing package destined for printing, the printout will be crisper if you use a higher scanner resolution, but you will almost certainly need to rescale the image in the DTP or drawing package and the scaling ratio is critical. Images from scanners are generally converted to sprites in modes 18 to 21; RISC OS regards the natural size of these sprites as 90 pixels per inch, so that their pixels match the nominal resolution of the monitor screen. Consequently, if you scan an image that is 4 inches wide at 300 dpi and import the resulting sprite, 1200 pixels wide of course, into a DTP or drawing document, you will find that its width is taken to be 13 1/3 inches. In other words, on a dimensions-only basis it has been scaled up by a factor of 300:90 and will be too wide to fit on an A4 page. So you will need to use the scaling facilities in your DTP or drawing software to reduce it to a more convenient size.
Note that these scaling facilities only affect the scale at which the graphic is reproduced on the screen or in printouts; the actual number of pixels in the sprite is not affected.
So, what scaling factor should you use? Let's take the simplest possible option and scale the image back to its original width of 4 inches. The required ratio is of course 90:300, the inverse of that previously applied by the package. You may need to express this ratio in a different format such as 30% in Ovation or 0.3 in Draw. This rescaling will pose no problems and since it restores the resolution of the image to 300 dpi, it brings the added bonus of a dot density which is used by many printers. If you print the document on a 300 dpi printer, there will be an exact dot-for-dot correlation between the scanned image and the data sent to the printer, so you should obtain a clean, accurate reproduction of the original.
Now you may well have been tempted to scan at the highest resolution available on your scanner, thinking that this will give the best quality. Let's see if this is true. Let's return to the previous example and see what happens when we scan the same original at 400 dpi and then print it on a 300 dpi printer. The sprite obtained will now be 1600 pixels wide and the handling package will regard it initially as 17 2/3 inches wide. To restore it to its original size would need a reduction of 90:400 (or 22.5% or 0.225). With some packages, such as Ovation, we should now be in trouble. Ovation's scaling facilities only handle percentages in whole numbers, so we should not be able to restore the image to its exact original size. And the 0.5% error when printing out that image rescaled to 22% or 23% would lead to inaccuracies in the printout which may well be visible as Moire fringes-periodically repeated stripes or streaks across and down the image.
Even if your DTP or drawing package does allow scaling as fractional percentages or by ratios such as 90:400 you still have a problem. You will have scaled the image back to its original dot density of 400 dpi but the printer prints at 300 dpi. This is not an exact correlation; the printer driver will need to interpret each 16 dots of the source image as 9 pixels for the printer, sufficient to introduce fringes, or if not fringes, some loss of definition.
Oddly enough, there is a simple solution. You know that your freshly imported sprite was scanned at 400 dpi, but your DTP or drawing software doesn't. It simply regards it as a large 90 dpi sprite. So you could pretend that it had been scanned at 300 dpi and scale it to 30% as before. It will now print out perfectly satisfactorily, but will be one third larger than life. You have effectively 'spaced out' the 400 dpi to 300 dpi. In the previous examples, if you had intended to use a 360 dpi printer, this would have introduced a new set of problems. 300 dpi does not translate very well to 360 dpi, so a new set of scaling ratios is needed to scale the image to a suitable pitch for the printer. If the image was scanned at 300 dpi, scaling by 90:360 (25% or 0.25) will raise the dot density to 360 dpi and this will give a clean printout on a 360 dpi printer, which will be approximately one sixth smaller than life.
If you use a 600 dpi printer (such as Laser Direct Hi-Res) to print out an image scanned at 300 dpi at its original size, you gain no benefit. My experiments with photographs scanned at 300 dpi show that actual-size printouts at 300 and 600 dpi are identical. But if you scale the sprite to 15% forcing the dot resolution to 600 dpi and then print at 600 dpi you obtain a printout that is half the height and width of previous printouts but still contains all the original detail. Reproduction is needle-sharp and very attractive. In all but the last of the examples considered so far the printout has been at the same or a similar size as the original scanned image. Supposing you want to print your scanned image at half or quarter or double its original size? You must first take account of the 'primary' scaling factor, i.e. the scaling factor needed to restore the image to full size or nearly full-size compensating for the printer resolution. With a 300 or 600 dpi printer this is 90% for 100 dpi scans, 45% for 200 dpi scans, 30% for 300 dpi scans, 22.5% for 400 dpi scans and 15% for 600 dpi scans. And you should only rescale your image to simple multiples of that primary scaling factor. Table 10.1 lists some scaling ratios which should give clean printouts with various scanner and printer resolutions. It does not claim to be exhaustive, so feel free to experiment. But if you choose an awkward scaling factor such as 13% simply because that makes the image fit the space available, don't be surprised if you end up with a nasty touch of the Moire fringes. I have sometimes seen manufacturers' literature prepared in-house using DTP equipment in which scanned images have been ruined by Moire fringes; clearly the operator scaled them to fit without thinking of the possible consequences!
Table 10.1 Scaling factors for clean printouts of scanned images Scanner pitch (dpi)
width="90%" border="0" cellpadding="0" cellspacing="0">
|100 ||200 ||300 ||400 ||600 ||800 ||1200|
|30%=1:3 ||15%=1:3 ||10%=1:3 ||5%=2:9 ||5%=1:3 ||5%=4:9 ||5%=2:3|
|45%=1:2 ||30%=2:3 ||15%=1:2 ||10%=4:9 ||10%=2:3 ||10%=8:9 ||10%=4:3|
|60%=2:3 ||45%=1:1 ||30%=1:1 ||15%=2:3 ||15%=1:1 ||15%=4:3 ||15%=2:1|
|75%=5:6 ||60%=4:3 ||45%= 3:2 ||50%=4:3 ||20%=4:3 ||20%=16:9 ||20%=8:3|
|90%=1:1 ||75%=5:3 ||60%=2:1 ||i5%=2:l ||25%=5:3 ||30%=8:3|
|135%=3:2 ||90%=2:1 ||75%=5:2 ||50%=8:3 ||30%=2:1 ||40%=32:9|
|180%=2:1 ||120%=8:3 ||90%=3:1 ||90%=4:1 ||40%=8:3 ||45%=4:1|
|25%=5:18 ||25%=5:9 ||25%=5:6 ||5%=2:9 ||5%=1:3 ||5%= 4:9 ||5%=2:3|
|50%=5:9 ||50%=10:9 ||50%=5:3 ||25%=10:9 ||25%=53 ||25%=20:9 ||25%=10:3|
|75%=5:6 ||75%=5:3 ||75%=5:2 ||50%=20:9 ||50% =10:3|
Note: the scaling factor is given as a percentage; the accompanying ratio is that of the size of the printed image to the scanned image. For example, an inlay scanned at 200 dpi, rescaled to 60% and printed at 300 dpi will be 4/3 of its original size.
These ratios should give clean fringe-free printouts in all circumstances, but they are not necessarily the only ratios that will do so.
Oddly, for colour scanners you can choose lower resolutions without the deterioration in quality becoming evident. A full colour scan at 100 dpi looks quite crisp, although a monochrome scan at the same pitch looks distinctly coarse. This is because the colours themselves provide automatic anti-aliasing. It is precisely the same optical illusion that is provided by the use of intermediate greys in on-screen text using the Acorn outline fonts.
And it is just as well that colour scans can use lower resolutions because, as we noted earlier, the combination of colour and high resolutions gobbles up the memory. Table 10.2 gives some guidelines. Clearly, if the sprite is larger than the RAM available in your computer, you will not be able to process it or to include it in documents. You may be able to store it on hard disc; this depends on the facilities offered by your scanner driver software. And even if it is too large for that, you may be able to pass the data coming from the scanner straight through to a colour printer, effectively giving you a colour photocopying facility. This may be useful (and profitable).
|Pitch ||2 colours ||4 colours ||16 colours ||256 colours ||24-bit|
|(dpi) ||1 bit per pixel ||2 bits per pixel ||4 bits per pixel ||8 bits per pixel|
|75 ||60 K ||120 K ||240 K ||480 K ||1.4 M|
|100 ||107 K ||214 K ||430 K ||860 K ||2.6 M|
|150 ||240 K ||480 K ||960 K ||1.9 M ||5.8 M|
|200 ||430 K ||860 K ||1.7M ||3.4 M ||10.2 M|
|300 ||960 K ||1.9 M ||3.8 M ||7.7 M ||23 M|
|400 ||1.7M ||3.4 M ||6.8 M ||13.6 M ||40.8 M|
|600 ||3.8 M ||7.7 M ||15.7 M ||31.5M ||95 M|
|1200 ||15.7 M ||31.5M ||63 M ||126 M ||378 M|
*A4 is taken as 11 x 8 inches. For A5 divide these figures by 2. For A3 multiply them by 2
Don't be deterred by the appearance of the scanned image on your monitor screen. What looks hideous on the screen may nevertheless print out perfectly. Sadly the reverse is also true! Video digitisers
A video digitiser is a card (podule) that plugs into the backplane of the computer. It includes a socket by which it can be connected to a source of video such as a camera, video cassette recorder or video disc system. As with the scanner, software is needed to drive the digitiser. Effectively it takes a 'snapshot' of the video image on its input and converts this to sprite format, most often in mode 15.
You may wonder how a mode offering just 256 rows of pixels (lines) can reproduce a video picture which in Europe is supposed to have 625 lines. The answer is that the 625-line TV picture is like a mythological beast-everyone has heard of it, but it does not really exist. There are 625 lines belonging to each frame, but in order to reduce the flicker on a TV screen a system known as interlacing is used. This takes the odd numbered lines and displays them and then, in the next frame, displays the even numbered lines. So the maximum number of lines on a TV screen at any given moment is in fact only 312. But even that is a highly optimistic figure, since not all of these lines are visible. Many at the top of the picture are dedicated to special purposes such as the carrying of teletext and other data.
Sometimes, on an incorrectly adjusted TV receiver, you can see the teletext data as a series of ever-changing dots on several lines at the top of the screen. In fact the number of visible lines on a TV picture is around 270, which is not far removed from the 256 rows of pixels in a mode 15 screen. The loss of the remaining few lines is not generally noticeable.
Video digitisers are available at a wide range of prices and with a matching range of facilities. If you wish to digitise standard-format TV' or video pictures, you should check before purchasing any particular digitiser that it does capture the full width of the picture. Some digitisers produce mode 15 sprites of size 512 x 256 pixels which are of course square; these digitisers omit an appreciable area from one edge of the source picture.
The facilities offered vary widely. The Pineapple Video Digitiser offers some sophisticated hardware facilities including a real-time display of the source and a comprehensive range of support software which allows many image processing options. The digitiser has hardware controls for hue, saturation and value and, although a little practice is needed to set these for optimum results, they do provide a means of compensating for scenes that are dull or lacking in contrast. Each image is initially stored in 256 Kbytes of RAM on the digitiser Board. This allows rather more than mode 15's 8 bits per pixel. Captured images can be stored on disc in this higher resolution format and then processed as necessary to give the most satisfactory sprite.
The sprites obtained from video digitisers are likely to be somewhat grainy since the 256 colours offered in mode 15 are a poor substitute for the millions of shades available in analogue video; some digitisers use dither patterns to render shades not available in the palette. Consequently digitised video may be unsuitable for such purposes as conversion to vector graphics using tracing. But you may find that image processing makes them more suitable. Video digitising also teaches some salutary lessons about the importance of the fourth dimension, time, in human perception. It sometimes happens that the scene that interested you is not really there; it was an illusion. What caught your attention was the juxtaposition of details in several successive frames, but which were never all present at once so that no one frame can 'tell the whole story'. On the other hand, you will sometimes find fascinating details on individual frames that pass unnoticed when the video is run at normal speed. If you have a video cassette recorder with a good freeze-frame facility, stepping frame by frame through sequences can he an enlightening-and sometimes a disillusioning!-experience.
Screens and parts of screens, as we have seen, are sprites. For the Acorn 32-bit machines there are a number of public domain/shareware utilities that allow screens to be 'grabbed' out of applications. Many of these take the form of a 'module'. When loaded into the computer's module area these interrupt the processor at regular intervals and test for the presence of a certain combination of keypresses. When the combination is detected, the current screen is saved as a sprite file in the currently selected directory. You can subsequently load this file into Paint or other software for editing or processing. For example, Figure 1.9 was culled from Fourth Dimension's flight simulator game Chocks Away Special Missions using just such a module.
Obviously you must ensure that the currently selected directory is on a disc that has sufficient room for the sprite file. One problem is that some applications reset the current directory. For example, you may set the current directory to be the root directory on your hard disc where you have megabytes to spare, but the games application out of which you wish to save that scintillating screen resets the current directory to floppy drive 0 from which the game is run on a protected floppy disc that is filled to me last byte! Also some applications in order to run faster disable interrupts so that this kind of screen grabbing module cannot be used.
You may wish to import screens from some other type of computer. This is perfectly feasible, but you will need an application such as ChangeFSI (described in the next chapter) to convert the 'alien' screen format to Acorn sprite format. You will also need a screen grabbing utility to save the screens on the source computer. For example, I once used my Archimedes to prepare a user manual for a suite of IBM PC applications software. There is a utility called Pzazz for IBM PC-compatible machines that works in a similar way to the ARM modules described, but with rather greater sophistication. It multi-tasks with the application software and on detecting the necessary keypress it interrupts the application and displays its own menu offering a choice of image formats and destinations for the saved graphics. When you have made your selection, the application screen is restored and saved and the original application is resumed.
I used Pzazz to store screens in TIFF (Tag Image File Format) on 720K MS DOS discs. These were then loaded into the Archimedes A440 running PCDir, ChangeFSI and Ovation simultaneously, Each TIFF file in turn was dragged out of the PCDir directory viewer on to the ChangeFSI icon where in a few minutes the original PC screen appeared in an Acorn window with an option to save it as an Acorn sprite and as such it was imported into Ovation. Although I had not used Pzazz or ChangeFSI before, everything worked perfectly at the first attempt.
Clip art consists of collections of ready-made graphics, often following a particular theme such as animals, plants, transport, music or sports, which are sold by software suppliers primarily for the purpose of decorating magazines, newsletters and other documents prepared on the user's computer system. Some clip art is in sprite format, but increasingly clip art for the ARM machines consists of vector graphics (Draw path objects) because this is easier to scale and in general more graphics can be fitted on to a disc.
Although intended for use in documents, clip art could be put to other use such as in animations or games programs. But if these were distributed to third parties, you might be infringing copyright, see below.
This chapter has described the copying of documentary material using scanners and of video material using video digitisers. Either form of copying could in some circumstances be illegal and, if you use either, you should first ascertain that you are not infringing copyright law.
The general principle of that law is as follows. You are allowed to copy up to 10 per cent of a document for your own personal use and presumably this implicit permission extends to electronic copies made using scanners and stored on floppy or hard disc for your own personal use. Technically it is illegal to record a TV broadcast even for your own personal use, although I have never heard of anyone being prosecuted for such personal use. Your copying of individual frames from TV broadcasts, either live or recorded, even for your own personal use, is therefore also illegal. If you distribute copies of copyright material on floppy disc or as hard-copy printouts, you are breaking copyright law unless you have obtained the consent of the copyright owner. The situation regarding the copying of screens from software is a little uncertain, but you should certainly not distribute such copies to third parties without the prior consent of the copyright owner.
Clip art falls into a slightly different category. It is art sold in the form of software for the express purpose of embellishing the purchaser's publications. Your purchase of clip art software necessarily includes permission to reproduce it ad lib on paper in documents that you create using your computer system. But you cannot copy the software itself without the permission of the copyright owner.