meteor detection

[tilvi]

We are trying to detect meteors from NSL images and especially during the Perseids 2004 event.
Heres the procedure I followed to get the light curve.


1) F1 (a FITS file with a meteor ) and F2 (another FITS file with same
sidereal time ) are selected.

2)The pixel positions x1,y1 and x2,y2 for start and end of the meteor
trail are noted. These x,y pixels are 3 sigmas greater than the background.

3) F1-F2 gives the subtracted FITS image and removes any star( if present) on the meteor track.

4) Using only single counts (green line on the meteor) along the track of the metoer , we get the light curve.

Heres the subtracted image and the light curve.


This is done using FITSVIEW.

comments?

[lior]

Tilvi,

This sounds great, and very important too. I have the following comments:

1. I believe that the light curve should be different for almost each meteor. The reason is that unlike stars, the light curve of a meteor is affected by the angle of the meteor towards the camera. For instance, if the meteor direction is exactly across the camera, it will look like a full long trail. However, if the meteor direction is exactly towards the camera, it will look like a very bright star, and no trail will be seen (what Dr. Brosch defines "flasher"). Most meteor trajectories are expected to be somewhere in between these two extreme cases. Therefore, two light curve might look completely different at concam even if the meteors are the same.

2. I'm not sure about looking only at the green line. The "PSF" of the meteor is definitley not sub-pixel. I would suggest to do some kind of averaging (I'm not yet sure which) for each pixel in the trail. If you don't do that, then the results are highly depended on the position of the trail within the pixel, which means a great deal of randomness. That is similar to the randomness that we get for C1 in the photometry files.

[tilvi]

Tilvi,

This sounds great, and very important too. I have the following comments:

1. I believe that the light curve should be different for almost each meteor. The reason is that unlike stars, the light curve of a meteor is affected by the angle of the meteor towards the camera. For instance, if the meteor direction is exactly across the camera, it will look like a full long trail. However, if the meteor direction is exactly towards the camera, it will look like a very bright star, and no trail will be seen (what Dr. Brosch defines "flasher"). Most meteor trajectories are expected to be somewhere in between these two extreme cases. Therefore, two light curve might look completely different at concam even if the meteors are the same.

2. I'm not sure about looking only at the green line. The "PSF" of the meteor is definitley not sub-pixel. I would suggest to do some kind of averaging (I'm not yet sure which) for each pixel in the trail. If you don't do that, then the results are highly depended on the position of the trail within the pixel, which means a great deal of randomness. That is similar to the randomness that we get for C1 in the photometry files.

During our discussion yesterday, Dan came with idea that we can try taking profiles at the two edges of the meteor and one at the centre.
I have these light curves below taken by changin the x,y pixels at the start and end of the meteor. It is seen that the light curve peak slightly shifts, may be by 1 pixel.
x,y positions are follows
[204,523]:[218,539]
[203,523];[218,539]
204,524];[218,540]

And as Lior said, we can try averaging, but I also am not sure what type of averaging. Because averaging would introduce another error of double counting of pixel values.

Another concern here is that while subtracting the two frames, one with meteor and the other with the same sidereal time, if there is significant change in the background itself, it might affect the light cruve. But i think the trend would be the same, but the actual counts might differ.

thoughts?

[tilvi]

I am trying to calculate ZHR (Zenithal Hourly Rate) for Perseids 2004 from NSL images.
Following is the simplified formula for calculating ZHR ( for LM <6.5)

