[prev in list] [next in list] [prev in thread] [next in thread]
List: kstars-devel
Subject: Re: Interoperability proposal
From: Ed Lee <ed () thefamilee ! co ! uk>
Date: 2024-02-23 13:56:32
Message-ID: 4e0432dc-66fa-46cd-8a59-b4d32bac5124 () thefamilee ! co ! uk
[Download RAW message or body]
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@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@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@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
>>>>
>>>
>>
[Attachment #3 (text/html)]
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi Wolfgang, <br>
<br>
I'll have a bit of a hack about with a view to scoping the pros and
cons with different approaches.<br>
<br>
Kind regards<br>
Ed Lee<br>
<br>
<div class="moz-cite-prefix">On 23/02/2024 13:04, Wolfgang
Reissenberger wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E4C4CB2F-C73E-4908-8C1D-F21A45B3A1D5@openfuture.de">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hi Ed,
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Kstars has a fairly good (but insufficiently documented) DBus
interface for scripting, which could be used that way.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>- Wolfgang</div>
<div>
<div dir="ltr">--
<div>
<div><span style="background-color: rgba(255, 255, 255, 0);">Wolfgang
Reissenberger</span></div>
<div><span style="background-color: rgba(255, 255, 255, 0);"><a \
class="moz-txt-link-abbreviated" href="http://www.sterne-jaeger.de">www.sterne-jaeger.de</a></span></div> \
</div> </div>
<div dir="ltr"><br>
<blockquote type="cite">Am 23.02.2024 um 09:51 schrieb Ed Lee
<a class="moz-txt-link-rfc2396E" \
href="mailto:ed@thefamilee.co.uk"><ed@thefamilee.co.uk></a>:<br> <br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<font face="Arial">Hi Wolfgang, <br>
<br>
Some more details regarding the second idea...<br>
<br>
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. <br>
<br>
My current preferred workflow for a planetary capture is:<br>
</font>
<ul>
<li><font face="Arial">Start KStars/Ekos</font></li>
<li><font face="Arial">Polar align using Ekos plate
solving</font></li>
<li><font face="Arial">Train a quick mount model using
Ekos plate solving</font></li>
<li><font face="Arial">Rough focus in Ekos (I'm manually
focussing with a Bahtinov mask)</font></li>
<li><font face="Arial">Slew to planetary target in KStars</font></li>
<ul>
<li><font face="Arial">In INDI control panel, disconnect
imaging camera</font></li>
<li><font face="Arial">Launch FireCapture from the
Desktop</font></li>
</ul>
<li><font face="Arial">In FireCapture, connect to INDI,
focus, adjust settings, capture, close FireCapture</font></li>
<ul>
<li><font face="Arial">In INDI control panel, reconnect
imaging camera (if attempting another target in the
session).</font></li>
</ul>
</ul>
<p><font face="Arial">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.</font> 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.<br>
</p>
<p>Hope that helps in understanding my intent?</p>
<p>Kind regards</p>
<p>Ed<br>
</p>
<font face="Arial"><br>
</font>
<div class="moz-cite-prefix">On 22/02/2024 22:27, Wolfgang
Reissenberger wrote:<br>
</div>
<blockquote type="cite"
cite="mid:EAB7C3FB-E763-4EEC-AFA7-750B25B4674B@openfuture.de">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
Dear Ed,
<div>very interesting ideas!</div>
<div><br>
</div>
<div>The first idea should be feasible.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers</div>
<div>Wolfgang</div>
<div>
<div><br>
<blockquote type="cite">
<div>Am 21.02.2024 um 15:50 schrieb Jasem Mutlaq <a
class="moz-txt-link-rfc2396E"
href="mailto:mutlaqja@ikarustech.com"
moz-do-not-send="true"><mutlaqja@ikarustech.com></a>:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">Hello Ed,
<div><br>
</div>
<div>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. </div>
<div><br clear="all">
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>--</div>
<div>Best Regards,<br>
Jasem Mutlaq<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Feb
21, 2024 at 5:35 PM Ed Lee <<a
href="mailto:ed@thefamilee.co.uk"
moz-do-not-send="true"
class="moz-txt-link-freetext">ed@thefamilee.co.uk</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> <font face="Arial">Hi,<br>
<br>
Although KStars is growing ever more
capable there are other programs that I
like to use in conjunction, mostly for
convenience.<br>
<br>
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. <br>
<br>
Two examples of how I would like to use a
generalised call:<br>
</font>
<ul>
<li><font face="Arial">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.<br>
</font></li>
<li><font face="Arial">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.</font></li>
</ul>
<p><font face="Arial">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.</font></p>
<p><font face="Arial">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.</font></p>
<p><font face="Arial">Kind Regards</font></p>
<p><font face="Arial">Ed Lee<br>
</font></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic