Tuesday, April 24, 2018

KStars 2.9.5 is out!

KStars v2.9.5 is now available for Windows, MacOS, and Linux.

Autofocus module users would be happy to learn that the HFR value is now responsive to changing seeing conditions. Previously, the first successful autofocus operation would set the HFR Threshold value of which subsequent measurements are compared against during the in-sequence-focusing step.

However, this method suffers from two issues:

  1. Seeing could change during the night.
  2. HFR value could be different for different filters.
These issues can lead to interesting artifacts under the right conditions, most notably repeatedly running a complete autofocus run after each subsequent exposure thereby losing precious observation time in a futile attempt to bring the HFR value down.

In KStars 2.9.5, we introduce an experimental adaptive HFR Thresholding algorithm that selects the median HFR value filter-wise. It still has to be seen whether this is an overall better approach, so go out and test this!

Ekos Scheduler module has received major patches from Eric Dejouhanet to improve its reliability and fix some corner cases. More patches are in the pipeline to make the scheduler rock solid in various complex scenarios.

A quite illusive and annoying time-zone related bug was fixed when using INDI GPS devices. Now KStars correctly accounts for the UTC offset. Another related issue is related to preventing race conditions between multiple devices that may send time information, such as mounts and GPS devices, so now you can explicitly select which device to receive the location and time information from.



Finally, Align module FOV now default to zero on startup. Previously, FOV as calculated from the telescope focal length & camera pixel size was used to derive other values passed to the solver. However, it turns out that the FOV for real optical trains can be different. Using focal reduces, coma correctors, and even filter wheels or spacers can alter this value, sometimes quite significantly to the unsuspecting user.

Therefore, relying alone on the calculated FOV might actually cause astrometry.net to fail since the actual FOV might fall beyond the field of view threshold boundary. With this addition, the first solver run would take a little bit longer but it would also produce a quite accurate effective FOV. You can think of the effective FOV as the real FOV that your combination of your camera, telescope, and whatever sits in between (aka optical train) ends up producing.


This effective FOV is then saved for each Profile-Telescope-Camera combination for future use. This is all done behind the scenes to make user experience much more pleasant and bullet proof when using the Ekos Alignment module.

Clear skies!

Thursday, April 12, 2018

Spring season KStars v2.9.4 is Released!

Glad to announce the release of KStars v2.9.4 aka Emad is now release for Windows, MacOS, and Linux!

The new release brings in more performance improvements and bug fixes.

Spring Galaxy Season
Credit Turki AlAmri


Valentin Boettcher
introduced a highly efficient binary interface for asteroids that would allow quite large (> 100MB) and distant catalogs to be loaded into KStars without a major impact on performance. Before this change, loading any JPL catalogs for faint asteroids (> 15 mag) resulted in significant slowdown of KStars during startup as well as during run-time. Now users can comfortably load fainter asteroids given they have enough system memory to handle it.

Automatic Flat field calculations were fixed for multi-channel DSLR frames along with an improved DSLR popup dialog. The online astrometry option with offline server bug was fixed and now users can connect to local instances of astrometry.net without any problems.

The Ekos scheduler workflow was revamped to evaluate all jobs every time a new job is invoked to ensure all scores are updated accordingly and not only on the first job run. More SEP work for star & galaxy detection is merged into the internal guide module resulting in a better object detection even in noisy environments.
Messier Marathon with Ekos Scheduler

Furthermore, the guide module is now a lot more tolerant to passing clouds. When a star lock is lost, it will attempt to reacquire the lost star for several iterations before giving up.

On the capture frontend, users can now instruct Ekos to take flat field frames exactly at the same focus position where light frames of the same filter were captured. For example, suppose you are taking an LRGB sequence, and the best autofocus position for Green filter is 37,000 ticks. By the time you finish the sequence the focus position would most likely have moved due to the Blue filter (unless they're perfectly parafocal). Once you start capturing flat fields afterwards, typically the focus position is kept as-is. However, now it is possible to synchronize the focus position when capturing flat fields as well. When a flat field Green capture is requested, Ekos shall instruct the focuser to move to 37,000 ticks as indicated by the last successful autofocus operation of the same filter.

Finally, users might have noticed especially on slower systems that opening large FITS files can take a while to load up. In v2.9.4, the FITS handling code was optimized with loading times improving on the order of 300%.

FITS Speed improvements

Turns out that statistics calculations were eating up significant amount of precious CPU cycles. Many of these calculations would greatly benefit from SIMD support like SSE/NEON but since KStars runs on multiple architectures, it requires an architecture-agnostic solution and major refactoring of the code base. Another solution that was more readily available is to employ multiple threads to by partitioning the image and therefore spreading the calculations. It is certainly a poor-man's SIMD in a way, but the results were immediately noticeable.

Using 16 threads, computing min and max values was reduced from 122ms to only 30ms. Running mean and standard deviation calculations took 118ms instead of 270ms. Here is an excerpt from the Qt Concurrent magic that made this signifantly easier to code than using plain pthreads.

QList<QFuture<QPair<double,double>>> futures;

for (int i=0; i < nThreads; i++)
{
 // Run threads
 futures.append(QtConcurrent::run(this, &FITSData::getSquaredSumAndMean<T>, tStart, (i == (nThreads-1)) ? fStride : tStride));
 tStart += tStride;
}

double mean=0, squared_sum=0;

// Now wait for results
for (int i=0; i < nThreads; i++)
{
 QPair<double,double> result = futures[i].result();
 mean += result.first;
 squared_sum += result.second;
}

double variance = squared_sum / stats.samples_per_channel;

stats.mean[n] = mean/nThreads;
stats.stddev[n] = sqrt(variance);

There is room for more improvement still, especially since now we are loading the FITS twice unnecessarily. This could be resolved by using an implicit sharing data model among FITS files that does not require a deep-copy of the data until the underlying data is altered. This could result in a 100% improvement in loading speeds when using Ekos as well. Stay tuned!