During an image session, Ekos now records many useful details about the image itself like HFR, SNR and Eccentricity.
Hy's great new Analyse module helps assessing the quality of the image session both in real time and after the session is ended.
But the information is not linked to the image itself: when the best frames need to be selected for processing, an external tool like PI's subframeselector has to be used for this purpose.
It would be nice to have these parameters stored in the image metadata as custom (non standard) FITS keyowrds, then any FITS reader or a simple script or a client like AstroDom could read those metadata and help sorting and filtering best frames before any processing is made.
hi Jasem,
from Eric's chart is not clear to me where Ekos ends. I mean if 'frame DB index' is meant to be part of Ekos or an external software? I will eventually post on that thread for clarification.
Many of us would like to help implementing new features but Ekos has a steep learning curve, partly because of its internal API and partly because it's C++.
I think that find a way to lower the complexity of the system would help increasing the developers base.
The Storage/Library module is supposed to manage blob export, storage and indexing of captured frames. I'd like plugins - in whatever language - to be available there and arranged in a pipeline applied to each frame as it is made available by Capture. Other modules may then query that module to search and obtain a file location or a data blob with particular properties. The problem I would like to solve is the resource availability on the system the module lives for such plugins to run. And that brings us to the future possibility of different Ekos modules communicating and moving data around.
thanks Eric for explaining. So if i understood correctly, the Storage/Library module will act as an information gateway for other external plugins or internal modules.
Then a software like the one I wrote ( a FITS image catalogue written in PyQT) could be a plugin for this new module for example?
Does the Storage and pipeline model would also work for a remote observatory? I.e. if the remote computer where Ekos (Capture and Storage modules) is installed differs from the one used locally for image processing.
Based on my experience what could help both on Ekos and INDI development is:
- More tutorials: there are indeed tutorials available both for driver and client development, but they are covering basic topics only (that's the list of simple tasks that you mentioned above I guess).
- Coaching / mentoring: having a senior developer investing time coaching new developers.
- Interactive online session where questions could be asked.
The APIs are well documented but I struggle to understand the lifecycle of a request and the workflow in general. Using the debugger helps but still the whole picture is missing: I wrote a couple of INDI drivers, they do work but still I do not understand the class hierarchy nor how the methods are related.
Here an overview of the architecture and a list of the main classes / methods could help.
As you said, Kstars is complex as a project. And beside its functional complexity, you have to learn C++ and QT; consider that most developers are now used to Python and Java or JS.
Any language can be learnt but having limited time and with no previous knowledge of C++, even manipulating numbers is hard.
To me if Ekos could support PyQT (don't know if bridging is even possible) would be a great help.
QT is great and I don't know if there are better alternatives but the 'everything is an object' approach is nice but sometimes slows things down.
I really appreciate that you are open to suggestions Jasem and hope that others can contribute to this discussion.
+1
Jasem has already produced video content. I have enjoyed his videos on the Stellar Mate youtube channel. The video on plate solving was an eye opener for me.
It would be really great if Jasem could put a video course on Udemy. Let it be reasonably priced, because this will be hard work.