Interoperability proposal

[Ed Lee]

Hi Wolfgang,

I'll have a bit of a hack about with a view to scoping the pros and cons 
with different approaches.

Kind regards
Ed Lee

On 23/02/2024 13:04, Wolfgang Reissenberger wrote:
> Hi Ed,
> is there a benefit keeping Kstars alive when the handover to 
> FireCapture? Or is the only requirement when Kstars terminates that 
> the INDI server is running?
>
> For the latter it’s a lot simpler to start the INDI server remotely, 
> because in this case the INDI server stays alive when Kstars terminates.
>
> What about thinking the other way round and build an orchestration 
> client that starts Kstars and the required steps, stops it when its 
> tasks are finished and launches FireCapture to continue.
>
> Kstars has a fairly good (but insufficiently documented) DBus 
> interface for scripting, which could be used that way.
>
> You hear, I‘m slightly sceptical about integrating such an approach 
> into Kstars. We have done substantial progress in terms of 
> modularisation, but our core modules are part of the application and 
> not exchangeable plugins.
>
> - Wolfgang
> -- 
> Wolfgang Reissenberger
> www.sterne-jaeger.de
>
>> Am 23.02.2024 um 09:51 schrieb Ed Lee <ed at thefamilee.co.uk>:
>>
>>  Hi Wolfgang,
>>
>> Some more details regarding the second idea...
>>
>> In FireCapture, the imaging camera is handled directly for maximum 
>> throughput. Other equipment must be connected via INDI (or ASCOM). 
>> The other equipment in this case can be mount, filter wheel and 
>> focuser. There is no need, from FireCapture's perspective, for 
>> KStars/Ekos, only INDI. So it's possible, but clunky, to launch an 
>> INDI server handling all the kit from the command line before 
>> starting FireCapture.
>>
>> My current preferred workflow for a planetary capture is:
>>
>>   * Start KStars/Ekos
>>   * Polar align using Ekos plate solving
>>   * Train a quick mount model using Ekos plate solving
>>   * Rough focus in Ekos (I'm manually focussing with a Bahtinov mask)
>>   * Slew to planetary target in KStars
>>       o In INDI control panel, disconnect imaging camera
>>       o Launch FireCapture from the Desktop
>>   * In FireCapture, connect to INDI, focus, adjust settings, capture,
>>     close FireCapture
>>       o In INDI control panel, reconnect imaging camera (if
>>         attempting another target in the session).
>>
>> So I'm using KStars/Ekos for setup and INDI server management, and 
>> FireCapture for capture and guiding. When FireCapture is active it's 
>> vital that KStars/Ekos is in an idle state, so in this case the 
>> button would only be active when the scheduler is not running, 
>> guiding is not active and no capture job is running. The plugin would 
>> just handle the three indented actions above. I wouldn't intend to 
>> manage the capture session in any way (guiding/focus/flip), that's 
>> the job of the capture control system - in my case FireCapture.
>>
>> Hope that helps in understanding my intent?
>>
>> Kind regards
>>
>> Ed
>>
>>
>> On 22/02/2024 22:27, Wolfgang Reissenberger wrote:
>>> Dear Ed,
>>> very interesting ideas!
>>>
>>> The first idea should be feasible.
>>>
>>> Regarding the idea interacting with FireCapture I’m not sure if I 
>>> understand the intention behind. Is there the idea to use KStars for 
>>> positioning the scope to the target, but then switching (at least 
>>> capturing) to FireCapture? Should guiding continue running for 
>>> example? What about meridian flip? Or Refocusing? There are many 
>>> features of other modules that lead to interaction with the Capture 
>>> module.
>>>
>>> Cheers
>>> Wolfgang
>>>
>>>> Am 21.02.2024 um 15:50 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com>:
>>>>
>>>> Hello Ed,
>>>>
>>>> That's a great idea. Perhaps something like "Plugins" that could be 
>>>> used to add extra functionality? KStars can be scripted by DBus 
>>>> though the documentation & level of support for this can be improved.
>>>>
>>>> --
>>>> Best Regards,
>>>> Jasem Mutlaq
>>>>
>>>>
>>>>
>>>> On Wed, Feb 21, 2024 at 5:35 PM Ed Lee <ed at thefamilee.co.uk> wrote:
>>>>
>>>>     Hi,
>>>>
>>>>     Although KStars is growing ever more capable there are other
>>>>     programs that I like to use in conjunction, mostly for convenience.
>>>>
>>>>     It occurs to me that my workflow could be made easier and the
>>>>     system capabilities extended by providing a generalised means
>>>>     to call other programs from within KStars/Ekos. At present
>>>>     there is already a specific occurrence of this where the
>>>>     scheduler can call start up / shut down scripts.
>>>>
>>>>     Two examples of how I would like to use a generalised call:
>>>>
>>>>       * Add a button to the Capture module that launches an
>>>>         external live stacking application (for example Siril),
>>>>         pass it the necessary commands to start receiving images
>>>>         from the current selected camera, and then start repeating
>>>>         captures. Stop capturing when the external process closes.
>>>>       * Add a button to the Capture module that disconnects the
>>>>         current selected camera from the INDI server and then
>>>>         launches FireCapture for planetary imaging. Reconnect the
>>>>         camera when the external process closes.
>>>>
>>>>     Abstracting the external program calls via scripts would allow
>>>>     user customisation and avoid any dependencies on / promotion of
>>>>     specific software. Sample scripts could be provided. It may
>>>>     also make the implementation simpler - an abstraction of the
>>>>     current scheduler script processing with additional control
>>>>     processes within KStars.
>>>>
>>>>     Before I start working on this I wanted to ask for any thoughts
>>>>     on this proposal, both regarding the implementation and also
>>>>     whether this would be perceived an acceptable route for KStars.
>>>>
>>>>     Kind Regards
>>>>
>>>>     Ed Lee
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20240223/4873b2c5/attachment-0001.htm>