Blog Image

Earthshine blog

"Earthshine blog"

A blog about a telescopic system at the Mauna Loa Observatory on Hawaii to determine terrestrial albedo by earthshine observations. Feasible thanks to sheer determination.

Full moon B-V colour

From flux to Albedo Posted on Sep 14, 2013 09:17AM

I have looked through all suitable images close to full moon (i.e. at high Sun-Earth-Moon angle) and only came up with a few relevant nights, all within 10 degrees of full moon. We were keen to make a colour map across the face for figuring out what colour range is there, and what colours are reflected under BS sunlight, rather than DS Earthlight.

JD2455814: is the best full moon data available — it’s shown on the left. We ran it through our colour pipeline and get a B-V ~ 0.9. The B and V images turn out to be slightly different sizes, which made the colour map hard to produce. Later it has turned out that this may be due to distortions introduced in the shift to align the images at all. Work is proceeding on this.

JD2455905: data taken when we were following an eclipse — Dec 09, 2011, total lunar eclipse. No non-eclipsed images, so nothing useful on the Brightside colour night (we should check the Moon is red though).

JD2456082 is also eclipsed — partially. No useful colour data as we have only eclipsed images. June 3, 2012

JD2455847 looked like a promising night — full moon at an airmass of 1.54. However, when I make a colour map (right panel above), it has a B-V of ~0.4 across the face. Can only assume that the exposure times are wrong in the headers (as has happened occasionally). One corner of the moon is slightlty eclipsed for
some odd reason in one filter only (V) — opposite Tycho. Perhaps we hit
the dome in this filter? These data should clearly not be trusted further.

Brightness of daylight sky

Post-Obs scattered-light rem. Posted on Jul 04, 2013 12:03PM

In V band, extinction is about 0.1 mag/airmass.

The Sun’s apparent brightness is -26.74.

0.1 mag of extinction means that about 10% of the light is taken from the sun and spread over the sky, about 21,000 square degrees. Half of this is scattered out of the atmosphere, half down to make the blue sky.

The integrated magnitude of the sky would then be of order -26.74 + 2.5*log10(10*2) = -23.5.. i.e. 3.2 magnitudes dimmer than the Sun.

Spreading this over half the sky (21000 square degrees or 2.7E11 square arcseconds) gives a reduction in surface brightness by 2.5*log10(2.7E11) = 28.6 magnitudes.

This yields a daytime sky brightness in V band of -24.24+28.6 = 4 mag square arcsecond.

If we have any daytime exposures with the ES telescope — we could check this and get numbers in other bands as well…

Presentation November 2012

Showcase images and animations Posted on May 05, 2013 05:36AM

Presentation at Swinburne (Melbourne) in November 2012

PSF profiles from the NGC6633 images

Post-Obs scattered-light rem. Posted on Apr 07, 2013 09:38AM

The PSF of the VE2-band Arcturus data deviated markedly from the other bands (next to previous post). We check on this further by looking at the PSF profiles of the stars in NGC6633, which were used to calibrate the filters (in this post).

We plot the central flux normalised PSFs in B, VE1, VE2 and IRCUT versus V (shown in green in each panel). The PSF is formed from 95 different stars spread over the frame in each case: e.g. this shows the stars in the IRCUT image.

The PSFs look like this:

Same plot as above but in log-linear form:

None of the PSFs are as sharp as the V band one — they all have more
flux at greater distance from the center. Interestingly, the VE2 band
profile is not discrepant, so the conclusion is that the IRCUT data for
Arcturus may simply have been out of focus.

It would seem the lesson from this is that the PSF can vary quite a bit — but note well that this is in the core only — as this is not a test of the extended power-law wings at all, as we are only probing to a radius of about 4 pixel (~30 arcsec) with these data.

V-VE1 colour map

Post-Obs scattered-light rem. Posted on Apr 07, 2013 03:59AM

In the previous post, we noticed that the VE1 and IRCUT filters have very similar profiles to the V band — at least for the data we obtained pointing at Arcturus.

Here we show a colour map (V-VE1, on an arbitrary magnitude scale: properly calibrated colours will come later).

It’s clear that the deep artifacts around the edge of the moon are much smaller now, compared to the B-V colour maps we have been producing to date.

Data used:

2456015.7558321MOON_V_AIR_averaged.fits 2456015.8108611MOON_VE1_AIR_averaged.fits

This shows that the core of the PSF of the V and VE1 filters are quite similar — and the power law tails as well — not just for Arcturus but for lunar images too.

Profiles of Arcturus in different bands

Post-Obs scattered-light rem. Posted on Apr 07, 2013 12:53AM

This is a followup to the previous post on the V and B band PSFs.

Here is the stellar profile of Arcturus, shown in B (blue) and V (green). Clearly the B band light has a different core to the PSF than V.

Arcturus data were taken on the night of 2011-03-22. The files used are

align_stacked_2455643.4800437Arcturus-B-FILTER.fits align_stacked_2455643.4891739Arcturus-V-FILTER.fits

Oddly, the V band data are affected by what we called “shutter bounce” — a non-axisymmetric feature to the right (along crows in the CCD) of the PSF, but the B band data show no sign of such a bounce (the PSF profile can be exceedingly cleanly centered, unlike V band). No explanation for this for the moment!

Here are the other bands, all compared to V (green symbols):

PDF version here:

Here are the same profiles, this time with the data averaged into radial bins. The solid green line is the V band profile in each case.

VE1 and V are very similar — but this is what we would expect. IRCUT is not too far off V either.. the B and in particular the VE2 filters differ significantly from V. The difference between VE2 and all the other filters is huge, so we need to look into that next!

PSF in V and B

Post-Obs scattered-light rem. Posted on Apr 06, 2013 01:22AM

It is clear from the colour maps we have been making of the moon, that the B band PSF must be quite a bit broader than the one in V-band. We have only measured the V-band profile with any precision to date: this is a first go at the B-band profile.

The images used are these:




both taken at an airmass of ~1.3 – so quite high in the sky (which is good).

A wedge shaped region is defined for each, as shown in this figure by the green vectors:

The (V band) image is on a logarithmic scale, with counts/pixel shown along bottom. The red circle marks the fitted (by eye) position of the moon.

Centers and radii are :
V band center (195, 287), radius 147 pix
B band center (197, 291), radius 147 pix

Plot shows log radius (from center of moon, in pixels) versus flux (counts/pixel) in V band (green curve) and B band (blue curve).

It’s clear that the dark side of the moon (DS) is bluer than the bright side (blue curve offset by ~0.05 in the log on the DS).

Plotting distance from the edge of the bright side, we get this:

Focusing on the falloff of light off the brightside edge (coincidentally the B and V band fluxes are almost identical in the two images, so they are effectively normalised at the peak flux) — we see in the figure above that the blue light has considerably broader scattered light than the V band. (Note that the radial scale is now linear, not log).

Next plot shows the falloff of light on a log-log scale, as a function of distance from the lunar edge (less 3 pixels, in order to catch maximum flux).

Clearly blue light is more scattered than V!

Up to now, we have been using a single V-band scattering profile for the light — which is based on this technique of measuring the scattered light off the lunar edge, fitting a power law to the falloff at large distance (the power law tail of the profile, which has a slope of order -2.7 to -2.9 on very clear nights, at least in the V band).

The power law tail in B appears to have the same slope as in V — the B band light beyond ~ 10^1.5 = 30 pixels from the lunar edge out to the limit of the wedge (250 pixels) follows V band closely.

However, there is a large excess of light from the lunar edge out to about 25 pixels. This is messing up our colour maps, producing the dark (very blue) artifacts around the moon.

More work is certainly needed! A deconvolution method to extract the true PSF from full moon images, in all our bands, might be the thing to try next, rather than the “poor man’s” wedge method! (Note that in the wedge method, we correct for the fact that the moon is not a point source, we do not use the profile of the light in the wedge directly!)

Stability of imaging in rapid sequence

Data reduction issues Posted on Feb 06, 2013 11:10PM

Our standard practice to date has been to take 100 exposures of the moon, each with an exposure time of 10 to 40 milliseconds, depending on the brightness of the moon. The exposure time is set so that the bright side attains about 50,000 counts maximum, in order to get good signal but not risk overexposure (saturation of the CCD wells).

We have looked at the differences between successive images in these 100 image stacks. A good night with a fullish moon was chosen (JD2456106)


and the relative difference between the first 50 consecutive pairs of images in the stack computed, and made into a movie — here

(this can be viewed with mplayer in linux)

An example of nine consecutive frames is shown below :

During the sequence of 50 exposures in the movie, the moon only moves about 1 pixel down and 1 pixel to the left, so drift in the position of the moon from one frame to the next is practically negligible.

White and black on the grey scale run from a -10% to a 10% difference with the previous image. Note that the two compared frames are normalised to the same total flux (this is typically a correction of ~1%).

We see plenty of structure in the difference image, which we interpret as being due to air cells — turbulence — above the telescope. The telescope size (3cm) and short exposure times (20 ms) mean that scintillation is very significant (because of the turbulence). In tests on bright stars with our telescope and 10 ms exposures, we were getting scintillation fluctuations in the fluxes of order 50% — very large — as one would expect (Dravins et al 1997a) (paper attached below).

Some of the structures look greatly elongated, and remind us of the “flying shadows” discussed by Dravins et al 1998 (paper attached below). To quote them : “Atmospheric turbulence causes “flying shadows” on the ground, and intensity fluctuations occur both because this pattern is carried by winds and is intrinsically changing”.

Analyse sequences of images in 100 image stacks, and make an estimate of the amount of turbulence present following Dravins et al’s work — for correlation with our fitted parameter alpha of the PSF — to see if the amount of turbulence in the frames has an effect on the PSF’s long power-law tail.


Dravins et al 1998:


