What I do not understand is that 15 seconds exposure mentioned in the video. If I remember correctly he said he broke the exposures into 15s subexposures and sum them in ram for the final exposure for
the image autoguiding with the main camera. Then another person in the video asked for that 15 seconds because astroimaging would normaly use exposures 1 to 15 minutes and he said you could also use the guiding scope to do the image autoguiding and use the main camera for longer exposures. That was the point where I was wondering because at the beginning of his presentation he claimed the errors that are introduced by those other methods to guide (fov, differential flexure,jitter) and then he recommends one of those to have longer exposures on the main camera. Maybe I missunderstood something

It has two modes. The traditional guide scope mode and zero drift mode using short exposure stacking as a imaging technique. His goal is to keep the star on the same photocell. Otherwise this technique is pointless - you can just align and stack the images without any guiding but you will loose the calibration accuracy.

The original author responded and agreed to cooperate with us in implementing his idea in ekos. Furthermore, I got few attachments, with detailed theory of operation paper and code samples. After short review it seems the implementation should be quite straightforward. Unfortunately, I have no experience with EKOS and QT programming. I can implement the image processing part. I will try to have a prototype proof-of-concept implementation soon.

Jasem, would it be possible for you to implement just a skeletal generic guide module with gui and just empty functions for the xy_shift(ref_im, cur_im) implementation?

Pawel, I will setup something soon that can be used for testing for this. Will create a branch in KStars and email you the details.

Great. I know very little about QT/KDE ...

Here is a primitive proof of concept on real astronomical image (1024x1024, green filter image of m13, quite dark).
The inside with 100px margin is taken as reference and compared with a frame shifted by x=3px y=4px
Attached is a map of the phase shift in the low spatial frequency region. A nice flat ramp of the phase shift from the indicates the direction of the frame shift.
This is just a proof of concept calculation but it shows that it could be calculated very easily and is indeed very sensitive. For one pixel shift we still have very strong and clear gradient in the picture.

I'm curious to see how _noise_ affects all of this? Turbulence..etc?

I expect it will mess things at higher spatial frequencies which we cannot use anyway due to the wrap-around of the phase. But ultimately we will see when we implement the thing with live feed. I am thinking about implementing a simple testing code outside of indi for RPi camera - just to test things out. I will probably have a bit of time to work on this later next week. If you manage to cook some skeleton by then that will be great. If not, I will start working anyway - just outside the system with integration in mind.

Just in between, I think this is so awesome to follow! Thanks a lot guys.

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?