Computer Based Meteor Search - a New Dimension in Video Meteor Observation

The abilities and power of video meteor systems have recently been discussed in detail by several authors [1,2,3]. The number of observers using this method to obtain high-quality meteor data is increasing. They extend the results of meteor photography to fainter magnitudes and smaller meteor showers. However, three main problems have to be solved before video work can become as usual and frequently performed as photographic or even visual observations:
We need

1. high quality and cheap video meteor cameras,
2. a computer based meteor search system and
3. an effective measurement and analysis software for the captured meteors.

Meteor Cameras

Until recently, the main problem developing suitable video systems for meteor astronomy was the price. Thus, most currently operated cameras are individual developments and stand-alone systems. Basically all of them consist of an image intensifiers coupled to some type of optics and an CCD imaging sensor.
However, especially in the last few years image intensifiers have become less expensive. Even second generation devices (MCPs), which show much better characteristics for our purposes, can now be purchased at reasonable prices well below $500, which makes the operation of more amateur owned video systems only a question of time.
Recently, we have designed and built a video meteor camera series (Figure 1). The six cameras consist of 0,75/50mm ultra-fast lenses, second hand MCP image intensifiers and simple CCD video modules for recording the MCP's output screen. The systems are able to record stars down to magnitude 8.5 and have an apparent field of view of 20 degrees in diameter. Their design is very compact (approx. 100x100x300 mm) and robust. This makes them especially suitable for field operation which is often the case in meteor astronomy. To our knowledge, this is the first camera series with several cameras having the same structure and therefore the same recording properties. This will be an considerable advantage when combining data from different stations. In addition it was proven, that meteor cameras can nowadays be built at prices below $800. The optical bench like mechanic design is open for future hardware extensions. It can easily be modified and adapted to other components.

Automated Meteor Search

One of the currently most difficult problems is the search for meteors. So far there is no system, that is able to automatically detect meteors on video tapes in real time. Until now all tapes have been manually inspected by the different observer teams and only first attempts of automation were to be found in the literature [3]. It is obvious that effective large scale video observation depends on the availability of automatic search systems, since the efficiency of manual inspections is limited. There is no sense in developing large camera series and doing regular observations if the video tapes cannot be analysed in reasonable times.
So far, the limited computing speed of available PCs together with noise problems of first generation image intensifiers made the automated search infeasible. However, with the development of new micro processor generations, price reductions for frame grabber cards in the multimedia era and the availability of essentially noise-free MCPs, on-line image processing has finally become possible.
In the last few months we developed and tested a prototype for an meteor recognition system which proved to work fine with the hardware currently available. The principle of the search algorithm was proposed earlier in [3] and is described in Figure 2:

A frame grabber digitises video frames at a rate of approximately 10 frames per second and subtracts successive images from one another. As the result only changes in the image (i.e. appearing and disappearing meteors) and noise remain visible. All persistent (i.e. stars) or slow moving (i.e. satellites) objects will disappear and do not influence the following steps.
To reduce the noise, the resolution of the image is lowered by a factor of four in both axis. So every new pixel is averaged from 16 raw pixels and the noise is reduced by 75%.
The next step involves a mask which is subtracted from the low resolution difference image. This mask accounts for different sensitivity and noise within the intensifiers field of view. It is dynamically generated from the average or maximum noise of the last n video frames (n = 10^2...10^3). By subtracting the mask from the difference image, constant probabilities for meteor detection in the entire field of view independent of camera properties and sky conditions are ensured.
Finally, the procedure looks for longish objects in the resulting image. That is, for every pixel the maximum sum of five neighbours aligned in different directions is calculated as shown in Figure 3. This sum has to be bigger than a certain threshold to be counted as a meteor. The threshold itself is similar to the mask dynamically computed from the average or maximum noise of the last n meteor-free frames, multiplied by a detection rate factor r.
The r-factor tunes the sensitivity of the detection algorithm: Being only slightly bigger than 1, it makes the procedure very sensitive to detect even faint meteors. However, the number of misidentifications (i.e. the algorithms identifies noise as a meteor) increases dramatically. On the other hand there will be almost no misidentification with higher r-values, but some of the fainter meteor will also be missed.
If there is no pixel sum exceeding the threshold, no meteor is detected. If such pixel sums exist, the computer counts them and stores the position of the brightest spot together with its time of appearance. If the number of pixel sums exceeding the threshold becomes too big, something 'strange' happened (a change of the cameras field of view, for example). In this case the procedure restarts calculating the noise mask, since general observing conditions may have changed.
The described algorithm was implemented in Borland PASCAL including inline assembler routines for all time critical sections. It drives an 512x512 pixel AT-bus frame grabber card with 256 grey levels. The program was tested on a 486/DX2 66MHz and a Pentium 90 MHz machine respectively, using the recordings from the alpha Monocerotid outburst in 1995. This shower was recorded with the prototype of the new cameras series, thus, a video system using an MCP intensifier. That is why the main problem we faced when we analysed MOVIE's video tapes in 1993 [3], the strong electron noise of first generation intensifiers, did not occur.
In order to achieve an appropriate number of inspected video frames per second, the search program needs to run four times, each time inspecting another part of the field of view (Figure 4 ). Every frame contains approximately 90.000 pixel.

