Now that the question of capturing the data with the RPi2 is resolved, a question of data compression arises. If you were to save uncompressed video on a disk using the current setup (720x576 @ 25FPS), during an average night of 12 hours you would end up with >400GB of raw data.

So it is clear that some kind of compression should be used. Usual lossy video compression methods are trying to reduce redundancy in video data to suit human vision. Regarding video meteors, the problem is more complex - you need to do your best to preserve meteor features (spatial and temporal resolution and pixel intensity) so you can do meteor detection later.

Usual video meteor setups have wide-angle lenses and relatively small resolution cameras. Our setup has a 64°x48° field of view and 720x576 camera resolution, which gives a plate constant of about 5 arc minutes per pixel. If you consider that an average meteor is at about 100km distance, one pixel corresponds to ~150m at that distance. This means that the real position of the meteor is actually quite uncertain and you shouldn’t compromise the spatial resolution any further.

The method we use was first developed by Mark Vornhusen for his Skypatrol software, and later extended by Peter Gural for use with NASA CAMS meteor network. In essence, you are taking 256 raw video frames (10.24s at 25FPS) and saving only the brightest pixels as you can assume the meteor was the brightest event in that portion of time. In addition, you track when the brightest pixel occurred (coded as an 0-255 intensity which corresponds to the frame number), the average pixel values and their standard deviation.

compressed image of a fireball

reconstructed video from compressed image

Thus you have reduced 256 frames to just 4 images (1:64 compression ratio) which you can use for meteor detection as the standard deviation can help you determine what is a meteor and what is the background.

tresholding (used for detection)