If we would use my quick and dirty test procedure in single-core interpreted language it would use 100% CPU and run like molasses But we are not going to. This test was rather to check my understanding of the algorithm and to approximate the *upper* bound of the processing time. I thing that the lower bound is around 50ms/frame (or 20fps) on RPi2 using GPUFFT. This would be a desperate measure since it needs root access and is not very portable. My plan is to use FFTW3 which is a well-optimized, portable FFT library. With this approach I hope for 2-5 fps on RPi2 and much better on regular PC.
Not much - since I got swamped by work and other duties - but it is not abandoned at all. Thanks for the ping.
Unfortunately the FFT libraries are much more convoluted in their API then I thought - using them from the higher-level languages. There is a substantial amount of code to write to prepare the data before transformation if we want to keep it portable. Jasem has written small bits in ekos to interface with it if I remember correctly but I got stuck on joining them together. I was hoping to return to my indi projects in autumn. Not yet .
I expect that the function will be realized.
If possible, I would like you to add live stacking mode and realize it.
This function is introduced to shops in Japan now and is gaining attention as a new viewing method.
About live stacking, it's a different story. There are multiple places where this could be implemented in Ekos+indi. There is an attempt inside the V4L2 driver itself, but it doesn't play well with Ekos and also doesn't match the expectations of users. The important point on this feature is for the user to see the object appear progressively, in a pedagogical way. That's what Atik implemented with Infinity, and the results are great. You should open a wish list item on this to discuss the idea.