**************************************** * MetRec - Meteor Recognition Software * * Version 5.3 2016/05/26 * * 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 / DVD 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. During recognition, the current input signal, preliminary results of the recognition process (e.g. mean subtracted image, regions of interest, segmented and identified stars, ...) and the system state are displayed at the monitor. II Hardware requirements -------------------------- Metrec comes in three version. The DOS version runs under plain Dos as well as MS-Windows 95 and 98. In case of Win 95/98, do NOT start it in a Dos but restart Windows in Dos mode instead. Only 32 bit Windows versions are supported, and the Win7 version requires that a Matrox framegrabber is installed on the same computer. So you cannot run the Win7 version on a notebook even if it is only used for data post-processing where not framegrabber is required, for example. MetRec is adapted to 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. Under Windows, you can install up to four framegrabbers and run four instances of MetRec in parallel on one computer, given that sufficient CPU power, RAM and bus bandwidth is avilable. In the following we consider the default configuration with one framegrabber. The program expects a PAL or NTSC video signal at the frame grabber input. A PC with a 700 MHz processor is about the minimum equipment. For good recognition performance a CPU with at least 1 GHz (DOS/WIN32) clockrate is advised. MetRec requires at least 32/256 MB (DOS/WIN32) of RAM, but 256/1024 MB (DOS/WIN32) are recommended. The software expects a graphics card with at least 1 MB of 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 8, 10, 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 Player, 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 software 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. A software installtion is not necessary - simply copy all the files into a dedicated working directory. After you have installed the frame grabber you need to install the Matrox Meteor driver under Windows 95/98/XP/7. MetRec comes with the Driver98.ZIP/DriverXP.ZIP/Driver7.ZIP archive. In case of Win7, you need to run the M900U64B06x32.exe in addition to the regular setup.exe installer. 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 if you see a live video image. You should save 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 (which may be smaller than a video frame), but that of the video frame as such (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 variable light sources (e.g. a clock or moving terestrial objects) in your video image, you need to prepare an input mask (see section IV) to omitt 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 (>=256 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 parallel 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. At first, 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, if it is lower than the full rate of 25/30 frames per second (PAL/NTSC). 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 best 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. Activate the screensaver with any unconfigured key to get a list of available options. 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 a 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 image will be saved as an uncompressed 8 bit BMP file of the required size. To find the best 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 normally choose the same brightness and contrast settings when grabbing the dark field and the reference image (see section VI). Only when the video image is too dark after subtraction it is ok to lower the brightness of the dark field. To obtain the dark field, you need to close the lens and cover the housing 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 processed. 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 correctly computes the field of view, 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 only see random noise when you display the resulting image (which is highly enhanced in contrast) 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 (ROIs) are extracted from the flatfielded mean subtracted image. These are the pixels with the highest brightness values. They can be displayed in real time 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 by 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 the camera so that all stars shift and suddenly became visible in the mean subtracted image, by a dropout of the VCR, or by moonlit clouds drifting fast 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 saves all of its parameters. Finally you can specify with MinimumFrameCount, on how many frames a meteor has to be detected before it is accepted. 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 specific events 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. These 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 evenly 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 by 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 specify with FloorThreshold the minimum allowed recognition threshold. Beside other run time parameters, 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 or DVD, you can set TimeBase to three and supply the start time of the tape / DVD under VideoTapeStartTime. Then the software uses that time. 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 seconds 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] 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 the EU, 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, PosDat and flux 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 convention: If the observation started between midday and midnight (i.e. in the afternoon / 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). One option to correct for this effect is the TimeDriftCorrection explained above. Alternatively 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 still 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 minutes. Set ClockSyncRate to 0 if you want to correct the clock only once at startup. If MetRec runs under Windows and your 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. Note that certain NTP servers require registration at costs, otherwise they will sporadically provide a wrong time. You can suspend the recognition temporarily 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 when 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. Another way is to normalize the mean and variance of the video image before processing. The current mean brightness and the variance are displayed on the left side. With the VideoMean and VideoVariance parameters you can define to which values the video signal shall be normalized. 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, a band that contains the region around the meteor is saved from every single frame. * If you set SaveSumImage to yes, 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 disk 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 or other video 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 controlled 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 and a short text 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. The optional text can be given by the TimeStampText parameter. 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 images 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 is strongly advised and 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 shot 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. The StartScript and StopScript parameters may be of help to control external hardware / software as well. With StartScript you can specify a script or program that will be executed before the observations starts, and StopScript at the end of observation. 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 and extension .BMP 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 disk. 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 cameras, 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 nensure, 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 polar 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. This is helpful, if you obtained a new reference star file during limiting magnitude calculation, and want to delete outliers before you use the new file. 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 increases 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 circle slightly larger than the rectangle (i.e. inivsible). 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 are detected. This setting will later be used as start value 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 11 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 zoom 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 measure 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 with big circles, others with small ones. Once you identified enough stars, you exit 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 measure 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 and vice versa. 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 distance between the frames is also normalized based on a polynomial regression of order 0, 1 or 2 (depending on the number of video frames). The mean squared error of the original and the corrected positions along 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 aligns 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 detections 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 with a unique identifier. 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 integrating 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). Note that close double stars that cannot be resolved by the cameras as counted as one star. 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 i the status window and the history window in the lower right corner by pressing h. For flux density calculation, the size of each pixel is now further corrected by the difference between the current and 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 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 (normalized to 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, a meteor shower specific 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 are 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). For obvious reason, the population index is not known before the observations - the values given in the MetRec.SHW file are only long-term average values. For this reason, MetRec computes the exponent of a power function and writes it to the MMDD_SHW.FLX file, which can later be used to transform the data to the really observed population index. 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 kilometer 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 if the user adapts the ReferenceStars parameter accordingly. Note that the limiting magnitude calculation is a neuralgic point: If it fails, e.g. because the plate constants are poor of the reference stars are shifted too much, neither flux density nor the population index can be calculated later on, and also the observing breaks by clouds can only be estimated. But how do you now if a reference star file is still of good quality and yields proper lm values? One way is to blink the stars in the life video stream by chosing X in any of the four display windows as described above. However, MetRec also computes the average deviation in x/y and alpha/delta for all identified and nearly identified stars in the field of view, and display the temporal development of these values in the lower right window (press h to switch between different displays). Even more, you can correct for a drift in x/y (e.g. when the camera direction has slightly changed due to thermal stress of the mounting) or alpha/delta (e.g. when there is an offset in time) by setting the PosDriftCorrection entry in the configuration file to 1 or 2. The current correction values are displayed in the graph at the lower right, and also the absolute position error and the corrected position error (i.e. after the correction in x/y or alpha/delta was applied). All values are stored in parallel in a text file YYYYMMDD.POS in the configuration file in order to be available for PostProc later on. Note that the correction will only work for small deviations of a few pixels at most. If the corrected position error is constantly smaller than the absolute error, MetRec will issue a warning at the end of observation and ask you to create a new reference star file. You can take a newly written reference star file from a clear night, remove outliers, and use that file for all upcoming nights until the deviation is getting to a critical value again. 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 message will be printed 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 dusk. 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. To summarize: It is possible that you let the software run over night and have a look at the fully automatically processed data including camera drift, 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). 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] [-regress] [-nosingle] [-noflash] [-nosync] [-noback] [-moveback] [-copydir d] [-movedir d] [-ref f] [-maxmet m] [-noimage] [-minmag m] [-minvel v] [-minframe f] [-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, are the other parameters activate additional functions of PostProc. The software will parse the logfile and show you first for your information all the Warnings that were written to the logfile. Then it displays 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 MOVE subdirectory is created and all of these meteors are moved from your database to this directory. You can select a different name with the -movedir parameter. Alternatively, you can copy the meteor into an extra folder. The default folder name COPY can be changed with the optional -copydir parameter. Sometimes it happens that only a part of a meteor is detected, or that noise at the begin or end of a meteor was also detected. The mean meteor path will be corrupted as positions are used which do not belong to the meteor. MetRec has an outlier rejection routine implemented that should detect and delete such incorrect frames (you can check that by pressing b and see if the displayed line matches to the meteor), but that routine does not always find the right solution. By pressing f while a meteor is displayed you come to the frame measurement mode. There you can correct the position of the meteor in every single frame, reject frames that do not show the meteors or shall not be used for some other reason, and active video frames which have been rejected earlier or whethere the meteor was not automatically detected. With the -regress parameter you can foce PostProc to compute a new fit of all single frames onto a great circle including polynomial regression of the velocity and outlier rejection. 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, or you simply run PostProc multiple times. PostProc has a number of optional parameters that allow you to automatically mark events to be deleted. These are helpful if you have hundreds 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. This way you can delete false detections at times when it was fully overcasted. -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 minutes). You can decide, whether or not these breaks are inserted into the logfile and the effective observing time is corrected accordingly. After the limiting magnitude profile is display, you can have a look at the development of the camera position drift. You can switch between the drist in X/Y, in RA/DE, the position correction that was applied by MetRec (and that will be applied by PostProc if coordinates are re-calculated), and the average position error with and without the correction. All these graphs are for your informatin only. 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 disk and prevent further observations. At startup, MetRec will issue a warning if the free disk space fell below 1 GB. 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. Instead of deleting the background images, you can also move them into a sub-directory BACK by using the -moveback parameter. In the end, PostProc will copy and move the post-processed files and the configuration file 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 incorrect 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 with all processed files with be upload by ftp to the IMO Network server when you use the -uploadarc parameter with the camera name. Before that, the data will be processed to meet the standards 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). If MetRec was used in max resolution mode, the original maximum resolution file will be uploaded in addition. All uploads together 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, PostProc 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 under WIN32) instead of the real meteor detector metrec.exe with the usual command line parameters, e.g. metrec.com [COM1] [COM2] [LPT] 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 by 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. Instead of using the described auto-restat features, you should control both your camera and the computer by a programmable time switch, which starts the hardware in the evening and shuts it 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. Under WIN32, you can use a similar batch file and save it in the autostart folder. choice /T:Y,5 Start MetRec if ERRORLEVEL 2 GOTO END cd metrec metrec.cfg metrec.log :END Make sure that you can automatically logon to the system without the need to enter a username and password (see https://technet.microsoft.com/en-us/magazine/ee872306.aspx). You should also disable automated installation of OS patches, as this may cause your computer to reboot uncontrolled in the middle of a night. Alternatively you can create a scheduled tasks for MetRec. 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. 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 video will be shown both unguided and centered at the meteor head. You can run the display frame-by-frame forward and backward in time. 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 an exhaustive search over all possible radiant positions and velocities. It lists those radiants that fit best to your meteors. StrmFind takes these radiants from different solar longitudes 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] [-maxp 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 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 to restrict the search space and accelerate the radiant search. There are two basic algorithms for computing possible radiants. Both have in common, 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 or the observed angular velocity deviates slightly from the expected velocity, 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 all meteor and radiant position / velocity pair, RadFind determines all local maxima in the probability distribution and lists them in the order of their accumulated probability. If you specify the -member parameter, RadFind will additionally determine, which meteors fit to the radiants found by the software. The maximum error in position and velocity 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 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 / velocity 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 can 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 normalized 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 theoretically become, all tested radiant will have a low probability. When this is scaled to unity with the -norm parameter, certain radiant bin get an exceptionally high probability. A last operations mode is selected 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, vinf=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 mass 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 solar longitude 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 rises 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, vinf=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] [-strength] [-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 differently 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 publishing. 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 MDC 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 MDC. 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 the MDC. 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 MDC 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 strongest 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 at infinity 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. Note 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 critical and examine the results carefully before claiming a new meteor shower. To help you with that task, you can use the Excel file search_shower.xslm. If allows you to find the nearest showers from the MDC working list given a date and radiant position, and to find the best matching radiant obtained by RadFind given a shower from the MDC working list of meteor showers. Last but not least there is a tool that allows you to create panoramic images from meteor showers by combining sum images from one or more cameras and/or nights. To start the tool, type panorama [-res r] [-crop c] [-cra a] [-cde d] [-scale s] [-proj p] [-mean m] [-var v] [-mask m] [-smooth s] [-load l] [-numdir n] indir1 [indir2 ... indir n] outfile.bmp The panorama tool will read and merge all sum images it finds in the given input directory. If you want to combine data from more than one directory, give the number of directories in the -numdir parameter and list all of them thereafter. In the first step, the panorama tool will merge all images internally in rectangular projection. With the -res parameter you can steer the size of the panoramic image. When you specify the -mean and -var parameters, all input images will transformed to the given brightness mean and variance, which is helpful if the background brightness changes by moon or twilight. If the sum files contain hot pixels or bright foreground objects, they will disturb the panorama. To avoid this problem, you can provide input masks in each input directory which masks these regions out, and specify the name of the image with the -mask parameter. The -smooth parameter will smooth the edges of sum images to get a smoother transition from one sum image to the next. Once all the transformations are applied to the input image, and the images are combined in a rectangular projection, you can save the image as is or you can transform the output image to a new projection. With -cra and -cde you can specify the right ascension and declination of the center of projection. If -crop is specified, the resulting image will be cropped. A value of 1 means that the smalltest rectangle is selected which completely circumscribes the panorama (i.e. the panorama is not cut anywhere). When 2 is selected, the biggest rectangle is chosen which is completely circumscribed by the panorama (i.e. the rectangle is completely filled by image data). The -proj parameter lets you choose in which projection the image shall be transformed before it is stored. Currently the following projections are implemented: 0 - rectangular projection 1 - mercator (cylindrical) projection 2 - sinusoidal (cylindrical) projection 3 - mollweide (cylindrical) projection 4 - orthographic (azimuthal) projection 5 - stereographic (azimuthal) projection 6 - gnomonic (azimuthal) projection The -scale parameter modifies the scale of the projection. The resulting image is stored under the given output name. The transformation of a large number of sum images may take a few minutes. If you are not yet sure which projection is the right one, you should first store the image in rectangular projection without further output transformation. In a second step you can load the image with the -load parameter, and specify with -numdir 0 that no further images are be added. Then you can experiment with different projections without having to calculate the rectangular projection repeatedly. 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: At first, the observing site has to be selected from a pre-defined list of loations. * refsta02.gif: After the operation mode and the gamma value have been choosen, the reference date and time need to be entered. * refsta03.gif: A circle has to be placed in the upper right window marking the border of the intensifiers field of view. * refsta04.gif: Now RefStars has segmented the stars in the reference image. The threshold between stars and the background can be adjusted, the result is displayed in the lower right window. * refsta05.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. * refsta06.gif: RefStars during the measurement of the reference stars. The crosshair in the upper right window is automatically placed at the next detected star. The position of the reference stars measured so far is marked with a black cross. The zoom window shows the position of the crosshair at four times magnification allowing you to find the center of the star with sub-pixel accuracy. The corresponding star from the star catalog is selected in the lower right window. The lower left window lists the data of all reference stars measured so far. * refsta07.gif: Pressing 'c' results in a plot of the current equatorial coordinate grid. The size of the displayed reference stars is a measure of their L1O position error: The larger the star, the larger the error. o changes the order of plate constants and yields a different coordinate grid as well as different position errors. The overall mean squared L1O error is given in the data window at left. ClockPos: * clock01.gif: ClockPos at run time. The current video data stream is displayed and a cursor is placed at the next digit to be measured. The digits measured so far are automatically recognized and displayed at bottom. MetRec * metrec01.gif: MetRec at run time. Up left is the current video frame, up right one of the backward tracing plots. The recording comes from the Draconid outburst, so most meteors are Draconids and the backward tracings intersect close to the expected radiant position. In the lower left window, the last detected meteor is displayed. The lower right window shows the position of meteors detected so far among the stars. * metrec02.gif: After reconfiguration of the display, the upper right window shows the mean subtracted image (normalized to enhance the contrast), the lower left window the regions of interest, and the lower right window the sensitivity image. * metrec03.gif: After reconfiguration of the display, the upper right window shows the flatfield, the lower left window the hot pixel plot, and the lower right window the coordinate grid with the position error of the reference stars. * metrec04.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 and identified stars as well as the corresponding limiting magnitude are given in the status window. * metrec05.gif: After reconfiguration of the display, the history of the position drift in right ascension and declination is displayed in the lower right corner. * 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. At startup of the software, all warnings messages from the logfile are printed. * post02.gif: Then all information about one detected meteor is displayed. The left window shows the corresponding information from the logfile. * post03.gif: A line or two arrows can be drawn to mark the detected position of the meteor. * post04.gif: If the meteor band or single frames are stored, the meteor can be displayed frame by frame. * post05.gif: In the inverted view, faint meteors become better visible. * post06.gif: If single meteor positions are in error, you can adjust the position of the meteor in every single video frame. * post07.gif: Upon leaving PostProc, the limiting magnitude is plotted over time to check, whether breaks may be inserted. * post08.gif: Also the position drift in X/Y, Ra/Deand the position error are displayed before leaving PostProc. * post09.gif: You can re-generate the backward tracing plots after you deleted the false detections, and decide if you want to keep the plot or not. Ref2TXT: * reftxt01.gif: In case the active field of view does not cover the full video frame, you can define the borders of the field of view here. 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 dozens 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 IMO 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 (typically 3rd order), 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 and the configuration file to your data subdirectory. 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 video recordings. It was developed after the Leonid storm of 2001 to condense 6 hours of video footage 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 parameters -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-explanatory: 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. You 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. 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 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.