Dravins et al 1997a (the scintillation figure is on p 186):


Dravins et al 1997b:


More CPU/GPU tests

Post-Obs scattered-light rem. Posted on Dec 30, 2012 12:07AM

I have been looking at the use of GPUs versus CPUs for our scattered light analysis. We need to be able to convolve artificial Lunar images (outside the atmosphere) with the instrument PSF. GPUs offer a considerable speed advantage.

First look (CPU versus GPU):

Upper left panel: artificial lunar image outside the atmosphere.

This artificial image is then convolved with a 2-D Gaussian-like PSF
which has fat (powerlaw) tails, and which closely reproduces what we see
in real data.

Upper right panel: convolution using 2-D FFT code running on a CPU

Lower left panel: convolution using 2-D FFT code running on a GPU

Lower right panel: the ratio of the two methods, i.e. the ratio of the two previous panels

There is a lot of structure in there, mainly images of the lunar
crescent turning up in different places — at a level of about 0.1% of
the intensity.

IMPORTANT: the CPU code was written in double precision, whereas the GPU was in single precision.

(The above reproduces with more explanation an earlier post)

Notes: The CPU code calls the FFTW3 libraries from Fortran (Dec’s ifort compiler is used), just using the standard Fortran to C wrappers provided with FFTW3. The GPU code is in written in CUDA.

Second look (CPU only, single versus double precision):

The plot above shows the ratio of the single precision CPU versus
double precision CPU (i.e. no GPU results shown on this plot).

There is similar structure in the ratio — and at about the
same level as the GPU tests gave, i.e. discrepancies at the level of a
few x 0.1% of the intensity.

Third look (CPU in double precision, renormalisation)

In this plot
we compare CPU double precision, applied to the ideal Lunar image, and without “min/max
renormalisation”. (Min/max renormalisation means scaling the input image so that the smallest value in the frame is 0.0 and the largest value is 1.0).

The ratio panel of the two convolutions (bottom right) shows noise only, and at a
very low level — 1 part in 1E7. Highly acceptable!

Fourth look (CPU, single precision, renormalisation)

This plot shows the same as the previous one — but with single precision rather than double. The artefacts are back, at the same old level of a few x 0.1%!


We might already be able to conclude from the above that double precision FFT/CPU is robust (negligible
artefacts), but that a single precision CPU, or a single precision GPU,
produces similar sized (few x 0.1%), and thus slightly worrying, artefacts.

But I need access to a double precision GPU to test this. Hope to do so next week!
The acid test will be the results of comparing double precision on a CPU to a GPU.

More colour maps

Showcase images and animations Posted on Dec 14, 2012 06:22AM

I have made four colour maps now in B-V on four different nights.

The nights are arranged like this:

JD2455938 JD2455945
JD2456015 JD2456034

A uniform scale is used for all four images, from B-V = 0.0 to 1.4. The BS light is coming out in all four images around B-V=1.0, and the ES at around B-V = 0.6-0.8,
depending on whether one is looking at highlands or lowlands (lowlands are redder).

The cause of the black dips along the BS rim is the problem that the B images are slightly larger than the V images – so even with good registration of the center of the moon (to the closet pixel), there are issues in producing these colour maps. The falloff in the halo light cannot be the same power law in V and B, because the halo changes colour — but this is still to be checked.

Best of the data — averaged frames with 100 good slices

Observing log Posted on Dec 14, 2012 05:58AM

I wrote a program called moonraker in fortran, which processes all our data, seeking out the best for further reduction. Peter has written something similar in IDL.

It goes through all the images and throws out ones with

1) saturated BS (> 50,000 counts in the peak of the BS)

2) underexposed BS (<10,000 counts)

3) smeared images (heavy bleeding of photons in the Y-direction on the chip, reaching the bottom 20 pixel wide strips of the frame). A mean count level of more than 50 counts in this strip triggers a flag and the frame is rejected.

4) rough check if the moon is too close to the edges of the frame. This is not yet optimal, but throws out the worst cases.

5) checks that the temperature of the CCD is OK (an entry in the fits file header tells us if the temperature of the CCD has stabilised or not)

If all 100 slices in multiple exposure frames are OK, according to the above, they are bias subtracted (using the biases on either side of the exposure, averaged appropriately for each slice, and scaled to the superbias created by Henriette) and averaged, and written to disk.

6) The magnitude of the total light in the frame (i.e. apparent magnitude) is then compared to the expected V magnitude (using the JPL model, with corrections for the east and western sides of the moon, depending on which side is illuminated by BS), taking into account the airmass of the observation and the extinction for the particular filter. This isolates for removal exposures which have been taken with an incorrectly reported filter. Finally, after extinction correction, only those frames which fall within ~ 0.2 magnitudes of the correct magnitude using the JPL model are retained.

The list of the final set of good exposures using this method is attached (all100.doc — actually an ascii text file):

There are 534 good frames, spread from nights JD2455938 to JD2456104.

A summary is as follows:

Night, number of good frames in V, B, VE1, VE2, IRCUT, comments

JD2455938 2 2 0 5 0 fullish moon, some foggy frames
JD2455940 3 1 0 2 0 fullish moon
JD2455943 3 3 0 3 1 fullish moon
JD2455944 3 1 2 1 3
JD2455945 1 1 1 2 0
JD2456000 3 0 0 1 1
JD2456002 7 0 0 0 0 V band only
JD2456003 9 0 0 0 0 V band only
JD2456004 1 0 0 1 0
JD2456005 6 0 0 0 0 V band only
JD2456006 4 0 0 0 0 V band only
JD2456014 3 0 0 0 0 V band only
JD2456015 7 10 4 6 4 1/3 moon, lots of frames
JD2456016 11 10 9 11 11 “
JD2456017 7 11 0 11 2 “
JD2456028 5 5 0 9 0
JD2456029 0 0 0 6 2 2/3 moon, lots of scattered light
JD2456030 1 0 0 3 2
JD2456032 1 0 0 4 1
JD2456033 4 1 4 2 4
JD2456035 0 0 0 1 0
JD2456045 5 5 4 4 4
JD2456046 4 8 10 11 10
JD2456047 6 5 8 6 7 stars visible in some frames, useful for PSF
JD2456061 2 4 3 6 4
JD2456062 0 0 0 2 0
JD2456063 0 0 0 5 0
JD2456064 0 0 0 3 0
JD2456073 4 7 7 10 8 some eclipsing of moon – dome issues?
JD2456074 4 2 3 7 5 scattered light haze or fog?
JD2456075 8 7 8 7 8
JD2456076 9 1 0 2 0
JD2456089 3 2 1 1 0
JD2456091 2 1 5 0 4
JD2456092 0 0 3 0 5
JD2456093 0 0 1 0 5
JD2456104 5 7 5 1 5 some foggy frames, moon a bit close to bottom corner

I’ve inspected all of these by eye and they look mostly pretty good! There are still a few bad frames here because the scattering of the halo is not selected for yet — but the number of frames with low alpha (i.e. haze or fog) is just a handful.

Some of these nights will be pretty useful for looking at colour changes in the ES over time. I am doing that next.

More colour mapping

Showcase images and animations Posted on Dec 13, 2012 04:42AM

Following on from the previous post, we have made a colour map based on two images (V and B) taken on JD2456034


Both are averaged results from stacks of 100 exposures, so the S/N ratio is 10 times better compared to the images in the last post.

V band exposure time was 72.5 ms, and the B band exposure was 222 ms, for a total of 7.3 seconds in V and 22 seconds in B. The observations were at an airmass of ~ 2.3.

The colour map looks like this:

with the colour scale (B-V) running from 0.2 to 1.3.

The BS (brightside) has a colour of around 1.0, which is still a little redder than the expected value of 0.9 (for BS on a full moon) by van den Bergh (1962).

There is more scattering of the light in B than in V, which accounts for the deep valley to the right of the BS, and the excess halo light beyond it. Colours here are not reliable. Colours just beyond the concave edge of the crescent on the DS are probably also affected by differences in the scattered light profile, so should be regarded carefully (this part of the moon can be examined when the crescent is on the other side). The left half should be pretty good!

The DS (darkside) has colours ranging from about 0.6 to 0.9 — with the lowlands redder than the highlands.

Lunar colour map

Data reduction issues Posted on Dec 12, 2012 06:00AM

We have used B and V images of the moon from JD2455859 to make a map of the B-V colour of the reflected light from a thin crescent moon.

We use the photometric transformations derived from our open cluster observations:

The B band image of the moon was shifted to the position of the V band image, and the colour computed from the fluxes in B and V directly from the pixel fluxes.

The map below shows the result:

The scale at bottom runs from B-V=0.1 to B-V=1.5.

The darkside (DS) has a B-V colour in the range 0.6 to 0.9 — whereas the crescent has B-V ~ 1.1. The measured colour of the BS is B-V ~ 0.9 (Van den Bergh, 1962, ApJ, 67, 147), so we may be a little too red. More work needed on this.

We are seeing roughly the colour difference expected between ES and the BS — ES should be a few tenths bluer in B-V.

There is a clear residual halo in the colour map, indicating that the scattered light around the crescent falls off differently in B and V filters (as we expect).

Very interestingly, the crater pattern becomes much harder to see in the colour map. The V and B images look like this (after registration) V on the left, B on the right:

The lowlands appear to be slightly redder than the uplands in the colour map, by a few tenths of a magnitude in B-V.

More work needed on this — this is just a progress report!

Technical info:

a) Images used were:
2455859.1313477MOON_V_AIR_DCR.fits and 2455859.1365256MOON_B_AIR_DCR.fits

b) The transformations used were (airmass is 2.6 for V and 2.7 for B, extinction coefficients for V and B are 0.10 and 0.15 respectively).

