Thursday, September 16, 2021

KStars v3.5.5 Released!

KStars v3.5.5 is released on September 16th for Windows, MacOS, and Linux. This release includes a number of new features and bug fixes.

Google Summer of Code 2021

Let's start with the highly successful Google Summer of Code project: KStars Deep-Sky-Objects Overhaul by Valentin Boettcher. This is mostly backend plumping and refactoring to enable KStars to process very large DSO catalogs without impacting memory or processor utilization. This required the development of a new Python-based catalog generator that consolidates and de-duplicates deep sky catalogs in a form usable by KStars.



The legacy system for handling DSO catalogs in KStars has grown rather organically and was a tangle between databases, CSV files and special case implementations. Many catalogs were hard-coded explicitly, making it hard to extend and generalize. Also, the sources of the catalogs and methods how they were transformed into the KStars format were inhomogeneous and hard to reproduce, making deduplication almost impossible.

De-duplication is a process to identify when different designations are used to denote the same deep sky object. For example, the infamous Andromeda Galaxy is known as M31 in the Messier catalog, whereas in the NGC catalog, its designation is 224, and in the PGC catalog, it is 2557 and so forth. Previously, when each catalog was loaded separately in KStars, there was no way to know whether these designations were actually referring to the same physical object. This led to interesting side-effects as these designations were sometimes loaded as separate unique objects in KStars. This is where de-duplication comes into play, it prevents duplication of the same object even when it is exists in multiple catalogs with different designations.

Another limitation for KStars deep sky catalog management is memory handling. KStars just loaded all the DSOs into memory and computed their position on the virtual sky for every draw cycle, which made all too large catalogs infeasible. Valentin task was to implement a unified catalog format which can be loaded into a central database and supports de-duplication. Furthermore, taking inspiration from the handling of star catalogs in KStars, the objects should be trixel indexed and cached in and out of memory (but only for large catalogs). Finally, it would be very desirable to make the creation/compilation of the catalogs reproducible and easily extendable to facilitate future maintenance.





Valentin developed a new python framework to generate KStars catalogs from sources. To learn how to create new DSO catalogs for KStars, please checkout the documentation.

While the above method is the recommended method to create highly efficient catalogs, you can still import DSOs using a basic CSV importer. This might be helpful to add a few DSOs of interest to some users.


With the previous legacy catalogs, the DSO object colors were hard-coded in the catalog itself. Now you can customize the color of each catalog to get the best experience possible suited to your needs.


Port Selector Tool

When creating a new Ekos Equipment profile, you will be presented with the Port Selector tool if any of your devices is a serial or networked device.

Your equipment profile may contain one or more serial and/or network-enabled devices. Although INDI performs an auto-search when you connect to your serial devices, it's recommended to select the appropriate ports and baud rates before connecting for the first time.


If a device is available on the network (WiFi or Ethernet), then you can configure the device host-name (or IP address) and port. It must be located on the same network where Ekos is running in order for them to communicate with each other. The port selector tool can be toggled at any time and not only during initial connection phase.

Re-usable Widgets


Wolfgang Reissenberger implemented new reusable widgets to be used across Ekos. These widgets replace the legacy raster-based pixmaps that were used in the Summary screen to report progress in focus, capture, and guide modules. Not only this reduces the memory footprint of KStars, but it also present fully interactive widgets at native resolution. 

You can switch back and forth between the available widgets to select the desired information to display.

Scheduler Artificial Horizon Restriction

Hy Murveit implemented a feature that was requested by our users for years: Artificial-Horizon -aware-scheduler! 

Users may define an artificial horizon zones where visibility is obstructed by natural or man-made structures. Furthermore, a terrain map can be superimposed to provide a 360 degree view of the horizon.

Artificial Horizon constraints, when enabled via the standard artificial horizon UI, will now be used by the scheduler to start or interrupt jobs. That is, if there is an artificial horizon constraint at a given azimuth, it will be used by the scheduler, along with the standard altitude constraint to determine if a job can start or continue. The scheduler uses the max of the altitude constraints as the constraint to enforce.

Ekos Internal Guider Improvements




Hy Murveit overhauled the Guider UI starting with simplifying the Guider Options Menu (GOM):
  • Dither options used to be in GOM's Guider Tab. Now the GOM has a Dither tab for dither parameters.
  • Moved the control parameters (e.g. DEC proportional gain = 133) to the GOM's Guide tab (where dither parameters used to be).
  • Removed the Control sub-tab from the Guide page (the sub-tab next to "Drift Plot" and "Calibration Plot").
  • Removed UI controls related to image guiding and rapid guiding
Furthermore, The standard control algorithm now uses calibration information when computing pulses. The control gain parameter for RA and (a separate one for DEC) now go from 0 to 1.0. It multiplies the error and the calibrated arcsec_per_ms_pulse. (Similar adjustments were made to the optional integral_gain.)
proportionalResponse = arcsecDrift * proportionalGain * arcsecPerMsPulse
The Proportional Gain was renamed to the industry standard name of Aggressiveness. The guider's min-pulse and max-pulse (both in milliseconds) parameters were changed to Min Error and Max Response, both with units of arc-seconds instead of milliseconds of pulse. Hopefully more intuitive to users. The derivative gain control was dropped since it was never used in the code before.

Users are highly recommended to revise their internal guider settings to achieve the best results.

More Improvements & Fixes

  • Add shortcuts for increasing and decreasing the time scale (by Nate Graham).
  • Control Mount with arrow keys (by Siyu Zhang)
  • Eliminating formerly required Python options for local astrometry.net on MacOS (By Robert Lancaster)
  • Stable alphabetical INDI device order (by Dušan Poizl)
  • Remove pre-calculated pixel-to-WCS lookup table which takes huge amounts of memory (two floats per pixel) and slows down image loading (by Jarno Paananen)
  • Broad Documentation updates with updated screenshots (by Antoni Bella Pérez)
  • Batch add option in the Observation Planner (by Akarsh Simha)
  • Better sectioning for translation (by Yuri Chornoivan)
  • Fix core computations in SkyPoint and StarObject, and a few other improvements (By Akarsh Simha)
  • Move focuser back to initial position when interrupted by a meridian flip (By Wolfgang Reissenberger)
  • Save Binning, Fits filter settings (guider), Camera gain (solver) and configure SEPMultistarOptions correctly (By Antonio Escriban)
  • Resize manager: change the size of the log view (By Jürgen Terpe)
  • Update skyculture sternenkarten simplifying some constellation lines adding new constellation lines for the southern hemisphere (By Edgar Scholz)







1 comment:

Unknown said...

Great news can't wait to give it a go.

I just tried to build from source on my RPi4 but get an error when running CMake.

"CMake Error at CMakeLists.txt:218 (find_package):
By not providing "FindStellarSolver.cmake" in CMAKE_MODULE_PATH this
project has asked CMake to find a package configuration file provided by
"StellarSolver", but CMake did not find one.

Could not find a package configuration file provided by "StellarSolver"
with any of the following names:

StellarSolverConfig.cmake
stellarsolver-config.cmake

Add the installation prefix of "StellarSolver" to CMAKE_PREFIX_PATH or set
"StellarSolver_DIR" to a directory containing one of the above files. If
"StellarSolver" provides a separate development package or SDK, be sure it
has been installed"

can anyone help?