**************************************** * MetRec - Meteor Recognition Software * * Version 4.0 2007/07/23 * * Copyright Sirko Molau * **************************************** Table of Contents ================= I Introduction II Hardware requirements III How to get started IV Tuning your system V Additional options VI Meteor shower identification VII Automated meteor observation VIII Meteor shower search IX List of screen shots X File naming conventions and practical use XI Copyright, registration and disclaimer I Introduction ----------------- MetRec is a software for the automatic detection and analysis of video meteors. In can be used both to inspect recordings on video tapes and to do online recognition with an automated video system. MetRec analyses half resolution grey scale PAL (384x288 pixel, 8 bit) or NTSC (320x240 pixel, 8 bit) video frames at rates up to 25/30 frames per second. It stores the appearance time of meteors and optionally a number of frames and a sum image from each event. MetRec is able to compute the meteor brightness, its velocity and equatorial coordinates, and to do determine the meteor shower on the fly. The software is highly flexible - it can be adapted to your system with a number of parameters to be set in a configuration file. All output is written into a logfile or to a printer. During recognition, the current input signal and the system state is displayed at the monitor. II Hardware requirements -------------------------- MetRec is designed for the Matrox 'Meteor/Meteor II' frame grabber family. The program expects a PAL or NTSC video signal at the frame grabber input. A PC with a 200 MHz Intel Pentium processor (or corresponding CPUs from AMD) is about the minimum equipment. For good recognition performance a CPU with at least 500 MHz clockrate is advised. MetRec requires at least 16 MB of main memory, but 64 MB are recommended. The software expects a graphics card with at least 1 MB memory installed. A fast PCI or AGP graphics card is advised to ensure that your system is not slowed down by the graphics output. You should have at least 25 MB of free harddisc space. When you intend to save meteor frames, a disc space of the expected meteor number times the number of frames per event times 150 kByte is approximately required. The program is designed for Dos, hence, it runs under plain Dos as well as MS-Windows 95 and 98. Do NOT start it in a Dos box under Win 95/98, but restart Windows in Dos mode instead. The software does not run under Win NT, 2000, ME, XP, Vista or other operating systems. It can also not be run on a virtual machine like VMWare, since the frame grabber is not virtualized by these. MetRec switches your machine into protected mode and manages the extended memory of your computer. The software is NOT compatible with DPMI servers like 386MAX and EMM386. Please, ensure that these are removed from your CONFIG.SYS file before you start MetRec. On the other hand, you should install a disk cache program like SMARTDRV to accelerate hard disk access. III How to get started ----------------------- In the following sections the details of MetRec and the additional tools will be presented. Many things will be difficult to understand if you never had a look at the program before. Together with this readme file there are a number of screen shots provided, which are listed in section IX. Looking at them when studying this text may help you to better understand the software. After you have installed the frame grabber you need to install the Matrox Meteor driver under Windows 95/98. It comes with the Drivers.ZIP archive. Use one of the Matrox test programs to check, if your frame grabber card is working properly. Alternatively, you may type "grab -2 -pal test.bmp" and check whether you see a live video image. You should create a copy of the default configuration file MetRec.CFG that comes with MetRec. Load the file into your favourite text editor and set some basic parameters: * Specify the type of frame grabber you are using: Set FrameGrabberType to 1, if you have a Meteor I installed, or to 2, if you own a Meteor II. * Set VideoSignalType to either PAL or NTSC depending on your video standard. * If you have frequently changing objects (i.e. a clock) in your video image, you need to prepare an input mask (see section IV) to reject these parts of the image. Set UseInputMask to yes and give the filename under InputMask. * Set the TimeZone you want to refer to. It is suggested always to use UT, i.e. to set TimeZone to 0. * Enter the apparent vertical size of a video frame in degree unter FrameSize. Do NOT give the size of your visible field of view here, but that of the video frame (i.e. if you have a circular fov of 10 deg which is half the vertcial size of your video frame, set FrameSize to 20). * Choose the size of MetRec's internal ring buffer. If you have enough memory (>=64 MB) you should set FrameBufferCount to the highest possible value of 300. To start the recognition software, type metrec [LPT] The last argument is optional. If you specify LPT, the recognizer's output will additionally be send to the printer port. If the software does not start, check the logfile for possible error messages. If the logfile exists already, it will be renamed to .000, .001 or the first number that is not yet used. The program will start to compute a flatfield. After a few seconds, the meteor detection will start. Check the frame rate in the status window at the left side and quit the software by pressing ESC. To obtain the best recognition performance, the program should run at the highest frame rate possible. If your machine is too slow to achive the full frame rate (PAL: 25 frames/s, NTSC: 30 frames/s), you may get a limited performance improvement by increasing the DisplayRefreshRate in the configuration file. Another possibility is to set InternalResolution to half or to increase the FrameStackValue (see section IV). Reducing the internal resolution will result in a minor loss of meteor detection performance. On the other hand, MetRec will run about twice as fast due to the reduced amount of data to be processed. If your frame inspection rate increases significantly, this will result in better overall performance. IV Tuning your system ----------------------- To get maximum recognition performance for a specific camera setup, you can tune MetRec with a number of parameters to be set in the configuration file. To understand these parameters it's necessary that you make yourself familiar with the meteor detection algorithm as such. The current video input signal is displayed in the upper left image window of MetRec. It is digitized at half resolution (384x288 or 320x240 pixels) with 256 grey levels (8 bit). The color information is discarded. If you work with half internal resolution (see section III), the image size will be reduced during digitization by a factor of two in both axis (i.e. 192x144 or 160x120 pixel). In the first detection step, a mean background image is subtracted from the digitized frame. The mean image is derived from the previous frames. Negative pixel values in the difference image are set to zero, so that only pixels with increased brightness are further examined. Next the mean subtracted image is combined with an input mask and displayed in the upper right image window of MetRec. Input masking allows you to remove those parts of the image which will disturb the recognition process. A superimposed clock, for example, changes the image rapidly and will cause many false detections. Blinking objects like twinkling stars behind trees near the horizon may have the same effect. It is advised to mask in addition all parts of the video frame outside the true field of view of your camera, as valuable computing time is saved that way. MetRec allows you to mask every part of the image you want. To do so, you need to supply an uncompressed b/w BMP file (384x288 pixels for PAL or 320x240 pixels for NTSC, 1 bit depth). All regions that are set to 1 will be considered in the detection process, whereas all pixels set to 0 will be discarted. In other words, the mean subtracted image is pixel-wise combined with the input mask by the logical AND function. How do you obtain the required BMP file? MetRec comes with the small utility program Grab. Start it with grab {-1 | -2} {-pal | -ntsc} [-full] [-br b] [-con c] [-int i] and press any key to digitize a frame from the current video stream. The first parameter specifies your frame grabber type (1 = Meteor I, 2 = Meteor II), the second your video standard. A number of optional parameters (not used here) follow. They allow you to grab frames in full resolution and to specify start values for video brightness (0..255), contrast (0..255) and frame integration (1, 2, 4, 8, 16 or 32). Finally you have to specify the name of the image to be written on disc (including the extention bmp). The frame will be saved as an 8 bit BMP file of the required size. To find optimal values for brightness and contrast, a grey scale histogram of the current video data stream can be shown during the execution of grab. Next you can use a simple graphics program of your choice (PaintBrush from MS-Windows, for example) and mark the regions to be used for recognition, and those to be discarted. Finally, save the file as an b/w image. If your program doesn't support the conversion from 8 bit to 1 bit, you can use the MetRec utility program Convert for this purpose. convert [-i] [-thresh t] The option -i inverts the resulting bitmap file. The -thresh parameter is also optional. It allows you to define which grey level is the threshold between black and white (default is 128). Finally, you need to enter the name of your BMP mask in the configuration file as described in section III. After your input signal is mean subtracted and masked, you should see only random noise in the resulting image displayed on your monitor. All constant light sources (like stars) and variable sources (like a clock) are removed. Still, the noise will not be uniform in the field of view, which is because the sensitivity and noise of most image intensified video systems is not uniform. For that reason your mean subtracted image is divided by a flatfield, which is displayed in the lower left image window of MetRec. After flatfielding, all parts of the field of view should have approximately the same sensitivity in the following meteor detection process. Similar to the mean image the flatfield is dynamically derived from the current data stream. It contains essentially the variance of each pixel. Each digitized frame is used for the flatfield update, only pixels belonging to meteors or satellites are discarted. When you start MetRec, either a first flatfield needs to be computed before meteor detection starts, or an initial flatfield is loaded. To do so, you must set UseOldFlatField to yes in the configuration file and provide the name of the file under OldFlatField. When you leave MetRec, the last flatfield will be saved with the name given under NewFlatField. There are a number of parameters to control the computation of the flatfield: Sometimes the objects in your video image wobble around a little due to szintillation or pixel jitter. Bright stars may then produce a number of false detections. To avoid this, you can smooth the flatfield. In return not only the sensitivy of pixels with strong noise, but also of their neighbouring pixels decreases. With FlatFieldSmooth you can control the diameter of the neighbourhood: The larger the value, the more pixels will be affected. FlatFieldSmoothDirection determines, whether the smoothing is symmetric or whether there is a preferred direction. If you camera is unguided and you have a small field of view, for example, you should smooth stronger in the direction of the apparent star drift, as the noise will be stronger there (1 = up, 2 = up left, 3 = left, ..., 8 up right). Set FlatFieldSmoothDirection to 0 for symmetric smoothing. In the actual detection step, about 10 regions of interest (ROI) are extracted from the flatfielded mean subtracted image. These are the pixels with the highest brightness values. They are displayed in the upper right image window when pressing 'r' during recognition. The 'i' key brings you back to the mean subtracted image. The computer determines, which of these regions of interest are static and which are dynamic: If in the previous frame(s) at the same position or in the direct neighbourhood another region of interest was detected, the ROI is called static. If there was no ROI at the same place, it's called dynamic. The neighbourhood threshold between static and dynamic is set such that it distinguishes between objects moving slower or faster than 2 degrees per second (computed according to the size of your field of view given by FrameSize, and the current frame rate). Static ROIs may be almost stationary meteors, but - especially if you have a good limiting magnitude - they are most probably satellites. This is why all stationary ROIs are dismissed and will not be further considered in the detetcion process nor will they be used for updating the flatfield. As meteors are usually elongated objects (contrary to noise, which is mostly point-like), a directional filter is applied to the ROIs. MetRec computes the sum over neighbour pixels that form a straight line with a dynamic ROI at the center. This is done for up to 8 different directions (vertical, horizontal, and diagonal), and the maximum of those directional pixel sums is the final value for recognition: If it exceeds a certain detection threshold, an 'event' is detected. If it is smaller than the threshold, it is discarted. The number of neighbour pixels that are added is determined by the MeteorElongation entry in the configuration file. If you have a small field of view and your meteors are big elongated spots, you should choose a value of two. Then the sum over 5 pixels in a row (two on each side of the central pixel) is computed in all directions. If your field of view is large and the meteors are more tiny, point-like spots, a value of one (sum over three pixels) or even zero (no sum at all) may be more appropriate. However, beware that this causes the noise level to increase significantly, as there are less pixels involved in the averaging process. In the next step, ROIs are clustered. That is, all pixels above the detection threshold (events) form one ROI cluster together with the other pixels in their direct neighbourhood. This is to ensure that one meteor causing several ROIs above the detection threshold is not counted twice. The nature of an event is defined by the overall number of ROI clusters in the current frame: If it's less than the value given under FlashThreshold in the configuration file, each cluster is considered to be an individual meteor. If the number exceeds this value, however, there was no meteor but probably some 'artificial flash' or lightning. It may have been caused by bumping into your camera, for example, so that all stars shift and suddenly became visible in the mean subtracted image, by a dropout of your VCR, or by clouds drifting through the field of view. MetRec will save the time of the flash, wait for some time specified by FlashRecoveryFrameCount, and continue meteor detection. If you set the SaveFlash parameter in the configuration file to yes, also an image of frame containing the flash will be saved. If you set FlashThreshold to zero, flash detection is deactivated. If the event was no flash, MetRec assigns every ROI clusters in the current frame to meteors that were detected in the previous frame. If there were no meteors in the previous frames that fit, a new meteor is assumed. If, on the other hand, there is a meteor in the previous frame without a corresponding ROI cluster in the current frame, MetRec waits two more frames and then considers the meteor to be gone and save all of it's parameters. Finally you can specify with MinimumFrameCount, on how many frames a meteor has to be detected before you accept it. If you set this parameter to a value greater than one, you may significantly reduce the number of false detections, as bright noise spots usually appear in single frames only. On the other hand, you may also miss some very short or faint meteors. For this reason, a value 3 is advised. Be aware that MinimumFrameCount is automatically set to 1 if you set StopDetectionOnSave to yes (see section V). Given the typical case that no event is observed in a frame, the positions of all dynamic ROIs are accumulated in the lower right image window of MetRec. If everything works well, the points should be approximately equally distributed in the full inspected field of view. If the pixels concentrate at certain points (if you see trails from drifting stars, for example), you should try to smooth the flatfield to increase the overall sensitivity of the detection process. If, on the other hand, there is a gradient in the image (from the center to the border, for example), you can try to improve the flatness by choosing a FlatFieldExponent different from 2.0, or a FlatFieldOffset different from 0. These two values influence the computation of the flatfield: Pixel noise is not squared anymore but raised to the power of FlatFieldExponent, before it is averaged and the square root is taken. Then the FlatFieldOffset is added to the square root. Finally, the value specified under FlatFieldFlooring is the minimum value for the flatfield. Once you leave MetRec, the final sensitivity image is saved under the name that is specified under SensitivityImage in the configuration file. As you have seen, the detection threshold for ROIs is the main figure that governs the whole recognition process. The smaller it is, the more events and subsequently meteors will be detected, but the rate of false alarms will increase at the same time. If the threshold is larger, the rate of false alarms will drop, but you may miss fainter meteors as the detector becomes less sensitive. To get maximum performance, the detection threshold is computed dynamically at run time. You can control it's computation with the RecognitionThreshold parameter in your configuration file, which can also be modified at run time with 't'/'T' as long as the software is suspended . MetRec accumulates the highest noise value for a number of frames, multiplies it with your RecognitionThreshold factor and interpolates it with the current to obtain the new detection threshold. To make this easier to understand, let's consider the following situation: The average noise in your flatfielded mean subtracted images is 0.5. In a specific time interval the highest noise value observed was 0.8 (excluding all pixels belonging to static ROIs or meteors). If you have set RecognitionThreshold to 2.0, the new detection threshold will be 1.6 smoothed with the current detection threshold. Everything that is twice as bright as the observed maximum noise is considered for further detection. You should try different values of RecognitionThreshold to find the optimum for your system. The smaller the value you choose, the more sensitive MetRec will be until you get to a point, where noise spots are frequently regarded as meteors brighter meteors as flash. If you set MinimumFrameCount to a value of two or three, it makes even sense to choose a RecognitionThreshold smaller than one. This will frequently cause the most noisy pixels to be above the detection threshold. However, they will usually not be detected as meteors, as they occur only rarely in two or even three consecutive frames. Two more things are to be mentioned regarding the detection threshold. You have to give it's start value as StartThreshold in the configuration file. Furthermore, if for some reason the adaptation of the detection threshold fails (if the threshold becomes smaller and smaller or larger and larger, for example), you can force a constant threshold by setting ConstantThreshold to yes. This is also advised when you expect to observe storm-like activity or if you want to have a constant meteor detection probability. You can follow the temporal development of the threshold in the little graph displayed in the lower right corner of the MetRec screen. The current value of the threshold as well as the maximum noise of the current frame and the accumulated maximum (which will be used for the next update of the threshold) are given in the status window. Once you leave MetRec, the development of the detection threshold is saved in a file with the name specified under ThresholdHistory. Finally let's consider the frame rate again: As described so far, the software grabs one video frame, searches for a meteor, grabs the next frame, and so on. The more frames you work on the better, since you may always miss some short meteors, which appear just inbetween two inspected frames. As described in section III you can control the frame rate with the DisplayRefreshRate and InternalResolution values (and with DelayTime in the rare case, that you have to slow down the software for some reason). Another parameter that influences the performance of MetRec is FrameStack. A value of n implies, that the program grabs n frames, stack them, and evaluates them together (subtracting the background, flatfielding, etc.). The net effect is, that you increase the total number of frames that are digitized per second (absolute frame rate), because the time consuming meteor search procedure is carried out only after every nth digitized frame, not after every frame. In other words, you have smaller gaps between digitized frames and the probability of missing a short meteor decreases. There is, however, one major negative side effect when increasing the FrameStackCount parameter. Both the speed and direction of a meteor cannot be determined accurately anymore, as the position of the meteor in each frame stack is not well defined. In addition, less shower meteors will be identified. This is because a meteor needs to be measured in at least two frames to allow the computation of meteor direction and velocity as well as equatorial coordinates and shower membership. So increasing the FrameStackCount parameter is not recommended and should be your last choice to speed-up the program. V Additional options ----------------------- MetRec supports different time and date bases, that can be defined with the TimeBase and DateBase parameter in the configuration file. If TimeBase is set to one, MetRec will use the current system time. This is appropriate, if you are doing meteor detection on a video signal that comes in real time from a video camera. If you stored an observation on video tape, you can set TimeBase to three and supply the start time of the tape under VideoTapeStartTime. Then the software uses the time from the video tape. If you run your computer or the video for several hours you may realize, that the computer clock is too fast or slow, because at playback the tape runs faster or slower than at recording or because the computer clock is drifting. Whereas the times are correct at the begin of recognition, they may be off by several tens of seconds or even minutes at the end of observation You can correct for this effect by telling MetRec, how many seconds the recognition time is off after one hour (TimeDriftCorrection in the configuration file). A more precise timing can be achieved, if you have a clock inserted into the video image. If you set TimeBase to two, MetRec will recognize the video clock, so that the time of each single frame is accurately known to a fraction of a second. If you have the choice, you should prefer this timing over the previous ones, as the accuracy of meteor velocity and duration measurements will increase. Right now only the time inserter made by Prof. Cuno of IOTA/ES, Germany, is supported (check http://www.astronik.de for details). If you are using another device to insert the clock with sub-second accuracy (i.e. with a unique time stamp for each video frame) into the video image, please, contact the author. To recognize the video clock, you must supply the position of the single digits in the video image. The tool ClockPos will help you to find the right coordinates. Start it with clockpos {-1 | -2} {-pal | -ntsc} [filename.cfg] The first parameter specifies your frame grabber type (1 = Meteor I, 2 = Meteor II), the second your video standard. You will see the current video signal and a cursor. Locate the cursor at the first digit (i.e. the 10 year digit) and press a key. The recognized number will be displayed continuously and you can locate the cursor at the next digit (1 year digit). Continue this procedure until you supplied the position of all 14 digits (year, month, day, hour, minute, second, and frame count). At the end the date and time should be recognized without errors. Once you leave ClockPos, the x and y positions of the different digits are displayed, which then have to be written into the configuration file under VideoClockXPosition and VideoClockYPosition. Optionally, you can directly supply the name of your configuration file when calling ClockPos. In this case the program will automatically replace the old video clock position entries in the file by the new values. Last but not least it might be, that the video clock was not synchronized at start time. You can supply the time difference under VideoClockOffset to correct for this effect. Independently of the TimeBase you have choosen, you can additionally correct for your time zone by entering the offset under TimeZoneCorrection. If, for example, you are working as strongly advised in UT (TimeZone = 0) but your clock is synchronized to your local time like CET (= UT + 1h) or CEST (= UT + 2h), simply set TimeZoneCorrection to -1 or -2, respectively. You are also required to enter the time at which the meteor detection shall finish with respect to your choosen time zone (RecognitionEndTime). The meaning of DateBase is similar to TimeBase. If you set it to 1, MetRec will determine the start date of your meteor detection from the internal clock of your PC. If you want to inspect old recordings, however, you can set DateBase to 3 and supply the correct date under VideoTapeStartDate. Setting DateBase to 2 causes MetRec to determine the start date from the video clock inserted into your video signal. MetRec uses the date to name data directores and PosDat files. If you are living in Australia, for example, this is not ambiguous since you will never observe close to midnight UT. In places like Europe, however, one observing night usually covers two dates. For this reason, there is the following naming rule: If the observation started between midday and midnight (i.e. in the evening), the date will not be corrected. If it started between midnight and midday (i.e. in the morning), however, one day will be subtracted for file naming. You can deactivate this convention by setting DateCorrection to no. As the internal clock is accessed several times a second, it may be off a few seconds after a long time (critical if TimeBase is one or three). This is why MetRec supports an external DCF-77 time signal receiver to synchronize the computer clock. The receiver is a serial DCF module available from Conrad Electronic (Germany) for approx. 20 Euro (including a cable). It works at all places where DCF-77 can be received, i.e. in all of central Europe. You plug the clock into a free COM port, set ClockSync in the configuration file to yes, and specify at which port the clock is installed (ClockSyncPort), and how often you want to synchronize the internal clock of your PC (ClockSyncRate). You can suspend the recognition temporary by pressing 'Ctrl-u'. The recognition resumes after you have pressed 'Ctrl-r'. All hotkeys are displayed by the screen saver, which is activated once you hit any key without a special function during recognition. Setting Beep to yes will cause MetRec to beep every time a meteor or flash is detected, or the video signal is lost. If your video signal is of low contrast or if it does not have an optimum brightness, you can adjust these values with 'b'/'B' and 'c'/'C' when the recongition is suspended. However, beware that this will cause systematic errors in the computed meteor brightness. If meteors appear in more than one frame, MetRec computes their direction in the mathematical sense, i.e. with 0 deg along the positive x-axis and 90 deg along the positive y-axis. If a meteor is only detected on one frame, the rough direction can be deduced from the orientation of the elongated ROI. If you wish another orientation of the angle, you can specify an offset under PositionAngleOffset in the configuration file. You can not only detect meteors, but also save the frames of each meteor on disc. You have three options to do so: * If you set SaveSingleFrames to yes, all meteor frames are saved. * If you set SaveMeteorBand to yes, only the band that contains the meteor is saved from every single frame. * If you set SaveSumImage to yes, only one combined image from all meteor frames is saved. Finally you can set two or all three options to yes, if you want to save sum images and the meteor bands, for example. As it was described the section III, all images are saved in half resolution (384x288 or 320x240 pixel, resp.). If you have a fast computer, a progrssive scan (i.e. non-interlaced) video camera and if need the maximum possible resolution, you should set the InternalResolution parameter to max. In this case, the meteor detection is identical to the standard setting full, but frames are digited and saved at the full video resolution (768x576 or 640x480 pixel, resp.) There are two modi available for saving frames: If you want to have every video frame from the meteor, but you computer runs not at the maximum frame rate, you can set StopDetectionOnSave to yes. Once MetRec has recognized a meteor, it will then grab a prespecified number of frames at the full rate of 25 (PAL) or 30 (NTSC) frames per second and save them to disc. If you set the parameter to no, the software will continue with the recognition and save all frames on which the meteor was detected after it's gone. In this case you may miss some frames, depending on your recognition frame rate. However, you still get accurate values for the meteor duration, velocity, and direction. For this reason it is strongly advised to set StopDetectionOnSave to no. With SavePreFrameCount you specify, how many frames are additionally saved before the first one on which the meteor was detected. SavePastFrameCount specifies the number of frames to be save after that frame (when StopDetectionOnSave is activated) or after the last frame containing the meteor (when StopDetectionOnSave is set to no). The maximum number of frames you can specify depends on the amount of main memory of your computer, as MetRec requires about 110 kByte for each frame (or 440 kByte if you set InternalResolution to max). By setting SaveMeteorData to yes you can save a data file for each meteor similar to the sum image. It contains the individual position measurements and additional information in text format. These files will be required for analysing double-station observations with software that is currently under development. If you have set SaveSumImage to yes and press 'm' during the operation of MetRec, the flatfield in the lower left image window of MetRec will be replaced by the sum image of the last meteor. Enter 'f' to display the flatfield again. Instead of the sensitivity image ('s') in the lower right window of MetRec, 'p' will show a plot of all meteors detected so far, or 'l' a plot of the last meteor only (given EquatorialCoordinates is set to yes, see section VI). All image are stored in the directory specified by BaseDirectory. You can use both absolute (i.e. c:\metrec\) or relative (i.e. ..\data) path names here. If you set AutoSubDirectory to yes, MetRec will automatically create a subdirectory named after the date in your BaseDirectory and save the files there. The names of the files depend on the value of FileNameRule in the configuration file. If it is set to 1, the name will be me_NNNFF.BMP, otherwise HHMMSSFF.bmp (with NNN = meteor number, FF = frame number, HH = hour, MM = minute and SS = second). If you set CreateIAPLogfile to yes, a second logfile in a special format is created. There is a special parameter AutoConfiguration, which will set a number of MetRec options to predefined standard values. Activating this features helps you to be consistent with the conventions of world-wide video meteor network (see section X). Once the recognition end time is reached, there are three ways how MetRec quits, to be configured by the QuitBehaviour parameter. If you set it to 0, MetRec will quit once you did a final key stroke, and you have the chance to look at the last screen. Setting the parameter to 1 will cause MetRec to quit immediately without confirmation, and a value 2 will cause the computer to shut down automatically at the end of observation. Beware that this requires that the disc cache program has written all data to disk before. MetRec will force Smartdrv.EXE to do so, but that works only if the directory of SmartDrv.EXE (typically c:\windows) is in the search path of your Autoexec.BAT. For digitizing video meteors to be measured with external software afterwards, MetRec supplies another tool. GrabSeq allows you to grab short frame sequences in half or full resolution and at the full frame rate. Start it with grabseq {-1 | -2} {-pal | -ntsc} [-color] [-even | -odd | -all | -half] The first parameter specifies your frame grabber type (1 = Meteor I, 2 = Meteor II) and the second your video standard. The third parameter is optional - you can choose, whether an RGB color image or as usual a grey scale image is grabbed. The fourth parameter is optional, too. It allows you to grab only then even or odd, or all fields of the interlaced video frames instead of the full frame. You may also grab a series of half resolution frames. Finally you have to specify the name of the frame sequence. It should contain no more than 5 characters and no extension, as the frame number is automatically added. GrabSeq will show you the current video stream. You have to press a key to start digitizing the frames, and then again a key to stop the digitizer. The program will stop automatically and save the frames once the programs runs out of memory. Together with the single frames a sum image will be saved on your hard disc. The meteor measurement software AstroRecord of Marc de Lignie requires an AVI file as input. Together with MetRec you will find the shareware program VFD, written by Bob Williamson. This program can be used to create an AVI file from sequences of BMP files. Please, refer to the manual vfd.doc for details about the use of this DOS command line controled application. Another tool supports the post-processing of your video observation. You can start it with postproc [-archive] [-shower] [-ref f] [-maxmet m] [-minmag m] [-minvel v] The only mandantory parameter is the name of your MetRec logfile. The software will parse the file and display detailed information of each detected meteor. If you saved sum images, the meteor image will be shown, and if you saved all single frames or the meteor band, you may have an additional look at the frame sequence. All you have to do is to decide for each event MetRec detected, whether it really was a meteor or not. You may invert the image, which may make the decision easier in case of faint meteors. If there are many false detections in short succession, you can batch delete a number of meteors at the same time. With the -minmag and -minvel parameters, you may delete by default meteors that are either too faint or too slow. These are often satellites. The program will mark all false detections, and once you leave it they will be deleted not only from the logfile, but also from the image collection, from the PosDat data file (see next section) and from the IAP logfile (if applicable). If you do not want to delete them physically but just remove them from your database, you can choose the move option. In this case, a MISC subdirectory is created and all of these meteors are moved from your database to this directory. Please, do not modify the logfile manually before starting PostProc, otherwise data may get lost. The program expects the logfile in the same format as written by MetRec. If you have copied the logfile, PosDat files or images into a different directory of your video archive, you can still run PostProc. The optional -archive parameter forces PostProc to read all files from the same directory as the logfile. The optional -shower parameter forces PostProc to recompute the meteor shower assignment for each meteor. This is useful if you have included a new shower in your MetRec.SHW file and want to check whether this shower was active or not. If you accidently used a wrong reference star file (see section VI), you can supply the correct file with the optional -ref parameter. All meteor positions and shower assignments are recomputed. Beware that rounding errors will occur in this case . Finally, postproc can read up to 1000 meteors at a time. If your logfile contains more meteors, you can increase the maximum meteor number of PostProc with the -max parameter. If you only want to have a look at a meteor band, you can use the ShowBND: showbnd If a data file for the meteor exists, the meteor will be shown both unguided and centered at the meteor head. VI Meteor shower identification --------------------------------- So far, all meteor positions were given in absolute coordinates within the current field of view. However, MetRec can transform these coordinates into the equatorial system. Once right ascension and declination are known, also meteor showers can be identified. For these conversion you need to supply a file with reference star positions. You start by grabbing a reference image from your video stream using the Grab tool (see section IV). This time it may make sense to use some of the extra options of Grab. Just like in GrabSeq, you may adjust the brightness and contrast of the grab interactively. In addition, you may reduce the noise of your reference image by integrating over a number of single frames. This will help you to measure even faint stars in the reference image, and to determine their apparent brightness more accurately. Then you can run the RefStars program: refstars [mask.bmp] The first parameter is the BMP file that you just grabbed, and the second is the name of the reference star file to be created. In addition, you may provide the name of your image mask used during recognition. RefStars is self-explanatory, so here only a brief overview is given. The first activity you are asked for is to choose your observing site from a list displayed at the left side of the screen. If your observing site is not stored in the list, you can add it manually to the observing site file RefStars.OSC before starting RefStars. Then you have to decide, whether your camera is guided or unguided. If it was unguided, you are asked to enter the date and time of your reference image (using the same time zone as MetRec, i.e. typically UT!). Then you have to define the center and the diameter of your cameras field of view. For that purpose, a circle is superimposed to the grabbed image in the upper right corner of the screen. You place the circle such that it just circumscribes the circular field of view of your image intensifier. If you don't use an intensifier and your field of view is rectangular, just make the cirle slightly larger than the rectangle. In the following step the software will automatically segment stars. You can manually set the segmentation threshold so that as many stars and as little noise as possible is detected. Next you are required to identify the field of view. Therefore a star map is displayed, which may contains all stars down to 8 mag from the Tycho star catalog. You can modify the center coordinates and the size of the visible section of the star map, as well as the rotation angle and the limiting magnitude for stars. An optional grid help you to fine tune the adjustment. The program starts with the orientation of your last observation corrected for the difference if the reference date and time. If you cannot recognize the star field, three hot keys bring you to predefined positions: CTRL-O to Orion, CTRL-U to Ursa Major and CTRL-X to the Southern Cross. Finally you have to identify reference stars in your image. The software locates the cursor at the brightest star that was automatically segmented. You can now correct the position of the crosshair in the digitized image an in the star catalog, or jump to the next automatically identified star. A four times enlarged image in the upper part of the screen helps your to place the cross-hair with sub-pixel accuracy. Each time you add a reference star, RefStars recomputes the plate constants and estimates the error for each star according to the leaving-one-out (L1O) algorithm. You can change the order of the plate constant fit (a higher order of plate constants requires more stars, but reduces the errors significantly especially if you have a large and distorted field of view) and compute a graphic display of the coordinate grid. This grid is also shown on startup of MetRec in the lower right image window. Reference stars with big L1O errors are shown as big circles, others as small ones. Once you identified enough stars, you leave the RefStars tool. It is advised to measure as many reference stars as possible (100 at maximum) to ensure high accuracy of the coordinate transformation. Especially with higher order plate constants, you should identify at least 25 (second order) or 50 stars (third order), respectively. The overall L1O error depends on your camera system, but with a typical video system (both intensified and unintensified) and a field of view of 50 deg or below, you should get overall errors of 3' or below, and even with wide field cameras (fov of 100 deg), the error should not be much larger than 5'. If the error is bigger than this, you have either choosen an inappropriate plate constant order (e.g. order 1 for a wide field camera) or you misidentified some reference stars. If your camera was guided but the polar alignment or the speed of your mounting not perfect, you may correct the drift of your camera. Therefore you need to grab a second reference image, preferably from the end of your session. It has to get the same name as the first, but the extension END. Then RefStars allows you to choose a third operating mode (drifting). Once you measured the first reference image as before, the second image is displayed. Again you have to specify the corresponding time, segment the stars, and choose the new field of view. Now you are required to identify a few reference stars in the second image. From the drift of the stars in the time elapsed between the two reference images, RefStars computes two correction angles and the speed of the mounting, which are later used by MetRec to correct for the drift. Whereas it is advised to measure several ten stars in the first reference image, it's enough to identify about ten in the second. After the reference star file is created, you have to set EquatorialCoordinates to yes in the MetRec configuration file, and specify the name of the file (under ReferenceStars). If the configuration file has the extension .cfg but otherwise the same name as your reference star file, RefStars will allow you to update the ReferenceStars entry automatically. Later you will find O-C mean squared position error and the L1O values for each reference star in the logfile of MetRec. With the reference star data MetRec is able to compute the plate constants and transform absolute (x,y)-coordinates into the equatorial system. The more positions you obtain from a meteor (i.e. the more frames contain the meteor), the better will be the accuracy of the equatorial coordinates and the derived meteor velocity. This is because MetRec computes a mean meteor trail from all shutter breaks. The mean squared error of the single positions as projected onto a great circle are given in the logfile. It's always zero if the meteor occured in only two frames. Beside the equatorial coordinates, MetRec also computes the probable shower membership for each meteor. The activity period, radiant position, radiant diameter, and geocentric velocity of each meteor showers are taken from the MetRec.SHW file, which contains the IMO working list of meteor showers. MetRec computes, which showers are active and above the horizon. Thereby the radiant position is corrected for zenithal attraction. Once a meteor is detected, the software calculates the minimum distance of the backward prolongated meteor from all active radiants as well as the expected meteor velocity for that shower at the given meteor position in the sky. If the meteor crosses a radiation area as defined in the shower list, and has the right velocity, it is assigned to that shower. A more elaborated way of matching meteors with shower radiants is supported by means of the MaximumMeteorTilt and MaximumMeteorShift parameters in the configuration file. If you use these, you should set the meteor shower diameters in the MetRec.SHW file to zero, i.e. assume point-like radiants. Then you specify which maximum errors in the position and direction of a meteor you expect. MetRec will check whether giving these permitted errors a backward prolongated meteor alligns with the radiant of a shower. The equatorial coordinates and the meteor shower are displayed at the screen and written into the logfile. The displayed meteor shower count list starts with an entry UNK if MinimumFrameCount is set to 1. These are all meteors which appeared only in one frame, so that the direction and velocity of the meteor are unknown and shower identification is possible. If you are not interested in these meteors, you should set MinimumFrameCount to 2 or 3 (see section IV) and lower the detection threshold, as no more single frame false alarms will occur. Furthermore, an IMO PosDat entry may be created for each meteor. For that you need to set PosDatEntry to yes and specify the name of the PosDat header and data file (under PosDatHeaderFile and PosDatDataFile). If these files do not exist, they will be created at startup time of MetRec. Each time you restart MetRec, a new header entry will be created and appended to the header file. The entries in the data file will be linked to that header. The support of PosDat allows you to inspect your data immediately after the observation with the Radiant software of Rainer Arlt. This very comfortable Dos program is especially designed for the investigation of known meteor showers and the search for new radiants. Another option is to use the StrmFind and RadFind tools of MetRec (see section VIII). In other words: It is possible that you let the software run over night and have a look at the fully automatically processed data at the very next morning. Using PostProc even the post-processing is only a question of minutes, which allows you to efficiently run an automated meteor observatory with MetRec (see section VII). The equatorial option enables also the computation of Lunar and Solar ephemeris. MetRec computes the setting and rising time of the Sun, the end and begin of twilight, when the Moon rises, culminates and sets, and the time and distance of the closest approach of the Moon to the center of your field of view. With the MaximumSolarAltitude parameter you specify twilight. If the Sun is above the given value at the observation end time specified by you, a warning will be issued and the recognition end time will be corrected automatically. The same holds for the restart time of MetRec (see section VII). If you set the WaitForDusk parameter to yes, MetRec will only start if the specified solar depression is already reached. That is, with this parameter you can run MetRec in the afternoon, but it will not start the observation before twilight. The MinimumLunarDistance parameter specifies the closest allowed distance of the Moon to the center of the field of view. If MetRec finds that the Moon will come closer during the observation, it will not start but issue an error message instead. This is of importance for image-intensified meteor cameras. These should never be pointed at the Moon, as the sensitive photocathode might get damaged. VII Automated meteor observations ---------------------------------- It is possible to run MetRec continuously in a number of nights. To do so, you must run the MetRec loader program metrec.com instead of the real meteor detector metrec.exe with the usual command line parameters. A .com file is started before a .exe file of the same name by default, so it is sufficient if you just type metrec [LPT] at the command prompt. In the MetRec configuration file, you set the AutoRestart parameter to yes and specify the time of restart under AutoRestartTime. MetRec will check if the Sun is lower than specified under MaximumSolarAltitude, and correct the restart time if necessary. Once the observation of one night is over, MetRec goes into a sleeping mode where it just tells at what time it will be restarted. You may quit the observation with ESC. If not, the software will quit automatically at the specified time, and the loader program will restart the software. If you set the AutoRenameLogfile parameter in the configuration file to yes, and if your first logfile name was of the type yyyymmdd.log, the name will be incremented automatically at restart. Thus, you have and own directory and logfile for each night. If the software shall run without supervision for a longer period of time, it is important to make it resistent to breakdowns or power failures. The best way is to control both your camera and the computer by a programmable time switch, which starts both in the evening and shuts them down in the morning. This requires, that MetRec is started automatically at startup of your computer, which can be achived by adding the following lines to your Autoexec.BAT file: PATH=%PATH%;; smartdrv.exe choice /T:Y,5 Start MetRec if ERRORLEVEL 2 GOTO END cd metrec metrec.cfg metrec.log smartdrv /C :END First, the disk cache SmartDrv is loaded. Then you are prompted for 5 seconds, if you like to start MetRec. If you don't type anything, the default is yes and MetRec ist started. After the observation, the disk cache is cleared and you can do anything else, until the time switch shuts down the power. Each night the logfile metrec.log is written. Since the logfile from the previous night is renamed first (metrec.000, metrec.001, ...), a number of logfiles are created which simply need to be renamed when the observations are post-processed after a while. VIII Meteor shower search -------------------------- It is in the nature of the software that you can only detect known meteor showers that are listed in the MetRec.SHW file. However, once you collected plenty of meteor records after a number of observations, you might be curious what else there is to find. The two tools RadFind and StrmFind will help you to answer that question: RadFind takes all meteors from your observations or from a specific solar longitude interval and does a brute force search over all possible radiant positions / velocities pairs. It lists those radiants that fit best to your meteors. StrmFind takes these radiants and checks, which of these where active over a longer period of time, i.e. which are possible meteor showers. To start the radiant search, type radfind [-stepp n] [-stepv n] [-maxd n] [-maxv n] [-vel n] [-norm] [-sol min max] [-member] [-iter] [-posdat] [-list] infile outfile The only mandantory parameters are the input file (a MetRec logfile) and the output file to which the results are written. If you want to analyse meteors from more than one logfile, you can add the -list parameter. In this case, infile is expected to be a text file with a list of all logfiles you like to analyse. Alternatively, you may analyse PosDat files with the -posdat parameter, or a list of posdat files. In this case, infile is the name of the PosDat data file, and in the same directory the PosDat header file is expected. PosDat allow you to merge data from different nights into a single database. You can, for example, download the summary PosDat file from the IMO Video Meteor Database (see http://www.metrec.org/database.html for details) and immediately analyse a few tenthousand meteors. In this case, however, you should select meteors from a specific solar longitude interval, as otherwise the radiants will be smeared out due to their drift. You can specify the interval with the -sol parameter. The stepsize for the radiant search are defined by the -stepp (position stepsize) and the -stepv (velocity stepsize) parameters. Default are 1 deg and 1 km/s. If you want to check only for a specific velocity (e.g. if you know already the velocity of the shower you are looking for), you can fix it with the -vel parameter. There are two basic algorithms for computing possible radiants. The standard is, that for each meteor and each radiant position / velocity pair the probablility is calculated, that the meteor belongs to this radiant. Only radiants that are above the horizon and fit the the meteor length and direction criterion (as known from visual meteor shower assignment) are considered. If the meteor fits perfectly to the radiant position / velocity pair, the probability is 1. If it misses the radiant by small amount, the probability reduces according to a Gaussian distribution. The resulting probability distribution of a meteor in the three-dimensional position / velocity space is similar to the probability mode of the Radiant software by Rainer Arlt. Once the probabilities are accumulated for each meteor and each radiant position / velocity pair, RadFind determines all local maxima and lists these in the order of their accumulated probability. If you specify the -member parameter, RadFind will in addition determine, which meteors fit to the radiants found by the software. The maximum error that is accepted by default is 10 degree and 5 km/s. You can modify these values by the -maxp and -maxv parameters. A more elaborate iterative algorithm, which is also by a factor of two more time consuming, can be choosen by the -iter parameter. At first, the probability distribution in the radiant position / velocity space is computed over all meteors as before. Then, the global maximum is calculated, and all meteors fitting to this radiant are determined. The probability distribution of this subset of meteors is computed, and the best radiant position and velocity are determined from this sub-distribution. Next, the sub-distribution is subtracted from the original distribution, and the algorithm repeats by searching for the global maximum, determining the meteors belonging to this maximum, and so on. The advantage is, that you remove step by step meteors from the most active radiants and continue to search for weaker ones. This way you will also be able to detect weak showers which would otherwise get completely lost. The last optional parameter is -norm. If you specify it, the probability distribution of each meteor in the position / velocity space will be normed such that it sums to 1, i.e. each meteor will create the same probability mass. This will give more weight to short meteors near the radiant (because their probability is shared between fewer radiant position / velocity pairs), whereas longer meteors away from the radiant gain from unnormalized distribtuions. In the output file of RadFind, at first the run time parameters and the number of meteors used for the analysis are listed. Then comes the list of possible radiants, which might look as follows: ra= 273.1 de= 33.0 vel= 45.0 : 318.00 / 411 (LYR: 271.0, 34.0, 49) ra= 223.3 de= -24.0 vel= 29.0 : 19.10 / 46 (SAG: 228.2, -17.4, 30) ra= 208.4 de= -22.5 vel= 20.0 : 14.13 / 37 ... The first three parameters are the position and velocity of the detected radiant. They are followed by the accumulated probability of this radiant position / velocity pair (in arbitrary units) , and the number of meteors fitting to the radiant. If the detected radiant can be linked to a known shower from the MetRec.SHW file, the listed radiant together with its parameters are appended. Once you did a radiant search over several nights or solar longitude intervals you may check with StrmFind, which of these are found in consecutive nights. To do so, type strmfind [-maxp n] [-maxv n] [-maxs n] [-mind n] [-ext min max] infile outfile StrmFind expects the output files from RadFind with the same filename prefix and consecutive numbers as extention (e.g. result.000, result.001, ...). With infile you specify the filename prefix of the series (without the extention) and with outfile the output file of StrmFind. If you do not specify the range of extentions with the -ext parameter, StrmFind expects the extentions 0 to 359 (i.e. one logfile for each degree in solar longitude). StrmFind reads these files and looks for chains of radiants with similar positions and velocities. By default, two radiants are considered to be connected, if their position differs by no more than 5 degree, their velocity by 5 km/s and their solar longitude by 1 degree. You may alter these values by the -maxp, -maxv and -maxs parameters, respectively. Unless other specified by the -mind parameter, a meteor shower is only reported if corresponding radiants are found in at least 5 input files, or the radiants span a solar longitude interval of at least 5 degree. The output file of StrmFind may look as follows: Shower # 3 : sol= 27 - 35 Apr 17 - Apr 25 9 rad points 1221 met Mean values : sol= 31 Apr 21 equ= 272.2 / 33.5 ecl= 273.4 / 56.9 vel= 45 val= 68.50 Max values : sol= 33 Apr 23 equ= 273.1 / 33.0 ecl= 274.7 / 56.4 vel= 45 val= 192.90 met= 411 / 64.0% Drift : equ= 0.3 / -0.1 ecl= 0.4 / -0.1 -------------------------- IMO Code LYR: sol= 26 - 35.0 Apr 16 - Apr 25 Max values : sol= 32 Apr 22 equ= 271.0 / 34.0 ecl= 271.5 / 57.4 vel= 49 Drift : equ= 1.1 / 0.0 ecl= 1.7 / 0.0 -------------------------- sol= 31 Apr 21 equ= 272.2 - 269.9 / 33.5 - 34.0 ecl= 273.4 - 269.8 / 56.9 - 57.4 vel= 45 / 49 sol= 33 Apr 23 equ= 273.1 - 272.1 / 33.0 - 34.0 ecl= 274.7 - 273.2 / 56.4 - 57.4 vel= 45 / 49 -------------------------- Individual radiant points: sol= 27 Apr 17 equ= 272.1 / 32.5 ecl= 273.2 / 55.9 vel= 42 val= 4.76 met= 7 / 1.0% sol= 28 Apr 18 equ= 272.1 / 32.5 ecl= 273.2 / 55.9 vel= 43 val= 6.83 met= 18 / 2.7% sol= 29 Apr 19 equ= 269.9 / 36.5 ecl= 269.8 / 59.9 vel= 44 val= 9.68 met= 21 / 3.1% sol= 30 Apr 20 equ= 271.5 / 35.5 ecl= 272.4 / 58.9 vel= 44 val= 24.75 met= 45 / 7.6% sol= 31 Apr 21 equ= 271.9 / 33.0 ecl= 272.9 / 56.4 vel= 45 val= 104.08 met= 156 / 28.1% sol= 32 Apr 22 equ= 272.5 / 33.0 ecl= 273.8 / 56.4 vel= 45 val= 191.96 met= 479 / 63.6% sol= 33 Apr 23 equ= 273.1 / 33.0 ecl= 274.7 / 56.4 vel= 45 val= 192.90 met= 411 / 64.0% sol= 34 Apr 24 equ= 273.6 / 33.0 ecl= 275.5 / 56.4 vel= 45 val= 63.02 met= 69 / 16.7% sol= 35 Apr 25 equ= 273.3 / 32.5 ecl= 275.0 / 55.9 vel= 48 val= 18.56 met= 15 / 4.7% ========================== It is the third shower that was detected, which is found in the solar longitude interval 27 to 35 degree (corresponding to April 17-25). 9 independent radiant point were found for this showers, and an overall of 1221 meteors assigned to it. The values in the second line are the mean equatorial and ecliptical coordinates, velocity and accumulated probability. The next line gives the same values from the interval with strongest activity. An overall of 411 meteors were recorded at a solar longitude of 33 deg, which is 64% of all non-shower meteors in that interval (i.e. this radiant had two-third of the strength of the "sporadic background"). The last figure is a good measure for the activity of the shower, since it is independent of the overall number of meteors records in that interval and the activity of other showers. Beware, however, that poradic meteors are recorded at any place and any time, whereas shower meteors can only be well observed when the radiant reaches a sufficient altitude. Since here all data from all night and places were used, the shower appears to be weaker than in reality. After the mean drift values in equatorial and ecliptical coordinates, it is stated, that the detected shower corresponds to the Lyrids, and the corresponding values for the Lyrids are listed from the MetRec.SHW file. The following two lines compare the values of the detected shower and the Lyrids for the mean and maximum activity solar longitude interval. At last, the radiant positons from the individual input files are listed. The first parameters are the solar longitude, date, equatorial and ecliptical coordinates, the velocity and the accumulated probability. The last two figures are the absolute meteor count belonging to the radiant in that interval, and the ratio of shower meteors to those not assigned to any shower. The ratio gives a nice activity graph for the Lyrids over time. Last but not least it should be mentioned, that RadFind and StrmFind can not only be applied to video meteor observations. You may feed them with any data in PosDat format, like your visual plottings, for example. However, be careful with the results you obtain. Both tools do only statistical analyses. You can easily "detect" hundreds of "new" meteor showers with these. It is your task to be cautious and examine the results carefully before claiming a new meteor shower. IX List of screen shots ------------------------- Many functions of the software are easier to understand if you can see how the things look like at run time. The following screen shots are available in the screen subdirectory: Grab: * grab01.gif: Grab at run time. The current video frame is shown. * grab02.gif: Integrating over a number of frames reduces the noise in the video data stream significantly. GrabSeq: * grabs01.gif. GrabSeq at run time. Frames are grabbed in full resolution by default. RefStars: * refsta01.gif: After the observing site and the operation mode have been choosen, the reference date and time need to be entered. * refsta02.gif: A circle has to be placed in the upper right window marking the border of the intensifier's field of view. * refsta03.gif: Now RefStars has segmented the stars in the reference image. The threshold between stars and the background has to be set, the result is displayed in the lower right window. * refsta04.gif: The appropriate region in the sky was choosen from the star catalog. * refsta05.gif: A grid helps to match the star catalog with the reference image more accurately. * refsta06.gif: RefStars during the measurement of the reference stars. The crosshair in the upper right window is automatically placed at the next detected star. The position of the reference stars measured so far is marked with a black cross. The zoom window shows the position of the crosshair at four times magnification allowing you to find the center of the star with sub-pixel accuracy. The corresponding entry from the star catalog is displayed in the lower right window. The lower left window lists the data of all reference stars measured so far. * refsta07.gif: Pressing 'c' results in a plot of the current equatorial coordinate grid. The size of the displayed reference stars is a measure of their L1O position error: The larger the star, the larger the error. 'o' changes the order of plate constants and yields a different coordinate grid as well as different position errors. The overall mean squared L1O error is given in the data window at left. ClockPos: * clock01.gif: ClockPos at run time. The current video data stream is displayed and a cursor is placed at the next digit to be measured. The digits measured so far are automatically recognized and displayed at bottom. MetRec * metrec01.gif: MetRec at startup. The first flatfield is computed and recognition has not yet started. The lower right image window shows the equatorial coordinate grid and the reference star position errors. * metrec02.gif: MetRec at run time. Up left is the current video frame, up right the mean subtracted image. The lower left image window shows the current flatfield, and the lower right window the sensitivity image. At bottom left the last logfile entries are displayed, and at right the threshold history is drawn. On the left side are status windows with date, time, status, and statistical data. * metrec03.cfg: After pressing 'm' the sum image of the last detected meteor is shown. The meteor position is marked with a black line. * metrec04.cfg: 'l' shows a star map with a plot of the last meteor. * metrec05.cfg: After pressing 'r' the upper right window shows the positions of the ROIs in the current video frame. It switches back to the mean subtracted image. PostProc: * post01.gif: PostProc at run time. All information about one detected meteor is displayed. The lower left window shows the corresponding part from the logfile. ShowBND: * show01.gif: ShowBND at run time. The sum image is shown and the meteor band is inserted dynamically. X File naming conventions and practical use ---------------------------------------------- MetRec is in regular use by a number of video meteor observers around the globe. They are gathering meteor data in every clear night and contribute to a large database that is compiled by the author. The IMO Video Meteor Network is still growing and your observations are highly welcome. The contact address is given in section XI. In order to be consistent with the global video meteor database, you should follow a number of conventions. This sections describes the typical steps of a meteor observation session with MetRec and the post-processing as required for the video network. If you set up your camera for the first time or changed its field of view, you start by grabbing a reference image with name yyyymmdd.bmp according to your observing night. You measure as many reference stars as possible, choose the order of plate constants that gives consistently the lowest position errors, and store all data in a reference star file yyyymmdd.ref. Then you prepare you MetRec configuration file yyyymmdd.cfg. If you have set the AutoConfiguration parameter to yes, you only need to update the reference star file and the RecognitionEndTime parameters from an old config file. If not, make sure that for each meteor a sum image, the meteor band and the data files are saved. All times should be UT. There should be an individual PosDat file for each night with name mmdddata.dbf and mmddhead.dbf, and all data is be stored in a special subdirectory yyyymmdd. You start the observation with MetRec and create a logfile yyyymmdd.log. If you realize that something goes wrong and you need to restart the observation, make sure that you delete the data subdirectory that was automatically created, as well as the PosDat files. Otherwise you will end with duplicate entries in the PosDat and logfile. If you want to run MetRec continuously in several nights, you should choose a generic configuration file name (e.g. metrec.cfg) and use either the yyyymmdd.log naming convention for the logfile, or the generic name metrec.log when your system is shut down at daytime (see section VII). After the observation you post-process the logfile in your current directory. You delete all false detections and everything you are not perfectly sure about. Even if there are plenty of false detections (e.g. due to clouds or insects), never delete the records by hand, because they need to be removed from the logfile, the PosDat data file, and the data directory! Always use PostProc which will do all that for you. The last step is to move the post-processed logfile, the updated PosDat files, the configuration file, and (if newly created) the reference image and file to your data subdirectory. This directory contains already backup copies of the original logfile and PosDat files, which can now be overwritten. If you used generic names, rename the logfile and config file to yyyymmdd.log and yyyymmdd.cfg, respectively. XI Copyright, registration, and disclaimer -------------------------------------------- This software is copyright by the author Sirko Molau. The author is not responsible for any damaged, corrupted, or lost data, or otherwise harmful occurences which may result from the use or inability of MetRec. This program has been tested and retested, and debugged, by myself. To the best of my knowledge, MetRec has no bugs, will not cause any corrupted or loss of data on a properly configured PC. To the best of my knowledge it will not do anything more than what is documented herein. However, I guarantee nothing, except that this program will take up hard drive space. MetRec is shareware. Amateur astronomers may copy, use, and redistribute the software free of charge. However, I would like to get a short message from everybody using MetRec to know, which versions of the software are used where. Professional or commercial users are required to register with the author and pay a registration fee of 250 Euro. Every user that works at an astronomical or comparable institute and get the camera system or computer hardware funded falls into his category. The registration is valid for all camera systems of the user and includes free access to future updates. Payment details are given at the MetRec homepage. For research purposes, you may obtain the documented C source code of MetRec at request from the author: Sirko Molau Abenstalstr. 13b 84072 Seysdorf Germany phone : +49/8752/869438 e-mail: sirko@molau.de The lastest version of MetRec and results from world-wide video meteor observations can be obtained from the MetRec homepage at http//www.metrec.org. There is a special mailing list for MetRec users and discussions about video meteor observation in general. Its name is metrec@yahoogroups.com, and you can subscribe at http://groups.yahoo.com/group/metrec. If you would like to join the IMO Video Meteor Network, just drop me a mail.