Vinst = -2.5*log10(sumv/exptimev) – 2.6*0.10 ! airmass = 2.6
Binst = -2.5*log10(sumb/exptimeb) – 2.7*0.15
V = Vinst + 15.07 – 0.05*bmv
B = Binst + 14.75 + 0.21*bmv

which implies that B-V = 1.35 * (Vinst-Binst) – 0.43

(the airmasses above were incorrect in the first version of this entry, they have been corrected now)

Identifying the best of the data

Data reduction issues Posted on Nov 21, 2012 11:35PM

We have been using the apparent magnitude of the moon compared to the JPL model of its expected magnitude (V band), to check which images suffer from gross problems, such as an incorrect filter in the beam, or light losses from thin cloud, or other reasons. This follows up on previous posts (,

This plot shows the difference between the measured apparent V magnitude of the moon and the JPL magnitude (i.e the difference between instrumental and true magnitude) as a function of airmass. There are about 5000 frames, mainly of averaged data (i.e. up to 100 images averaged together) in the total data set (as of November 2012), of which about 1000 are in the V band, and plotted here.

(a pdf version is also available).

Blue represents one side of the moon (the side with the Crisium Mare), green the other side. Opposite sides of the moon have differing distributions of uplands and mare, leading to about a 0.15 magnitude offset between the reflected light and the JPL model (which implicitly assumes a uniform disc). The dotted lines show the expected trend with airmass for an adopted 0.1 magnitudes/airmass extinction — quite close to what we are seeing in the data. There is a lot of structure in this diagram!

To clarify which side of the moon is which: the next plot shows the Crisium side illuminated by sunlight:

This plot shows the Grimaldi side being illuminated.

Now we concentrate on the crescent light on the Crisium Mare side (blue points in the plot):

Concentrating on just this side of the moon, we see a very tight (extinction) relationship with airmass, with notable outliers. They are all the the dim side of the relationship — indicating loss of light relative to the JPF magnitude). The reason for most of these has been identified — most often because of thin cirrus or haze (this affects the scattered light around the bright side of the moon, which we model with a power law with slope “alpha” — these are indicated on the plot with that symbol. The moon went behind the tower and cables on the western horizon in one case “cables” and one image has low S/N. Two have “?” — no reason was found for these outliers, so they are simply dropped. This leaves us with a nice looking sequence of data for this side of the moon. I’ll look into these further as there may still be structure in there as a function of lunar phase.

The other side of the moon, the side with Grimaldi and extensive Mare, shows much less clear trends with airmass than the other side.

The dotted lines are the same as in the previous figure — they bracket the good data on the Crisium side. Strange things are happening at low airmass (z<1.2) – it turned out that most of these peculiar data are from a single night (JD2455912) as the next figure shows (background of these points shown in blue). Note the airmass scale has changed to make these points easier to see.

The entire night of JD2455912 seems to be a dud — as similar strange happenings show up in the other filters — VE1, VE2, IRCUT (but not clearly in B, as only one good B image was taken on that particular night).

Analysis of the remaining (grossly) discrepant points shows that they are often all on a single night. The next plot shows some of these problem nights:

Blue: Totally discrepant data from JD246691 : drop these.

Red: Near full moon!

Purple: data from JD2456061,2,3 (three nights). For almost all the moon is too bright by 0.3 mag — possibly bias issues? Will look at this.

The bulk of the green points lie along the expected extinction line, with an offset relative to the other side of the moon (Crisium) of about 0.15 mag. We can bracket these data and use them for the ongoing analysis of earthshine. We look at this in the remainder of this post.

The next plot shows both sides of the moon in green and blue crosses, but for all filters (instrumental magnitude – JPL V-magnitude) as a function of airmass. No data have been dropped yet — it’s all the nights we have.

The colour of the moon in the various bands shows up nicely as an offset relative to JPL V-magnitude (e.g. B-V is of order 0.9, second panel from bottom). The Crisium side of the moon shows much cleaner results than the Grimaldi side, in all colours. The dotted lines bracket the good Grimaldi data, and are the same in all panels. Data which appears between these two lines in other bands then V, mean that the V filter was actually in the beam, not the nominated filter. There may be similar effects for all filter combinations, but for the moment we can oinly pick out misfirings which resulted in the V-filter being in the beam. Only a small fraction of the data seem to be so affected, which is very good.

Extinction depends on the wavelength of the filter : this is clearly seen as differing slopes in the zeropoint (ie. the difference between instrumental and true (JPL) magnitude) with airmass.

Once the grossly erroneous observations/nights are cleared out of the data, the sequence of good data as a function of airmass can be picked off the plot (we call this tunneling).

Firstly, opposite sides of the moon are reduced to the same scale, by adding 0.05 mag to the magnitudes (in all bands, B, V, VE1, VE2, IRCUT) on the Crisium side, and subtracting 0.15 mag from the Grimaldo side photometry. This brings both sides onto more or less the same sequence with airmass. We then estimate (by eye) the extinction as a function of airmass in each filter. The results are:

B 0.15 mag/airmass
V 0.10 mag/airmass
VE1 0.08 mag/airmass
VE2 0.06 mag/airmass
IRCUT 0.12 mag/airmass

Interestingly, the extinctions in IRCUT and VE1 are somewhat different, which we wouldn’t expect as the filters are ostensibly rather similar. We should look into this further. In any case, these extinctions allow use to define lines about 0.3 mag wide around each sequence for each filter and pick off the best data. The result is this diagram:

A list of these frames is here:

There are 3162 frames on this list — cut down from about 5000, so about 60% of the frames have survived the “tunneling” process. This is still a quite conservative list because I haven’t

1) checked for the Lunar centering,

2) checked for “alpha”, the scattered light parameter, except for those very obvious cases which showed up by eye.

Final plot: using just the good data, the extinction corrected apparent magnitudes at MLO are compared to the JPL model as a function of Lunar phase. The scatter is small in some of the filters — we are down to absolute photometry errors of just a ~ 0.1 mag relative to JPL, which is pretty good considering we cover a range of airmass mainly from 1 to 5, but with some of the data out to airmasses of 15!

There is a hint we can do better still, because there is still structure as a function of phase — for example, the B band magnitudes at negative phase are a bit brighter still than the positive phases — indicating we didn’t get the correction for each side of the moon quite right. There are also trends in the reflected light with phase, but this probably reflects the fact that phase and airmass are somewhat correlated (small absolute phases tend to get observed at higher airmass, because the moon starts the night closer to the horizon).

What the JPL model for the moon’s apparent magnitude gives us

Real World Problems Posted on Sep 24, 2012 12:09PM

We weren’t sure of how exactly JPL models the Moon’s brightness in HORIZONS, i.e.

The following plot shows that JPL calculates the actual observatory-object distance in giving the Moon absolute magnitude, but does not use any albedo map of the Lunar surface — so it is symmetrical with phase on either side of new moon (say).

Lower panel : apparent magnitude of the Moon over a 12 month period (September 2010-2012) computed with Horizons, and shown in a narrow range of the illuminated fraction (40 to 50 percent). The scatter in the apparent magnitude around the trend is ~ 0.1 mag.

Most of this scatter is due to the changing distance of the moon around its orbit (between ~0.019 and 0.023 light minutes). The middle panel shows the magnitude if we correct the photometry to a standard distance (0.0215 light minutes) — this reduces the scatter to 0.03 mag. (The distance provided by Horizons includes the position of the observatory on the Earth — this can make a difference of up to ~12,000 km in the Moon-Observatory distance).

The upper panel shows the residuals in a least squares fit to the middle panel, as a function of Julian day over the 1 year sample period. This clearly shows that most of the 0.03 mag scatter in the middle panel is due to the changing Sun-Earth distance during the course of the year. Accounting for this reduces the scatter to <0.01 mag. We interpret this to mean that no surface features of the Moon are being included in the Horizons’ apparent magnitude estimate, since we expect considerably more scatter than that (but we are working on this!).

Brightness of opposite sides of the Moon

Data reduction issues Posted on Sep 19, 2012 11:10AM

We have isolated the very best images in V band, in which the Moon is well centered and well exposed.

