Wyvern, I hate to be the bearer of bad news, but despite the obvious amount of work you have done, I’m not sure you can finish this project in a meaningful way in the time remaining.
First, let me apologize for this project. In my opinion it is too advanced for a high-school student to undertake. Also the writeup is severely lacking on so many counts that it would be a challenge even for students with many more years of experience than you could possibly be expected to have. That this project is to blame for the situation you are now in is not going to be much consolation I’m sure. Second, I did not see Donna’s call for help until today because I have been (am) ill. But I don’t think that a more timely response would really have helped all that much.
There are two huge problems in what you have so far. First, the whole point of this project (not too clearly emphasized I fear) is to compare data taken at different sites. Data from one site does not permit comparisons to be made. This lack will be nearly impossible to remedy in the time remaining. Second, your images for the sky-glow measurements are severely under exposed; not enough photons were collected to see the very dim glow of the night sky (much fainter than is visible to the human eye). Had the exposures been long enough, I doubt you would even see the stars, as they would be totally saturated and contribute very little to the histograms (this is a good thing, since otherwise you would have had to remove all the data points around the brightest stars so as better to see the dim sky glow). Looking at your sample histograms I estimate you would need exposures at least ten times as long as your longest sky-glow exposure (80 rather than 8 sec). Why so long? It may be that the lens of your camera is too small (in technical jargon, the f-stop can not be set to as low a value as 2.8 — the recommended value), or the image detector (CCD) is less sensitive than that of the camera used in the example. Anyway, you need something like an average count of around 100, where the “control” (which should be called the “calibration”) shows that the camera has maximum dynamic range. To remedy this would require getting new images on cloud-free nights. That would need more time than it seems you have.
What is most critically missing from the on-line write-up (I don’t have easy access to back issues of Sky & Telescope) is an explanation of how to use the series of exposures on a white surface. These data are not really a control in the usual sense of that word. They give a calibration of your camera. In an ideal camera, the value of each pixel (PV) would be exactly proportional to how much light fell upon it over the course of the exposure, something like:
PV = k * S * T
where S is the number of photons/sec hitting the detector (unknown), T is the exposure time, and k is a constant set by the camera optics, the detector efficiency, the f-stop setting, and the focus distance.
We know PV and T, thus
S = PV /( k * T)
For this ideal camera, one could measure the relative brightness of the diffuse sky glow from the value of any pixel (they would all be identical), for example to compare site A to site B using the same camera set up and the same exposure time T, we would have
(S at A)/(S at B) = [PV at A]/[PV at B]
and be able to get the relative brightness ratio for the two sites, without ever knowing the value of k, just that it is constant between the observations. That’s good, since k depends on lots of things in complicated ways.
What about a real, not ideal camera? For the real camera, each pixel will be a little different, so we use some measure of what all of them are doing — that is where the average and modes of the histograms of PV come in. I’ll just denote those as <PV> where the <> means average or mode. Worse, the actual PV observed will be distorted from the PV of the ideal camera,
<PV> = f[<PV> ideal]
Luckily, f[] depends on the product S*T rather than S or T alone. (As always, this s not exactly true, especially if the number of photons detected per second it very large; it is true enough for the cases of interest to us here.) We can exploit this observed feature to calibrate out the unknown function f.
<PV calibrator> = f[k * (S calibrator) * (T calibrator)]==g[(T calibrator)]
where I have absorbed the unknown values of k and (S calibrator) into the definition of a new function g. This function g is just what you constructed from your “control” data. To use this calibration, we take an observed <PV> and find the corresponding exposure time on the control field that would have produced that value of <PV>. I’ll call that time the equivalent exposure time, EET. Formally we can “solve” to find EET by inverting the function g, EET = ginverse[PV]. That’s actually easy to do graphically. For a given value of <PV>, we move horizontally over to the curve you made of g[T], then drop down to find the equivalent exposure time EET that would have been needed in the cal setup to get the same count. Of course for this to work you need to make sky observations that are long enough to reach values of <PV> that are in the “nice” part of the curve g[]. From your plot that looks to be from 50 to 200 pixel val units.
(Your exposures reached at most 8 for your longest exposure; that’s too low.) Suppose you had exposed for 80 seconds, then at your first site you would have seen something like <PV> ~80 (at best). Reading across from 80 on your calibration curve I get 0.02 seconds, which would be the value of EET for this site. Suppose you had data from a second site with all the same parameters, also at 80 seconds, and <P> was 120. Following the same procedure I (by eye — hard to do on log plots) yields an EET of 0.04. The ratio of the two EET values is then the ratio of the sky brightnesses of the two sites ( 0.04/0.02 = 2 ).
I see that you took a full set of exposure times at each site. I don’t think that was the intent (I hope not). Next time, if there is one, you only need a single exposure time (something like 10 times 8 seconds might work).
You may be curious about all the points on your sky curves at short exposures that yield the same value, <PV> around 0.5 What is happening is that you are seeing noise in the readout electronics of the CCD image detector. You would see the same thing if you blocked the aperture entirely. You can make your <PV> values more closely adhere to the S*T dependence the calibration technique requires if, as a first step, you subtract this low level from all your data before proceeding further with the other stages. As long as you are using exposures that produce <PV> much greater than 0.5, however, you can safely ignore this defect in the mathematical model of the exposure process.
Once again, my condolences on the way your project went.
