**************************************** * MetRec - Meteor Recognition Software * * Version 5.1 2012/07/30 * * 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 Post-processing your observation VIII Automated meteor observation IX Meteor shower search and other add-ons X List of screen shots XI File naming conventions and practical use XII Additional utilities XIII 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. The software calculates the limiting magnitude and the size of the field of view covered by the camera. It is able to determine the meteor shower on the fly, and the flux density for each meteor shower. 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 comes in two version. The DOS version 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. In fact, it is not even necessary to start Windows at all. As soon as the Matrox Meteor driver is installed, you can start a DOS box and type the following: - cd c:\ - attrib -r -h -s msdos.sys - edit msdos.sys modify the line BootGUI=1 to BootGUI=0, save the file and leave the editor - attrib +r +h +s msdos.sys After the next reboot, the Windows GUI will not start and you can run MetRec directly from the DOS prompt. To start the GUI later, simply type "win". The Win32 versions runs under Win XP (32 bit only). MetRec is designed for the Matrox 'Meteor' (DOS only) and 'Meteor II' (DOS and Win32) frame grabber family. It supports also the Meteor II MC (multi channel), but not the Meteor II DIG (digital) frame grabber. The program expects a PAL or NTSC video signal at the frame grabber input. A PC with a 300/600 MHz Pentium processor (DOS/Win32) is about the minimum equipment. For good recognition performance a CPU with at least 600/1000 MHz (DOS/WIN32) clockrate is advised. MetRec requires at least 16/256 MB (DOS/WIN32) of main memory, but 64/512 MB (DOS/Win32) are recommended. The software expects a graphics card with at least 1 MB memory installed. 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/600 kByte (full/max resolution) is approximately required. A hard disc of 10 GB is typically sufficient for all purposes. MetRec does NOT run under Win Vista, Win 7, all 64 bit versions of Windows or other operating systems. Only those programs that do not access the grabber (e.g. PostProc, RefStars) can run on a virtual machine like VMWare, VirtualBox or Virtual PC, since the frame grabber is not virtualized by these. The DOS version of 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, it is strongly recommended to install a disc cache program like SMARTDRV to accelerate hard disc 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 X. 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/XP. It comes with the Driver98.ZIP/Driverxp.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. * If you have more than one frame grabber installed on your computer, set FrameGrabberDeviceNumber to the grabber you want to use (default is 1). * Set VideoSignalType to either PAL or NTSC depending on your video standard. * If you have not yet measured reference stars (see section VI), 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 vertical size of your video frame, set FrameSize to 20). * If you have frequently changing objects (e.g. 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. * Choose the size of MetRec's internal ring buffer. If you have enough memory (>=64 MB) you should set FrameBufferCount to the largest possible value of 300. To start the recognition software, type metrec [COM1] [COM2] [LPT] The last arguments are optional. If you specify COM1, COM2, or LPT, the recognizer's output will additionally be send to the serial port (configuration 115200,N,8,1) or printer port of your PC. 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. You can also configure a DelayTime for the rare case, that you have to slow down the software for some reason. 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. MetRec has four main windows. In the default configuration, the upper left window will show the raw video data stream, the upper right window backward tracings from the detected meteors (details about that will follow), the lower left window a sum image of the last detected meteor, and the lower right window a star map with the last detected meteor. You can choose different content by configuring the ULWindowContent, URWindowContent, LLWindowContent and LRWindowContent parameters in the configuration file, or by pressing F1 to F4 and the corresponding letter at run time. Depending of the InternalResolution parameter, the video input signal is digitized at 384x288 (PAL) resp. 320x240 (NTSC) pixels (full resolution) or 768x576 (PAL) resp. 640x480 pixels (max resolution) with 256 grey levels (8 bit). The color information is discarded. If you work with max internal resolution (see section III), the image size will be reduced after digitization to the same size as in full resolution mode. As the first (optional) operation, a dark field is subtracted from the digitized image. Use that option to remove hot pixels, which will interfer with the limiting magnitude calculation later on. You can provide the name of the dark field BMP file with the DarkField parameter in your configuration file. How do you obtain the required BMP file? MetRec comes with the small utility program Grab. Start it with grab {-1 | -2} {-pal | -ntsc} [-dev d] [-mean] [-full] [-br b] [-con c] [-int i] [-ts t] [-dark darkfield] 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, and the third the device number of your frame grabber (in case that multiple frame grabbers are installed). A number of optional parameters follow. -mean will force grab to average frames instead of using a first order response filter for integration. The next parameters 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). The -ts parameter will add a time stamp when specified as 1 and a date & time stamp when specified as 2. The -dark parameter allows you to subtract an already existing dark field during grab, which is necessary when grabbing a reference image (see section VI). 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. Note that you should choose the same brightness and contrast settings when grabbing the dark field and the reference image (see section VI). For the dark field, you need to close the lens and cover the camera to make sure that no strewn light enters the camera, and then you grab the image with sufficient frame integration to remove noise. After dark fielding, a mean background image is subtracted from the digitized video frame. The mean image is the average of the previous frames. Negative pixel values in the difference image are set to zero, so that only pixels with increased brightness are further examined. After that, the mean subtracted image is combined with an input mask. You may display the live mean subtracted and masked video stream by choosing the content I. 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 mandatory to mask all parts of the video frame outside the true field of view of your camera (e.g. in case of intensified cameras with a circular field of view) or that are covered by terrestrial objects (trees, houses, roofs) to ensure that MetRec can compute the true fields of view and proper limiting magnitude and meteor shower flux densities. In addition, 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. You can obtain the necessary input mask file with the grab tool. You take an image of your field of view and use a simple graphics program of your choice (PaintBrush/Paint from Windows, for example) to 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 when you display the resulting image displayed on your monitor. All constant light sources (like hot pixels, 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 can be displayed by choosing content F. 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 your 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 next 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 by choosing content R. 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 or twinkling stars. 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' (a meteor candidate) 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 (vertical, horizontal, diagonal). 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 someone 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 will 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 of 3 is advised. If you hunt for specificevents like sprites or lunar impacts, the value has to be set to 1. Meteors will only be reported if they have the right angular velocity. The velocity range is defined by the MinimumMeteorVelocity and MaximumMeteorVelocity parameters. There values a valid for the zenith and will be reduced accordingly if the meteor is observed lower at the horizon. Given the typical case that no event is observed in a frame, the positions of all dynamic ROIs are accumulated in the sensitivity image, which you can display by choosing content S. 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 improve the overall sensitivity of the detection process. 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 its computation with the RecognitionThreshold parameter in your configuration file, which can also be modified at run time with t/T as long as MetRec 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 2.0x0.8=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 and brighter meteors as a flash. If you set MinimumFrameCount as advised to a value of two or three, it makes sense to choose a RecognitionThreshold smaller than 1.0. This will frequently cause the most noisy pixels to be above the detection threshold. However, they will not be regarded 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 under 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 meteor activity or if you want to have a constant meteor detection probability. Alternatively you can sepcify with FloorThreshold the minimum allowed recognition threshold. 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 text file with the name specified under ThresholdHistory. 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. Before the recognition starts, MetRec will ask you to press a key. This allows you to start the recognition exactly at the time you specified as start time. 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). TimeDriftCorrection will not only correct the recognition time at run time of MetRec, but it will also correct your computer clock at startup to account for the clock drift since you run MetRec last time. If you know the time drift of your computer clock accuraty, this enables you to run MetRec automatically for many days without a significant time drift. 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. 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} [-dev d] filename.cfg As usual, the first parameter specifies your frame grabber type (1 = Meteor I, 2 = Meteor II), the second your video standard, and the third your frame grabber device number. 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. In addition, the program automatically replaces the old video clock position entries in the specified condiguration 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, your clock is synchronized to your local time like CET (= UT + 1h) or CEST (= UT + 2h), simply set TimeZoneCorrection to -1 or -2, respectively. MetRec will automatically correct for daylight saving time if the DSTCorrection parameter is set to yes. In the example above, you can leave TimeZoneCorrection at -1 all year long. Note that the DST correction will only work properly in Europe, since at other locations the begin and end date of daylight saving time may be different. You are also required to enter the time at which the meteor detection shall finish (RecognitionEndTime) in UT. 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. Currently two receiver types are supported: A serial DCF module available from Conrad Electronic (Germany) for approx. 20 Euro (including a cable), and the ClockMouse from Hopf. Both are discontinued, but are widely used among video observers. They work 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, specify the clock under ClockType (1 = Conrad, 2 = ClockMouse), at which port the clock is installed (ClockSyncPort), and how often you want to synchronize the internal clock of your PC (ClockSyncRate). The last figure is given in VideoFrames, so if you have a PAL video signal and like to adjust the clock once per hour, you needs to set it to 3600*25=90000. Set ClockSyncRate to 0 if you want to correct the clock only once at startup. If MetRec runs under Windows and you computer is connected to the internet, you may also synchronize your system time with a NTP (network time protocol) server. An external NTP client program is necessary for that. 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 to 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. You can set two or all three options to yes, if you want to save sum images and the meteor bands (default), for example. Finally, there are two specific options for the SaveSingleFrames parameter: If you set this value to first, only the first video frame of a meteor is saved. If you set it to bright, MetRec will save single frames only for meteors that are brighter than the value given as SingleFrameBrightness, and that last longer that the value given in SingleFrameDuration. This option is particularly helpful if you do not want to waste your hard disk with thousands of single frame images, but still don't want to miss bright fireballs that may confuse the meteor detection process. 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 progressive scan (i.e. non-interlaced) video camera and if you need the maximum possible resolution, you should set the InternalResolution parameter to max. In this case, the video frames are digitized and saved at the full video resolution (768x576 or 640x480 pixel, resp.) If you want to reduce the resolution of your sum image and single frames later to save disc space, you can use the RedRes tool. Start it with redres [outdir] whereby indir specifies the directory that contains the files with max resolution, and outdir the target directory to which the files shall be saved. If you don't specify a target directory, the files will be overwritten in place. Sometimes AVI files may be required from your meteors. The meteor measurement software AstroRecord from Marc de Lignie, for example, requires an AVI file as input. Another small supplementary MetRec tool allows you to create a sequence of BMP files from a meteor band (and the sum image, if available). Start it with transbnd and specify the name of your meteor band. The sum file should be in the same directory. The program will write a sequence of BMP files which can be used to create AVI files or other animations with third party software. Together with MetRec you will find the shareware program VFD, written by Bob Williamson. Here is an example on how to create an AVI file from the BMP file sequence: vfd ??.bmp -A2 -S25 -O.avi -F2 For more details about the use of this DOS command line controled application, please, refer to the manual vfd.doc. 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 the last frame containing the meteor. SavePostFrameBright defines, how many additional frames are saved in case a bright meteor is detected and SaveSingleFrames is set to bright. 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). MetRec can print time stamps on the individual video frames and the sum image of a meteor. This function is actived by the parameter TimeStamp (0 = no time stamp, 1 = only time, 2 = date & time). The position of the time stamp within the image is controlled by the TimeStampXPosition and TimeStampYPosition parameters. 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. It is also used by ShowBND to have the meteor band centered at the shutter break. The SaveBackgroundRate Parameter specifies, if MetRec shall save averaged background images at fixed time interval. A value of 10, for example, means that every 10 minutes a background image is saved. Set the parameter to 0 do deactivate that function. 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). 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 the IMO Video Meteor Network (see section XI). MetRec supports the control of external hardware. It allows to send a short string to a serial port every time a meteor is detected. That can be used to trigger a DLSR camera to take a high-resolution short of the meteor, for example. To enable this function you have to configure the SendSerialPing parameter in the Metec configuration file to yes, and to specify the serial port with SerialPingPort. The SerialPingType parameter specifies, which information is sent at what time to the serial port. Once the recognition end time is reached, there are four 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, a value 2 will cause the computer to shut down automatically at the end of observation, and a value of 3 will cause a reboot. Beware that under DOS this requires that the disc cache program has written all data to disc 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} [-dev d] [-color] [-even | -odd | -all | -half] The first parameter specifies your frame grabber type (1 = Meteor I, 2 = Meteor II), the second your video standard and the third the frame grabber device number. The next parameter is optional - you can choose, whether an RGB color image or as usual a grey scale image is grabbed. The following parameter is optional, too. It allows you to grab only the 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. VI Meteor shower identification and flux densities ---------------------------------------------------- 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, and the limiting magnitudes and meteor shower flux densities can be calculated. For this 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 makes 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. For non-intensified camera, best recognition results are typically achieved with contrast set to maximum (255) and brightness such that the background is dark grey (typically ~200). In addition, you may reduce the noise of your reference image by integrating over a number of single frames and using the -mean option. This will help you to measure even faint stars in the reference image, and to determine their apparent brightness more accurately. If you subtract a dark field (see section III) during meteor detection, you need to supply the same dark field during grab that you also use in MetRec. This is to ensure, that the photometry obtained from the reference image is identical to the photometry during meteor recognition. Then you can run the RefStars program: refstars [-num n | -drift] [-update] [file2.bmp ... filen.bmp] [mask.bmp] file1.bmp is the reference image that you just grabbed, and filename.ref is the name of the reference star file to be created. If the reference image contains too few stars (<50), you may grab a number of reference images at different times, and measure them all together. In this case, you have to specify the number of images with the -num parameter, and list them one by one. The -drift parameter has to be given when you have a guided camera with bad equatorial alignment, i.e. when your stars are slowly drifting. The -update parameter allows you to read an existing reference star file at startup and either continue the measurement of more stars, or delete reference stars. You may also provide the name of your image mask used during recognition. Only stars inside the active field of view are measured then. 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 with a text editor to the observing site file refstars.OSC before starting RefStars. Then you have to specify the gamma correction parameter of your video camera. When gamma is set to 1.0, there is a linear dependency between the intensity of an object and the pixel value. However, in practice gamma values smaller than 1 are frequently used, which provide a larger dynamic range at low brightnesses and increase the limiting magnitude and meteor detection performance. Specifying the gamma value here ensures that this has no negative impact on the photometric accuracy. In the next step you define, whether your camera is guided or unguided. If it was unguided, you are asked to enter the date and time of your reference image (in 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 need to set the segmentation threshold such that as many stars and as little noise as possible is detected. This setting will later be used when MetRec calculates the limiting magnitude, so make sure that the parameter is set properly. Thereafter 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 helps 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 Majoris 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. When you have a first set of reasonably good plate constants, you can adjust the star map based on the preliminary plate constants. So if your initial star map alignment was sub-optimal, you can improve the star map during the measurement. In order to measre faint stars, you can also apply a highpass filter to the input image which will make even the faintest objects easily visible. 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 in MetRec if you choose the content C. 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 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. There are several options to delete poor reference stars and outliers. You can move the cross-hair to the position of the star and press d to delete the nearest star. Pressing l will delete the last star you measured, and D the star with the overall biggest L1O error. When you press L, you can enter the maximum allowed L1O error for reference stars. All stars with bigger error will be deleted thereafter. This option is particularly helpful if you want to delete outliers in a reference star file created by MetRec with several thousand entries. Note, however, that you will be warned when you try to delete more than 10% of the reference stars. Otherwise you overall L1O error is artificially reduced, which will have a negative impact on the limiting magnitude calculation of MetRec. To be on the safe side, you may use O instead of L. That will delete outliers with more than two times the average L1O error. When you finished the measurement of the image, you can either leave RefStars, or the procedure will be repeated for the next reference image(s) if you grabbed more than one. 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. Running RefStars with the -drift parameter, you measured the first reference image as before, and then 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. If you choose the content X, a blinking star map will be superimposed to the raw video data stream in MetRec. This allows you to check, whether your coordinate conversion is working properly. All stars must be exactly inside the little circles. The same feature is also available in PostProc (see section VII). 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 (most probable) shower membership for each meteor. The activity period, radiant position, radiant diameter, geocentric velocity and population index 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 each 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. An alternative 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. MetRec will plot the meteor into a star map that can be displayed by choosing content L (only the last meteor is plotted) or P (all meteors are plotted). In addition, MetRec creates a simple backward tracing plot. There are nine different star fields that cover the full northern and southern sky. MetRec prints the meteor trails and backward prolongations showing the probable radiant position for all possible meteor shower velocities. You can display the plot by choosing the content P, or 1..9 for the individual star fields. If there is activity from a known or unknown source, you may recognize it as the convergence point of a number of backward prolongations all intersect at one point. In the end, all nine plots will be saved in one big BMP file under the name given with the TracingImage parameter. Furthermore, an IMO PosDat entry may be created for each meteor. For that you need to set PosDatEntry to yes. The PosDat files are named MMDDdata.DBF and MMDDhead.dbf according to the current month and day. If these files do not exist, they will be created at startup time of MetRec. Otherwise, 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 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 IV). The plate constants are also crutial for the determination of the effective field of view of the camera. For all pixels with are used for meteor detection (i.e. which are not masked out by the input mask), MetRec determines the pixel size and the altitude. Accumulating the sizes of all pixels yields the total collection area of the camera in square degrees. Assuming an altitude of 100 km for the meteor layer, the size of each pixel together with its altitude is transformed into square kilometers. The total collection area, i.e. the area that the camera is monitoring at the meteor layer, is derived by accumulating the area each pixel covers. A camera pointing low in the sky will naturally cover a much larger area than a camera pointed to the zenith. On the other hand, the meteors are more distant and therefor fainter when observed near the horizon. Based on the altitude of a pixel, the distance to the meteor layer is calculated, and a corrected pixel size is obtained by expressing distances larger than 100 km as a reduction of the pixel size. If the meteor layer is at 200 km distance for a given pixel, for example, the intensity will have reduced by a factor of 4 compared to the default distance, which comes down to a loss in limiting magnitude of 1.5 mag. Given a typical population index of 3.0 for sporadic meteors, a loss of 1.5 mag reduces the number of detected meteors by a factor of 3^1.5=5.2. Thus, the size of the pixel is reduced by a factor of 5.2, and the accumulation of all corrected pixel sizes yields the corrected total collection area of a camera in square kilometer. All values are given in the MetRec logfile. The corrected total collection area is one basic parameter that governs the efficiency of a meteor camera, i.e. whether it monitors a small or large fraction of the meteor layer and therefor how many meteors the camera records. The other basic parameter is the limiting magnitude of the camera. To calculate that, MetRec obtains first a noise-free mean image from the input video signal, and applies a threshold to segment stars from the background. The corresponding image can be displayed in MetRec by choosing the content A. In parallel the software calculates at what x/y position in the image there should be a star (based on the same star catalog RefStars is using, and by reverting the plate constant function). At the start of each minute, MetRec determines which of the segmented stars match to stars from the catalog, and which are just noise. The result is displayed with content G in MetRec. The identified stars are counted, and from their overall number the limiting magnitude is calculated in the same fashion as in visual observation. The limiting magnitude is written into an extra file named YYYYMMDD.MAG (according to the current date) in the data directory, and is displayed in MetRec by pressing h. Next the corrected size of each pixel can be further corrected by the difference to the standard limiting magnitude (6.5 mag), once more using an average sporadic population index of 3.0. If the limiting magnitude is 5.5 mag, for example, the corrected pixel size will be reduced once more by a factor of 3.0^1.0. The corrected pixel sizes are multiplied with the effective observing time in the previous minute and accumulated over all pixels, which gives the effective collection area of the camera in square kilometers times hour (corrected for a limiting magnitude of 6.5 mag). The effective observing time and collection area per minute are written into the limiting magnitude file YYYYMMDD.MAG as well, and they are accumulated over the whole night. At the end of observation, the sums are written to the observing statistics of the MetRec logfile. The same procedure is slightly adapted to determine meteor shower specific collection areas. Instead of 100 km, the meteor layer altitude is used, which is calculated from the meteor shower velocity and the radiant altitude. Also, the population index of 3.0 is replaced by the shower specific population index given in the metrec.SHW file. Two more shower-specific corrections are applied to the effective collection area: At first, the distance of each pixel from the meteor shower radiant is computed. From that, the expected angular velocity of shower meteors at that pixel is derived and transformed into a motion in the x/y space during the exposure of one video frame. The exposure time depends on the type of video signal (PAL/NTSC) and whether or not the video signal is interlaced, which has to be specified with the InterlacedVideo parameter in the MetRec configuration file. As the meteor is moving, the light is distributed over more pixels on the CCD chip, hence, for each pixel there are fewer photons available. So the meteor motion results in a further reduced meteor compared to stellar limiting magnitude for the given shower, which is an additional correction factor for the pixel size. Second, the total effective collection area for each shower is corrected by the radiant altitude, because there are fewer meteors when the radiant is lower in the horizon. The meteor shower dependent limiting magnitude and effective collection area is written to the data directory in a set of files named MMDD_SHW.FLX (according to the current date and the IMO meteor shower code). In the end, the number of meteors detected for each shower is divided by the effective collection area to obtain the flux density of the meteor shower, i.e. the number of meteoroids per square kilometers and observing hour, that would yield a meteor brighter than 6.5 absolute magnitude with the radiant at the zenith. The flux values are typically uploaded to the central VMO server in the post-processing step (see section VII), but in case of an expected meteor outburst or a similar event, it can be even uploaded in real-time if the computer is connected to the internet. This is achieved by setting the RealTimeFluxUpload parameter to yes, and by specifying the name of the camera with the CameraName parameter. It refers to an entry in the VMO file, which is described in the next section. During the calculation of the limiting magnitude, the identified stars and their measured position are written in parallel into a newly created reference star file named YYYYMMDD.ref (according to the current date) in the data directory. This way, several thousand or even tenthousand reference star measurents distributed over the full field of view are obtained in a single clear night. Outliers can be removed from that file by running RefStars with the -update parameter as described above. The result is a reference star file that is much more accurate than any manual measurement (as a shere by-product of lm calculation), which can be used for subsequent nights. In other words: It is possible that you let the software run over night and have a look at the fully automatically processed data including radiant plots and meteor shower flux densities at the very next morning. Using PostProc even the post-processing is only a question of minutes (see section VII), which allows you to efficiently run an automated meteor observatory with MetRec (see section VIII). 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 VIII). 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 start 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 Post-Processing your observation ------------------------------------- MetRec calculates all relevant meteor and meteor shower parameters in a single pass. However, in every night there are typically a few false detections, which need to be removed from all the files written by MetRec. That is the task of the PostProc tool. You can start it with postproc [-archive] [-shower] [-count] [-summary] [-posdat] -nosingle] [-noflash] [-nosync] [-noback] [-ref f] [-maxmet m] [-noimage] [-minmag m] [-minvel v] [-minlength l] [-minedge d] [-maxcount m] [-minlm l] [-maxbrk b] [-uploadarc c] [-uploadflx c] [-upload c] [-noflx] [-noint] filename.log The only mandantory parameter is the name of your MetRec logfile. The software will parse the file and display detailed information for 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. 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 and from the PosDat data file (if applicable). The meteor shower flux will be corrected and the shower-dependent flux files as well. If you do not want to delete the meteors 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. Postproc can read up to 10000 meteors at a time. If your logfile contains more meteors, you can increase the maximum meteor number of PostProc with the -maxmet parameter. PostProc has a number of optional parameters that allow you to automatically mark events to be deleted. These are helpful if you have hundred or thousands of false detections due to bad circumstances (e.g. moonlit drifting cloud patches) with a few meteors inbetween. If there are many false detections in short succession, you can batch delete a number of meteors at once with the -maxcount m parameter. If m or more meteors appeared in short succession, they will be deleted automatically. 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 -noimage parameter will cause all meteors without a sum image to be deleted. -minlength l deletes all meteors shorter than l pixel, and -minedge d all meteors that are closer than d pixel to the edge. When -minlm l is specified, all meteors will be deleted that occur when the limiting magnitude is worse than l. When leaving Postproc, the limiting magnitude profile of the night, the effective observing time and the times when meteors were detected are displayed. Based on these, PostProc proposes to insert breaks for times where the sky was overcasted. A break is suggested if the measured limiting magnitude was less than half of the nominal limiting magnitude of the camera for at least five minutes. If no lm information is available, a break will be suggested when there was no meteor for a longer amount of time. The -maxbreak parameter can be used to adjust, whether smaller or larger gaps without meteors will result in a proposed observing break (default is 60). You can decide, whether or not these breaks are inserted into the logfile and the effective observing time is corrected accordingly. When you saved single frames, the -nosingle parameter of PostProc will delete these. That allows you to save single frames with MetRec just in case you record a fireball or another unusual event that is not well covered by the meteor band, but free the wasted disc space afterwards by deleteing all the useless single frames. You should still set SaveSingleFrames to no or bright if your camera runs in automatic mode, as already a single night with patchy clouds can completely fill up your hard disc and prevent further observations. In a similar fashion, you can delete flash images with the -noflash parameter, clock sync entries with the -nosync parameter, and background images with the -noback parameter. In the end, PostProc will copy and move the post-processed files, PosDat files and tracing images to the data 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. The -count parameter will only update the meteor shower counts in the summary at the end of the logfile, and the -posdat parameter will force the PosDat files to be re-created. If the full observation summary at the end of the MetRec logfile is missing (e.g. because the computer was shut down early), or if the summary is inccorect because you restarted MetRec during the observation, you can re-create the observation summary with the -summary parameter. 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, and that the limiting magnitude information, flux densities measures and the newly created reference star file should be deleted, as they are typically wrong in this case. If you want to join the IMO Video Meteor Network, you observations and your flux data need to be uploaded in regular intervals to the IMO server. Also that task is automated with PostProc as long as your computer is connected to the internet. For preparation, you need to edit the postproc.VMO file and give details about your camera. To upload flux data, you simply have to add the additional parameter -uploadflx with your camera name. PostProc will look for the parameter of that camera in the PostProc.VMO file and upload all relevant flux files by HTTP. The full data directory will all processed files with be upload by ftp to the IMO Network server when use use the -uploadarc parameter with the camera name. Before that, the data will be processed to meet the standard of the IMO network (e.g. no single frames and flash images in the IMO Network archive, only full resolution images), and a warning or error message will be displayed if the flux values are not in the expected range (e.g. because of a poor reference star fit). Both upload are initiated by the -upload parameter and the camera name. Sometimes there is the need to post-process a larger number of observations, e.g. when a new meteor shower list is introduced. Here the non-interactive mode of PostProc is helpful, which is started with the -noint parameter. When this parameter is given, MetRec will carry out all actions specified by the input parameters (e.g. calculation new equatorial coordinates or PosDat files, re-assigning meteor showers, uploading files) without user interaction. So you can run PostProc in batch mode on a larger set of files. VIII Automated meteor observations ---------------------------------- It is possible to run MetRec continuously in a number of nights. You must run the MetRec loader program (metrec.com under DOS, metstart.exe und Win32) 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 [COM1] [COM2] [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 you 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 an 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. Under DOS, that can be achieved 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 disc 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 is started. After the observation, the disc 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. They will be automatically renamed when the observations are post-processed after a while. The same mechanism can be used for the Win32 version of MetRec. An automated start of the software can be achieved by putting Metrec into the AutoStart folder, or by creating a scheduled task for MetRec. IX Meteor shower search and other add-ons ------------------------------------------- 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. The Ref2Txt and Txt2KML utilities allow you to create KML files, which will display the collection area of your camera(s) in Google Earth. Start the first tool with ref2txt reffile [refimage] [txtfile] It will read the given reference star file, ask for a few camera parameters for the plot, and append the output to the default file ref2txt.TXT, or to the text file that you specified as optional parameter. If your camera has a restricted field of view, you should give a reference image in addition. MetRec will let you define, which part of the fov is really used for observations, and display only that part of the field of view. When a number of camera data are collected in the text file, you can convert that into Google's KML format by txt2kml txtfile [kmlfile] The specified text file will be read and the output is written to the default file txt2kml.KML, or the file that you specified. That KML file can be opened directly by Google Earth. It is in the nature of MetRec 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 [-conf conffile] -sol min max [-stepp n] [-stepv n] [-maxd n] [-maxv n] [-alpha min max] [-delta min max] [-vel min max] [-lat min max] [-norm] [-member] [-metcount] [-metdate] [-iter] [-assign] [-posdat] [-list] The list of parameter may get too long for the command line prompt, so you can write them into a configuration file specified by the -conf parameter. The only mandantory parameters are the solar longitude range (-sol) which shall be analysed, 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.imonet.org/database.html for details) and immediately analyse a more than a million meteors. 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 range in right ascension, declination, velocity or latitude of the observing site (e.g. if you know already where the radiant is approximately located), you can fix it with the -alpha, -delta, -vel and -lat parameters. There are two basic algorithms for computing possible radiants. The standard is, that for each meteor and each radiant position / velocity pair the probability is calculated, that the meteor belongs to this radiant. Only radiants that are above the horizon and fit to 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 Laplacian 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 can be adjusted by the -maxp and -maxv parameters. If -metcount or -metdate is specified, RadFind will not print the original meteor ID from the logfile or PosDat file, but the absolute meteor number in the data set or the date of the meteor instead. 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 next 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. Another 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 distributions. Note that normalized distributions are error prone. If you have a false detection in your data set which is faster than meteors may become, all tested radiant will have a low probability. When this is scaled to one with the -norm parameter, certain radiant bin get an exceptional high probability. A last operations mode activated by the -assign parameter. Here, the radiants are not determined by the software, but the given radiant list MetRec.SHW is read and the meteors are only assigned to these showers. 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: pos= 271.0 / 33.5 +/- 1.4 vel= 46.0 +/- 1.2 : 125.04 / 560 ( 134 + 426 ) / 887.7 ( 211.2 + 676.5 ) (LYR: 269.9 / 34.0, 49) The first parameters are the position and velocity of the detected radiant (alpha=271.0 deg, delta=33.5 deg, vel=46.0 km/s) with corresponding mean squared errors (1.4 deg in position, 1.2 km/s in velocity). They are followed by the accumulated probability of this radiant position / velocity pair in arbitrary units (125.04), and the number of meteors fitting to the radiant (560). In brackets are the number of meteors in the first and second half of the interval (134 and 426, resp.). This probabiliy does not reflect the absolute strength of a meteor shower, as certain showers can be observed better than others (in mid-northern latitudes, for example, the Geminids with the radiant high above the horizont compared to the eta-Aquariids whose radiant rised only in the morning hours). To correct for this, RadFind calculates the observability function of each detected radiant (i.e. what are the chances that meteors of this radiant can be observed at the given observing site and solar longitude interval) and weights each meteor accordingly. The weighted accumulated meteor counts (887.7) broken down for each half interval (211.2 and 676.5, resp.) are given next. If the detected radiant can be linked to a known shower from the MetRec.SHW file, the listed radiant (LYR) together with its parameters (alpha=269.9 deg, delta=34.0 deg, vel=49 km/s) 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] [-maxpunk n] [-maxv n] [-maxunkv n] [-maxs n] [-maxsunk n] [-mind n] [-mindunk n] [-ext min max] [-strenth] [-html] 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. To put higher thresolds for unknown meteor showers (i.e. those not listed in the metrec.IAU file), use the -maxpunk, -maxvunk, -maxsunk, and -mindunk parameter, respectively. The -strength parameter will sort the list of meteor showers by strength and not by solar longitude. The -hmtl file will create a set of HTML files from the results ready for internet published. The output file of StrmFind may look as follows: Shower # 62 ------------ IAU meteor shower number : 6 IAU meteor shower code : LYR IAU meteor shower name : April-Lyrids IAU meteor shower status : e sol long interval (IAU) : 28 - 36 ( - ) date interval (IAU) : Apr 18 - Apr 26 ( - ) mean sol long / sol long at max (IAU) : 32 / 32 ( 32 ) mean date / date at max (IAU) : Apr 22 / Apr 22 ( Apr 23 ) number of radiant points : 9 number of meteors : 4234 median rank : 1 accu probability at max : 243.00 normed meteor number at max (rel / spo): 4865 ( 20.5 / 15.7 ) ------------ mean vel / vel at max (IAU) : 46.8 / 47.0 ( 48.4 ) ------------ mean alpha / delta (drift) : 272.3 / 33.2 ( 0.1 / 0.0 ) alpha / delta at max : 272.5 / 33.0 IAU alpha / delta at max (drift) : 272.7 / 33.4 ( 1.2 / 0.2 ) ------------ mean ecl lon / lat (drift) : 273.5 / 56.6 ( 0.2 / 0.0 ) ecl lon / lat at max : 273.8 / 56.4 IAU ecl lon / lat at max (drift) : 274.1 / 56.8 ( 1.9 / 0.1 ) ------------ sol date rank equatorial ecliptical meteors norm met num long alpha delta +/- lon lat vel +/- val abs rel abs rel spo 28 Apr 18 1 271.8 34.5 1.9 272.8 57.9 47.0 1.7 15.30 115 5.3 214 1.5 1.1 29 Apr 19 1 270.6 34.5 1.8 270.9 57.9 45.0 1.6 24.70 173 7.2 285 1.8 1.4 30 Apr 20 1 270.8 34.0 1.7 271.2 57.4 46.0 1.2 61.83 506 18.2 807 4.3 3.3 31 Apr 21 1 271.6 33.5 1.4 272.4 56.9 46.0 1.1 139.13 1326 40.1 2122 9.6 7.4 32 Apr 22 1 272.5 33.0 1.2 273.8 56.4 47.0 1.1 243.00 3025 84.9 4865 20.5 15.7 33 Apr 23 1 272.5 33.0 1.2 273.8 56.4 47.0 1.1 246.05 2490 84.0 3972 20.1 15.5 34 Apr 24 1 273.6 33.0 1.4 275.5 56.4 47.0 1.3 83.11 571 23.9 919 5.8 4.5 35 Apr 25 1 274.5 32.5 1.6 276.8 55.8 48.0 1.4 26.60 151 6.5 249 1.6 1.2 36 Apr 26 48 269.2 37.0 2.2 268.7 60.4 55.0 2.2 2.77 42 2.3 73 0.6 0.5 =========== It is the 62nd shower that was detected, which is found in the solar longitude interval 28 to 36 degrees (corresponding to April 18-26). It matches to the shower number 6 in the official IAU working list of meteor showers, namely the April-Lyrids (LYR) which has the status of an established shower (e). There is no interval of activity given by the IAU. The mean solar longitude of all meteors is 32 degrees (April 22), which matches the solar longitude interval with highest activity and the time of maximum given by IAU. 9 independent radiant point were found for this showers, and an overall of 4234 meteors assigned to it. The median rank was one, i.e. in their activity interval the Lyrids were most of the time the strongest source in the sky. The accumulated probability at the time of maximum was 243, and the number of meteors at maximum (corrected by the observability function) was 4865. Normalized by the sporadic activity in the same time interval, the shower has a strength of 20.5, and if the annual variation of sporadic activity is also taken into consideration, the peak activity was 15.7. This number is called the video rate - it approximates the visual ZHR of the shower. The average velocity of the shower was 46.8 km/s, which is close to the velocity measured at the date of peak activity (47 km/s). The IAU shower list gives 48.4 km/s. The average radiant position was alpha=272.3 deg and delta=33.2 deg with a drift of 0.1 deg in right ascension and 0.0 deg in declination per degree solar longitude. At the peak, the observed position was alpha=272.5 deg and delta=33.0 deg, whereas the IAU gives a radiant position at peak of alpha=272.7 deg and delta=33.4 deg with a drift of 1.2 deg in right ascension and 0.2 deg in declination. The next three lines give the same values transformed to ecliptical coordinates. Finally, the values for each indivdual radiant point which was assigned to that shower are given in detail. At solar longitude 28 deg (April 18) the radiant was the strong in the sky (rank 1) and located at at alpha=271.8 deg / delta=34.5 deg with a mean squared position error of 1.9 degrees. That translates to an ecliptical longitude of 272.8 deg and latitude of 57.9 deg. The observed velocity was 47 km/s with a mean squared error of 1.7 km/s. The accumulated probability was 15.30 and 115 meteors were assigned to that radiant. That gives a relative strength of 5.3. If the observability function is taken into account, the corrected meteor count is 214, which yields a relative strength of 1.5 or a video rate of 1.1 (considering also annual sporadic variations). So the last column presents the activity profile of the shower 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 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. X 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. * grab03.gif: The live greyscale histogram may help you to find the right brightness and contrast settings. GrabSeq: * grabse01.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 intensifiers 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. A grid helps to match the star catalog with the reference image more accurately. * refsta05.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. * refsta06.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. In the upper right window, the stars from the star catalog are superimposed to the live video stream. They match perfectly to the stars in the life image. * metrec02.gif: MetRec at run time in standard configuration. Up left is the current video frame, up right one of the backward tracing plots. In the lower left window, the last detected meteor is displayed. The lower right window shows the position of this meteor among the stars. * metrec03.gif: After reconfiguration of the display, the upper right window shows the mean subtracted image, the lower left window the regions of interest, and the lower right window the sensitivity image. * metrec04.gif: After reconfiguration of the display, the upper right window shows the flatfield, the lower left window the plot of all meteors, and the lower right window the coordinate grid. * metrec05.gif: After reconfiguration of the display, the lower left window shows the segmented stars, and the lower right window the limiting magnitude plot. The history of the limiting magnitude is display below, and the number of segmented (in bracket) and identified stars as well as the corresponding limiting magnitude are given in the status window. * metrec06.gif: Space or any other key without a special function activates the screen saver, which displays all MetRec hot keys. * metrec07.gif: When the recognition is suspended, different hot keys can be used. PostProc: * post01.gif: PostProc at run time. All information about one detected meteor is displayed. The left window shows the corresponding information from the logfile. * post02.gif: A line or two arrows can be drawn to mark the detected position of the meteor. * post03.gif: If the meteor band or single frames are stored, the meteor can be displayed frame by frame. * post04.gif: In the inverted view, faint meteors become better visible. * post05.gif: You can superimpose the expected position of stars and the meteor in the field of view to check, whether the coordinate transformation was working properly. * post06.gif: Upon leaving PostProc, the limiting magnitude is plotted over time to check, whether breaks may be inserted. ShowBND: * show01.gif: ShowBND at run time. The sum image is shown and the meteor band is inserted dynamically. Above the image is the meteor band centered at the current shutter break. GrabStrm: * grabst01.gif. GrabStrm at run time. There are different options to define how many video frames are combined by image, and how they are combined (min, mean, max). LightCrv: * light01.gif: In this example, the brightness of three stars is measured in parallel with LightCrv. The measurement area is defined by the inner circle. The area between the middle and the outer circle is used to define the local background brightness. The graph on top shows the brightness ratio for one of the selected stars. XI 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 XIII. 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 your MetRec configuration file yyyymmdd.cfg. If you have set the AutoConfiguration parameter to yes, you only need to update the reference star file and possibly 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. 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. Otherwise you will end up 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 VIII). 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, the flux files and the data directory! Always use PostProc which will do all that for you. Check whether your tracing image shows interesting radiant features. If not, the tracing file should be deleted. At the end, PostProc will move the post-processed logfile, the updated PosDat files, the configuration file and the tracing image (if it contains interesting data) to your data subdirectory. If you measured a new reference image, it should be moved there as well. This directory contains already a copy of the original logfile, which is now overwritten. If you used generic names, the logfile and config file will be renamed autmatically to yyyymmdd.log and yyyymmdd.cfg, respectively. If you have both an interesting tracing plot and a new reference image, rename the latter one to yyyymmdd.bm2. XII Additional utilities ------------------------- Over time, additional tools have been developed that are not directly related to meteor observation. GrabStrm is a utility to create time lapse movies from long recordings. It was developed after the Leonid storm of 2001 to condense 6 hours of video recordings into a 3 min animation. GrabStrm grabs a number of video frames (configured at run time), combines them with a method also configured at run time (maximum, mean, and minimum pixel values of all frames), and stores them as a BMP file. Later, AVI files can be created with third party software from the BMP sequence. To start GrabStrm, type grabstrm {-1 | -2} {-pal | -ntsc} [-dev d] [-full] [-br b] [-con c] [-int i] [-meth m] [-ts t] [-dark darkfield] As always, the first parameters are the frame grabber and video signal type, and the frame grabber device number. The optional parameter -full will force that full resolution video frames are digitized, the other optional parameters are start values for brightness, contrast, integration, and method of frame combination. Filename is a three letter prefix, to which a five digit video frame number is added. -ts will print a time (1) or date & time stamp (2), and -dark will subtract a dark field during grab. LightCrv is a utility for measuring the brightness of up to five objects (typically stars) in the video data stream. It was created to measure the light curve of a star occulted by a minor planet. Start it with lightcrv {-1 | -2} {-pal | -ntsc} [-dev d] [-full] [-ti] [-obj n] [-ref f] [-track t] [-br b] [-con c] [-dark darkfield] The first parameters describe the frame grabber and video signal type, and the frame graber device number. The optional parameter -full will force LightCrv to analyse full resolution video frames. If a Cuno time inserter is superimposed to the image, you can force LightCrv to evaluate that clock by the -ti parameter. -obj defines how many objects you like to measure in parallel, and -ref is the frame refresh rate similar to the DisplayRefreshRate of MetRec. Typically the recording will be unguided, so the stars are slowly drifting in the field of view. -track allows you to track the object automatically, whereby -track 1 is a low tracking rate and -track 3 will track the objects very fast. The last two optional parameter -br and -con are the start brightness and contrast. Together with -track, they can also be modified at run time of LightCrv. As always you can subtract a dark field with the -dark parameter. Once you have started the tool, you will see the live video stream and three circles. You can use the cursor keys to move the circles within your field of view and center them at the object to be measured. All pixels within the inner circle belong to the object that shall be measured. The ring between the middle and the outer circle defines the background area. You can modify the size of these three circles with the u/U, v/V and w/W keys to adjust it to your needs. The light curve that is displayed in real time above the live image shows the ratio of the object to the background brightness (both single values and an averaged graph). If you specified more than one object, you can press A to switch to the next object, and adjust the three circles for that as well. Once you finished, you press any key and LightCrv starts to store the measurements in the output file. The format of the text file is self-describing: Frame Time Position 1 Brightness 1 Position 2 Brightness 2 # [s] X Y Object Backgr. Ratio X Y Object Backgr. Ratio 45 P. 363 P. 45 P. 403 P. ====================================================================================== 1 0.04 49 14 3821 20191 1.53 288 93 3642 25825 2 0.08 49 14 3845 20124 1.54 288 93 3580 26285 3 0.12 49 14 4044 20243 1.61 288 93 3633 25955 4 0.16 49 14 4047 20159 1.62 288 93 3687 25685 ... The first two colums give the video frame number and the time since start in seconds. Object #1 was located at x/y position 49/14 (the position did not change in that short time interval). The object was composed of 45 pixels, the background of 363 pixels. The 5th column gives the pixel sum for the object, the 6th column the pixel sum of the background, and the 7th column the ratio of both values weighted by the pixel sum. The next columns give the same values for the second and further objects. XIII 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 and all other tools. The programs have been tested and retested, and debugged, by myself. To the best of my knowledge, they have no bugs, will not cause any corrupted or loss of data on a properly configured PC. To the best of my knowledge they will not do anything more than what is documented herein. However, I guarantee nothing, except that these programs 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/869437 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. Further information about MetRec can be found in the MetRec Wiki at http://www.imo.net/wiki Information about the IMO Video Meteor Network can be found at http://www.imonet.org. If you would like to join the network, just drop me a mail.