We measure the apparent magnitude of the moon in these images by simply measuring the total flux, and applying the standard photometry relations (i.e.

We correct for extinction of 0.10 mag/airmass (from

We then compare the apparent magnitude to the expected apparent V magnitude from the JPL ephemeris for the Moon ( This uses the relation quoted in Allen “Astrophysical Quantities”, which actually comes from Eqn 8 of this paper:

The plot shows the difference in the apparent magnitude as a function of phase (new moon = 0). Blue and green show opposite sides of the moon.

There is a bit of scatter in these data, but there are two clear sequences around phases 50 to 100 showing that opposites sides of the moon differ in luminosity by about 0.1 mag. This is quite a lot less than we expected to see, viz. this post:

Lunar apparent magnitude with phase

Data reduction issues Posted on Sep 11, 2012 05:22AM

The plot shows the apparent magnitude of the moon in V and B as a function of lunar phase (phase=0 is new moon).

We measured the flux in images in which the filter was reliably V or B and used the transformations determined from NGC6633 (i.e. to get the apparent magnitude.

These data have been obtained for a large range of airmass (z) — from z = 1 to 10, with most of the data in the range z = 1 to 3. We derived extinctions of 0.10 mag/airmass for V and 0.17 mag/airmass for B, by comparing to the apparent V magnitude from the JPL ephemeris for the Moon ( (more about this below). The solid black line shows the V apparent magnitude as a function of
phase after extinction correction, and adjusting the zeropoint by 0.2
mag in V to fit.

Note that B is ~ 1.0 mag fainter (i.e. B-V ~ 1.0, as we’d expect).

The airmass fits are shown above : the plot is the difference between the apparent magnitude from the JPF ephermeris and our transformed instrumental V band (or B band) magnitudes, shown as a function of airmass. The two lines show 0.10 mag/airmass (V band) and 0.17 mag/airmass (B band) — they are not fits. There are some bad outliers, especially in the V band, which are probably due to the incorrect filter being in the beam.

Effect of registration errors on measuring the flux in a darkside patch

Error budget Posted on Aug 21, 2012 11:53AM

We have looked at the error in measuring the flux in a patch on the earthshine side if the position of the patch is uncertain by a few pixels.

A circular patch (aperture) was chosen, as shown by the green circle below:

The aperture is 31 pixels in radius, and is in a not particularly uniform luminosity area of the lunar disc.

The amount of scattered light into this area is rather small (~<10% of the flux) and has been ignored.

The flux in this aperture was computed for the correct registration (no offset in x or y) and for offsets of 1 and 2 pixels in both x and y (i.e. a rectangular grid of -2 to 2 pixels offset in x and the same in y).

Simply summing the flux in this aperture yields a 1.5% error in the flux, if the registration error is up to 2 pixels. The error reduces to 1.0%, if the registration error is just 1 pixel.

We tried rolling off the edge of the aperture with a cosine function (i.e. from 1.0 to 0.0) — it starts 6 pixels inside the edge of the aperture. We weight the flux in each pixel by this function. Pixels inside this rolloff zone are weighted with 1.0.

The improvement is rather small. For this “soft tophat” aperture, registration errors of order 2 pixels lead to a flux error of ~1.4%. This is to be compared to the error of 1.5% for the hard edged aperture. If we can achieve registration errors of 1 pixel, the soft edged aperture yields a flux error of 0.8%, compared to 1.0% for a hard edged aperture.

Next we tried a much more uniformly illuminated region of the moon:

The results are much better. In this region, a registration error of up to 2 pixels yields flux errors in the patch of order 0.2% (31 pixel hard edge aperture) and 0.15% (31 pixel soft edge aperture). This is very acceptable!


Using a soft edged aperture helps ameliorate registration errors, but not as much as we had thought.

Selection of uniformly illuminated patches helps much more! Doing both is a good thing.

Instrumental zero points

Observation Resources Posted on Jul 01, 2012 03:47AM

Peter and Chris observed NGC6633 – an open cluster in the Galactic plane — on 26th June 2012. The aim was to calibrate the zero points and colour dependencies of all the filters.

Coordinates are RA = 18h 37m and DEC = +06 34 (J2000) — which goes more or less overhead. We observed very close to the zenith, so the airmass was very close to 1.0.

Image above shows the FOV for the IRCUT filter (which is very similar to V). About 80 well measured stars are identified in the cluster and marked with blue circles.

We got great images for all 5 filters (first time we got all 5!).

Johnson V and B data were obtained from WEBDA:

Exposure times were:
V 25 sec
B 34 sec
VE1 12 sec
VE2 32 sec
IRCUT 12 sec

Counts were measured in the ~ 70 identified stars in a 2.5 pixel aperture (i.e. 7*2.5 = 20 arcsec radius aperture).

Transformations to V, B, VE1, VE2 and IRCUT were derived from ~ 70 stars, where the instrumental magnitudes for each filter are of the form:

Vinst = -2.5*log10(Vcounts/exptime)
Binst = -2.5*log10(Bcounts/exptime) etc…

V = Vinst + 15.07 – 0.05*(B-V)
B = Binst + 14.75 + 0.21*(B-V)
VE1 = VE1inst + 16.30 + 0.18*(B-V)
VE2 = VE2inst + 13.88 + 1.09*(B-V)
IRCUT = IRCUTinst + 16.43 + 0.16*(B-V)

The scatter in the derived relations is
V 0.02 mag
B 0.05 mag
VE1 0.04 mag
VE2 0.06 mag
IRCUT 0.06 mag

The transformed data for the stars are shown in this plot:

The V and IRCUT filters both transform to Johnson V, and the B filter transforms to
Johnson B, with relatively small colour terms (i.e. the dependency on (B-V) of the transformation).


Firstly we compare these relations to those derived at the last (only partially successful) attempt to calibrate the filters using M41.

The report on the M41 data is here:

The transformations from the two clusters are:

V = 15.15 + Vinst – 0.08*(B-V) : NGC6633
V = 15.07 + Vinst – 0.05*(B-V) : M41

B = 14.46 + Binst + 0.26*(B-V) : NGC6633
B = 14.75 + Binst + 0.21*(B-V) : M41

The colour terms are quite similar, but the zeropoints differ substantially, particularly for B. Since we were unsure about the quality of the M41 data, I think these these should be disregarded. We’ll do NGC663 a few more times over the next few weeks — it’s a very well placed cluster, and the stars are quite sparse — which is very good for us.

We need a set of images as the cluster goes to much higher airmass, so we can measure the extinction coefficients for each filter. I think we have at least some of these data already from 26th June 2012.

TO DO: apply these to lunar images to measure the colour of the brightside and earthshine light.

Cable near setting Moon

Real World Problems Posted on Mar 29, 2012 09:59AM

The image shows a cable which the moon can move behind as it is setting at 285 degrees azimuth and 25 degrees latitude.

Arrows show the dim line which is the cable against the sky. The middle arrow shows a glint off the cable from the Moon.

The cable can whip around quite a bit in the wind. It clearly shows up in the CCD images when the Moon is behind it.

Moon movie with halo

Showcase images and animations Posted on Mar 23, 2012 04:34AM

Movie shows 9 images of the moon centered on a particular crater on the bright side.

Greyscale is “minmax” + “log” in DS9.

The halo light looks very stable around the bright side edge. Naively at least, it appears as if the determinations of alpha (power law fall off of scattered light at large angle) should be very stable.

In this time sequence one can see the terminator changing slightly — certain features brighten, others dim – – especially crater walls and mountains.

Movie is here:

play it with e.g. mplayer Vmovie.mpeg -loop 0
for a continuous loop.

Error on determination of linearly changing albedo

Error budget Posted on Mar 11, 2012 12:41PM

I have run simulations like Peter’s of our ability to recover a changing albedo with time.

The sims are over a period of a decade with 100 observations of (global) albedo per year (randomly chosen nights). 1000 sims were run and the slope of the albedo change with time measured using least squares from the monthly means. One sim was for no change in the average albedo with time, the other for a linearly incrasing albedo with a slope of 0.1 percent of the albedo per year — i.e. mean yearly albedo increases from 0.300 to 0.303 over a decade.

It’s important to start each sim on a different day of the year — if not, there is a bias in the slope caused by the seasonal pattern being the same in all sims.

The plot shows the histograms of the slope determinations.

Black histogram: no change to the mean albedo with time. Green histogram: change of 1 percent over a decade – i.e. 0.1% per year.

The natural variation in the albedos was set at 1 percent in addition to the seasonal variations.

The histograms are centered on the correct slope — but the width of the histograms is quite broad and backs up Peter’s sims of last week and reported in the blog.

For the green curve the mean of the 1000 simulations is 0.100 (i.e. an excellent match to the input albedo rise of 0.1 %/year) and the scatter is 0.025.

This setup (10 years, 100 albedo measurements per year, 1% natural variation in the albedo) gives a 4-sigma detection of a rising albedo of 0.1%/year

measuring linearly changing albedo

Error budget Posted on Mar 09, 2012 05:41AM

Simulation of 100 albedo measurements per year of a linearly rising
albedo of 1 percent per decade. The simulation is based on the mean monthly global albedo estimates over several decades from a suite of models as in Bender et al . 2006 (Tellus, 58A, 320) figure 3.

grey crosses : individual measurements

green line — monthly averages

red circles — annual averages

the black lines are the fits to the monthly averages — they both come out with the correct slope – so it does work!

the two panels show the effect of 1 percent (lower) and 0.1 percent scatter (upper) on
the individual albedo measurements due to natural variability.

the 0.1% case allows the underlying model to be seen clearly.

1% scatter in the daily albedo makes things look a deal noisier — but the right slope comes out and one can get a pretty good seasonal pattern
from the monthly means and better stull by folding the data into a year.

we are looking further into what daily variations naturally arise — the Bender paper is not clear on this.

Bunch of papers on earthshine

Relevant papers Posted on Feb 06, 2012 10:49AM

2004: The BBSO group’s Science paper:…304.1299P&db_key=AST&link_type=ABSTRACT&high=4d491396e418829

2005 Controversial multi-dataset compilation:

2006: Frida Bender et al at MISU gets in the act:

2006: Palle has a shot back ati Bender:


Langley/NASA is not amused:…20..575L&db_key=PHY&link_type=ABSTRACT

Langley revises their methods:

BBSO shoots back:


BBSO rumbles some more:

And so does NASA:

I stumbled across these, which look interesting:…700.1428O&db_key=AST&link_type=ABSTRACT

If only!

Relevant papers Posted on Jan 29, 2012 11:38AM

Just for fun: this in yesterday’s “The Age”, from an article originally in the Guardian:

“Albert Einstein with an equation for the density of the Milky Way.”

Oh how we pine for an equation for Earth’s albedo!

More analysis of scattered light

Post-Obs scattered-light rem. Posted on Jan 29, 2012 01:48AM

Some more analysis of scattered light.

I take three synthetic lunar images —

1) a thin crescent with no ES, i.e. BS only

2) ES only

3) BS + ES

Raw images shown on the left — with scattered light on the right. (All images shown at the same display levels, making the halo hard to see!)

The albedo adopted was 0.30 for the ES on (2) and (3).

All three are generated with the correct flux scaling for the components
i.e. image (3) is the sum of (1) and (2).

These three images are convolved with the PSF with alpha=1.8.
No noise is included in the final output images.

I then compute the amount of light which has scattered off the
original synthetic images and onto new pixels. (A list of all pixels which
had non-zero counts in them in the original images was kept and the
counts in these pixels in the convolved images compared to the total
counts in the convolved images. The normalisation of the convolution is set
to the total counts in the original images).

While doing this, I checked how much light scatters off the edge of the 512×512
frames and into the larger (3*512)x(3*512) frames used for the FFT. This turns out
to be ~0.04%, a good deal less than our target accuracy (0.1%)) for alpha=1.8, so this is not a major source of error.

The amount of off-moon scattered light is as follows

1) BS only : 4.2 percent
2) ES only : 0.58 percent
3) BS and ES : 3.9 percent

