<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I will definitely check this out tomorrow. That is not the correct amount of memory obviously. In this case, it should detect that there is not enough memory and disable the option to load all the indexes concurrently.<div class=""><br class=""></div><div class="">The goal with the settings is to actually reduce the number of settings by wrapping them up in the options profiles. <a href="http://Astrometry.net" class="">Astrometry.net</a>, sextractor, and kstars had huge amounts of different settings that would make astrometry work or fail. The options are hidden and all in different places. I’m trying to consolidate that. Once this is perfected, unless you have a special case, you should just be able to select from several profiles and not even have to look at all the settings like downsample, min width, max width etc etc etc. I’m trying to perfect a set of settings that work well for most people, so that you can just select that and go with it.</div><div class=""><br class=""></div><div class="">I’m sorry that it is taking a while to perfect the integration, but on my machine, due to the optimizations and parallelization that I added, the stellarsolver library has reduced the solving time from several minutes to several seconds for most images, and now it can solve images that were not solvable before. It can blind solve images that have no information about them including Jpegs in several seconds. In addition, this new library makes it possible for users on windows to solve just as quickly as on Linux without installing all kinds of extra packages that must be installed in compatibility layers. It also resolves issues on Macs, where people’s python installations make astrometry have all sorts of problems. And third, it will allow us to stop reading and writing so many temporary files to the Pi’s file system, because that wears it out.</div><div class=""><br class=""></div><div class="">So yes, I know that astrometry was working before on your system and this might not work perfectly yet, but please be patient while we perfect it because I have been working hard on this project for many months since February and I think it will really help for a lot of users. Again, it was not my plan to put it into KStars master before we were ready, but please be patient.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 15, 2020, at 10:39 AM, Giles Coochey <<a href="mailto:giles@coochey.net" class="">giles@coochey.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">When I run the StellarSolverTester on my RPi4 8GB, I get the
following alarming log line:</p><p class="">###<br class="">
</p><p class="">Evaluating Installed RAM for inParallel Option. Total Size of
Index files: 31.7369 GB, Installed RAM: 1.71799e+10 GB<br class="">
There should be enough RAM to load the indexes in parallel.</p><p class="">###<br class="">
</p><p class="">Naturally, it bombs out every time out-of-memory except with some
very specific settings.</p><p class="">I've never changed <a href="http://Astrometry.net" class="">Astrometry.net</a> defaults and it completes a
solve very easily. I'm now inundated with settings, some of which
appear to be able to crash kstars / stellarsolvertester...<br class="">
</p><p class="">I compiled the latest kstars 3.5.0 after today's commits on my
Astroberry, but have reverted to Astroberry's packaged 3.4.3 for
the time being.<br class="">
</p><p class=""><br class="">
</p>
<div class="moz-cite-prefix">On 14/10/2020 18:28, Hy Murveit wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:CA+B1P8vdoOD4rCpMA0tQZobdDtzGWKisviHOFyy_CJjtqxy4Bw@mail.gmail.com" class="">
<meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
<div dir="ltr" class="">I'm forwarding an issue I've seen re plate solving
with the latest KStars using stellarsolver.
<div class="">I did report this to Rob, but on Jasem's suggestion, am
forwarding to Devel also.</div>
<div class="">I really appreciate the efforts Rob and Jasem are putting
in for this release.</div>
<div class=""><br class="">
</div>
<div class="">(Not sure where to report bugs that might block 3.5, other
than this email list)</div>
<div class=""><br class="">
</div>
<div class="">The TL;DR is that I cannot successfully plate solve using
the StellarSolver internal methods</div>
<div class="">on a Raspberry Pi 4 (running Raspberry Pi OS). Lots of
detail below.</div>
<div class=""><br class="">
</div>
<div class="">Have others successfully plate solved on a RPi4?</div>
<div class=""><br class="">
</div>
<div class="">Hy</div>
<div class=""><br class="">
</div>
<div class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">-------------------------------------</div>
<div dir="ltr" class="">
<div class=""><br class="">
</div>
I pulled the latest stellarsolver and kstars, and then
added <a href="https://invent.kde.org/education/kstars/-/merge_requests/104" target="_blank" moz-do-not-send="true" class="">your new MR</a>
on top of it, and compiled on my RPi4.
<div class=""><br class="">
</div>
<div class="">TL;DR With your new code, WCS works, but the only
plate solving that works for me is local astap.
'SEP/StellarSolver/4ParallelSmallScale' and switching to
'local astrometry' both fail to solve the captured
images. Going to my old KStars with local astrometry
works. I tried other .fits files (meaning other
locations in the sky) and they also failed.</div>
<div class=""><br class="">
</div>
<div class="">I ran these tests. </div>
<div class="">(1) Load and Slew with your MR
and SEP/StellarSolver/4ParallelSmallScale. This looks
like it successfully pulled the WCS info from the file,
but the plate solve after slewing failed and stopped. </div>
<div class="">(2) I switched to local ASTAP and it worked (e.g. it
got the WCS, slewed, then iterated 3 times on image
capture and successful plate solve.</div>
<div class="">(3) I switched to 'local astrometry'. Seemed to get
the WCS, then quickly fail to solve.</div>
<div class="">(4) I switched to my old/saved KStars (pre your
changes, no stellarsolver). Worked fine.</div>
<div class="">(5) Parked, Unparked, repeated #4, still worked.</div>
<div class="">(6) Went back to the "new Kstars". Retried #3. Still
failed.</div>
<div class="">(7) Retried #2. Still Succeeded.</div>
<div class="">(8) Retried #1. Still failed.</div>
<div class="">(9) I tried #1 with several other fits files. All
seemed to load WCS then fail plate solving very quickly.
Probably same issue as with #1 (I gave you lots of
details below).</div>
<div class=""><br class="">
</div>
<div class="">Hy</div>
<div class=""><br class="">
</div>
<div class="">Details:<br class="">
<br class="">
<b class="">Test #1. <br class="">
Load and Slew, using the same .fits file I shared,
Internal SEP/StellarSolver/4ParallelSmallScale. (load
all in memory is UNchecked).</b><br class="">
<br class="">
I got the below (just cut/pasted the bottom logging
window in the align tab).<br class="">
Honestly, with all the output blowing by, it's hard to
see what happened, but from looking at the cut/paste, I
see
<div class="">that it looks like it got the WCS position from the
.fit header, slewed, and then failed to solve.</div>
<div class="">The image on the screen looks reasonable.</div>
<div class="">(See below, I retried with ASTAP)</div>
<div class=""><br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br class="">
</div>
</div></blockquote></div><br class=""></div></body></html>