software for finding faint asteroid tracks

[Robin Leadbeater]

This may be old news to the cognoscenti (Asteroids are definitely not my area of expertise)  but I was interested to read of  the discovery of an asteroid using new amateur software which can  find faint moving objects in stacks of images without prior knowledge of the path.

https://www.cloudynights.com/topic/692309-amateur-astronomer-discovers-apollo-asteroid/

Cheers

Robin

[Dr Paul Leyland]

Unfortunately the software released is Windoze only, which rules out a large number of astronomers.  Oh well.

Looks like a free implementation should be created.  Time to track down the references given in a paper on the Tycho site.

[Grant Privett]

Its not that hard to do, you just have to be willing to throw CPU at the problem and wait. 🙂

But looking more closely at the manual, its obvious the author has put in some considerable effort. So, I think I will have a rummage around and see if I have a compatible old GPU knocking about. Could be fun.

Its not exactly an expensive licence afterall.

[Grant Privett]

I got bored last night and so had a quick go at implementing a barebones blind stacking process that was totally self contained and and didnt use GPUs (not an area of programming I have ever had cause to venture into). To keep it simple I used Python3. It was able to stack a 60x 1Mpixel image set on a given drift/rotation rate in about 5-6seconds. So if you are wanting thousands of them, be prepared to wait thousands of seconds.

If you’ve a spare desktop knocking about then you can just start it running and come back in a few hours. Not a big deal. 

Tycho wins though on being: 1, fast 2, fully integrated 3, largely already debugged and tested.

I think Python is part of the Linux install these days isnt it, so you can have some fun.

[Dr Paul Leyland]

Good work Grant!

Could you point me at the source code please, or perhaps mail me a copy?  It has been a few years since I last wrote GPU code (CUDA then, ought to be OpenCL these days) and perhaps I may be able to get off my backside and do something if given a sufficiently large kick incentive.

There are tens of thousands of images stored on a server at home in the UK and it would be nice to see what can be dug out of them.

Thanks.

[Grant Privett]

It won’t be elegant or finished for a few days – I’m bug hunting at the moment – but it will be a single self contained file (probably 1800 lines or so). Mainly uses standard stuff like numpy. I’m running it under Anaconda.

May be able to improve the speed and memory usage yet. As far as possible I’m avoiding the temptation to resample images using splines or similar when I translate them to try to avoid the blurring/smearing that causes and maximise pixel counts. Happily, with well set up mounts the rotation isnt much. I’m doing integer shifts and translates where I can. 

Python does gobble the memory though – havent checked yet but its probably converted the images to floating point or 64bit ints or something silly.

[Dr Paul Leyland]

Hi Grant,

You are probably aware of the material below, as it has a long history, but it is posted here for the amusement and possible education of others.

Zeroth Law of Optimization: First get it right, then get it fast.

You can do anything arbitrarily quickly as long as your code is not required to get the right answer.

First Law: Intelligence trumps code.

Use a good algorithm. Optimizing a bad algorithm is akin to polishing turds.

Second Law: Know what is going on.

Unless you profile your code and take timing measurements most everywhere, you don’t have a clue what is worth optimizing.

Third Law: Don’t do it.

Only calculate stuff you actually need. You might be surprised at how much extraneous garbage is computed in libraries, etc, without your knowledge.

Fourth Law: Don’t do it now.

Covers a number of issues, including lifting computations outside loops and storing stuff in registers or cache-friendly memory.

[Grant Privett]

I particularly like it when, at work, other members of staff tell me my code isn’t written in the Python style and dismiss working, structured, debugged and documented code as somehow flawed.

I have twice had to demonstrate that doing image processing without using a linked list is generally faster and uses a lot less memory: which makes a big difference when you have a runtime greater than a few minutes. 

I was forced to use Python at work after IDL licences were deemed too expensive and Matlab was clearly next on the chopping block. The libraries it has are great. The language itself, sucks.

[Grant Privett]

Version 5.3 was released this week. You don’t need a GPU to run it, but it will be slow. But, we all have lots of spare time at home suddenly…. 

Also, as feedback, you will find that it doesnt seem to like pre-2015 GPUs – even with the latest CUDA drivers.

[Grant Privett]

Daniel Parrott, the US developer of Tycho Tracker, has just released another version of Tycho Tracker. As before, the best way of using it is via GPU – the good news is that it now lets you test the GPU you have installed and tells you if its compatible. If its not the right sort (or capable enough) the CPU option is still there.

A friend had trouble using the GPU version under a Linux Windows emulator (wine?) but now theres a CPU version that problem may not apply. I tried it on 22x 4min Starlight H18 frames of the ecliptic taken with an 11″ RASA and it found 5 asteroids on the frame (and identified them) and in addition a single unknown object down at mag 19 – that looked real to me. It wasnt quick (5.5hrs) but I set Tycho running when I went to bed and looked at the results as I munched my muesli the next morning.

Its fairly straight forward to use and there is a manual. A full licence is $US 25 but you get a month to play with it before having to decide.

[Author]

Posts