Is there some kind of statistical analysis in place to prevent outliers from triggering excessive corrections? For example If a corrupted image frame were to come in, as can occur in my experience with ASI120. How would the algorithm respond to that?

I believe this is beyond the scope of the phase shift algorithm and within the scope of the PID controller that uses these data. For example, Ekos internal guider would ignore transient spikes for this very reason.

I was just looking over his paper and code. I definitely like it. I think it could make guiding more accurate and easier to do. One concern I have though is the number of calculations that have to take place for each guiding image shift. I saw that he used floats, not doubles, which helps. But wow, there are a lot of steps to get the shift involving 3D arrays and of course FFT calculations. Could this cause problems for some less powerful systems in terms of both memory and processing speed?

There is a substantial amount of calculation involved but I think it is manageable. Implemented in python (interpreted language) and working on 1M pixel image it took 2s per frame on single 2.4GHz core without any optimisations. The real algorithm uses 5-6 smaller transforms (256x256) and we will write it as tight and optimized as possible. Furthermore it is going to run on the main control computer not the embedded platform (e.g RPi). If we need to, we can use graphics card FFT to speed things up quite a bit (approx 10x). There is a GPUFFT library for RPi which runs at 7ms / 256x256 single precision transform (See www.raspberrypi.org/blog/accelerating-fo...forms-using-the-gpu/) so we can probably run the algorithm at 10-30 fps even on the RPi2.
Even using FFTW on RPi (first gen! 700MHz) we can get to 100ms/transform - thus 1-2fps frame rate. I think this is quite enough for our purpose.
I am not very concerned with the speed of FFT - the name is *Fast* Fourier Transform ...

2s per frame on a good computer running a test is a long time, considering all the other stuff that the computer must be doing for imaging and considering you want to guide with a rate faster than once per second. Also remember that many willl be using a powerful computer, but one of the things that makes KStars/Ekos so powerful is that you can now run the entire thing off just a raspberry pi 3 with no external computer running.

That being said, you are very correct about what you said about opimization and about using a compiled rather than an interpreted language, etc. I bet those times will improve. I particularly like what you said about using the graphics card and the fft library for the calculations to speed it up. If we can get the algorithm to solve at 30 frames per second on a raspberry pi, I think there is no problem at all.

Also, as long as we keep the option to guide with a star, I dont think we need to worry too much about it not working fast enough for all computers right away.

I'm guessing it's not going to use 100% of the CPU for 2 sec, so that wouldn't affect the rest too much. This method, as far as I read, is also not meant for the Pi perse, if it would work it would be nice, but it's not the goal I believe. And why would you want to guide much faster than 2 seconds? I always guide at 3, lower and I'm just chasing the seeing.

I just tested 2d GPU FFT on my RPi2 and it ran at 6ms/(256x256)block. We need 6 such blocks + some additions/divisions that is below 50ms per frame or 20fps. This is close to live video frame rate. We do not need anything like this. The performance is limited by the INDI protocol not by the processing stage. INDI can hardly do few FPS just displaying the frames. This will not be the bottleneck of the pipeline.

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.

Awesome, sounds great!

What's new in this project?

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.

kyoei-tokyo-astrodivision.hatenablog.jp/entry/2017/10/12/190618