Update on Trajectory Mapping: Object position errors, part 1
-
by
pravk7
scientist, admin
Hello,
As mentioned in a different discussion thread, there’s been a hold-up in getting Asteroid zoo classifications through the pipeline. There are basically two reasons for this: (1) multiple projects submit asteroid candidates to the Minor Planet Center using the same Catalina data; the MPC and the various projects are working on a system to better deal with this. (2) various sources of error in the data have made mapping clicks to trajectories a minor challenge.
This second hurdle is something the science team can address, and we are very close to fixing this.
There are two major sources of error that make mapping clicks to trajectories a difficult problem:
(1) user click offsets — natural deviations from the object center due to how different users perceive object centers, and
(2) telescope re-pointing errors —during each sequential observation of the same sky-position, the images incur some systematic deviations (at the sub arc-minute level).The telescope re-pointing errors are the most severe, but can be corrected fairly easily.
The above image shows where the true trajectory (red circles), uncorrected click classifications (blue circles) and corrected click classifications (green circles) fall.
One can see that before re-pointing correction, the click positions on the sky are just wrong (blue circles). Post correction, we have near-perfect alignment between click classifications and the true trajectory (green and red respectively).
However, if we take a closer look (on the sub-arc minute level), we can see that there are some residual differences between the green (corrected clicks), and the red (true centers). See image:
The green dots (despite the correction), seem to have kinks in the trajectory. This could be due to a combination of user biases, and inaccuracies in the correction algorithm. It is not unreasonable to see why the worst mapping happens on image 2 and 3 in the four image sequence -- the asteroid is grazing a star in these images. Several users could have perceived a different object center (e.g. clicked on the star rather than the object for these images).
For a one-off image, performing an additional correction is pretty straightforward. But the process needs to scale in an automated manner to all kinds of Asteroid zoo classifications. This is where the hold up lies. We need to make sure that the correction happens at greater accuracy and for all classification scenarios. Hopefully the next update on this topic will describe the solution to this problem.
Cheers
Posted
-
by
DZM
admin
Thanks so much, @pravk7 -- featuring this to make sure that everyone sees it!
Posted
-
by
nicro46
It is reasonable to assume that users Asteroidzoo can not have a great precision in the betting objects (do not remember that this required accuracy has ever been emphasized since the project started, and he is talking to a couple of weeks and since then I have tried to put more attention, but with these tools you can not do much). It is therefore obvious that the reports of possible new asteroid has to be regarded examined, and if necessary correct the Asteroidzoo Team, before being sent to the MPC. How much of this can be done automatically?
Posted
-
by
AstroTinker
Telescope re-pointing errors. I can see these often in what I mark as #ffd, since the most obvious are the ghost-stars moving in formation( from a bad flat field image?) This nearly identical upside-down T motion is seen in many sets. What your explanation illustrates is that our marks are NOT being locked to exactly what we -see- we are marking in -each- image. If we are being fed sets that our software is already (mostly) correcting for this motion(so we can compare them), why is this correction offset not -already- part of the metadata for each set in our system(along with our marks), since -obviously- we are not marking random spots? Why are you having to do it -again-??? As for that software, as I noted elsewhere, the color comparison algorithm seems to get this type of correction closer than the regular frames. Is there a difference? Possibly related: one type of error that kills sets is a bad border, especially on the bottom. Compare a #bad-border (bottom) set between the color and the regular -in the browser-, and you see that the regular system seems to -center- the image between top and bottom, yet the color -correctly- keeps the image against the top, making me wonder if that is a problem in the framing display system in html, and if so, AGAIN, is what we see to mark -different- than where your baseline for the set says we should be marking? If so, a bad border, even one or 2 pixels, -could- be another component of the problem. I also note that when I try to re-point a slightly off mark, there is a definite granularity to where I can mark. Is this supposed to be a pixel level granularity?
Posted
-
by
AstroTinker
Analysis of the errors. You illustrated one example of a comparison between our markings and a known track. Could you do that type of comparions for several, or even all, that we have marked and have known tracks, to see if there is something systemic in the differences in marking? I.e. always 2,3 off, or are there groupings, i.e. some 1,4, some 1,2, and what is different between those. Maybe different telescope, different image groups, different day groups, early evening vs late morning, different individual, etc.? I might be able to give a hand, if needed.
Posted
-
by
pravk7
scientist, admin
in response to nicro46's comment.
@nico -- the idea is we do the whole pipeline automatically. From clicks to MPC submission. But that's easier said than done. Working on it bit by bit. Rest assured all clicks are being cataloged and mapped to detections.
@AstroTinker -- errors in clicks or telescope pointing are inevitable. The first pass at the pipeline we assumed that everything worked perfectly -- so we assumed users clicked on exactly the object centers, and there were not tracking issues. Next we adjusted algorithms to account for these variations. We're very close to reliably spitting out good trajectories from the pipeline and submitting to MPC.
I will post an update on the improved pipeline soon.
Cheers.
Posted
-
by
AstroTinker
in response to pravk7's comment.
Thanks for the update!!!
Posted
-
by
nicro46
in response to pravk7's comment.
Ok, that being so, I agree that it is not easy, for our part we can strive for greater support if we do know clearly how to proceed.
Posted
-
by
djsimister
in response to pravk7's comment.
That's positive news. Thanks for the latest.
Posted
-
by
hightower73
Was just wondering if there was any further news please?
Posted
-
by
djsimister
Probably there's a lot of very hard frustrating work going on behind the scenes at our 'AHHQ' All to get our 'amassment' of potential new found Asteroids officially confirmed as such. I can assure you, all this work you are doing and have done previously to achieve this is appreciated. Now you may not think so, or feel that it is! but it is very much....
So hey, let us know how your doing? and how you're feeling about it all? Don't suffer in silence. You are not alone. We do want to share your pain or pleasure ( Only that which relates to Asteroid finds though!, none of your personal stuff please!) :~} Just a few words on the board would be very welcome.
Thanks a lot + Appreciations again.
Posted
-
Why don't you give us a way to zoom? Then we could improve our pointing accuracy. Some of these images move and change in size greater than 20 pixels between images much less objects. Also the pointer sometimes obscures the small objects that I try to mark affecting accuracy. Perhaps you could give us the open cross to initially point with rather than the current closed center pointer.
Posted
-
by
hightower73
in response to dennispattensr's comment.
to zoom ctrl and the _- button to zoom out and the += button to zoom in
Posted
-
by
OLIEATON
Image AAZ000krv5 Take a look at this image I am not really sure how to explain this.
Posted