With this technique, the program was able to analysis every third non-interlaced video frame (8.3 frames/s) running at the 486 PC, and every second frame (12.5 frames/s) when started at the Pentium machine, respectively. The 30 minute test section of the Amo tape contained 28 meteors, 25 of which had been found by visual inspection. The computer detected 20 meteors during the four necessary test runs achieving a detection rate of almost 75%. The r-factor was set to 2.5 leading to only one misidentification. This low number is as important as the ratio of detected to recorded meteors. Normally the meteor activity is much smaller than on the test tape. The number of misidentifications should therefore not exceed 5 per hour to make the search procedure effective.
It can be concluded, that automatic meteor detection is possible with today's computer technology. The remaining 25% of undetected meteors occurred either in the small corners of the field of view remaining uninspected, or they were just too faint. In both cases they are not suited for further analysis anyway, since their positions is inaccurate due to the proximity to the border, or they would be lost in the noise.
It turned out, that the CPU speed is not anymore the main problem. The real bottleneck is the transfer speed from the frame grabber card to the computer's main memory, i.e. the bus system. It is important to have a frame grabber that allows the transfer of raw images to the main memory: Currently more common MPEG-compression boards are not suitable for meteor detection.
The suggested inspection rate of 10 frames per second is appropriate for meteor detection. Since even faint video meteors last in average at least 0.2 seconds, all of them will be visible on at least one inspected video frame. It would be even critical to further increase the frame rate, since especially slow moving meteors near a shower radiant would be missed due to their almost stationary appearance.
We expect, that the detection rate and the number of test runs can still be improved. On the one hand, the data transfer speed within the PC can at least be doubled using PCI frame grabber cards. This implies an reduction down to two or even one test run necessary for each video tape. In addition, there are still improvements in the back end of the algorithm thinkable. They do not significantly increase the computing time due to the reduced size of the image, but might still improve the detection rate.
Currently, the software has prototype status to study the properties and abilities of the suggested algorithm. In the future it is planned to do a market analysis. We intend to find a cheap frame grabber that matches the needs of video meteor observers, and to implement the search program for that hardware.

Computer Based Measurement and Analysis

The problem of measuring video meteors was the first to be solved by several video observers. Almost every team developed its own analysis software for different hardware and different computer generations [4,5,6]. Recently, Marc de Lignie has expanded his AstroRecord measurement program to video observations. The program is a hardware independent solution. It requires Video for Windows AVI animation files as data input and does all the necessary calculations to obtain the meteor's data. The software was introduced at the last IMC and received much attention.
We suggest to decide for one software package for each of the described problems (AstroRecord for the meteor measurement, for example) to avoid that all the programming work is done again and again. This strategy ensures, that all meteor data are obtained with the same procedure allowing us to directly compare results of different observers. In addition, there has only one program to be maintained and improved with further progress in meteor science and computer hardware.

Future Prospects

From the current point of view, the analogue recording of the sky using a VCR and video tapes seems to be an appropriate solution. Real time image compression hardware, which allows the storage of several hours of video signal on a computer's hard disc, as well as digital video are currently under development. It is to expect, that it will take some more years until the prices for such components have reached a suitable level for amateurs. Due to digital broadcasting and the multimedia age as such there exists a mass market for such equipment, so we would like to claim that as the next generation of video systems.
There have been discussions whether or not CCD cameras could be used to transfer the information directly from the imaging sensor to the computer. This would make the optics and electronics of the video camera as well as the frame grabber card redundant. There would be no signal conversion from the CCD output via gain control to analogue video signals and back to digital computer images. Hence, the noise and the computing overhead should reduce significantly. However, currently in amateurs astronomy available CCD cameras serve other purposes and do not reach the frame rate needed for meteor observation. This leads automatically to longer integration times, and two of the main advantages of video systems are lost: the ability to directly record the development of a meteor and the measurement of its velocity without a shutter. In addition, integrated video cameras belong to the mass market and are therefore relatively cheap. Stand-alone CCD cameras, however, are only used in some small areas and will always be more expensive.

Conclusions

With the availability of cheap meteor cameras on the one hand, and the possibility to automate the meteor search on the other hand, two remaining problems for the large scale usage of video systems in meteor astronomy have been solved. It is expected, that a complete hardware and software solution will be available by the end of the year, which makes extensive scientific studies based on amateur video recordings possible. To achieve that aim it is essential, that every video observers does not only record the sky, but also inspects and measures his own video tapes. This will be possible due to smaller hardware costs and centrally available analysis software.

Acknowledgements

We wish to thank Felix Bettonvil from the NVWS, who found those amazing ultra-fast lenses for our meteor camera series at an optical flee market in the Netherlands. So far we didn't even know, that such fast lenses do exist. We would also like to thank Detlef Koschny, who helped purchasing the image intensifiers and contributed to the mechanic components of the cameras.

References

[1] Hawkes, R. L. (1994), "IAU Report on TV Meteor Activity for 1991-1994",
Reports of Astronomy, p.216

[2] Gural, P. S. (1995), "Applying State-of-the-Art Video and Computer Technology to Meteor Astronomy",
WGN 23-6, p.228

[3] Molau, S. (1993), "MOVIE - Meteor Observation with VIdeo Equipment",
Proceedings of the International Meteor Conference 1993, p.71

[4] de Lignie, M. and Jobse, K. (1989), "Accurate Radiant Determination from TV Meteors",
Proceedings of the International Meteor Conference 1989, p.41

[5] Hawkes, R. L. et al (1992), "Analysis Procedures for Two Station Television Meteors",
Proceedings of the International Meteor Conference 1992, p.28

[6] Molau, S. (1994), "MOVIE - Analysis of Video Meteors",
Proceedings of the International Meteor Conference 1994, p.51