Welcome, Guest
Username: Password: Remember me
20 Aug 2017
INDI development team is happy to announce the release of INDI Library v1.5.0. This new exciting release builds on the maturity of INDI Library and comes with many new supported devices and fixes for existing drivers.
Read More...

TOPIC: Image Autoguiding

Image Autoguiding 7 months 4 weeks ago #15586

  • Jochym
  • Jochym's Avatar
  • Away
  • Expert Boarder
  • Expert Boarder
  • Posts: 133
  • Karma: 2
  • Thank you received: 37
Great. I know very little about QT/KDE ...

Please Log in or Create an account to join the conversation.

P.

Image Autoguiding 7 months 4 weeks ago #15588

  • Jochym
  • Jochym's Avatar
  • Away
  • Expert Boarder
  • Expert Boarder
  • Posts: 133
  • Karma: 2
  • Thank you received: 37
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.
Attachments:
The following user(s) said Thank You: knro, nmac, supernov

Please Log in or Create an account to join the conversation.

P.

Image Autoguiding 7 months 4 weeks ago #15593

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

Please Log in or Create an account to join the conversation.

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?

Image Autoguiding 7 months 4 weeks ago #15598

  • Jochym
  • Jochym's Avatar
  • Away
  • Expert Boarder
  • Expert Boarder
  • Posts: 133
  • Karma: 2
  • Thank you received: 37
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.

Please Log in or Create an account to join the conversation.

P.

Image Autoguiding 7 months 4 weeks ago #15601

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

Please Log in or Create an account to join the conversation.

Image Autoguiding 7 months 4 weeks ago #15622

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?

Please Log in or Create an account to join the conversation.

Image Autoguiding 7 months 4 weeks ago #15623

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.

Please Log in or Create an account to join the conversation.

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?

Image Autoguiding 7 months 4 weeks ago #15626

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?

Please Log in or Create an account to join the conversation.

Last Edit: by rlancaste.

Image Autoguiding 7 months 4 weeks ago #15629

  • Jochym
  • Jochym's Avatar
  • Away
  • Expert Boarder
  • Expert Boarder
  • Posts: 133
  • Karma: 2
  • Thank you received: 37
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 ... ;)
The following user(s) said Thank You: knro, supernov, rockstarbill

Please Log in or Create an account to join the conversation.

P.
Last Edit: by Jochym.

Image Autoguiding 7 months 4 weeks ago #15633

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.

Please Log in or Create an account to join the conversation.

Image Autoguiding 7 months 4 weeks ago #15635

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.

Please Log in or Create an account to join the conversation.

Image Autoguiding 7 months 4 weeks ago #15636

  • Jochym
  • Jochym's Avatar
  • Away
  • Expert Boarder
  • Expert Boarder
  • Posts: 133
  • Karma: 2
  • Thank you received: 37
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.

Please Log in or Create an account to join the conversation.

P.
Time to create page: 0.872 seconds

Login

3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!


Gallery

Replica

Why INDI

Replica