algorithm for meteor detection

[tilvi]

I have been thinking of having an algorithm for the detection of meteors in the NSL images and also do a kind of averaging(PSF) along the meteor's path.
Heres I have a rough idea about this.

1) Subtract two FITS files (one with meteor & other frame on any other night but with same sidereal time). This leaves us with the subtracted image with only meteor (assuming the background is same in the two frames and even if it is different, it can be taken care of).

2) Visually construct a box (either square or rectangular) enclosing meteor. And note the four corners of this box.

3) Average all the pixel counts along the columns.

4) Count the number of pixels which has counts greater than average background. (say Xcounts)

5) Average all the pixel counts along the rows.
6) Repeat 4 and say Ycounts

7) Compare Xcounts & Ycounts. Plotting the counts along the greater pixels (X counts or Ycounts), gives us the light curve.

comments?

[tilvi]

Here is the trial run from the algorithm mentioned above. I did not do the subtraction part from the above procedure. Note that in the fitsview, i have not selected the whole meteor path due to curve track.

The first image shows the output from the algorithm and the 2nd image shows one derived from the fitsview





comments ?

[gtancredi]

Dear Tilvi

I have produced a fireball detection algorithm that runs for CONCAM images.
My algorithm is an application of the Hough transform. It works better for long trails but trails as short as 10-20 deg. are detected.

We have not writen a paper yet, but I have already made some presentations about it.
If you want I can send you the poster we present at the last Meeting of the Metoritical Society (the only problem is a 3Gb file).
The big problem for CONCAM images is that you can not distinguish between plane trails and meteors.
Cameras for meteor detection usually have some kind of chopper in from of the camera in order to get a trail with short dashes. You can then measure the velocity.
Another drawback is the fact that you only have one camera per site, therefore you can not do triagulation. With two simultaneous observation you can compute the pre-entry orbit of the meteor.
This is a crucial information for meteor research.

You asked:
> I would like to know if there are any
> standard procedures for reductions of CCD detected meteors.
I do not know if I answer your question with my previous comments.
In case that your question refers to photometric measurements, I do not know any standard procedure. My suggestion is to take the peak of the brightness along the trail.

There is a software to detect meteors in Video cameras (MetRec - http://www.metrec.org) but I do not know how they compute the meteor magnitude.
Since they are using video images, this should be like the instantenous maximum brightness, similar to my suggestion.

Gonzalo


PD: I posted this answer on the Asterisk to continue the discussion.
We may get some comments from other colleagues.
--
Gonzalo Tancredi
Dpto. Astronomia Tel : (598-2) 525 86 24/25/26 int. 319
Facultad Ciencias Fax : (598 2) 525 05 80
Igua 4225 Email : gonzalo@fisica.edu.uy
11400 Montevideo - URUGUAY http://www.fisica.edu.uy/~gonzalo

[makc]

...comments?

I have problems with english, so perhaps I've misunderstood you. Also, I come from digital image processing backgrounds (Kodak POS photo voodoo ), so I will use other words here.

If I understand you, you average "important" pixel values in X and then Y directions, and then use one of these two sequences instead of "light curve" along the path?

I.e. this is actually "light curve" along the "projection" of the image onto one of bounding box sides?

If so, it may or may not serve your purpose, but it certainly will not coincide with the one you get with fitsview...

In return, I would like to know the way you are going to use curve for detection, as it relates mentioned "meteor-vs-plane" problem. Are you suggesting that "light curve" of meteor would have something that will make it distinct from, say, "light curve" of plane trace, etc?

Regards.

[tilvi]

...comments?

I have problems with english, so perhaps I've misunderstood you. Also, I come from digital image processing backgrounds (Kodak POS photo voodoo ), so I will use other words here.

If I understand you, you average "important" pixel values in X and then Y directions, and then use one of these two sequences instead of "light curve" along the path?

I.e. this is actually "light curve" along the "projection" of the image onto one of bounding box sides?

If so, it may or may not serve your purpose, but it certainly will not coincide with the one you get with fitsview...

In return, I would like to know the way you are going to use curve for detection, as it relates mentioned "meteor-vs-plane" problem. Are you suggesting that "light curve" of meteor would have something that will make it distinct from, say, "light curve" of plane trace, etc?

Regards.

I think you are right in the sense that the algorithm I suggested will not be able to differentiate between the plane track and the meteors . And here one more thing I should have mentioned is that this algorithm is not for the detection of meteors but for getting the light curve. It is assumed that meteor is already detected. Sorry for the wrong topic name.
For me it looks like , both, fitsview and this algorithm should give the same light curve since both works in the same way, i.e. getting the counts along the meteor track. The only difference is that I am averaging the counts column-wise and row-wise to know the projection of the meteor.
?

[makc]

...but "the only difference" is still a difference...

Plus, if there would be no, what would be need in re-inventing it? I assumed it was all about detection based on curve, and so your stuff would be "easier way to go" or something...