Forum Replies Created
-
Posts
-
I’m a big fan of Intel NUCs. There is a bit of fiddling involved in setting them up, as you usually have to buy the memory and SSD separately, and then install an operating system yourself, though a few pre-built kits are available. The higher spec models are very powerful machines, and they seem pretty robust. The one on my desk is 12-core / 32 GB RAM / 1 TB SSD – not a bad system for £750.
Conversely, if you go down the laptop route but are disappointed by the lack of connectivity, bear in mind that USB-C ports do give you some options. You can buy hubs cheaply that can split a single USB-C port into HDMI, ethernet, and USB ports. Despite being a tiny plug, USB-C is actually a 24-pin connector and so it can deliver roughly four USB-ports-worth of bandwidth. I’m no fan of USB-C, but the performance isn’t *that* bad. 🙂
Tim,
I’m guessing you’re referring to the image-download button, which used to open / download the original full-resolution image file. You can still do this.
If you right-click the image and select “Open image” (the exact wording will vary between browsers), your browser will open the full-resolution image.
Alternatively, underneath the image, in the section “Files associated with this observation”, you can download the original image file onto your computer for viewing in your favourite graphics package.
Best wishes,
Dominic
1) Problems with the plate solver
We’re aware that the plate-solving software is producing a high rate of false matches currently.
I’m surprised by this, as we’re using <astrometry.net> with mostly default settings, and it is supposed to be quite robust against finding spurious matches. However, I’ve told it that we have no prior information about the field-of-view of each image, so it’s searching for matching star patterns from a full range of length scales, from 30 degrees right down to 2 arcminutes. Consequently, the database of star patterns it’s using is extremely large: about 30 GB of data.
My guess is that we’re getting spurious matches because there are an awful lot of possible star patterns that an image can spuriously match when we’re checking it against so many possibilities. The sky is quite large when you look at it with a 2 arcmin field-of-view.
As for finding Jupiter in Pavo – well, astrometry.net looks only at stars, and knows nothing about planets. This is no more surprising than some of the meteor spectra which are also getting erroneous fits. In general, I would not expect planetary images to get successfully plate-solved as they wouldn’t contain enough stars.
At some point, it would be nice to improve this, and once we do so, it should be possible to retrospectively update the plate solutions of old images (at the cost of a few thousand hours of computation time). However, fiddling with this is likely to be a large project, and I’m not volunteering to do it imminently.
2) The sky map
Note that the sky map only shows 400 images at a time. You should see a message at the top along the lines of: “Showing latest 400 of 2568 observations. Older observations have been omitted to avoid excessive processing time.” Note that it also cannot show images which haven’t been plate solved, for obvious reasons.
You really don’t want it to try to display thousands of images at the same time.
If your image isn’t showing up, you probably need to make your search criteria more specific.
Dear Alex,
Thanks for this useful bug report.
* I’ve fixed the lack of spell checker. I hadn’t realised there was a switch I needed to set to enable it.
* It was always our intention that all times should be entered, recorded and displayed in UTC. A mistake on my part meant an erroneous timezone conversion was happening in the display code. So, the observation you added earlier today was recorded correctly, but was being displayed incorrectly. This is now fixed.
* Unfortunately, this has opened a whole new can of worms. If you look back to observations you uploaded over the summer. They are now showing incorrect times. Upon further inspection, these times have been faithfully migrated from the old Drupal system. But the previous f***ing content management system was doing everything in local time, not UTC. Hence the timestamps from all our old data are wrong. Theoretically this could be fixed, but it would be a heck of a lot of work…
Best wishes,
Dominic
Sorry about this.
We did test that comments were migrating properly, but it seems some may have slipped through the net.
Unless we discover that this is a really widespread problem, it’s probably going to be quite hard to fix retrospectively now, as we’d have to merge the old and new comments.
It was noticeable that in the previous system relatively few images attracted comments, and our hope is that by making comments more prominent in the new system, images will start attracting a bit more discussion.
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