let’s call this the “halo light”.

these numbers highlight why getting the BS to ES normalisation correct
when generating forward scattering fits to data is important!

We want to measure the DS to BS ratio to an accuracy of 0.1 percent, so the approximately 4 percent of halo light has to be gotten right when figuring out the amount of BS light. The difference between BS only halo light and BS+ES halo light is of order 0.3 percent, 3 times more than our desired accuracy. This shows that the ES makes a non-negligible contribution to the halo light.

Those numbers were for alpha=1.8. For alpha=1.6, I get

1) BS only : 6.9 percent
2) ES only : 1.58 percent
3) BS and ES : 6.0 percent

Now the ES is making a very significant contribution to the halo light — 16 times more than the accuracy with which we would like to know the BS light.

The light lost off the 512×512 frame is small at 0.04% – half of our target error.
However, for alpha = 1.6, this lost light increases to 0.3 percent of the total.

Lost light off 512×512 array for centered thin crescent Moon

alpha lostlight
2.0 0.004 %
1.8 0.04 %
1.7 0.11 %
1.6 0.32 %

It looks like we need to take into account lost light off the 512×512 array
when we are doing the fitting for the BS, especially if the images aren’t well centered, as is presently an issue!

More added

In response to Peter’s comments:

We have both done tests on artificial data which suggest that we are able to measure alpha with an accuracy of +/- 0.01. I figured out the corresponding missing light off the edges of the image for this uncertainty in alpha:

alpha lostlight
1.80 +/- 0.01 0.038 -/+ 0.004 %
1.70 +/- 0.01 0.11 -/+ 0.01 %
1.60 +/- 0.01 0.32 -/+ 0.03 %

So if we really have alpha=1.8 and can measure it with an accuracy of 0.01, we are pretty safe — at least for this thin crescent which is well centered.

Peter asked: what if extinction and alpha are correlated? Great idea! We should certainly look into this!

