Forum Replies Created
-
Posts
-
Thanks for pointing these issues out, Paul.
* The issue with the page <https://britastro.org/observations/user.php> should now be fixed.
* Animated GIFs should work fine, though there is sometimes a lengthy processing time after you upload them. This sometimes means they may not appear straight away. Normally this is a few seconds, but in one extreme case (with many frames) I’ve seen a processing time of two minutes.
* I received an error report from the issue you had with the comment editor, and I think this should now be resolved. The problem was caused by your comment being over 256 characters, which should have been fine, but my code couldn’t handle it… 🙂
* There is indeed an issue with some images being erroneously tagged with the wrong objects. This is a feature of the migration process of images from the old system to the new, and should not affect new uploads. Basically, the old system did not tag which objects were in which images, and so I had to populate this information by searching through the metadata associated with images for the names of objects. In most cases this worked very well, but unfortunately “Copernicus” is both the name of a Moon crater and also the star 55-Cancri. Also, images of comet M3 (Atlas) are unfortunately also tagged with Messier 3. At some point, perhaps we’ll find a volunteer who wants to go through and manually correct some of these mis-tagged images…
Thanks for pointing this out, Mike. I had unintentionally removed the ability to add links to the descriptions of images (and comments too). The “link” button should now have reappeared.
Hi Alan,
Thanks for your kind words! Plate-solving refers to the process of looking at the pattern of stars in an image, and attempting to match it against a star catalogue in order to work out the celestial coordinates of the image. We use a piece of software called astrometry.net to do this. However, the software takes a few minutes to run, and newly uploaded observations join a queue to be processed, which means there is a delay between you uploading an image and the celestial coordinates appearing in the associated metadata.
When the plate-solver finds a match, you should see a panel to the right-hand side of your image with a tick-box “Enable overlay”. This will overlay a star chart over the top of your image.
Best wishes,
Dominic
Martin,
I inadvertently set the log-in page to redirect to my profile at around 2pm, and it was like that until around 2.45pm. Which was a bit of a screw-up…
To make this more awkward, most web browsers cache web page redirections for around 24 hours. So, if you tried to log in with a particular browser while it was broken, you may continue to have trouble logging in for a little while.
In Firefox, you can fix this by going to History -> Clear recemt history…. If you delete your browser history from the past couple of hours, it’ll forget about the erroneous redirect. Or, if you do nothing, it should fix itself by tomorrow.
Sorry about that,
Dominic
The new image gallery software is able to do this, but currently it is only permitted for gallery administrators (e.g. archivists uploading images on behalf of BAA sections) to associate multiple files with a single observation.
We can certainly consider rolling this out to all BAA members in due course, once we emerge from the immediate post-launch testing phase.
Existing links should continue to work. They will point to an archived version of your old member page content, with some features disabled – e.g. the ability to leave comments.
The new member albums are now live. We had a few minor teething issues earlier today, but you should now be able to upload images using the new interface.
I think people here in Cambridge would say it’s an indication of just how good the Gaia data now is that all these biases can be measured and corrected.
None of these effects were measurable before, because they were entirely hidden in random noise. The measurements are now so stable and repeatable that these systematic skews start becoming apparent.
This is one of the reasons why so much work goes into every Gaia data release, and why successive data releases can’t simply come out at the push of a button. When you get rid of all the random noise, what’s left is the systematic noise, and that’s where the really hard work begins.
I work on the PLATO mission, and we’re seeing similar trends there. We set E2V the challenge of building the lowest-noise CCD they’ve ever made. What happened last year when they got rid of all the random thermal noise? They discovered entirely new leakage current patterns which no mission has ever seen before, because they’d always been entirely hidden in the noise before.
The G-band was never part of the standard Johnson-Cousins system, and so my understanding is that it’s not particularly standardised. In fact, professional observatories now tend to all have their own bespoke sets of filters, and so you can’t directly compare a PanSTARRS g with an SDSS g, for example. Though they’re very similar.
As I understand it, the Gaia G-band is indeed the unfiltered response of its CCD. Though, of course, Gaia doesn’t have any atmospheric extinction, so it won’t be a perfect match to anything you can get on the ground.
If one is being really pedantic, there are multiple different revisions of the Gaia G-band, as each data release includes improved instrumental corrections (which depend on colour). If you google for Gaia photometry you can find plenty of long gory papers about the process.
I’m impressed that you manage to achieve 0.1 mag accuracy!
I have also played around the background subtraction and flat-fielding with my meteor camera, which I use to get as many stars as possible when calibrating the pointing and lens abberations using astrometry.net. But the stars have a tendency to be horribly saturated (which isn’t an issue for me).
Presumably you have to tweak the gain manually for each target, to place the star optimally within the very limited dynamic range you have? I’ve noticed that stars often have quite evident “ringing” artifacts on either side of them, due to a analogue signal losing its higher frequency components, which would be another noise source. The limited number of pixels is another factor that I would imagine might making accurate photometry difficult.
Yes – unfortunately CUP is going through a lot of changes currently. You may have heard the news that CUP is going to merge with Cambridge Assessment in 2021. The university says there will be lots of exciting opportunities for CUP to produce “digital education” tailored to exam syllabuses. But at the same time, they’ve admitted they will be laying off a significant number of staff:
https://www.cam.ac.uk/news/cambridge-university-press-to-join-with-cambridge-assessment
I fear the future is not very bright for the bits of CUP not connected with “digital education”, given it will soon be a sub-division within an exam board.
The BAA Forum Terms of Use do say:
“We ask that contributors to the forum and member pages use their full name, to promote a sense of collegiality and community amongst our members.
We certainly consider that to be best practice. However, we currently only enforce this where we suspect dishonesty.
It is important to recognise that many people have very reasonable concerns about posting information about themselves online. People who work in certain professions (state school teachers, social workers, civil servants, etc) can live under the threat of immediate dismissal in the event of a single online post which is perceived to violate their employer’s code of conduct. It is understandable that such people increasingly want to err on the safe side (or feel extreme pressure from their employers), and prefer that their posts should not come up in Google searches for their names.
Others may simply feel they don’t want to release information about themselves to fraudsters Googling for their name.
If there are specific concerns, the website administrators are able to cross-reference any forum post against the BAA membership database.
Grant,
Using the median isn’t a good way to exclude outliers, especially if a significant number of pixels are outliers (stars in a busy field). If, let’s say, 10% of pixels contain stars, then those outliers at the top of your distribution effectively mean that your median gives you the 55% percentile of the sky background distribution, which might be rather a noticeable skew towards the brighter end of the distribution.
Of course, that would be far better than taking the mean of a distribution containing stars, because the latter really would give you a nonsensical result. But to do this well, you really want to entirely get rid of the stars from your sample of pixels.
As Nick says, the way to do that is via “sigma clipping”. Take the mean and standard deviation of your pixel brightnesses. Exclude all pixels which are more than X standard deviations away from the mean. Iterate a few times.
I’ve come across this problem in the context of doing background subtraction from the images from my meteor cameras. In that context, the median has an additional issue that it’s quantised. If you take the median of a large sample of integer values between 0 and 255, you can’t get the noise below 1 ADU unit. With the mean of large numbers of samples, my sky background model sometimes reaches a formal precision of about ~ 0.2 ADU unit.
I would assume Nick has enough bit depth in his data that quantisation is unlikely to be a worry, though.
Cheers,
Dominic
Nick,
You’ve got me attempting to do undergrad statistics at 2am after a couple of beers, so this may be a pile of nonsense. But the formula I get is as follows…
* By definition, SNR = Signal / sqrt(Sky_Noise^2 + Photon_Noise^2)
* Define the sky noise in an individual pixel to be sigma_sky. If the standard deviation of M sky pixels is measured to be sigma, then your best estimate of the sigma_sky = sigma*sqrt(M/(M-1)). The sqrt() term comes about because sigma is a slight underestimate of sigma_sky, since the same sample of M sky pixels was also used to calculate the mean sky level relative to which their standard deviation was measured. For large M, sigma_sky=sigma.
* The total noise in the summed brightness of all N pixels within your aperture is sigma_sky*sqrt(N) = sigma*sqrt(NM/(M-1)).
* This equals Sky_Noise in the SNR equation above.
* Now for photon noise. Define the number of photons collected from the star to be N_photon. By the definition of the gain, N_photon = S/G. The noise in N_photon is sqrt(S/G) since it is a Poisson process. Thus, the noise in S is sqrt(S/G)*G = sqrt(SG).
* Putting it all together…
SNR = S / sqrt(SG + sigma^2 * NM / (M-1))
* My formula is closer to yours than the AAVSO’s, but not quite the same.
* In my formula, SNR decreases as G gets larger. This must surely be correct? Higher gain cameras have more noise. In your formula, and the AAVSO’s, SNR increases with G. This doesn’t seem to make any sense.
* I think this formula behaves correctly when images are stacked. When you stack X images, sigma is divided by sqrt(X), and G is effectively divided by X. Net result: SNR increases as sqrt(X), as you expect.
* I’ve never done any aperture photometry in my life, so the above may or may not be complete nonsense.
Cheers,
Dominic
Jean Meeus’s statement that it can only be deduced from observations is (unless I’m mistaken) only true for UT1 – a time standard which strictly follows the Earth’s rotation.
The time that the clock on your wall reads is UTC, which is pinned to International Atomic Time (a realisation of TT), but has leap seconds added to keep it closely aligned to UT1.
The quantity you’re almost certainly looking for is (TT-UTC), which is exactly 37 seconds currently, and changes in 1 second steps when leap seconds are added to UTC.
Whilst observations certainly are needed to determine (TT-UT1), it’s not a very useful quantity for most people, because UT1 is only used for a few specific applications that directly involve the Earth’s rotation. The ones that come to mind are calculating precise sidereal time, and calculating the Earth’s rotation angle during eclipses. Oh, and of course deciding when to put leap seconds into UTC! 🙂
If the problem you’re working on involves the times when the Moon is at certain positions in its orbit, then that’s a problem where the Moon’s orbit is defined in TT, and you want to report times in UTC. So UT1 doesn’t come into it.
Your question doesn’t make sense!
If you’re after (TAI-UTC), then that’s not an observed quantity. It’s defined by when leap seconds are inserted. A simple list of leap seconds over recent years will give you an answer that is 100% accurate by definition:
https://www.ietf.org/timezones/data/leap-seconds.list
The current value is precisely 37 seconds.
But… if you’re after UT1-UTC (I can’t quite think why you would be – it’s only relevant to rising and setting times!), the full gory details are all here with awful lot of decimal places (see Bulletin A):
https://www.iers.org/IERS/EN/DataProducts/EarthOrientationData/eop.html
However, UT1-UTC is maintained at a value less than 0.5 seconds by inserting leap seconds whenever it drifts outside that range. If, as you say, you are only interested in accuracy to the nearest second, then you can assume that UT1-UTC always equals zero.
This was indeed a very beautiful meteor. Two of my meteor cameras caught it, on opposite sides of Cambridge…
https://pigazing.dcford.org.uk/moving_obj.php?id=20200922_035352_b29217a987c61766
https://pigazing.dcford.org.uk/moving_obj.php?id=20200922_035353_ca8e636784ff1d42The times on the Pi Gazing website are all in UTC, in case you’re wondering.
I haven’t got around to doing any triangulation with my data yet, and I also don’t have built a mechanism for exporting data from PiGazing into a format compatible with the larger UK networks. But it sounds like you’ve already got plenty of data for this one! 🙂
Dear Alan,
I’m sure the BAA Office will be very glad to help you with this. You can find their contact details here:
https://britastro.org/contact/Contact-the-BAA
Best wishes,
Dominic
White dwarfs have good thermal conductivity, so the core won’t be much hotter than the surface.
Young white dwarfs start life at ~10 million K. But that phase doesn’t last long. Heat dissipation scales as T^4 (Stefan’s Law), so the initial cooling is very rapid.
A rough calculation suggests that if a white dwarf takes 10 billion years to cool to 10,000 K, the same white dwarf would take only about a decade to cool from 10^7 to 10^6 K, and a few hours to cool from 10^8 to 10^7 K.
