Forum Replies Created
-
Posts
-
I think we need to draw the line somewhere. The object tagging need to be good enough to enable observers to search for images of their favourite objects, and BAA Section Directors need to be able to quickly find images that may be of interest to their sections. BAA members do often take images of quite faint / obscure comets and asteroids, and may want to compare them with others. But beyond that, the tagging system should be as simple as possible.
Already a significant fraction of users clearly find the tagging quite tricky to use, and I am typically cleaning up the tagging of several dozen images each week.
The BAA Sections haven’t historically tended to collect large numbers of images of planetary moons.
As it happens, although the asteroid database is indeed large, it was very easy for me to build. I downloaded a copy of Ted Bowell’s database of asteroids, and filtered on objects with more than 10 years of observations and more than 500 observations in Ted’s database. That yields 155,000 asteroids… actually a very manageable number to just stick in a computerised database.
As for comets, I just asked the Comet Section to give me a list. I got a list of 4,000 comets, and they’ve been happy to add new comets themselves as they appear.
The old BAA Member Pages (before December 2020) did allow observation dates to be set in the future. Indeed, that may even have happened rather often: from memory, if people forgot to set the observation date, the default was set to the current time with a granularity of 15 minutes, while the upload time was set precisely. All of that was faithfully migrated across to the new database, even though the user interface no longer allows new observations to be in the future.
For some images, it’s very important to record the observation date – for example, planetary images, variable nebulae, etc. But as you say, there are other types of observation (e.g. blink comparisons) where it’s more complicated. For some deep sky images, where the photons have been collected over many nights, it’s very complicated indeed.
I think it would be reasonable to set the “observation date” to the date of the most recent observation, but there’s no “BAA convention” on this. What’s most important is to provide the details in the explanatory text. I’m sorry that your explanation got missed in the migration – there were a small number of comments that had migration issues, mostly due to character encoding issues.
I fear this isn’t the answer you were looking for, but if I were you I’d buy some more RAM.
Python is notoriously memory hungry, and 4GB isn’t a lot, especially if it’s being shared with other applications. I don’t know why virtual memory isn’t helping, but seemingly it isn’t. It would have been horribly slow anyway. Depending on the age of your computer, an 8GB memory module is likely to cost less than £50. The Crucial website has a system scanner to tell you exactly what parts to buy.
If you can afford it, a 16GB upgrade might be a safer bet.
Hi Robin,
Thanks for reporting this. The HTML filter that I use to ensure the descriptions don’t contain nefarious code was apparently blocking the “target” attribute on web links, and so the “new window” option was getting blocked. I can’t see any reason not to allow this.
It should now be working, and you may well find that any links you have previous set to open in a new window will suddenly now start working as intended.
Cheers,
Dominic
Hi Robin,
I think the permissions issue you had is now fixed. You should now be able to flag any of your observations which have been incorrectly plate solved.
I’ve flagged the two images you linked above myself, and also taken the liberty of updating the object tagging on the Nov 2020 image, so that it will come up in any searches for images of those two novae. The two novae weren’t in the object database at the time you uploaded the image, but I added them a few weeks ago.
Thanks again for reporting this,
Dominic
Hi Paul,
Many thanks for your offer to help.
To fill everyone in, the plate-solving facility of the new image galleries is certainly somewhat experimental. When it went live in December, there were a few teething problems that we identified. Among these:
* Plate-solving images that cover a very small area of sky can be very slow, and we imposed a time limit of 4 minutes on the software (and on a rather slow computer). In practice, some images can take up to 20 minutes of CPU time.
* We did not correctly solve images with EXIF rotation headers.
* We did not correctly solve colour-inverted images.
* We had a significant number of false positives – for example, photos of grass which supposedly resembled some star cluster.
Within recent weeks, I updated our automated software to fix these issues, and invested 8,000 CPU hours in re-solving the entire archive of 47,800 images – this time with a time limit of 45 minutes for each image, and on a computer twice as fast as the one I used in December.
The result has been a very dramatic increase in the number of images for which we have sky coordinates – specifically, an increase from 11,950 to 23,363. We do still have a significant number of false positives, but in the short term we think the best way to deal with those is to offer a facility to flag them (as Robin refers to). BAA members are able to flag their own images, and a small number of administrators also have the power to do so.
I’m not sure we have any immediate plans for further developments, though we’re always interested to hear feedback. We’ll certainly let you know if we have ideas for ways in which you can help.
You might find the two plots below rather interesting. The first is a histogram of the time taken by astrometry.net to solve the images in the archive. The second is a scatter plot of run-time against the angular width of the image.
Best wishes,
Dominic
PS – I’m about to look into Robin’s original issue now, and will post separately when I have more news.
Hi Robin,
Thanks for reporting this.
The plate-solving system does produce a significant number of false positives, unfortunately. The reporting system was introduced last weekend as the easiest way to remedy this, and when I notice false positives myself, I often flag them right away. However, there’s clearly some outstanding permissions issue that my testing didn’t pick up.
I won’t be able to look into this until very late tonight, but I’ll aim to get this fixed for you tomorrow.
Thanks,
Dominic
Denis,
These are good questions, but as Richard suggests, they will probably remain unanswered for some time – and perhaps forever!
The orbits obtained by meteor cameras are only very approximate, and in particular it’s quite difficult to measure the velocity of meteors accurately. This is unfortunate, since even a small error in a meteor’s velocity can make a big change to the inferred orbit.
The result is that we don’t really know where this object was a few years ago, let alone any further back in time. Its composition will probably give us some clues about where it was 5 billion years ago, when the solar system formed. Where it’s been hanging out for the past 5 billion years, we can only guess.
But there are clues. Its aphelion is rather close to Jupiter, so in all likelihood it was thrown onto an Earth-crossing orbit by an encounter with Jupiter’s gravitational field. Was this recent? Probably yes. Earth-crossing orbits are quite unstable, so that encounter almost certainly happened in recent decades / centuries.
Has it had previous close encounters with the Earth? Probably not very close. If it had done, its orbit would have been perturbed. Specifically, its aphelion would no longer be close to Jupiter. The encounter would either have thrown it out the solar system (most likely), or closer in to the inner solar system (unlikely). But it probably has crossed the Earth’s orbit before. It would be relatively unlikely to hit a bullseye on the first attempt.
Best wishes,
Dominic
All modern processors have quite sophistocated throttling (a.k.a. power management).
The CPU will slow down when it’s idle, or when it gets too hot. Even in a desktop PC, the very fastest clock speeds (often called “turbo boost” or similar) can usually only be sustained for minute or so, unless you have some serious cooling.
So, I am slightly dubious about the wisdom of putting a power-hungry i7 processor in a “fanless” case. It won’t overheat, but I doubt it’ll achieve nominal performance unless you put it in the fridge.
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