ZHR=(HR * r^(6.5 -ML)/Sin(A)

HR= Meteors seen for 1 hour
r= Population index(~2.6 for Perseids)
LM=average limitiing magnitude for that hour
A=Showers radiant above the horizon during the observation time.

Since meteor survive for ~2 sec, we need to consider the limiting magnitude of CONCAM for 2 sec exposure ( and not 180 sec exposure).
Is there a way to know the limiting magnitude of CONCAM for 2 sec exposure?

[RJN]

Tilvi,

First, please see this thread discussing likely NSL results from different exposure times for a meteor shower: http://nightskylive.net/asterisk/viewtopic.php?t=32

There is a very simple calculation that can be done to estimate an effective CONCAM limiting magnitude for meteors. Assume that meteors are all well above background (beta = -1 in the above thread), even at the "limiting" magnitude. Then the difference in limiting magnitude for a 180 sec exposure and a 2 sec exposure is

dm = 2.5 * log_10 (180 s / 2 s) ~ 5 magnitudes.

So if the limiting magnitude in the center of a CONCAM3 frame (zenith) is sixth magnitude for sources that are always on, the limiting magnitude for source that is only on for 2 sec is first magnitude.

A web search shows that a typical meteor duration is actually more like 0.4 seconds. Plugging this into the above equation yields dm = 6.6, meaning the dimmest meteor visible to a CONCAM3 has a magnitude closer to -1 -- a fireball. To be more accurate, one should redo this including explicitely including the effect of the accumulating background and that detection occurs at some sigma over the background.

- RJN

[tilvi]

Tilvi,

First, please see this thread discussing likely NSL results from different exposure times for a meteor shower: http://nightskylive.net/asterisk/viewtopic.php?t=32

There is a very simple calculation that can be done to estimate an effective CONCAM limiting magnitude for meteors. Assume that meteors are all well above background (beta = -1 in the above thread), even at the "limiting" magnitude. Then the difference in limiting magnitude for a 180 sec exposure and a 2 sec exposure is

dm = 2.5 * log_10 (180 s / 2 s) ~ 5 magnitudes.

So if the limiting magnitude in the center of a CONCAM3 frame (zenith) is sixth magnitude for sources that are always on, the limiting magnitude for source that is only on for 2 sec is first magnitude.

A web search shows that a typical meteor duration is actually more like 0.4 seconds. Plugging this into the above equation yields dm = 6.6, meaning the dimmest meteor visible to a CONCAM3 has a magnitude closer to -1 -- a fireball. To be more accurate, one should redo this including explicitely including the effect of the accumulating background and that detection occurs at some sigma over the background.

- RJN

I calculated ZHR using 2 sec exposure which gives limiting magnitude (LM) ~1. ZHR (Zenithal Hourly Rate) turns out to be >1000, which is not true for Perseids 2004. ?

values: A=45, LM=1, HR=4 (~ 4 meteors/hour seen at MK on Aug 12 )

http://www.imo.net/

comments?

[Vic Muzzin]

Tilvi
I think your limiting magnitude is inaccurate. It might be interesting to find an accepted count rate for this years shower and emprically determine CONCAM's limiting magnitude for meteors.

[nbrosch]

Tilvi:

I suggest you look at our recent work astro-ph/0409186 that deals with meteor light curves. I like your idea of subtracting one frame from another at the same ST; you may even create a ST template by median-filtering a number of frames at the same ST and use this to subtract fromthe frame with the candidate meteor. I suggest using the entire light contribution for the meteor not only the "spine" represented by the line profile. To obtain that, enclose the meteor track with a rectangular aperture aligned with your line. "Collapse" the light contribution onto the long dimension of the box to obtain a vector. The light distribution along this vector is what you are looking for.

What does worry me about this procedure is the change in linear scale with position wrt the horizon: a pixel means more km when a meteor is closer to the horizon. Given that meteors hardly slow down, except near the end of their luminous track, this means that the pixel number along the line you plot the brightness distribution of does not have equally-spaced sampling. The tick marks are not at equal time intervals.

Cheers,
Noah Brosch

[tilvi]

Tilvi:

I suggest you look at our recent work astro-ph/0409186 that deals with meteor light curves. I like your idea of subtracting one frame from another at the same ST; you may even create a ST template by median-filtering a number of frames at the same ST and use this to subtract fromthe frame with the candidate meteor. I suggest using the entire light contribution for the meteor not only the "spine" represented by the line profile. To obtain that, enclose the meteor track with a rectangular aperture aligned with your line. "Collapse" the light contribution onto the long dimension of the box to obtain a vector. The light distribution along this vector is what you are looking for.

What does worry me about this procedure is the change in linear scale with position wrt the horizon: a pixel means more km when a meteor is closer to the horizon. Given that meteors hardly slow down, except near the end of their luminous track, this means that the pixel number along the line you plot the brightness distribution of does not have equally-spaced sampling. The tick marks are not at equal time intervals.

Cheers,
Noah Brosch

Dr Noah
Thanks. Infact I had gone through your paper on the meteor light curves and it has really given me some insight. Dr Nemiroff forwarded the link. Also, I don't know if I missed that, I couldn't find the spatial resolution of the video frames in your paper. I guess for CONCAM we can resolve only till 11 arcminute. I was thinking of constructing the light curves by assuming a constant velocity for Persieds. I got a few papers & books which gave these values. But still spatial resolution might be another limiting factor to get good light curves and also the parameter deduction such as symmetry parameter, might be very sensitive to start & end postion of the meteor.

[nbrosch]

Tilvi, our cameras normally use a lens that yields a field of view of 6 by 8 degrees. The frames are regular PAL TV, thus some 520 pixels or so across a frame. This gives the scale, which is about one arcmin per pixel.
Noah Brosch

[tilvi]

Atleast on one occassion during Perseids 2004, NSL captured a fireball which clearly supports (?) the theory of fragmentation of particles during the entry of meteors into the atmosphere. Don't know whether its caused by different pieces held together or one piece fragmented into many.
Dr Noah also mentions this in his recent paper on meteor LC curves.



Below are the plots for the counts.
1) Shows counts along the full path
2) Shows counts before the final peak.