Graphics on the ARM
Another RISCWorld exclusive serialisation.
Tracing - Pixel to Vector Graphics
One of the disadvantages of pixel graphics is that they cannot be scaled easily. If you increase a sprite's size (by, say, doubling the number of pixels on each axis), each pixel in the original is represented by a block of four pixels in the enlarged version. So the pixel structure becomes more obvious in the jagged edges of oblique lines and curves. And if you reduce its size, detail is lost as pixels are merged (Figure 12.1). Vector graphics, in contrast, can be magnified or reduced indefinitely without incurring any such penalties. Consequently, a means of converting sprites to vector graphics offers distinct attractions. Applications that do this are called tracing packages.
Figure 12.1 - The high-resolution version of the RISC OS 3 Apps icon at (a) natural size, (b) magnified by 2, (c) magnified by 4, to show how the pixel structure becomes increasingly obvious, and (d) reduced to half size and then remagnified to show the loss of detail
Tracing programs use one of the image processing operations considered earlier, edge detection, to find the edge of each coloured area in the sprite in turn. Having identified the edge, they then create a Draw-style closed path to Fit the outline.
There are, of course, limitations to the process. Tracing programs always work in terms of filled shapes bounded by thin lines, so a line of uniform thickness in the sprite will nevertheless be translated into a shape, even though it would have been more logical and economical to represent it by a single line.
Some tracing programs attempt to reproduce the colours of the original sprite; others do not, leaving you with the tedious task of selecting objects and changing their path styles one by one if colour is important to you. Although you can easily scale the resulting Draw image, you may find that other editing tasks are even more complex than they would have been on the original sprite. A sprite is two-dimensional; what you see is all there is. A Draw file, in contrast, can contain one interesting detail on top of another, so that some objects are hidden behind others, the data stack itself providing a kind of rudimentary third dimension. Although a sprite contains no depth information whatever, tracing programs generally assume that any coloured area that is completely surrounded by another coloured area is in front of it. So if there is one coloured area in the sprite that surrounds everything else-the background colour in many sprites being the most obvious example-that will become the first (rearmost) object in the Draw file. In general this supposition does sort the objects into quite a sensible order.
Not all sprites are suitable for conversion. Those that contain a multiplicity of isolated pixels, for example in dither patterns, will not produce satisfactory Draw files. This, sadly, rules out the creation of Draw files from most images obtained from video digitisers, unless you have the patience to subject the image to a great deal of softening and loss of detail first. Indeed, the sprites that give the most satisfactory conversions are those that most resemble vector graphics in the first place, in that they have large expanses of uniform colour.
Before you purchase a tracing package, it is worthwhile to stop and consider carefully the task you wish it to perform. If the sprite you wish to trace is fairly simple, it could be that your best bet is to import it into a drawing package and draw around it by hand.
There are several tracing packages for the ARM machines, These include Midnight Graphics' Tracer and Iota's Outliner. Probably the best known is David Filling's Trace which is modestly priced and, unlike some of its competitors, produces full-colour drawings.
David Filling's Trace is supplied on the same disc as D2Font which converts Draw files to Acorn format outline fonts (described in Chapter 3). This immediately suggests one interesting application for a tracing program: to convert scanned images of a typeface to Draw files which D2Font can then process into an outline font. In practice the resulting fonts usually require some further attention to make them usable.
Trace is absolute simplicity to use. Clicking on the icon opens two standard RISC OS windows labelled Sprite and Draw (Figure 12.2). If you have not used the application since you installed it, the two windows will of course be empty. You drag the sprite you wish to convert into the Sprite window, click Menu, select Choices, adjust the error setting or accept the value offered (more on this later) and click on Trace to start the operation. The time taken depends on the complexity of the sprite. On an A5000 three or four scanned characters take just a few seconds. It is fascinating to watch the Draw file appearing in the Draw window.
Figure 12.2 - The two windows in Trace when it has finished a tracing operation. That the two graphics look almost identical is a tribute to its abilities. Now for an abstruse philosophical question: Does a roundal consist of a hollow white ring surrounding a small black dot or is it a small black dot over a much larger white dot over an even larger black dot? For the answer see the next Figure.
Each window has an identical menu. Options allow you to save either the original sprite or the Draw file produced from it, to initiate tracing, to zoom in and out (zoom ranges from 999:1 to 1:999 and is applied simultaneously to both windows), to choose the error setting and save your choice and to show vital information about both sprite and Draw file.
Figure 12.3 - The Draw file from Figure 12.2 disassembled to show its structure; a pale grey background has been added. It clearly reveals the answer to the abstruse philosophical question posed by the previous Figure: neither, it's a small black dot on a larger white dot on a larger black dot on an even larger white rectangle!
The error setting in Trace determines the accuracy with which the resultant drawing reproduces the edges of complex coloured areas in the sprite being traced. If you argue that it should reproduce them exactly, you are in trouble. For if il did that, it would then reproduce the outlines of the individual pixels of which the sprite's design was composed. And if you subsequently scaled the drawing upwards, the jagged edges would become every bit as obvious as they would if you had magnified the sprite itself. It was largely to eliminate this very effect that tracing packages were developed! So, ironically, to gain any real benefit from the tracing process, a degree of error must be built into it, the paths created must follow an average edge rather than the exact edge. It is worth experimenting with different error settings. The default setting of 0.80 pixel gives excellent results with many sprites, but you may find with certain types of sprite a different setting is preferable. Also, if you are converting characters that you intend to incorporate into an outline font using D2Font or an equivalent application, it helps to make the sprites as big as possible. The larger they are, the more accurate will be the renderings from Trace and the less work you will have to put into subsequent tidying by hand.