[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kstars-devel
Subject:    Re: Interoperability proposal
From:       Wolfgang Reissenberger <sterne-jaeger () openfuture ! de>
Date:       2024-02-23 13:04:33
Message-ID: E4C4CB2F-C73E-4908-8C1D-F21A45B3A1D5 () openfuture ! de
[Download RAW message or body]

[Attachment #2 (text/html)]

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">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);">www.sterne-jaeger.de</span></div></div></div><div dir="ltr"><br><blockquote type="cite">Am \
23.02.2024 um 09:51 schrieb Ed Lee &lt;ed@thefamilee.co.uk&gt;:<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">&lt;mutlaqja@ikarustech.com&gt;</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 &amp; level of support for this can
                  be improved.&nbsp;</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 &lt;<a href="mailto:ed@thefamilee.co.uk" moz-do-not-send="true" \
class="moz-txt-link-freetext">ed@thefamilee.co.uk</a>&gt;  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></body></html>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic