Automatic motion recognition

How difficult is it to program an automatic software using C that is able to read astronomy images of up to 4096x4096 pixels (or other sensor geometries), search for bright or faint blobs, calculate its subpixel centroid, compare with the same locations of other the previous or next image, look for other blobs in those and eventually find the same one by its linear motion/equal motion intervals if the images were taken with equal time gaps in between?

Moreover, as an additional feature, take subsequent images with equal time gaps in between and overlay them such that very faint blobs become visible by signal-accumulation and noise-averaging, and do the same as outlined above until linear motions are found for the same blob.

What are key skills one needs to have in C in order to program this?

What computer hardware would be reasonable if wanting the program to need no more than 1 minute for 3 subsequent images?

• How difficult is it to program ... ... less difficult if you plan to use something like opencv.org – High Performance Mark Jul 3 '16 at 10:39

You would greatly benefit from knowledge in signal processing, but some specific useful knowledge would be in computer vision and estimation (like Kalman filters or alpha beta filters).

With respect to tracking blobs, you could use blob detector algorithms to find meaningful blobs, use some descriptor like SIFT to describe the blob and then do feature matching between images to figure out matching blobs. Then based on the matches and time differences between images, you could do some sort of Kalman filter estimation of speed.

One of the common libraries you can use to solve this problem, as I mentioned in my comment below, is OpenCV. It covers most common computer vision and image processing problems you might end up with. I will note that you may have to experiment with various algorithms because they don't always perform as robustly as they could. When I worked in the Computer Vision group at the Jet Propulsion Lab, I found OpenCV failed to implement various algorithms to be as fast and robust as they could be when compared to the in house algorithms made by NASA engineers. NASAs codes were far superior even for simple things like blob detection and feature descriptors.

• So you mean the formal definition of a blob as an actual signal instead of just an arbitrary accumulation of noise? Assuming it's perfectly circular, one could define it through a Gaussian point spread function, the measurement of pixel ADUs in some customary adjustable signal circle and a surrounding ring which measures the background noise. As it is usually done in aperture photometry. Ok, I see there are two parts in such a program, a) the definition of a signal blob, and b) how the program looks for such moving blobs. How difficult is implementing part b)? – Lucas Jul 2 '16 at 22:37
• @Lucas A blob can be more formally described in the following link about blob detection: en.m.wikipedia.org/wiki/Blob_detection. But the main problems are defining a blob, being able to locate your blobs, describing them, creating a list of the blobs and their descriptors for each image, and then trying to match blobs, based on their descriptors, between adjacent images. Based on the matches, you can attempt to track them using a Kalman filter or something. Most of this can most easily be tackled with OpenCV, though I am not sure a Kalman filter is implemented in OpenCV or not. – spektr Jul 3 '16 at 0:46

The answer to quantify the difficulty is not trivial to give. It depends already hugely on your $C$ programming skills. As $C$ is not accounted to be an easy language, a more trivial answer is not so easy. Is there a reason to not use $C++$? You can still write $C$-style code in $C++$ and are not forced to use object oriented coding style if you want to improve a basic but essential function.

Furthermore, look for available libraries, e.g. openCV. That one will greatly improve your blob detection. It is a frequently used picture analysis library. Most likely the blob detection is your runtime crucial step. Your input data is of size ~ 16 mio points here. Finding the centroid is ignorable (can be done in linear time). As the number of blobs should be far lower than 16 mio, the last part of your algorithm might be even with an $n^2$ algorithm acceptable fast for you. OpenCV usage will give you most likely maximum run-time efficiency and short and readable code for this first step.

The computer specs: In general the described problem does not sound computational hard. Most likely a standard computer will do the trick. You can test maybe a plot detection on a test picture with Photoshop or Gimp to get a feeling. If you run into time issues: a better graphic card will only help you if you are doing GPU - computing. Most likely you will do not. Increasing the number of cores will only help you if you utilize multithreading. You need to be sure that you are able to do so. Memory should not be an issue. 4kx4k pixels is nothing.

• My skills are merely introductory with self-defining functions as the most advanced skills I know. Unfortunately, I didn't get the explanations for arrays, and pointers anymore in the lecture. But I'm in no hurry to get a program working and only want to know how long my way is until I could get it done. Any key skills/commands I must be able to handle while dreaming or good explanatory books for the journey? – Lucas Jul 3 '16 at 21:50
• @Lucas you definitely need to understand the fundamentals of C/C++; at least arrays, pointers, dynamic memory allocation, and structs. I recommend starting with C because it is much smaller of a language and easier due to that. – spektr Jul 3 '16 at 22:44
• I forgot to add that the program definitely should be able to do "plate solving" (conversion of celestial spherical coordinates to the flat image), so that each star in the image has it's proper coordinates even though the image is flat. Moreover, automatically highlight the found objects in the images and extract their coordinates into a file. So, abilities to visualize for the user. – Lucas Jul 5 '16 at 11:40