Before any discussion of the system which was chosen for analysis and data collection in this project, it is worthwhile looking at the overall pattern of events which were envisaged when the application for research funds was made. Figure 3.1, below, shows the proposed plan in diagrammatic form.
Figure 3.1: Proposed flow pattern for the analysis process
No computer analysis on this scale had been attempted before within this field. It was clear that no commercial hardware and software combination (certainly within a realistic price range) would be able to provide an integrated solution here, particularly given the very specific requirements of the NAC high-speed film analysis. For this reason, it was decided to develop all the required software in-house, with as much of the analysis as possible included in a single package.
An Acorn Archimedes (model 440/1) was chosen as the main project computer for the following reasons:
The original (planned) hardware list had included a Hawk V12 Image Processing System, basically consisting of an 8-bit grey scale video digitiser and support software for the Archimedes. It soon became clear that this system, although 'ready' according to the manufacturers, Wild Vision Ltd., would not in fact be available within the required time scale. For this reason, an alternative was chosen - this was the Archimedes Real-Time Video Digitiser, manufactured by Watford Electronics. This expansion card, with similar general specifications to the originally planned Hawk V12, offers 6-bit grey scale video 'grabs' (giving 64 possible levels of intensity) and an image resolution of 512 by 256 pixels. This image size is ideal for the planned system, giving reasonably sized image files and sufficient resolution on screen. It should be noted, however, that the 512 by 256 image size corresponds to a picture which should have an aspect ratio of 5:4 (rather than 2:1), and some simple scaling is required to display an un-distorted image on screen. This is discussed in detail in section 3.4.2, which deals with the screen display routines.
The Hawk V12 monochrome digitiser, which was originally planned to be part of this system, was accompanied by an extensive library of 'C' utilities and functions which could have been included in or accessed by our own software. Although not appreciated at the time, it has become clear that this software, as a result of being written in 'C', would have been far too slow for our purposes. It was, in a sense, fortunate that this package was unavailable at the start of the research period. The Watford 6-bit digitiser which was used, although not supplied with any programs of direct use, came with a considerable amount of supporting software including numerous short Basic programs. These programs illustrated the ease with which digitised images could be manipulated using simple Basic and assembly language programs. Since all the project software was to be written from scratch, there was no requirement for compatibility as there would have been if we had needed to interface to the 'C' library supplied with the Hawk V12 card. BBC Basic V (hereafter referred to simply as 'Basic'), which is built into all Archimedes computers, was therefore chosen as the main programming language for this project. Speed-critical sections of code were written in assembly language, and contained within the Basic shell.
A window-based software package is supplied with the Watford digitiser which allows single fields to be grabbed one at a time from a video source, manipulated in various ways and saved to disc. This was unsuitable for our purposes, for two reasons. Firstly, we needed to digitise a large number (>500) of separate images; a process which would have taken far too long using this system. Secondly, it was important for us to be able to 'grab' precise frames from the video sequence - a facility not offered by the software supplied with the card.
In order to test the various required techniques for image grabbing and display, several fairly short programs were written 'in-house' and developed up to a point where they could be easily and reliably integrated into a larger package. These programs are described in the following sections.
One slight inconvenience with the Acorn Archimedes is that the colour palette is fixed and contains only 16 levels of grey. The Watford card, capable of creating files with 64 intensity levels (from 6-bit accuracy, 26 = 64), is supplied with an example program which uses look-up table to map grey intensity levels onto colours in the default palette. These colours, when viewed on a monochrome monitor, yield a far better grey-scale display, and could easily be incorporated into a screen redraw code as a look-up table, referenced once for each pixel.
Using this idea I wrote a simple program to experiment with various colour combinations. With this program, 'Greys-1', running in conjunction with an oscilloscope connected to the monochrome video output of the Archimedes, it was possible to choose colours which produce a linear grey scale. The oscilloscope gave an unbiased view of the linearity of the grey scale - something which was very difficult to get using a video monitor. The linear 'screen' grey scale which was obtained using this technique became the default look-up table. A slightly more advanced version of the program, called simply 'Greys-2' was also developed in house, in order to load, edit and save previously created tables.
Figure 3.2 : A 64-level grey scale - the colours were picked using program 'Greys-2'
To display images on the computer screen, pixel intensity values are passed through a look-up table to translate from image intensity to screen 'colour' before the required bytes are written directly to the screen RAM area. A bonus of this technique (of using colours to give levels of grey) is that the images can be laser printed without modification and themselves showed a good grey scale. This is illustrated by Fig. 3.2, which has of course been laser printed.
A full listing of program 'Greys-2', (which essentially contains 'Greys-1') is included as Appendix 2.1.
Following the successful development of the 'Greys' programs, it was necessary to test a few other basic elements of code, including those for image compression, decompression and display, as well as carry out some speed tests on the code. It was hoped that this stage would also highlight any bugs or bad features in the software core, if present.
The program written and developed by myself for this task was called 'WD-Misc1' (for Watford Digitiser, Miscellaneous 1). This program represents a critical point in the development of the final software package, since it demonstrates all the required main functions - namely:
Although the digitised images produced by the Watford card have dimensions of 512 by 256 pixels, they represent an original image which had an aspect ratio of 5:4, corresponding to 640 by 512. This is precisely the dimensions of the screen in Mode 15 (where pixels are two 'address units' high) under RISC OS, and the display is re-sized by duplicating every fourth horizontal pixel on the screen. Although more complex stretching techniques were considered, this was found to be a perfectly adequate method and does not slow the code down too much, in spite of the fact that the useful 32-bit word-alignment is lost in the move from 4-byte (32-bit) to 5-byte (40-bit) looping.
Display of the digitised NAC images is one of the most central and commonly used functions in the software developed for this project. Code supplied with the Watford card is very slow, taking approximately 0.9s to display an image (the image is stored uncompressed in the Watford RAM area - decompression, carried out when the image is loaded into the Watford card, adds another 0.3s). It was assumed from the start that custom display code would be needed for this, and the development of the routine became something of a mini-project running throughout the research period. The technique which has been used involves writing byte values directly to the area of the Archimedes RAM which constitutes the screen - the position of this area is not constant but can be found easily using a firmware call each time the program is run. By writing directly to the screen memory, the display speed is absolutely maximised and does not suffer from any of the delays inherent in other higher-level drawing or rendering techniques. The display routines have been optimised very much further since early versions, including full 32-bit word manipulation and the use of 10 registers on the ARM chip. The time taken to draw a complete image onto the screen, including look-up table addressing, was reduced to 0.37s by the end of the first year, at which point the main processor of the Archimedes was upgraded from an ARM2 to a 'Cached ARM3' with a corresponding speed increase of approximately 5 (depending upon load). The animated display rate on the Archimedes 440/1 is now limited by hard disc access and data transfer rate, which is difficult to improve.
Within the final year, the maximum animated display rate has been further increased by the use of my own A5000 computer, with its faster IDE hard disc, faster RAM (running at 12 MHz instead of 8MHz), and ColourBurst graphics card. The ColourBurst card, made by State Machine Ltd., implements a full 24-bit palette (giving, if required, 256 greys) and removes the need for a look-up table, as well as reducing the load on the main processor by managing the display. Screen redraw takes less than 1 vertical sync period (vsync, i.e. 1/50 sec) using this system - the display time per image is therefore entirely dependent upon the speed at which the images are loaded from the hard disc or CD-ROM (see Section 3.6.10).
The original program, 'WD-Misc1', soon evolved into 'WD-Misc2' with a host of new features, the most significant of which was automatic timing of program functions. The time taken by each function has been included in the comments at the relevant point in the program listing. A screen dump from this second program, showing the title screen and options, is shown in Fig. 3.3.
Figure 3.3 : Title and options screen from WD-Misc2. Note that the initial letters of each of the options (e.g. Archimedes, Watford, Load, Save, Compression, ...), used to make a selection, are normally displayed in bright red!
It was necessary to apply some data compression to the digitised images in order to reduce the file size, thus speeding up the loading process and saving hard disc space. The image compression technique which was adopted is identical to that already used by the Watford digitiser, being a modified implementation of run-length coding which takes advantage of the two spare bits in each byte. The simple decompression process, most important in this project, is explained in Fig. 3.4 below.
Figure 3.4 : Guidelines for decompression of 'Watford-compressed' image files.
The first byte of a compressed file must have bits 6 and 7 clear, in order to define the intensity of the first pixel, but all other pixels could be described relative to this with a considerable resulting compression ratio. This decompression algorithm can be easily implemented in ARM assembler, with the complete code requiring only 18 instructions in the listing of HV-1 (see Appendix 3). Although the Watford ROMs provide a command to decompress image files, the custom routine is included (i) to make software 'stand-alone', i.e. not requiring the Watford card to be installed, and (ii) because this custom code has the advantage of being faster by a factor of 10.
In use with real images from the 1989 experiments, the Watford compression technique gave a compression ratio of approximately 2:1 on average. Some comparison was made to other compression techniques including the widely used Lempel-Ziv-Welch (LZW) type, used for example in the GIF and compressed TIFF image file formats. This particular method gave an improved compression (of the order of 3:1 to 4:1) but was too slow a process. The conclusions reached were that (a) the Watford compression technique is well suited to the type of images used here, and (b) an implementation of any more complex routine would be too slow in operation, as well as requiring more development and debugging time. At the end of this development process, the time required to decompress an image was roughly half that required to load the compressed data from the hard disc of the computer, the two steps together requiring approximately 0.3s (± 50%, depending upon image content).
Having transcribed the NAC film to VHS video tape, the next problem was that of digitising precise video fields from the available sequences. Although this is, in principle, easy using the pause/still facility found on most video recorders, it was clear after a few tests that the Watford digitiser could not reliably grab images from a still video source (which often jitters badly, compared to a smoothly playing video signal).
Using a piece of equipment specially built at Sussex by Dr. P.N.Smith, we were able to 'mark' the audio track of the video tape with a very short sound burst of a precise frequency, and this could then be used as a reference point for digitisation of the video records. The same piece of equipment could then be used to give a 'logical' (0-5V) signal which indicated the audio mark. When monitored in conjunction with another output of this special audio marker/trigger tool, it was possible both to start a counter consistently and to count frames of video after a certain point. The interfacing was carried out using an Acorn AKA10 I/O card, which is a double-width expansion card based around the Rockwell R6522 Versatile Interface Adapter (VIA) chip.
Although it was necessary to program the VIA chip at register level, this was not a problem (see Appendix 2.3 for details and embedded program comments). A number of the very short Basic programs which I had written, separately testing such things as the I/O card clock and counter, were merged into the 'RunImage' file of a RISC OS application called MultiGrab (see Appendix 1 for notes on the Acorn RISC OS conventions such as 'RunImage' files). This multi-featured program, the first which has a genuine use within the hypervelocity studies project, operates as follows:
Step 1: Temporarily exits the RISC OS desktop, claiming as much memory as possible.
Step 2: Reports on screen the maximum number of digitised images which can be held.
Step 3: Asks for various user choices of the number of fields to grab, the initial gap and subsequent spacing between fields, and the file name tag (see below) to be used when saving the images.
Step 4: Prompts for a key press, by which the user indicates that the video tape has been set running in the right place.
Step 5: 'Watches' the digital input lines until an audio mark is flagged.
Step 6: Counts fields according to the user options.
Step 7: Grabs the required number of fields.
Step 8: Displays fields sequentially, with an option to save the images to disc.
Figure 3.5 shows the opening screen and options, described in steps 1 to 7 above. Step 8 is illustrated in Figure 3.6, which shows a single frame from the display of grabbed images. Note that the image used in Figure 3.6 contains only 16 levels of grey and was drawn using the *ShowPic command, which is part of the Watford Digitiser software.
Figure 3.5: Initial screen and options from the 'MultiGrab' application.
An indexing system was adopted which allowed the images to be 'marked' according to the shot number and unique time for each digitised field of video. The video timer had marked each field with a time stamp of the format minute:second:centisecond (e.g. 03:13:00, visible in Fig. 3.6, indicating 3 minutes 13.00 seconds). The last four digits of this time label were used to 'tag' each image, preceded by a two-digit code for the shot number (S1 for shot 1, S2 for shot 2, etc.) and an underscore to act as a separator. Thus the image shown in Fig. 3.6 is labelled S3_1300 since it is a frame from shot 3 and shows a time mark of 03:13:00. The 'MultiGrab' program was able, once one image had been labelled (i.e. giving a reference point), to step forward or backward and suggest filenames which fitted this model. Since the spacing between consecutive fields is known to be 2 cs there was no need to write any software for identification of the numerical time marker.
Figure 3.6: An example screen shot from the view stage of 'MultiGrab'
In order to avoid the problems of over-filling directories (Acorn RISC OS supports only 77 files per directory) each shot was sub-divided between a number of directories, with each directory covering a range of 100 units in the filename notation and thereby holding a maximum of 25 digitised fields (since the time step is 4 centiseconds per frame at 25 frames per second).
A full annotated listing of the 'MultiGrab' version 1.00 program, including assembly language segments, is given in Appendix 2.1. It is important to note that this program does not use any customised display code (since display speed is not critical during this period), but instead uses the very slow display routines supplied as part of the Watford digitiser ROM.
As soon as a useful number of images had been digitised from one shot, work began on longer term software development, specifically more detailed testing of those assembly language routines for image compression, decompression and display, which had been written to form the central core of an integrated program. To this end, a program called HV-1 (for 'HyperVelocity 1') was written as a test bed for these routines. This program, which provided the first means of sequentially displaying digitised images from the NAC film sequences (and in that respect alone was an important step for the Sussex group), was designed for only simple image manipulation with no facility for measurement, but provided a valuable insight into the potential capabilities of the system. Important stages in the evolution of this program were:
Due to practical constraints, it was not possible to store all digitised images from all shots together on the hard disc, and the selection which would need to be loaded onto the hard disc (from floppy disc backups) at any given time depends upon the type of study being carried out. It was therefore necessary for the software to keep a record of which images were available - this could have been done either by maintaining some kind of data file (which would hold a list of the names and positions of all available files) or by examining the hard disc, looking for image files, each time the program was run. For simplicity I chose to use the latter technique, and the code for this was developed and tested within HV-1 (See PROCexamine_disc in Appendix 3).
This piece of software was a vital stepping stone, allowing us to experiment with different techniques and get a feeling for the analysis process, including any problems which might have arisen at this stage. As it happens, only a few minor problems were encountered and this program expanded rapidly to fill its intended role as a final test before the development of the main programs HV-2, for 2-D analysis, and HV-3, for 3-D analysis. (These programs are described later).
The basic HV-1 program does the following:
Although part of the program, the cursor which appears on screen when HV-1 is run has no effect and does not allow any screen features to be measured - this was included purely to test visibility and experiment with the user-definable pointer within RISC OS. The program, which contains plenty of comments, is listed in full in Appendix 3. As with all other code written for this project, highly symbolic and self-explanatory procedure and function names have been used wherever possible. The HV-1 program was the final feasibility test before development of the full analysis program.
As described in section 3.1, this program was intended from the start to be an integrated package, capable of data collection and analysis. It was also important that the code could be developed flexibly as work progressed and as more information was collected about the experiments - we had no clear idea of what would be the best techniques for, say, rotation measurement, fragment tracking and so on. The result of this development, essentially carried out continuously until mid-1992, was a 3600 line program of mixed Basic and Assembler, capable of everything which had been envisaged and much more besides. The unexpectedly large amount of data collected during this period of development (and subsequent use) of the program has highlighted the value of such a careful and open-ended approach.
The HV-2 program, which has been used for all analysis of the 1989 single-camera experiments, essentially began as a tidied up version of HV-1 (see section 3.5), but in the light of expected developments was re-named to HV-2 (for HyperVelocity 2) and placed within an application shell, allowing it to be run easily from the 'desktop' on any Risc OS machine. This became most significant when, in 1992, two 2nd year MAPS project students used the program successfully to study the digitised NAC film from shot 1 and carried out a limited study of the fragment velocity field from this shot.
In the following sections I will discuss the development of each aspect of HV-2 and the techniques used to collect various data. In order to avoid including program code, I shall make reference to procedure (PROC) names which have been included in the program listing and mini-index (Appendix 4). In order that this thesis can serve as a 'users manual' for the software developed during the project, I will cover all main features of the system with some explanation and illustration of each, including the required key-presses. With reference to the last point, it should be noted that while the state of the <ctrl> and <shift> keys is significant, the case of any alphabetical characters is not. I have intentionally used one or other case where it helps clarify the usage in this chapter, for instance when setting the axis sizes of a fragment it makes more sense to use 'a', 'b', 'c' rather than 'A', 'B', 'C'.
The vast majority of data used in our published papers and presented here have been collected using version 2.1 of HV-2, and all discussions in the following sections apply to this version. More recently I have increased the version number to 2.2 and updated the program to allow use of the better hardware which I have fitted (at my own expense) to my A5000 computer. Since these enhanced features are not available when using the software with the Archimedes 440/1, I document these only in the final section of this chapter. No features have been lost from v2.1 to v2.2 - the latter is entirely backward compatible.
There are a number of choices which must be made each time the program is run, as shown in Fig. 3.7. Note that the square brackets indicate the 'default' response, i.e. the response which will be assumed when the ¿Return key is pressed with no other input.
Figure 3.7: Initial options screen from version 2.1 of the HV-2 program. Note that the 'default' options have been selected in all cases here by just pressing ¿Return at each prompt.
Although the software can be used on any RISC OS system, there is not usually any way of detecting, for instance, which type of monitor is connected to the computer. The dedicated Archimedes 440/1 is usually connected to both a colour and monochrome monitor - when using only a colour monitor, it is of no use to load a colour-to-grey table (see section 3.4.1) for image display since the colours themselves will be visible. In this case, the screen display uses just the 16 grey shades available in the default palette. Due to a shortage of equipment the two project students were not always able to use the two monitors. Similarly, this meant that they were also often working on a machine with no hard disc. For this reason, it was necessary to enable the program to load and display images from either the hard disc of the 440/1 or floppy discs. Although no problem in principle, it is somewhat slower using floppies than using a hard disc machine; not only because of the slower loading of data but also because floppy discs can only hold 10-12 images on average, and a fair amount of disc swapping is required.
When the 'Mono 64' option is selected, confirming that the software is running on a system with a monochrome monitor attached, it is possible to load one of a number of different look-up tables (LUT's) for the greys-to-colours translation. During the early development of this program, a few different LUT's were created for specific purposes. One which has been retained was based upon the advice of David de Vorchik, of Acorn Ltd. (manufacturers of the Archimedes), who provided the following simple formula:
This defines the grey intensity level (0..255) for an Acorn printer driver, corresponding to the red, green, blue (RGB) combination in a given colour. The fixed palette contains 8-bit colours accessed either by their GCOL number or an internal colour number used by the video chip. This latter, used in direct screen addressing (as in the image display code written for this project), is defined as follows:
Bit Meaning
0 Tint bit 0 (red & blue & green bit 0)
1 Tint bit 1 (red & blue & green bit 1)
2 Red bit 2
3 Blue bit 2
4 Red bit 3 (high)
5 Green bit 2
6 Green bit 3 (high)
7 Blue bit 3 (high)
Using this information, it is straightforward to calculate the grey levels associated with all 256 entries of the default Risc OS palette, and to then sort them to produce a 256-level grey scale (which can be shrunk to 64 levels as required here). This scale is of course optimised for printing rather than screen display, but when screen images (sprites) are to be saved and printed it provides a perfectly acceptable display on a monochrome screen as well.
Once the basic choices have been made in HV-2, the program examines either the hard disc or each floppy disc in turn, building an array of filenames with each one corresponding to a digitised image. Since the image filenames indicate the video time mark (though not the 'true' time associated with an image), this array also constitutes a map of the available raw data in the time domain. During the analysis process it is useful to be able to start work from - or jump to - any NAC frame, and to this end the available images are indicated in a semi-graphical form as shown in Fig. 3.8, below. The square brackets indicate which frame is selected, and the details of that frame appear on the screen below the map.
Figure 3.8: Image map indicating which NAC frames have been found. Note that in this case all images are 'highlighted', and also that the 'Q' option has no effect in this context.
Once a frame has been selected, the corresponding file is loaded and displayed along with a 'status bar' reporting various things. Running from left to right, this line indicates:
Figure 3.9 shows the initial screen from a shot 3 analysis session, with the first image (file S3_1184) loaded.
Figure 3.9: The first digitised image and status bar from a 'Shot 3' analysis. The spherical artificial rock target can be seen at the bottom of the view, against a background of the wall of the travertine quarry (approximately 20 m away) where the 1989 experiments were conducted.
As soon as the initial image appears, all main program options are available. These include several relating to image display, as follows:
left mouse button or '<' - step backward (in time) once
right mouse button or '>' - step forward once
<ctrl>F - forward animation (until any key pressed)
<ctrl>R - reverse animation (until any key pressed)
keys 1..9 - set the number of NAC frames to move each step
K - 'Kill' display (leaves only status bar and markers)
Z - 'Zap' the status bar (i.e. switch it off!)
<ctrl>K - change contrast settings
Looped animation (with full image display) was found to be of very little use due to the limited speed. Far more useful was the option to 'kill' the display - once some idea of the time scale had been acquired it was simple to go forward or backward quickly though the set of available images, re-activating the display once the required point was reached. A nice secondary feature of this was that, since point fragment markers were still visible, animation forward or backward gave a cartoon-like fast display of the disruption. When a significant number of fragments had been identified and tracked for each shot, this became the preferred means of moving quickly through the images.
Some parts of the digitised images, particularly near the impact point, suffer from very poor contrast, making fragments difficult to spot. This can be partially remedied by varying the gamma curve (of screen pixel intensity vs. image intensity), using the <ctrl>K option above. When this is activated, a small square graph similar to Fig. 3.10 appears in the top right of the screen showing the current gamma curve, and this can be modified and saved. The special keys which are active in this mode are outlined below; descriptions refer to figure 3.10:
¬ ® (cursor keys) - decrease/increase 
and 
together
¯ (cursor keys) - decrease/increase 
(i.e. gradient up/down)
keys 1...9 - change form of curve by setting power, 
, to 'n'
<shift> + keys 1...9 - change form of curve by setting power, 
, to '-n'
R - redraw image with current curve
Q - quit, discarding modified gamma curve
<Return> - adopt curve, redraw, and return to normal operation
Figure 3.10: Gamma curve similar to the one displayed in a mini-window when <ctrl>K is pressed. The straight diagonal shows the default (linear) relation, i.e. 
.
Once a gamma curve has been adopted, it is saved in file 'UserSpecs' (in the LUTs directory) and reloaded each time the program is run. This system for contrast adjustment was found to be very easy to understand and to use, and allowed fragments to be tracked by eye further than would otherwise have been possible. The relevant program code for all this is to be found in PROCcontrast (in Appendix 4) and its sub-calls.
Before any measurements can be made of fragment parameters, it is necessary to tell the computer where the fragments are. This process, which I have called tracking, is done essentially 'by hand', pointing to successive positions of a fragment and either pressing 'P' (for Position) or clicking with the middle mouse button. Although we considered using more advanced techniques it was clear that any other system, such as for instance using a neural net to recognise fragment shapes, would change the nature of this project and require far too much development time. By picking up fragments at the end of their visible trajectories it is possible to isolate quickly individual fragments and track them backwards, in some cases all the way to the target sphere.
In order to begin tracking a fragment, it must first be 'identified' - this allows the program to set up storage space for the positions of the fragment (potentially x and y in every frame) as well as the rotation, size and other records required. This facility is accessed by pressing 'I' (for Identify), and can be ended by pressing 'T' (for Tracking off). Although fragments are primarily labelled according to the numerical order in which they are identified, a second index is maintained by the software which allows fragments to be sorted into a different order, e.g. increasing rotational rate.
Initially, the process of tracking fragments was unsatisfactory because (i) every position of a tracked fragment needed to be 'clicked' using the mouse, and (ii) the high density of digitised NAC frames, coupled with fairly slow full-screen displays, led to apparently little displacement even after many steps forward or backward through the sequence. The procedure was soon made faster and more intuitive by the addition of a few program features:
The interpolation is implemented as a simple linear algorithm - this was found to be perfectly adequate since (a) interpolation was only used for fairly short sections of the fragment path, and (b) the majority of fragments travel almost straight for most of their visible trajectory, as can be seen from Fig. 3.11. The figure also illustrates the fact that the fragments tracked entirely by hand (solid lines) exhibit considerable noise in their trajectories, while interpolated tracks (dashed lines) are, not surprisingly, relatively smooth. The fragment trajectory lines can be displayed once by pressing 'L' (for Lines) or activated permanently (and de-activated) with <ctrl>L. To restore the original display (e.g. after displaying the lines once using 'L') the screen can be Redrawn by pressing 'R'.
Figure 3.11: Tracks of 118 fragments from shot 3, 1989. The ball outline has been drawn at the bottom of the image to provide a reference point and scale.
Only the first few fragments were tracked entirely by hand, and this was done in the first stages of the study when all digitised images were stored on the hard disc, hence available for measurement. Given that the 1989 NAC frame rate had been chosen to catch the fastest fragments, it is not surprising that there was generally far more film than required (some fragments hardly moved at all between frames). For this reason, the images were often stepped by 4 or 8 at a time (see Section 4.3 and Sub-section 3.6.2) during the tracking process and of course no fragment position was recorded for the intermediate frames. Initially this had the effect that fragment position markers seemed to 'disappear' where the current image had either been skipped or missing during the tracking process. In this case, interpolation proved to be a fundamental tool, saving a lot of essentially unnecessary work.
Once some fragments have been tracked, it is possible to step forward and backward through the fragment indices (e.g. stepping from fragment 5 to fragment 6, etc.) using the comma and full stop keys - this is not as unintuitive as it sounds, because they have the '<' and '>' symbols on them. (Note that these keys with <shift> pressed step through the NAC images one at a time). Fragments can also be picked for editing or further tracking using the select-by-number feature, invoked by pressing 'F'. The program asks for a fragment index number, and this defaults to the last new fragment.
If a fragment has been tracked and its marker is visible on the screen, it can be selected by placing the mouse pointer over the mark (or, specifically, nearer to this mark than to any others) and pressing 'S'.
In the event that a fragment position has been recorded wrongly, it can be erased by pressing 'E'. This allows fragment tracks to be edited or removed completely.
As well as being required for fragment size and shape measurements, basic distance information (i.e. the length of the path projected onto the plane of view) is central to the calculations of observed fragment velocity and envelope expansion rate. As explained in section 2.8, a pair of digital callipers were used to measure accurately the dimensions of the fragments which had been collected from the ground after the experiments - it seemed sensible to apply a similar technique to the visible fragments in the fast-framing film, albeit with totally digital (i.e. software-based) callipers.
The original plan was to change the mouse pointer to a circle or ellipse of variable size (and shape, in the case of the ellipse) which could be fitted around fragments in individual still images. This soon proved to be too confusing and a simpler system was adopted, using just two parallel straight lines which could be rotated and moved about using the mouse. The spacing between them can be changed using keyboard control and recorded by the program to indicate the relevant measurement. Complete key/mouse controls are:
mouse button 1 - rotate callipers anti-clockwise
mouse button 3 - rotate callipers clockwise
',' (comma) - decrease calliper spacing
'.' (full stop) - increase calliper spacing
mouse button 2 - indicate measured distance in mm (see top left of Fig. 3.6.4(b))
'a', 'b' or 'c' - record distance as a, b or c in the tri-axial ellipsoid model
'S' - set scaling for all other measurements (i.e. define ball diameter)
'Q' - Quit callipers, i.e. return to normal operation
By pressing 'S' the user defines the ball diameter in terms of screen pixels. This is used in conjunction with the entered known value of the ball diameter in mm (see Section 4.4) to calculate the true distance represented by a given number of screen pixels, if assumed to be in the plane containing the ball and perpendicular to the viewing direction. This initial measurement is shown in figure 3.12.
Figure 3.12: Initial calibration, when the callipers are used to record the ball diameter.
Figure 3.13 shows the callipers in use while studying a fragment not far from the original ball position. Also visible is the equivalent spacing, 89 mm, calculated when the middle mouse button was pressed a few moments before the screen image was saved for inclusion here.
Figure 3.13: Close-up of a fragment being measured in flight (same scale as 3.12).
The facility for even slow animation was an advantage; once some idea had been acquired of the size and shape of the fragment in question, it was possible to make consistent measurements even from blurred views. This further improved during fragment spin analysis (described in Section 3.6.6) when fragments could be viewed at a much faster frame rate than normal. For this reason, the callipers are also available during the spin analysis, although restricted to the small window only.
Two means of directly studying the velocity of tracked fragments are provided within 'HV-2'. The first uses a series of reference marks called Time Separated Markers, or TSM's. The second applies to the numerically calculated value of the observed velocity, where the observed velocity is specifically the velocity component in the plane containing the ball and perpendicular to the direction of view.
The TSM's (invoked by pressing <ctrl>T) are markers, drawn over the fragment trajectory and spaced at (initially) 10ms time intervals as calculated by the interpolation code. They are further apart in space for fast fragments, and this gives a useful means of examining qualitatively the velocity field. It is also possible to display these markers for all fragments simultaneously - this yields an interesting but complicated plot, which becomes more complicated as more fragments are added. The most valuable use of this facility is as a 'quick-look' means of studying the velocity of a single fragment. The spacing in time of the TSM's is one of the program variables which can be changed in the Variable Table (explained in later Section 3.6.9).
Figure 3.14 shows a full-screen plot of all fragment trajectory lines and TSMs (spaced at 10ms) from shot 1. Although this is at first glance overcrowded and confusing, following a single trajectory allows one to study a fragment's velocity relative to that of its neighbours.
Figure 3.14: Example plot showing time-spaced markers (TSMs) from shot 1
Given the known timing of the NAC film sequences (Section 2.6) and the pixel-based size measurements (Section 3.6.4) it is straightforward to calculate the observed velocity of fragments in the field of view. Once fragments have been tracked, their observed velocity can be calculated automatically, and the errors reduced if the fragment has been tracked for a significant length of time. In principle, the longer a fragment is observed the smaller will be the error in the calculated observed velocity, but although some fragments are visible for as long as 100 ms, the (unknown) vertical component of their true velocity changes by approximately 1 m s-1 during this time and would therefore have led to a complicated problem of error estimation. Following fragments for more than a few tens of milliseconds would also have introduced further errors, since the distance of the fragments from the camera is not known and varies with time. The 'observed velocity' of each fragment is therefore calculated over the first 10 ms of tracked flight, where possible, or over the entire track if a fragment was not visible for this length of time.
As explained in Section 3.6.2, it was difficult during the early stages of this project to build a mental image of a particular fragment - a vital step in the process of rotation rate and rotation sense measurement. This was because of the slow full-screen frame rate, of less than 3 frames per second. The solution to this problem was to slowly load all required frames from disc, keeping them in RAM before displaying a fast animation. Even though this was a significant step forward, two major problems still remained:
These problems were solved satisfactorily as follows:
Pressing <ctrl>S invokes the spin analysis mode - the initial stages of this are automatic as the computer loads all relevant images and 'cuts' a small piece from each. The size of the grabbed mini-pictures is 129 by 65 pixels - since the pixels are twice as tall as wide this gives a square image, approximately a quarter screen high and wide. An odd number of pixels were used in both directions in order to have a precise central pixel. The small image is 'grabbed' from the screen as a Risc OS sprite (i.e. after the image has been passed through the look-up table, adjusted according to the current gamma curve) and once a library of images has been collected these can easily be animated at up to 50 frames per second. This provides a superb system for fragment rotation analysis.
Figure 3.15 shows selected frames from a sequence of these small pictures, for a representative fragment. Also visible in these images are the four lines which are added during the track 'grabbing' stage of the spin analysis - these lines form a cross-hair which helps to pinpoint the fragment in question without obscuring the view. By including these lines as part of each small picture the animation runs faster than if they are redrawn each frame.
Figure 3.15: Every 2nd frame from the spin analysis (option <ctrl>S) of fragment 6, shot 4. Frame numbers run from 20 to 78, and real time runs from 26ms to 106ms. Note the fragment reaching the edge of the view in the last images.
This system of small animated frames proved so useful, in terms of helping us visualise the fragment shapes and dynamics, that several extra features have been added. These include a facility to activate the 'callipers' (described in Section 3.6.4) and a 'lightcurve' feature, described in the following section.
An example of the screen which appears after the sequence of small images has been grabbed is shown in Fig. 3.16. The current image is shown in the central window, and this display can be animated using the '<' and '>' keys to move backward and forward through the film sequence. It was useful to be able to change the speed of this animation, and to this end the numeric keys '1' to '9' allow the user to set the time between frames, in multiples of 2 cs (giving a range of 
to 
s per frame).
By setting a time mark at a suitable point in the film sequence it is possible to specify the rotational period (or half period) of the fragment. The time mark can be moved by pressing 'T', at which point it is set to the current image and time, and the central image is copied into the right-hand window. In the example of Fig. 3.16, the fragment has undergone a full rotation between the time mark and current images.
Above the centre, the current frame number and timing are shown along with the fragment number and rotational period, if it has been measured. Also shown is the time between the current image, and the time mark image. The rotational period of a fragment is measured and recorded by pressing either 'F', for a Full rotation, or 'H' signifying a Half rotation. The sense (either clockwise, positive, or anti-clockwise, negative) is then recorded using the square brackets as indicated below the three images.
Figure 3.16: The 'spin analysis' screen which (eventually) appears after <ctrl>S is pressed.
The left-hand window shows a simple low-resolution plot of the lightcurve for the current fragment, with horizontal lines indicating the upper and lower limits and vertical lines indicating the current image time and reference. This lightcurve feature is described in the following section.
In photometric studies carried out using optical telescopes, lightcurves represent the intensity of reflected light as a function of time from an asteroid under investigation. Since this measurement is made upon what is essentially a point source, the observed intensity is integrated over the entire surface of the body. Nevertheless, a wealth of information can be extracted from these lightcurves - primarily concerning the rotational period, pole orientation, some surface properties, and an estimate of the shape of the asteroid. The analysis of lightcurves is an important topic; detailed discussions can be found in (e.g.) Harris and Lupishko, 1989, and Magnusson et al., 1989.
After some initial trials, it was found that a somewhat non-standard lightcurve could be useful in HV-2 for analysis of the spin rates of some fragments. Our technique differs from conventional lightcurve studies in two key ways:
(i) Our fragments are not point sources;
(ii) There is a visible background adding noise to any intensity measurements;
A further difference is that this is not the primary method of measurement - the vast majority of rotation rates can be measured directly from the NAC film, so lightcurve measurements would only be vital to the study of a few fragments in each shot. The significance of the last point is that, as a result of the limited use, lightcurve studies were not fully pursued in this project. Only a simple plot is generated by the program and no Fourier analysis is applied. On the other hand, being able to track the fragments by eye, at the same time replaying the observations as many times as required, has been a distinct advantage, and has resulted in a number of useful measurements upon otherwise 'un-measurable' fragments.
In order to address point (i) above I adopted an approach using a fixed array of screen pixels (9 ´ 5 data points) centred upon the recorded position of the centre of the fragment. These pixels, which cover a small area relative to most fragment images, are assumed to be usually contained within the fragment on the computer screen - this also solves the problem of point (ii) above by excluding any background intensity from the data (i.e. the light from the background, visible around the fragment, rather than the ambient light levels). The intensity levels recorded for these pixels are summed according to a weighting pattern held in a string array by the program and this result is expressed as a percentage of their maximum possible sum. Various weighting arrays were used, and the eventual set of pixel weights were chosen by comparing lightcurve plots to rotation rate data on fragments which could also be measured directly without ambiguity. Figure 3.17 shows an enlargement of a frame from the film strip of Fig. 3.15, with the lightcurve pixel array highlighted.
Figure 3.17: The pattern of pixels used to determine a fragment 'lightcurve'. The right hand image is the centre of frame 60 from Fig. 3.15. Note the pixel weights used, as shown on the left, which are held within the program as 5 string variables, light$(0) to light$(4). The empty boxes (in the pixel map) represent a zero contribution - these pixels are shown dark grey in the fragment image.
Once the lightcurve of a fragment has been measured it is shown alongside the small dynamic view in the spin analysis display (previous section). An example is shown in Fig. 3.16. In the example, two large peaks are apparent - these arise in this case because the fragment is a surface fragment with white paint on one face. While in this mode, the lightcurve can be auto-scaled (or returned to normal) by pressing 'A', in which case the vertical scale is adjusted to make the lightcurve fill the left hand window. For any further analysis it is possible to save the lightcurve data as a Comma Separated Value[1] (CSV) file by pressing 'S'.
Figure 3.18 shows two high resolution HV-2 lightcurves generated from the digitised NAC film. The left hand plot shows the intensity of light from a small flat fragment, which emerges from the interior of the target after some 45 ms. This fragment is very small and does not immediately appear to have a measurable rotation. When studied in parallel with the lightcurve, however, it can be seen that the fragment goes through 9 half-turns in the period over which it has been tracked. The recorded rotation rate for this fragment is -23 ms, meaning an anti-clockwise rotation with a period of 23 ms. It is interesting to note two things about this fragment and its light curve: (i) the peaks correspond to the fragment appearing 'thin', and in fact indicate that the light background of the quarry wall is visible around the fragment, and (ii) no clear shape difference can be seen between successive peaks in the lightcurve, so it would be very difficult to determine without the film comparison whether this fragment undergoes a full or half rotation between peaks.
The right hand plot of Fig. 3.18 shows the lightcurve from a small flat fragment which has come from the surface of the target. Although small, this fragment does not present an image smaller than the lightcurve measurement array (as was found with the previous example). It has a light coloured paint on one flat face and exhibits a substantial spike at time spacings of ~14 ms, which (confirmed by direct observation) is the period of rotation. Perhaps more interesting is the set of small peaks between the large spikes - these correspond to the inner surface of the fragment which is far less reflective. In this case the true full rotation period of the fragment is apparent at the start of the sequence but the lightcurve is confused by noise after 100 ms or so, this being partly due to the the fragment almost disappearing in the dust cloud, and partly due to the sample rate (of the NAC frames) being too low.
Figure 3.18: Two example lightcurves (see text) from fragment 16 (left) of shot 1 and fragment 12 of shot 2. The recorded rotational periods of these fragments are 23 and 14 ms respectively. Arrows above each curve indicate whole rotations of the fragments concerned - note that the second plot is undersampled and does not show significant peaks at t3 or t5.
Notice how the overall magnitude of both lightcurves drops away as each fragment's position relative to the camera changes and (in these cases) present less substantial reflections toward the observer. This is analogous to the solar phase angle variations observed in real asteroid lightcurves (Harris and Lupishko, 1989).
The accuracy of the lightcurve for measurement of a fragment's rotation period is impressive, particularly in cases such as those in Fig. 3.18, where a fragment has rotated several times within the view, allowing for an average value to be taken. As stated at the beginning of this section, the lightcurves were only occasionally actually needed, but they provided a useful check in a number of cases where fragments were rotating too fast or too slowly to be confidently measured by eye.
A variety of graphs and scatter plots are available in HV-2. These are activated by pressing 'G' at the main display screen, at which point the list shown in Fig. 3.19 is offered:
Figure 3.19: HV-2 Graph options screen, accessed by pressing 'G' at the main image screen.
Special options are available for each type of plot, such as running box plots or a choice between visual and ground data, where applicable. Also included in option 'A' is the c2 analysis of the fragment distribution, used in assessing the statistical significance of fragment jets. The majority of graphs for this thesis have not been produced directly from HV-2 but using a commercial graph plotting program, called GraphBox. This program, not available during the early stages of the project, has allowed more control over the labels and axes than can be achieved using HV-2. Nevertheless, the facility to produce graphs and plot data while still within the HV-2 environment was, and remains to be, very useful.
Numerous extra features, not covered in the previous sections, have been added to the HV-2 program. These include such things as on-line help, a screen image saver, direct numerical entry of fragment data from other sources, and so on. Each special feature is briefly described below with the necessary key-press to invoke it.
On-Line Help: Accessed by pressing 'H' at the main display screen, this feature lists all options and keys in HV-2, with their context, on a series of separate screen pages. This list constitutes the best reference for anyone seeking to use the program.
Stop, Save, Quit & Exit: 'Q' exits from most special features (e.g. Callipers mode). Pressing <ctrl>Q ends a program session, saving all data collected. By pressing <ctrl><shift>X, it is possible to exit without saving if, for instance, no new data has been collected. During an analysis session, pressing 'D' saves data to the computer's hard disc without interrupting the work, and <ctrl>D saves to a floppy disc in drive 0.
Screen Save: <ctrl>Z saves the current screen as an Acorn 'sprite' file. Each time this facility is invoked a new file name is chosen so that a series of screen images can be saved, and a small text window is opened giving the user a chance to rename the file in special cases.
Hard Copy: The Copy key (next to Delete) produces a hard copy of the current screen image, using the current printer. This option has not been used much, as it does not allow any post-processing. A screen save (previous point) is generally preferable.
X-Y Plot: If a suitable plotter is available (i.e. one supported by the PlotMate module) pressing <ctrl>P will activate a procedure which enables an X-Y plot to be produced showing (optionally) all fragment trajectories, point markers, indices, etc.
Change Pointer: It is sometimes useful, when tracking certain fragments, to change the pointer shape and colour (e.g. to use a light pointer in a dark image or vice versa). The pointer can be changed by pressing <ctrl>C - four possible pointers are available, and these are cycled through repeatedly.
Fragment Ordering: As mentioned in Section 3.6.3, a second array of fragment indices is maintained along with the standard array, and this allows the fragments to be sorted quickly into some preferred order. Pressing 'O' calls a procedure for sorting (ordering) the fragment indices. The order into which the fragments are sorted can be either ascending or descending, and based upon any variable or parameter such as size, rotational period, etc. of the fragments,
Data Printout: Pressing <ctrl>P invokes a procedure for printing the details of all fragments, in whichever order they were last sorted to (if any). A variety of simple options allow the printout to be customised, and this technique was used to produce the fragment data lists which constitute Appendix 6.
Target Position and Display: By positioning the mouse pointer over the centre of the target and pressing <ctrl>B (for Ball) it is possible to define the centre of the ball. Then pressing 'B' gives an outline picture of the target based upon the user-defined diameter (see Section 3.6.4) and pressing 'A' yields a segmented semi-circular plot showing 3 ball diameters and angular divisions of 30°. An example can bee seen in Fig. 3.14 - the display in this figure was created by pressing 'K' (Kill picture) followed by 'L' (Lines, i.e. trajectory plot) then <ctrl>T (to plot TSMs) and finally 'B' and 'A' to plot ball and angular grid.
Numerical Entry: This facility, invoked by pressing 'N', allows numerical values of the axis sizes (a, b, c), rotational period and velocity to be entered directly. The primary use of this during the analysis process was to enter the apparent rotational period of fragments which were turning too slowly to be measured using the normal system. In 'spin analysis' mode it is only possible to set the rotational period in terms of a full or half rotation - some fragments clearly undergo a quarter or one-eighth rotation while visible, and a quick calculation by hand allows these values to be incorporated into the data. Similarly, a value of 999 ms could be entered this way for the rotational period of fragments which were visibly not rotating. It is unlikely that the velocity will ever need to be entered by hand.
Variable Table: This special program mode, accessed by pressing 'V' in the main display, allows a selection of key variables to be viewed and, in some cases, changed. Figure 3.20 shows the screen display during this mode.
Figure 3.20: The 'Variable Table' screen from HV-2
The majority of variables displayed in this mode are automatically set to sensible values, but the ball size must be set initially for each shot. Once set, the ball diameter need not be changed again and will be saved with the trajectory data on exit. It is also possible to change the type of display used by the program - the size, shape and colour of point markers (indicating the recorded and interpolated points for each trajectory) can be changed here, as well as the colour and style of the fragment trajectory lines.
High Resolution Switch: Although the resolution of the digitised images is fixed, the lines, point markers and other graphics can be drawn at higher resolution and give a much nicer display. This feature, activated with <ctrl>H, is only available when the normal image display has been 'killed'. It is particularly useful when saving screen images for inclusion in papers and reports (e.g. Fig. 3.11, amongst others, in this thesis) or processing in another application. The improvement in resolution is a factor of two in the vertical - 640 ´ 512 pixels compared to 640 ´ 256. Although higher resolution display modes are available (up to 1280 ´ 1024 pixels), using these would require a lot of new program code to scale the images because the range of addressable points changes.
Two significant hardware upgrades have been added to my own Acorn A5000 computer, which I have used increasingly over the last year of the project. Since I have purchased these upgrades myself, and now have the computer at home, the features described here will not be available to anyone using the Archimedes 440/1 machine which was originally bought for the project. Lack of funds currently excludes any possibility of similarly upgrading the 440/1 hardware.
The first upgrade was a ColourBurst Card from State Machine Ltd. - this card significantly enhances the graphic capabilities of the computer, allowing larger screen modes (i.e. more pixels) and more colours than normally available. The feature which is used by HV-2 is that of enabling the palette (in 256-colour modes) to be completely redefined to an accuracy of 24 bits per colour (8 bits each of red, green and blue). This, in principle, removes the need for a look-up table and allows 64 grey levels to be displayed on screen alongside the normal colours. No more than 64 levels of grey are required because this is the number of levels used by the Watford digitiser (see Section 3.4.1). In practice, it was simpler to still use a look-up table in order to apply the gamma curve generally and allow it to be saved in a system-independent way.
A second enhancement was made possible as a result of our group purchasing a machine for writing to Compact Disc Read Only Memories (CD-ROMs). The capacity of a CD-ROM is 650 Mb (compare this to the 40 Mb capacity of the Archimedes 440/1 original hard disc!), and blank CDs are relatively cheap (< £20 at time of writing). By adding a CD-ROM drive to my system I am able to read these discs, and have 'cut' a disc which contains all the NAC images from each experiment in 1989. Having all digitised images available has been a distinct advantage for the latter stages of analysis of these shots. Although CD drives are slower than hard discs, this loss of speed has been minimised by placing images consecutively on the CD-ROM so that the 'seek time' of the drive head is effectively zero.
Figure 3.21: Initial options screen from HV-2 version 2.2; this can be compared to Fig. 3.1 which shows the equivalent screen from version 2.1.
The initial options screen for HV-2 version 2.2 is significantly different from that of version 2.1, as shown in Fig. 3.21. The new option to use a CD drive and the possibility of using 256 grey levels (although only 64 are actually implemented) cover the new features and no further reference is required once the program has been started. The apparent quality of the digitised images is significantly improved by the new display, as well as benefitting from the large monitor which I use with my A5000.
[1] Comma Separated Value (CSV) files are a common format for exchanging numerical data between programs. They consist simply of pairs of numbers, in text form, separated by commas - in this case the numbers are time (in milliseconds) and relative intensity (a value between 0 and 63).