I had another idea — what about if we made longer exposures of the moon which would saturate the moon but sample the halo light well all the way to the edge of the frame? Could we then measure alpha with appropriate accuracy where it counts — at the moment we are merely extrapolating a not very well sampled halo beyond the edges of the frame to estimate the missing light (in 30 ms exposures, the halo light is very close to the bias level at the edges of the frame, so is not well measured out there, and a bias error could lead to systematics in the estimate of alpha, perhaps larger than the error estimate adopted above of 0.01, which was obtained for rather idealised synthetic data.

The behaviour of the scattered light around the moon beyond the edges of the frame is still very much an open question — we didn’t acquire the data at the last full moon to settle this, but just got more questions!

More still: position of the Moon

Tested the effects of the positioning of the moon using the same setup as above

For 1 pixel shift of Moon in the x-axis, I got negligible changes in the amount of lost light.

For a 10 pixel (circa 70 arcseconds) shift (to the left along the X-axis for a crescent moon which is illuminated on the left side):

alpha lostlight
2.0 0.005 %
1.8 0.04 %
1.7 0.12 %
1.6 0.33 %

The changes to the fractional lost light are very small. So the good news here is that we are not very sensitive to the precise position of the moon if it’s near the center.

Scattered light from Moon measured at MLO

Post-Obs scattered-light rem. Posted on Jan 11, 2012 09:36AM

Peter and Chris took images of the sky near the moon, going outwards from the Moon in 0.5 degree steps, in order to measure the powerlaw falloff of light using the MLO telescope.

Data taken on night of 2012-01-08.

We got good data for 4 positions, 1.0,1.5, 2.0 and 2.5 degrees from the moon,

WCS coordinates for the frames were found using This is a great site!

Stars in the fields were found by searching Simbad for objects brighter than 10th magnitude. A small program was written to locate these stars and do the photometry based on the magnitude equations determined previously for the CCD, and their J2000 coordinates. This is quite nicely automated now. Bias frames were subtracted from each of the images and the magnitudes and sky flux of the known stars in the field computed. The magnitudes were compared to the known magnitudes and came out very nicely.

The images were taken at
POS3 : 06:27:24.313 +22:22:27.07
POS4 : 06:27:25.994 +22:51:53.62
POS5 : 06:27:23.910 +23:22:22.01
POS6 : 06:27:26.336 +23:51:34.44

Some example images with stars of known magnitudes:

POS 3:

The Moon during all of this was at 06 27 36 +21 50 28.

Distances from the center of the moon were computed for each star, and the sky flux next to that star plotted as a function of Lunar distance on a log-log plot.

PDF version of this plot:

Upper plot shows the magnitudes of the stars found in all four fields versus their correct magnitude. Lines is the 1:1 relation.

Lower plot shows the brightess of the sky versus the distance from the Lunar center in log(arcsec).

Line is a powerlaw fit, and has a slope of -0.6.

This is very curious. We were expecting -1.5 to -2 or so. What is this extra light?

The surface brightness is about 16 mag/sqarcsec in the inner most position at 1 degree from the moon, dropping to about 17.5 mag/sqarcsec at 2.5 degrees from the moon. This is a very slow drop in the brightness. The Moon was in the Milky Way plane, but the luminosity of the Milky Way is about 20-21 mag/square arcsec. So it’s not the Milky Way we are seeing.

For the present this is a cosmic puzzle!


Improved coordinates of the Moon were computed from the times of the exposures by Peter and a better plot results. Here it is:

Slope of the halo is now -0.9. That’s a bit better. More work to be done on this at the next full moon.

Laser versus LED

Post-Obs scattered-light rem. Posted on Dec 30, 2011 04:16AM

I looked at a bright white LED instead of a bright green laser.

Imaged it with the Canon 35 mm camera as before.

The result is exactly the same scattered light power law around the source.

Did this to check that nothing funky is going on with using a laser as a point source!

I added a scattering plane to the setup – a translucent tupperware lid was placed directly in front of the camera lens. Imaged the LED with and without the scattering plane. The lid scattered light very nicely (left) versus naked LED (right)!

The red curve shows the scattered light profile, the black curve the naked LED. Light is scattered on all scales in this experiment. Can one have a regime where scattering in the optics is dominant and elsewhere where atmospheric scattering is dominant? Not sure at all about this — my feeling is if the atmospheric scattering has a shallower power law index than the optics scattering, then it will always win. Could scattering be scale dependent?

The power law index for the naked LED is -2.6, for the scattered version it’s -1.5. This latter value is very similar to what we get for the moon in the 35 mm camera shooting through air! The tupperware lid simulates the Earth’s atmosphere, presumably by accident.

Scattering through camera optics, air and tupperware lids all produce power law profiles. Is that not interesting? Scattered light follows a power law under a wide range of conditions!

Laser PSF in Canon 35 mm

Exploring the PSF Posted on Dec 29, 2011 12:54PM

As a follow up to the knife edge imaging of the moon with the Canon 35
mm camera, I took images of a laserpointer shining into the lens.
Laserpointer was set on with tape and shone into the camera lens from a
distance of about 5 meters. Camera was on a good tripod. The laser
pointer was aligned to be pointing into the lens by watching to see it
emerge from the back of the camera out the viewfinder and onto a wall
behind the camera. Eyes were kept well away from everything!
Exposure times of a few hundredths to a few thousandths of a second gave good halos.

Laser was pretty well centered. There is a weak secondary image off to lower right. The main image is saturated in the core out to about 10 pixels radius.

The laser has a strong core surrounded by a quite uniform intensity “platform”, after which the light falls away like a power law.

The radial profile of the laser (blue) compared to the moon (green) is shown below.

The laser pointer’s profile falls off faster than the moon — but not very much faster.

If we assume that the laser is a good point source, then there is scattering in the lens/CCD combination in the camera which is seen as a power law at large R.

Slope of the lunar halo is about -2.0, whereas the slope of the laser pointer halo is about -2.6. Getting close to the diffraction limit of -3!

The lunar profile is then interpreted as a combination of both scattering in the camera and scattering in the atmosphere. Its slope is shallower — so atmospheric scattering totally dominates at large R (scale both powerlaw falloffs to the same flux at log(R)=2 or 100 pixels to see this — atmospheric scatter would then dominate internal lens scatter by about an order of magnitude out at R=1000). Not sure what’s happening close in, as the laser pointer has a strong uniform intensity “platform” of light around the core — easily seen by eye just by pointing it at a piece of paper. A point like source of light, like a street lamp seen at a large distance might be a way around this problem.

I also imaged the laser pointer projected onto a white wall — long exposure times of many seconds — and got the same result — similar core and platform and a halo with the same slope.

All very interesting !

Knife edge due to a house

Post-Obs scattered-light rem. Posted on Dec 28, 2011 02:48PM

Observed the full moon with a Canon 35 mm camera, eclipsed by a “sharp edge” (the front balcony of our house) and then moved the camera so that the Moon appeared from behind the edge and imaged it again. The moon was about 45 degrees above the horizon on a very clear sky. Sector was chosen to avoid the gum trees seen lower left smiley

Image above is the UNECLIPSED moon close to but detached from the edge of the house. The radial profile was measured in the inner region of the sector shown, with the outer region defining the background sky for subtraction.

Image above shows the light from the moon, now placed just behind the roof’s edge. The radial profile was measured in a similar manner as before.

The idea is to test if the scattered light far from the moon is the same in both cases, i.e. is mainly due to the atmosphere.

The result is that it does indeed seem to be due to the atmosphere — the light falls off as a log-log power law exactly the same and, for two images with the same exposure time, the falloff has the same surface brightness on the sky.

The falloff at large R (> log(R)=2.1, or about 125 pixels (1 pixel is about 1 arcminute) is exactly the same in the two cases, going out to more than 1000 arcmin (15 degrees). There is some funny behaviour near the knife edge, with some missing light in the eclipsed profile relative to the uneclipsed one, but it was very difficult to estimate where the center of the moon was behind the knife edge — since the moon is eclipsed — and the behaviour is quite sensitive to the moon’s position. Tried to figure out where the moon was using stars in the background, but the field distortions in the 35mm lens were too severe to model with a handful of stars.

If we try this again it would be better to leave the camera fixed and wait for the
Earth to turn and eclipse the moon, rather than moving the camera. A sequence of images as the moon approaches the knife edge might make modeling where the moon ends up behind it easier.

M41 and photometric calibration of filters

Post-Obs scattered-light rem. Posted on Dec 27, 2011 03:50AM

UPDATE: The measurements on this post have now been superseded but more reliable data from NGC6633. See blog entry for July 1st, 2012!

On 23/12/2011 Peter and Chris observed M41, an open cluster in the Milky Way plane at 06:46, -20:40. It was a very clear night and we got good images (although off center) in all bands. Image below is a centered B band frame.

Stars identified from the WEBDA database for this cluster are shown below:

Data for these stars are here:

The transformation to standard V and B are rather good. There is a small
colour dependence in the V filter (-0.08 mag/mag) and quite a large one in the B filter (+0.28 mag/mag). The scatter is quite low in the V transformation — 0.02 mag, and a little larger in B — 0.05 mag.


Instrumental magnitudes convert to true magnitudes as follows:

* compute instrumental magnitudes
V0 = -2.5*log10(ADU/sec)
B0 = -2.5*log10(ADU/sec)

* instrumental colour
(B-V)_0 = B0-V0

* transform instrumental colour to Johnson B-V
B-V = -1.056293 + 1.529783*(B-V)_0

* transformation to Johnson V (scatter is a very small 0.02 mag)
V = 15.15 + V0 – 0.08*(B-V)

* transformation to Johnson B (scatter is quite large at 0.05 mag)
B = 14.46 + B0 + 0.26*(B-V)

These are for a (rather small) 2.5 pixel aperture – designed to avoid crowding by nearby stars. The correction for the aperture size is ~0.1 mag brighter.

There are no standard magnitudes for VE1, VE2 or IRCUT. I have searched for
similarities with V, B or I, since these are the bands we have external magnitudes for.

The following definition of VE1 magnitude gives a very close 1:1 match between V and VE1:

VE1 = 16.34 – 2.5*log10(ADUs/sec) + 0.06*(B-V) (scatter 0.04 mag)

so VE1 is functionally quite similar to V.

On the other hand, VE2 is very similar to I. With this definition for the VE2 magnitude:

VE2 = 14.22 – 2.5*log10(ADUs/sec)

one gets very close to a 1:1 relation with I, with a scatter of only 0.03 mag. No colour term either — so VE2 this is an excellent match to I.

We didn’t get any good frames in the IRCUT filter. We’ll have to try that some other time!

Summary : Our V and B are much like their standard Johnson counterparts.
Our VE1 is functionally more or less the same as Johnson V, and VE2 is very close to Cousins I band. The latter seems a bit odd. I haven’t seen the filter curves, so they’ll be fascinating in this context. What is the IRCUT filter going to show? More to follow.

When fog falls yea verily upon the mountain

Observing log Posted on Dec 21, 2011 03:26PM

A skycam image showing where there is fog on the mountain. The navigation beacons are hazed out (in the NNW) so there’s fog at ground level. Close up please!

Noise model – Poisson versus Gaussian noise estimator

Post-Obs scattered-light rem. Posted on Dec 14, 2011 02:14PM

The noise model is improving rapidly. Below is a simulation of a lunar image (right) from a synthetic moon provided by Peter; and the corresponding real image (left).

Images are equalised histograms with the same scaling of log(flux).


Until now I had been using Gaussian sampling for the noise, but this fails badly when only a few photons are expected in a given pixel — while this is not an issue for most of the moon (ES>10 counts/pixel in typical exposures, and BS is of course very bright) — it matters a lot when modeling the halo far from the moon.

Replaced the Gaussian noise model with a combination of a Poisson model for low count rates and Gaussian for high count rates (>25 counts per pixel). The Poisson code is both very slow and inaccurate at high count rates, so a combined model was necessary.

The Poisson code comes from here:
Credit : W.P. Petersen, IPS, ETH Zuerich.
(I should check it’s public code).

More on the method to get a Poisson sampled count in regions where the expected number of photons is < 1 to follow later!

MORE stuff on this:

There is a timing hit doing Poisson noise, it’s quite
long winded.

For 30 summed images the total run time is about 40 seconds
on my laptop with Poisson noise. for 30 images with Gaussian
noise, the run time is about 2 seconds. The FFTs only take about
1 second of this. So there is presently a huge performance hit. I think this can be greatly improved.

Important note: 30 summed images using Gaussian noise look
very similar to 30 summed images using Poisson. This is
because 30 images of Gaussian sampling simulate Poisson
sampling rather well. It’s very different though when talking
about a SINGLE frame:

ABOVE : GAUSSIAN noise (left) versus POISSON (right): for a simulated lunar image in a single 30 ms frame. The very low light levels are much better modeled in the Poisson frame on the right, where the flux level drops to a few photons per pixel — and very much better when the level drops well below a photon per pixel.

Gaussian (right) versus Poisson noise (left) — but for 30 coadded 30 ms images. The differences cannot now be seen by eye, since mathematically the samplings are now more or less the same thing.

I have now written my own subroutine to do Poisson noise, and it seems to reproduce very well the results of the code acquired from It’s slightly slower though; thought I could improve on the run speed easily, but I was wrong!

Need to still check for small systematic differences between expected mean number of photons and the numbers actually returned by the Poisson routine, since we need to worry about this at the 0.1 percent level. More on that later.

Working method for albedo measurement

Post-Obs scattered-light rem. Posted on Dec 05, 2011 01:17AM

My last post was on techniques to measure the ES using artificial images as input.
Three boxes are defined on the image which are mainly sensitive to alpha, ES and threshold. Box 1 (off the BS limb) turned out to be completely dependent on alpha alone — and one can get a very accurate alpha measurement from just measuring the photons in the box (see plot below). The scatter in alpha is only 0.01 in tests of the method based on semi-realistic synthetic images made by coadding 10 x 30ms images together and properly including Poisson noise. Error in the bias level or registration of the moon and overall normalisation of the image is NOT yet included. Having determined alpha, it takes a little care to then compute the amount of light due to BS scatter in the box on the ES limb, and subtract it. Doing this, one then gets the actual ES level in the box. This correlates very well with input albedo and can be empirically turned into an output albedo (see plot below), with a scatter of 1% — our target accuracy. So it looks to me as if 1% is achievable! Yay! However, there are quite a few systematic effects not yet included here, all of which will shift us hither and thither. So that’s yet to be done!

Basically I think this method is the same as Peter and Jacob are pursuing at the moment — simply trying to fit away the unwanted scattered light in the ES box — except that I do it “empirically” by building a calibration from a range of synthetic data with different alphas and albedos — whereas they are working from a single frame — which is what we will actually have to do in practice.

Anyway, all of the above gives considerable oomph to the idea that the glass is 90 percent full!

New analysis method

Post-Obs scattered-light rem. Posted on Dec 03, 2011 10:36AM

I’ve developed an kind of ’empirical’ method for measuring alpha and ES on a frame, I am working from 30 co-added 30 ms exposures of a fake moon, so the S/N is rather good.

Here’s how it works:

Three boxes are defined on the lunar image as shown below

Image shows an example synthetic lunar image (30 co-added 30ms exposures)
for some value of alpha and earth albedo (threshold is identically zero in
the tests done to date).

Box 1 : (far left) designed to be mainly sensitive to alpha. (11×21 pixels)

Box 2: (middle) mainly sensitive to ES level on DS. (26×21 pixels)

Box 3: mainly sensitive to threshold level — i.e. the bias (51×21 pixels) (not analysed here).

A set of synthetic lunar images is created for a range of values of albedo and alpha, chosen randomly in the range albedo = [0.0, 0.6] and alpha = [1.6,2.0].

For each alpha and albedo pair, the total photons are measured in boxes 1 and 2.
I then ’empirically’ calibrate relations between the photon counts in the boxes and alpha and albedo.

Above is the plot for the counts/pixel in Box 1 — it correlates extremely well with alpha and has no measurable dependence on albedo. The lower plot implies alpha can be measured with an accuracy of ~0.01 from the counts in in box 1. (Note well that alpha here is the power to which the PSF is raised — it is already a power law like r^-1.6, and it is then raised additionally to power alpha).

The counts/pixel in box 2, selected to be mainly albedo sensitive, are indeed very well correlated with albedo. There is a very small dependence on alpha (lower panel). Taking into account both dependencies results in recovering the albedo with an accuracy of about 0.03 — compared to a typical albedo of 0.3, for an accuracy of 10%. We require 1% accuracy! Not sure what’s driving the 10% figure at this stage. Is it merely Poisson?

We can improve things by using more of the frame — the boxes were selected pretty arbitrarily just to get the ball rolling. The modeling is also pretty ideal at this stage as the error in the threshold is not yet included, and one has to have a good synthetic moon image to get started — any error in the synthetic moon (i.e. before scattered light and Poisson sampling is included) will bias the method.

Update: method now much improved — fitting functions work much better using log of the counts in the boxes, rather than the counts in the boxes (as I should have realised — we are dealing with a power law in the scattering!). This leads to great improvements, as discussed in the blog entry above.


Showcase images and animations Posted on Nov 09, 2011 12:59PM

Here is the resulting DMI news on the net:

Photon noise in Canon camera

Error budget Posted on Nov 01, 2011 04:19AM

I have measured the pixel noise in the Canon EOS 35 mm camera. This is the same one as used to measure the halo of the moon at large distances (up to 15 degrees) from my Sydney backyard.

60 exposures were taken of a flat white surface, in groups of 10, with 5 exposures times from 1 second down to 1/200th of a second. (A 6th exposure time was discarded due to saturation).

Frames converted from CR2 format to fits format using cdraw and convert:

ls *.CR2 | awk ‘{print “dcraw -T -4 ” $1}’ | bash
ls *.tiff | awk ‘{print “convert ” $1, $1″.fits”}’ | sed -e s/.tiff.fits/.fits/ | bash

the tiff files this produces still have colour information, which I wasn’t expecting. The fits files are of course grey scale, but I suspect they are averaged over the three colours (RGB), so that the apparent photon counts are three times smaller than the actual photon counts.

The standard deviation and mean flux in 9 randomly chosen individual pixels was computed across the of 10 images obtained for each of 5 exposure times. The square root of the mean (times 3) is then plotted versus the standard deviation of the values, yielding 45 noise measurements (i.e. 9 pixels x 5 exposure levels of the pixel = 45). If the noise is anything like Poisson noise, these should lie on the 1:1 line.

This proves to be approximately the case as seen below.

It’s pretty noisy though! (i.e. the noise measurement is noisy).

Inspection of the fits files ds9 shows that there are clear correlations on various scales in both the X and y directions in the images — so the camera is surely introducing smoothing of some sort, so there is only so far one can push this analysis!

Conclusion : Poisson noise is a fair first order approximation for the behaviour of a commercial camera CCD chip.

Noise model

Post-Obs scattered-light rem. Posted on Oct 30, 2011 11:38AM

I have made an attempt to figure out what the noise levels are at various fluxes in individual frames.

28 images of the nearly-full moon were used. They were very carefully aligned (using subpixel rebinning and the iraf task imshift). The shifts were determined with a fortran program which centered the moon using center of light — this was written because no iraf task I could find could easily align such images without reference stars.

Below I show in green circles the regions that were used to measure the standard deviation of pixels in a 10×10 box on the lunar face. These were chosen because they are relatively flat and have a range of luminosities. All the pixels in the scattered light off the lunar edge were also used, in a sector starting from the center between the position angles 40 and 50 degrees (i.e. off to the upper right at 45 degrees).

The standard deviation of the selected pixel positions over all the 28 exposures was computed, and a plot made of the sqrt of the mean counts in the pixel versus the standard deviation of the counts.

If the noise is Poissonian, then these are related 1:1. The plot below shows that this is only approximately the case (solid line). A closer model is that the noise is about half of what is expected (dotted line). Why the noise is sub-Poissonian is open to speculation, but must be due to some slight smoothing we don’t account for (possibly iraf introduces some smoothing when rebinning the data for the subpixel shifting).

The points at the lower left are those from the scattered light off the lunar edge. The other points are the pixels in the 5 small patches indicated by the green circles in the previous figure.

It’s difficult to fill in more points because it’s hard to find flat regions of the appropriate luminosity. Flat regions are needed because the technique is very sensitive to slight misalignments in the images (if one examines regions where the luminosity is changing rapidly — such as near the lunar edge, craters, strirations etc on the lunar face — the standard deviation goes haywire).

Assuming Poissoninan noise in test data generated from synthetic moons appears to be a conservative option, as it is pretty close to the correct value and possibly an overestimate, so currently I’d recommend that.

Update and error correction: The ADU conversion for this chip is approx. 3.8. The statistics above are were done in ADU, not photons. This of course accounts for the factor of two (=sqrt(3.8)) problem above. Thanks to Peter for spotting this error.

Using photons instead of electrons gives a pretty close fit t the 1:1 relationship. We could try this for a range of lunar exposure times, using the same flat regions on the moon and the halo off the edge, to fill in the gaps for a range of luminosities.

Fit the ES directly?

Post-Obs scattered-light rem. Posted on Oct 28, 2011 01:16PM

Peter sent me images of the ideal crescent moon for a range of Earth albedos — 0.0, 0.29, 0.30 and 0.31. I made a map of the scattered light to see how much brighter the ES (Earthshine) is than the scattered light from the crescent. Over most of the dark side, ES does indeed dominate over the scattered component — which augers well for measuring its ratio relative to the BS (bright side).

Top left: ideal moon outside the atmosphere with NO earthshine at all (Earth albedo = 0) i.e. we see the BS (brightside) only.
Top right: scattered light from the BS only.
Bottom left: scattered light of the same ideal moon, but with the ES for albedo=0.30 included.
Bottom right: the difference between the top right and bottom left images.

Interestingly, one can subtract the modeled BS to obtain the ES over the entire lunar disc. The isophotes of the remaining light are then nicely round around the full, ES-only illuminated disc, as seen in the lower right panel. This might be a way to check that the solutions are coming out the way they should — i.e. fit the BS and scattered light from it only, remove it — and the rest should be the ES. Errors in modeling the BS will show up as asymmetries in the ES that remains. Perhaps we could think about solving for the ES directly, by fitting a lunar model with a BS only, and recovering the ES on the lunar face directly?

GPU- versus CPU-based modeling of scattered light

Post-Obs scattered-light rem. Posted on Oct 21, 2011 02:53AM

I have spent some time examining to what extent GPUs could help us speed up scattered light fitting of ideal moon images to the observed images, while visiting Swinburne in Melbourne.

Ben Barsdell (Swinburne) had some c++ code to convolve two fits files using an NVIDIA compatible GPU (GTX480) running CUDA. The FFT library is FFTW, the same as I have been using for CPU-based modeling of the scattered light.

Upper left: ideal lunar image (intensity is log scale).
Upper right: convolved with our best PSF using CPU based FFT.
Lower left : convolved with PSF using GPU.
Lower right: ratio of the two methods (seen in more detail below).

On a desktop my fortran code calling FFTW does the three FFTs needed —
ideal moon image, psf image, their multiplication in the Fourier
domain, and the inverse FFT for the final result — in about 1100
milliseconds (ms). (This excludes the time needed to insert the 512×512
images into 1536×1536 images to sufficiently reduce edge wrapping
effects, which brings the total runtime to about 3000 ms). So the FFTs
are taking about 300 ms each.

Using the GPU, we attained FFT
speeds of about 40 ms each, a speed of a factor of 10 or so. This is
typical of what Ben expects for such applications (he is doing a careful
study of the types of astronomical problems GPUs can be profitably
applied to, and where the bottlenecks typically lie.)

this means we can speed up our light modeling code by about 10 times — possibly
quite a bit more because the overheads per modeled image can be reduced
quite a lot by careful programming, since we want to explore a large
parameter space, but don’t need to do the same overheads each time we

VERY IMPORTANT: the CPU code did the FFTs in double complex precision, whereas the GPU was doing single complex precision.

compared the output images of both methods — for the case of scattered
light from an ideal moon with a power law fall off PSF with a slope of
about r^-2.8.

VERY IMPORTANT: there is significant structure left in the methods if we divide the CPU output by the GPU output, as shown int he image above.

The scatter in the mean about 1.0000 is 2.028E-4 and there is a frame minimum of 0.9936 and frame maximum of 1.003, so the deviation from unity in the ratio of the two methods is not worse than ~0.7% anywhere on the frame. There is certainly structure, and it looks like it might be too much for our purposes! (We would like this to be better than 0.1% at the very worst). We are checking if this has to do with the single precision used.

Unless this problem can be solved, it is not clear that the speed gain with the GPUs
is worth having!

PSF of Vega obtained by Tom Stone

Exploring the PSF Posted on Oct 20, 2011 03:10AM

Peter sent Chris a file called “ROLO_765nm_Vega_psf.dat”

which contains the PSF of Vega measured by Tom Stone.

Here is the profile:

the horizontal scale is log of r in arsecs.

the inner part is something like a Gaussian, like King finds.

the halo outer part goes at r^-2.4, in the range 1.2 < log(r) < 2.0,
so steeper than King but not as steep as our steepest profiles
to date (these are r^-3).

The very outer parts are certainly affected by sky subtraction,
as the light will be well below sky at log(r)>2, one could fix this
probably by choosing the sky so that the halo continues at the
same gradient, but this is of course arbitrary.

It seems that for a wide range of telescopes and instruments,
the distant stellar light falls off as a power law — we see this
in the ES telescope, a 35 mm camera, King’s profile, and a
range of other instruments/telescopes summarised in a paper
by Bernstein (ApJ, 666, 663, 2007).

The slope of the power law can change even on the same
telescope/instrument! We see different powers on different
nights. This is important!

PSF Profile for Altair

Exploring the PSF Posted on Oct 20, 2011 03:02AM

Attached plot is the Altair profile from the latest run.

The data don’t go quite as deep as Menkab, but are highly
interesting all the same.

for the IR, V and VE2 filters, the slope is very close
to our canonical r^-3
or so which we get for the moon.
it was a very clear night, so that’s SUPER!

for the B and VE1 filters the halo is rather different — as
can be see in the plot!

we might have some sky subtraction problem with VE2, so let’s
not worry about that too much at this point.

the peculiar profile is definitely B — as before with Menkab —
there is a peculiar hump in the psf at log(r) ~ 0.8 to 1.0
(6 to 10 pixels). We saw the same in Menkab and wondered
about focus.

Could there be something funny going in with internal
reflections in the B filter, so that an extra halo appears around
stars in that filter but not in the others — or at least not

Light far from Moon in Canon 35 mm camera

Exploring the PSF Posted on Oct 20, 2011 02:58AM

We obtained images of the full moon from Sydney with the Canon
35 mm camera, reaching out to about 15 degrees from the moon
— three times further out than the King profile reaches. We are
curious about how far out it goes as a power law.

The plot shows the profile done for a range of exposure
times, getting longer and longer, at the cost of overexposing the
moon and halo around it, but better sampling the faint halo
far away.

I have shown the raw data merging into the background sky in the
bottom panels. Subtracting this sky gives the halo only profile in
the middle panel for the range of exposures.

Top panel shows the overall profile by using only the valid (not
overexposed) parts of each curve — by simply accounting for the
different exposure times — nothing more has been done. They
sit on a pretty well defined locus all the way from the edge of the
moon out to the edge of the frame (~15 degrees out) and follow
roughly r^-1.8. It’s probably flatter than this closer in. This is of
course the scattered light, not the PSF per se, but very far from the
moon — like > a few degrees — the moon is essentially a point source
anyway (it’s only 30 pixels across on a chip 3900 pixels wide).

I learned something important! The profile is r^-1.8 when sky subtracted!
We can follow it well beyond the point that the halo is much fainter than
the sky. So King I think is talking about the sky subtracted profile as well.
I have been wondering when the King profile would actually join
the sky and become a DC component… of course it doesn’t, that’s
the point. The DC component, i.e. Rayleigh scattering (?) is caused
by the bright source as well, but is not considered part of the profile.
I guess. So if we were trying to model the scattering over very large angles
we’d have to consider both components. My guess is that for our
ES telescope the field of view is so small that the scattered light is
the halo only — the Rayleigh component is negligible. One starts
to see it in the 35mm camera data at about 1000 pixels (1 pix
is approx 1 minute in these data) so about 10 degrees to 15
degrees from the moon (lower panel shows a blue curve which
essentially joins the bias level at large r, whereas the green and
black curves are flattening out to a level which is bias + a fair
bit of sky). In these data, the sky is about 5*2.5 = 7.5 magnitudes
below the full moon surface brightness (seen in upper panel, with
brightness of the moon at log(r)=0 and the (subtracted) sky having
similar brightness as the halo at about log(r)=3 — beyond which one
traces the halo below the sky).

Altair and Menkab – the psfs

Exploring the PSF Posted on Oct 12, 2011 12:12PM

We now have good radial profiles of Altair and Menkab. Altair was observed in very good conditions, and its profile is close to the expectation of r^-3 for the diffraction limit — in three of the 5 bands. In B and VE1 funny things are happening which we don’t yet understand. The Menkab profiles have halos like r^-1.5 — much broader. The plots below compare both stars:



We think that Menkab might have been taken on a not-quite-perfect night photometrically. We’re looking into this, so watch this space!

PSF of Menkab in 5 bands

Exploring the PSF Posted on Oct 09, 2011 05:38AM

Peter took data on Menkab in 5 bands (October 7th, 2011) – B, V, VE1, VE2 and IRCUT. Surprisingly, the halo around the star follows r^-1.5 in all bands. Was the night a bit hazy? On a clear night we have been expecting r^-3.

The central PSF, within ~5 pixels, is very regular, as the stars are nicely round (Altair, with the best inner PSF to date, was a very boxy image — see posting on this below).

The VE2 image has a significantly broader transition region to the outer halo. Quite strange!

The 5 profiles are here :

The are compared to the profile we got for Altair in V band a few nights ago and our best guess profile in V from the modeling the scattered light from the moon.

The halo slope is about r^-1.5 in all 5 bands for Menkab. They also wiggle a bit, unlike when we get r^-3, which is straight as best we can tell. The “shutter bounce” effect is also much harder to see because, presumably, the flatter halo is washing it out. It’s visible but weak in the 2-d images.

This is all a bit surprising and very potentially very important. We may be much more dependent on the atmospheric conditions on each night that we thought.

It would be very good to do aperture photometry of the star as a function of time in each band for each obtained image, to check if the night really was “photometric”.

PSF in a Canon 35 mm camera

Exploring the PSF Posted on Oct 04, 2011 02:45PM

We decided to look at the scattered halo light around the moon in a conventional 35 mm Canon camera, out of sheer curiosity.

The field of view of the Canon of about 10 degrees across, with images of 3888×2592 pixels. There is a pincushion effect toward the very edges but otherwise the halo is well traced. 12 images starting from an exposure time of 1/2500 seconds and increasing exposure time by factors of two at each step were taken. The images were taken from Chris’ back garden in Sydney on a very clear night in September 2011.

Upper plot: halo around the saturated moon (seen at left) for the five longest exposures. The uniform separation of the profiles by 0.3 (in the log) is just as expected for factors of two increase in the exposure times, so the system appears to be linear. Lower plot: log-log plot of the halo flux versus distance shows a very closely followed power law with slope ~ -1: this we call a “Toto” profile (= r^-1). The earthshine camera instead shows a “Mitzi” profile, r^-3, which is as expected for a diffraction limited telescope. A 35 mm camera has a great deal more scattered light!

What the Skycam saw

Observing log Posted on Oct 03, 2011 08:29AM

A selection of Skycam shots to show what you can see. From top left : a hazy night, a very hazy night (ice crystals?), a very clear night, water on the sky cam and the laser star, the skycam on a wet afternoon and the crescent moon on a bright sky just before sunset.

Altair maps the stellar psf!

Exploring the PSF Posted on Oct 02, 2011 08:23AM

We took a few hundred 0.4 second exposures of Altair, to measure the stellar PSF. Plot below shows Altair (green) versus our current best model (red) of the PSF based on fitting the moon. Note x axis is log(r/pixels).

The match is excellent, especially for the outer halo with its r^-3 powerlaw! Disagreement in the inner PSF (r<3 pixels, log(r)<0.5) is because Altair is very elliptical — so the radial PSF shown here has a lot of scatter. Note that this might be due to saturation/miscentering during the coadd – we’ll look at that.

Dome and telescope pointing

Observing log Posted on Oct 01, 2011 07:21AM

Ben has created a map of where the dome should be for a range of telescope pointings. Map works well so far! We are adding data points to it as we go along, and also mapping out the edges of the dome slit at various positions:

A better resolution version is available here:

Comparison of brute force and FFT methods for computing scattered light

Post-Obs scattered-light rem. Posted on Oct 01, 2011 02:11AM

Tested two methods for scattering light from an ideal moon. The Ideal image is shown upper left (log scale) with a completely dark sky, narrow BS crescent and ES.

Bottom left is the moon after scattering the light using our current PSF and a brute force method — simply add all the pixels in the ideal image multiplied by the PSF. Bottom right is the same, but using an FFT method instead. The scattered light at the edges of the frame is too high to simply use the 512×512 frame in the FFT, instead the idea moon is placed in the center of a 1536×1536 frame, the FFT carried out, and then clipped back to 512×512. Upper right is the ratio of these two methods. There is a lot of structure at a very low level — the display limits on the ratio are set at 0.9993 to 1.0009, and the ratio is with 0.1% of unity everywhere on the frame. This should be sufficiently accurate for our purposes, but we should double check!

The histogram of pixel values in the ratio image is shown below:

Front Iris not affecting throughput?

Shutters Posted on Sep 30, 2011 01:05PM

Chris and Peter observed the bright star Markab on the night of September 30 2011. We noticed that changing the size of the Front Iris — from 30 mm setting to the 40 mm setting had no effect on the amount of light coming from the stars. In both positions we were getting peak counts in the star of around 56000, and total of 246000 in a 10×10 box centered on the star.

We were expecting the flux to increase in going to the 40 mm iris from the 30 mm iris by a factor of (40./30.)^2 = 1.8.

Are we misinterpreting what this iris does – or did it not move? We will ask Dave about this cosmic mystery!

Night with strong halos

Exploring the PSF Posted on Sep 29, 2011 01:46PM

Sep 29 — Peter and Chris observed Markab — noticed much broader halo around the stars than usual. Image below shows that this can even be seen in the sky camera.

Left: clear night from 2011-09-27, Jupiter in center of frame. Right: not photometric conditions 2011-09-29, Jupiter has a slight halo. Note that the bright “star” right above Jupiter is possibly an internal reflection (of Jupiter?) in the sky camera.

We will observe Jupiter through whatever this stuff so we can compare directly to previous determinations of the PSF.


Exploring the PSF Posted on Sep 29, 2011 03:30AM

The plot shows astigmatism of the psf across the image plane. A short single exposure of the open cluster M7 was used, exposure time = 60 seconds. Ellipticity is shown by the length of the lines in the lower plot — and the lines are aligned with the position angle of the sources. The upper plot shows that ellipticity rises pretty sharply towards the CCD edges — from about 0.05 in the center to about 0.4 at the edge. n.b. ellipticity is defined as e = 1 – b/a, where a is the semimajor axis and b the semiminor axis. Ellipticity at the center of the field is about 0.05 – not 0.0. These results are for the ellipticity of the inner core of the PSF (it’s measured out to 3 pixels radius). Whether the power-law halo of the PSF is non-round on any scales is still under study.

Shutter timing stability from full moon observations

Shutters Posted on Sep 29, 2011 03:19AM

On night of Septembter 10, 2011, 28 images on the almost full moon were obtained at 0.015 second exposures. We compute the mean level of these images. They are dominated by the full moon, the sky flux is negligible, and the moon is well centered.

The mean count rate for these frames is 5546.7 counts / 0.015 sec and the standard deviation of the mean counts over all 28 frames is 8.4 counts – if this standard deviation is all due to shutter timing error for these frames, the timing error is ~1.4%. On these short timescales the shutter timing is at least this accurate.

Longer sequences with bias frames in between the lunar exposures would be good. None of the frames dropped out, but we know that this can happen occasionally, with as much as 20% of the frames dropping out.