Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Juan Conejero

Pages: [1] 2 3 ... 26
1
Announcements / PixInsight 1.8.8-2 Released
« on: 2019 November 25 09:27:46 »
Hi all,

I am glad to announce a new version of the PixInsight core application: 1.8.8-2. This version is now available as an automatic update to versions 1.8.8 and 1.8.8-1 for FreeBSD, Linux, macOS and Windows.


Main Bug Fixes and Improvements

* Fixed a complex bug in version 1.8.8-1 of PixInsight that has been causing sporadic segmentation faults, especially during long script executions. This mainly includes the BPP and WBPP scripts. See original bug reports:

https://pixinsight.com/forum/index.php?topic=14283.0
https://pixinsight.com/forum/index.php?topic=14265.0

* Windows: Fixed a bug where process and script execution times where incorrect (with absurdly long values) for tasks lasting more than 20 minutes approximately.

* All platforms: Improved elapsed time measurements with guaranteed time stamp resolution better than 1 microsecond on all supported platforms.

* Improved management of updates, with better evaluation of package inter-dependencies and more flexible update repositories.


Known Issues

FreeBSD and Linux

* Recent versions of the KDE Plasma desktop environment include a morphing popups desktop effect that causes problems with recent PixInsight versions. If this effect is enabled, it slows down some dragging operations in the PixInsight core application, such as dragging icons and view selectors. You should disable this effect, which is very easy from KDE's System Settings panel. This problem is also present on Linux.

* On recent versions of the KDE Plasma desktop environment, a display tearing prevention option (v-sync) is enabled by default. This option can cause input lag problems (e.g., slow cursor movement over image windows). This option should be disabled for optimal PixInsight performance:

- System Settings > Display and Monitor > Tearing prevention: set to 'Never'
- Click Apply

Linux

* PixInsight is not compatible with the open-source Nouveau graphics driver. If your distribution is using Nouveau, you must remove and replace it with the proprietary Nvidia driver in order to use PixInsight.

macOS

* On Apple laptops with dual graphics cards, the integrated Intel graphics driver may cause problems with recent versions of PixInsight. If you use one of these laptops, we recommend you disable the Automatic graphics switching option on System Preferences (Energy Saver section) before running the PixInsight core application.

Windows

* There are problems with Intel graphics drivers on machines where the _only_ graphics card available is an integrated Intel HD graphics GPU. This mainly affects laptops. This does not mean that PixInsight cannot work on these machines, just that you can expect screen rendering and usability issues. Unfortunately, there is nothing I can do to solve these problems. On machines with dual graphics (e.g., an NVIDIA discrete graphics card plus an integrated Intel HD graphics card), there are no problems at all because PixInsight forces the use of the high-performance discrete GPU automatically.

* On some laptops with nonstandard screen resolutions, such as the Microsoft Surface, PixInsight cannot find valid screen scaling factors automatically. On these machines, you may have to run the PixInsight core application with the --ui-scaling command line argument. For example, to apply a UI scaling factor of 2:

C:\Program Files\PixInsight\bin\PixInsight.exe --ui-scaling=2

You only have to do this once, since the scaling factor will be stored in application preferences automatically. Of course, if you already are using version 1.8.6 and the interface looks correct, then you don't need to do this; this is only required for new installations.

__________

Thank you for your attention.

2
Announcements / Compatibility Update: RAW Module
« on: 2019 November 15 13:49:20 »
Hi all,

This announcement is relevant for PixInsight users working with raw data acquired by some DSLR cameras. It describes a serious incompatibility introduced by recent versions of LibRaw, an open-source software library which our standard RAW module uses as a back-end to support raw formats of digital cameras.

Description of the Problem

The RAW module included in the latest 1.8.8 version of PixInsight uses LibRaw 201910 snapshot. Since this version, LibRaw has changed the way some raw formats are decoded. The changes we are interested in here refer to the coordinates of the visible region of the raw image with respect to the entire (uncropped) raw frame. As you probably know, many (most?) DSLR raw formats define unused areas of the raw frame, which correspond to rows and columns of pixels that are never exposed to light. Obviously, these unused regions are located at the edges of the raw frame, and their dimensions and location depend on the particular formats used by each camera model. Our RAW module provides a preferences option to enable/disable automatic cropping of unused areas, which is enabled by default.

Unfortunately, the changes introduced by LibRaw since the 201910 snapshot version for some cameras create an incompatibility with master calibration frames generated from raw frames of the affected formats with PixInsight 1.8.7 and earlier versions. This problem affects mainly to some Canon cameras, where the visible region of the image begins at odd vertical pixel coordinates from the upper left corner of the entire raw frame. This includes, probably among others, the following cameras:

EOS 1D Mark IV
EOS 5D Mark II
EOS 7D
EOS 60D
EOS 550D
EOS 600D
EOS 1200D

See the original bug report where this problem has been first described (to my knowledge) on this forum. The report refers to the Canon EOS 600D, which is quite popular among PixInsight users working with DSLR cameras. As you can see, in this camera the visible region of the frame starts at vertical pixel coordinate y=51, where x=y=0 corresponds to the pixel at the upper left corner of the uncropped raw frame.

LibRaw versions before the 201910 snapshot version reported frame coordinates correctly for all Canon cameras, that is, the actual coordinates of the visible image within the raw frame, as well as the actual Bayer pattern, which is always RGGB for these cameras.

Since the 201910 snapshot version, LibRaw intentionally removes the first row of pixels from the visible image for these raw formats. In the case of EOS 600D for example, LibRaw reports now a visible region starting at y=52 with a height of 3464 pixels, instead of the actual 3465 pixels. Since the cropped frame starts at y=52 instead of y=51, the reported Bayer pattern is now GBRG instead of RGGB.

The authors of LibRaw have good reasons to implement this change. As a software developer, I can understand their reasons from a technical point of view. The repercussions of this change for daylight or 'normal' photography applications are as minimal as a single row of pixels cropped at the top of the image. However, the problems generated are severe for applications requiring calibration of raw data.

LibRaw is not going to revert these changes. Since there is no alternative to LibRaw for a multiplatform application, we have to find a suitable solution.

Our Solution

The solution we have implemented is quite simple: a special update-compat repository, where you can opt-out of the new RAW module in PixInsight 1.8.8-1 and future versions, replacing it with a module that is compatible with existing master calibration frames generated with PixInsight 1.8.7 and older versions for the affected cameras (see the list above).

If you really need to use master calibration frames incompatible with the latest version of LibRaw, here is the procedure to opt-out of the current RAW module:

1. Make sure that you are using PixInsight core version 1.8.8-1. This version is distributed as an automatic update for core version 1.8.8.

2. Make sure that you have applied all available updates for 1.8.8-1. Note that this includes an update to the standard RAW module. You must apply this update before continuing.

3. From the main menu, select Resources > Updates > Manage Repositories.

4. On the Manage Update Repositories dialog, click the Add button.

5. Enter the following repository URL:


6. Click OK, Then OK again on the Manage Update Repositories dialog.

7. From the main menu, select Resources > Updates > Check for Updates.

8. The Select and Download Updates dialog should now be open. Make sure that the RAW_compat update is available, then click Apply.

9. After downloading and extracting the update, as usual, exit the PixInsight core application and apply the update.

10. Check that you have the RAW_compat module in Format Explorer.

Here is a small video showing the above procedure:


After the update, the standard RAW module will be replaced by a special RAW_compat module that uses an improved version of LibRaw 0.19.5-Release. The RAW_compat module is basically the same RAW module included in PixInsight 1.8.7. You can use it while you have to use old master calibration frames for Canon cameras suffering from this incompatibility. Our recommendation, however, is to return to the standard RAW module once you are ready to work with newly acquired data.

To return to the standard RAW module, remove the update-compat repository enabled with the above procedure. Then add the following repository URL:


and repeat the check for updates process, etc. This will reinstall the standard RAW module using the latest LibRaw version available.

I hope this solution will be useful for all users that have to suffer from this serious compatibility issue. Please realize that we are not causing this problem. For obvious reasons, we cannot stick to an old version of one of our fundamental third-party support libraries. Thank you for your patience and understanding.

3
Announcements / PixInsight 1.8.8-1 Released
« on: 2019 November 14 04:27:27 »
Hi all,

I am glad to announce a new version of the PixInsight core application: 1.8.8-1. This version is now available as an automatic update to version 1.8.8 for FreeBSD, Linux, macOS and Windows.

Main Bug Fixes and Improvements

* Fixed a bug where a wrong warning message was shown when closing an image, after working on it in the Real-Time Preview interface with multiscale processing tools (MultiscaleLinearTransform and MultiscaleMedianTransform). Original bug report:

https://pixinsight.com/forum/index.php?topic=14181.msg85200#msg85200

* Fixed an object dereferencing bug that was causing a memory leak of 32 bytes per image. This bug has not been reported by users.

* Implemented several improvements to the Real-Time Preview interface, which is now faster and provides more robust previews with respect to the initial 1.8.8 version.

* Build numbers are now definitely deprecated and will no longer be used (although they are still available from JavaScript code for compatibility with existing scripts). Build numbers have been replaced by revision numbers, which are exclusive for each release (for example, this new 1.8.8-1 version).

* The application's main window title no longer shows version numbers. The title is from now on just "PixInsight".

Breaking Changes

New syntax of update repository information XML files. The deprecation of build numbers, along with several improvements implemented in this version, change the way update repositories must define their XML repository information files ('updates.xri' files) from now on. A complete description of these changes will be published, but to keep existing third-party repositories working right now, below is a description of an important change that should be implemented by third-party repositories in 'updates.xri' files to provide updates since version 1.8.8-1.

Until version 1.8.8-1 of PixInsight, the 'version' attribute of 'platform' XML elements can include optional build numbers as fourth elements of version specifications. Here is an example:

   <platform os="all" arch="noarch" version="1.8.8.1492:1.8.8.1493">

Since version 1.8.8-1, build numbers are no longer allowed and version specifications must always have three components separated by dots. To address a particular range of PixInsight core versions, you should specify a revision number in the third element of each version specification, separated by an hyphen character. Examples:

   <platform os="all" arch="noarch" version="1.8.8-1:1.8.8-3">
   <platform os="linux" arch="x64" version="1.8.8-1:1.8.8-1">

In practice, this means that if you want to differentiate between specific core versions released before and after 1.8.1-1, you'll have to build separate repositories to distribute your scripts and/or modules, and inform your users about the different repository URLs.

If you are not using build numbers to distribute your scripts or modules selectively, then you don't have to make changes for now. For example, the following platform XML element will continue working correctly in PixInsight 1.8.8-1:

   <platform os="all" arch="noarch" version="1.8.6:1.8.8">

Should you have any doubts or problems with these changes, please don't hesitate to ask here.

__________

Thank you for your attention.

4
Announcements / PixInsight 1.8.8 Released
« on: 2019 November 07 14:10:42 »
I am glad to announce that PixInsight 1.8.8 has been released today. This version is a new milestone in the history of PixInsight, with important new features and a strong focus on stability and performance. It is the result of an intense research and development work carried out during the last months. Expect much more during the months ahead.

Installation packages for PixInsight 1.8.8 are now available to all licensed users for FreeBSD, Linux, macOS and Windows:

https://pixinsight.com/dist/

This version is a major update that you have to install manually. It is not available as an application update.

If you have version 1.8.6 or 1.8.7 already installed, this new version does not require a license reactivation. If you are still using a 1.8.5 version or older, see the official 1.8.6 version announcement for a detailed description of our new licensing system. See also FAQ 2.10 for additional information on license reactivations.


New Features

Here is a brief list with the most important changes and new features implemented in PixInsight 1.8.8.



Improved Real-Time Preview

The Real-Time Preview interface has been largely redesigned and reimplemented in version 1.8.8 of PixInsight. You can now zoom the real-time preview image by clicking and dragging with the mouse to define a rectangular selection. This can be done in Select Preview mode (click the concentric squares button), or directly by clicking the middle mouse button and dragging.


You can navigate through a chain of successive zoomed previews with the Next Preview, Previous Preview and Full Preview buttons. Finally, you can adjust the size of the real-time preview window to fit the current image automatically by clicking the Fit Preview button. The rest of real-time preview features and functions are basically the same as in previous versions.

Besides new user interface features, the Real-Time Preview interface is now faster, more accurate and reliable with all tools currently implementing real-time preview functionality.



New Pixel Rejection Algorithm: Generalized Extreme Studentized Deviate (ESD)

The ImageIntegration tool implements a new pixel rejection algorithm: Generalized Extreme Studentized Deviate (ESD) Test, or ESD rejection for short. This is an implementation of the method described by Bernard Rosner in his 1983 paper Percentage Points for a Generalized ESD Many-Outlier procedure, adapted to the image integration task. The ESD algorithm assumes that each pixel stack, in absence of outliers, follows an approximately normal (Gaussian) distribution. It aims at avoiding masking, a serious issue that occurs when an outlier goes undetected because its value is similar to another outlier. The performance of this algorithm can be excellent for large data sets of 25 or more images, and especially for very large sets of 50 or more frames. I have seen very good results in some of our tests for more modest sets of 12-15 images.

ESD rejection takes just two parameters:

Expected maximum fraction of outliers. For example, a value of 0.2 applied to a stack of 10 pixels means that the ESD algorithm will be limited to detect a maximum of two outlier pixels, or in other words, only 0, 1 or 2 outliers will be detectable in such case. The default value is 0.3, which allows the algorithm to detect up to a 30% of outlier pixels in each pixel stack.

Significance level. This is the probability of making a Type I error (false positive), or the significance level of the outlier detection hypothesis test. For example, a significance level of 0.01 means that a 1% chance of being wrong when rejecting the null hypothesis (that there are no outliers in a given pixel stack) is acceptable. The default value is 0.05 (5% significance level).

The documentation of the R implementation of this algorithm provides interesting information with the results of 10,000 simulations for different data sets and parameters. I'll describe this algorithm in detail, including our implmentation and its advantages for the image integration task, in the release information board of this forum during the coming days.



PixelMath: New Functions and Features

The following PixelMath functions have been implemented in version 1.8.8 of PixInsight:

range( x, a, b )

x constrained to the [a,b] range:
Returns x if x >= a and x <= b
Returns a if x < a
Returns b if x > b

rescale( x, a, b )

x rescaled linearly from the [a,b] range to [0,1]:
Returns 0 if x < a or b - a is zero or insignificant.
Returns 1 if x > b
Returns (x - a)/(b - a) if x >= a and x <= b
a and b are swapped internally (and transparently) if b < a.

gauss()

Normal (Gaussian) random deviate with zero mean and unit standard deviation. A typical application of this function to add normal distributed noise to the target image is:

$T + k*mdev( $T )*gauss()

where the median absolute deviation from the median (MAD), multiplied by an optional amplitude parameter k, defines the standard deviation of additive noise adaptively.

poisson( x )

Random Poisson deviate for the specified pixel value x. A typical application of this function is:

poisson( 65535*$T )/65535

which will generate Poisson noise for the current pixel value in the [0,1] range, simulating a 16-bit detector of unit gain.

studentt( degreesOfFreedom )

Random deviate from a Student's t distribution with the specified degrees of freedom, which must be > 0.

chisq( degreesOfFreedom )

Random deviate from a chi squared distribution with the specified degrees of freedom, which must be > 0.

gamma( shape[, scale=1] )

Random deviate from a Gamma distribution with the specified shape and (optional) scale parameters. If not specified, the default scale is 1.0.

PixelMath comments

The PixelMath language supports now C-style comments with the '/*' and '*/' delimiters. This is very useful when one wants to document briefly the PixelMath expressions, or to try out several function parameters or subexpressions without having to create temporary process icons. For example, the following expression can be used to combine two images selectively:

iif( $T < k, $T + (1 - k)*A, $T )

If one wants to check which areas of the target image will be combined with pixels from A, a comment can be used as follows:

iif( $T < k, 1/*$T + (1 - k)*A*/, $T )

which will replace all target pixels less than k with white temporarily. After finding a good value for k in this way, the comment can be removed to apply the actual PixelMath transformation.



Improved Blink Tool


Blink is now faster and more reliable. Besides important improvements in its graphical interface, Blink implements now a fully parallelized statistics calculation procedure. On machines with a reasonable number of CPU cores, Blink's automatic histogram transformation is orders of magnitude faster than before. The same applies to the series analysis report.



PixInsight Platform: Improved Multithreading Performance

In this version we have reimplemented a significant part of our code base to improve performance of multithreaded code. The improvement is especially relevant for machines with many cores running CPU-intensive tasks. See for example these benchmarks performed on the same workstation:

http://pixinsight.com/benchmark/benchmark-report.php?sn=4ON47FRJB0NF090S421V1LHNH2B6O9EW
http://pixinsight.com/benchmark/benchmark-report.php?sn=2BEVIS11SHGMU7F0774YJ3HTN4YH1MDV

Besides the difference in the amount of installed RAM, which is not relevant in this case, the machine is the same in both benchmarks: AMD Ryzen Threadripper 2990WX with 64 or 128 GiB of RAM (DDR4 UDIMM ECC 2666 MHz). With 32 physical cores and 64 threads, this machine shows a performance improvement close to a 10% in version 1.8.8 with respect to versions 1.8.6 and 1.8.7 (CPU performance indexes of 25087 and 22844, respectively).



PixInsight Platform: Improved Project Management

Bundled PixInsight projects (.pxiproj file suffix) can now be freely renamed without breaking their functionality. Of course, existing projects will work flawlessly and will be converted to the new format transparently when rewritten with the File > Save Project command.

Besides this, loading projects is now faster and the image reading tasks are now more responsive and provide more feedback on the process console.



PixInsight Platform: New Hack Font

The Hack font has replaced DejaVu Sans Mono as the standard core manospaced font on all platforms. Hack provides better screen legibility for source code and pixel readouts.



PixInsight Platform: New Pseudo-Random Number Generators

Since version 1.8.8 of PixInsight we use exclusively xoshiro256** and xoroshiro1024** PRNGs (XOR/shift/rotate and XOR/rotate/shift/rotate, respectively) on the entire PixInsight/PCL/PJSR platform. Previously used Marsenne Twister and xorshift generators have been deprecated, although they are still available for compatibility.



PixInsight Platform: Support for Bitmaps Larger than 2 GiB


Bitmap objects (available on the PCL and PJSR development environments) can now be larger than 2 GiB. This includes pixel data allocation and direct pixel access, along with the entire drawing capabilities of our Graphics and VectorGraphics objects. This overcomes an important limitation present in core versions 1.8.7 and older.



Updated Third-Party Support Libraries

PixInsight 1.8.8 includes the following updates to critical support libraries:

* The RAW format support module integrates the latest LibRaw 201910 snapshot version. This means that we now support Canon CR3 raw files, among many other new camera raw formats and other improvements.

* Core application built with the latest Qt version 5.13.2. The core PixInsight 1.8.8 application uses the latest version of the Qt library (as of writing this) on Linux, macOS and Windows. We are still using Qt 5.12.2 on FreeBSD, but this will change as soon as possible.



Bug Fixes

PixInsight 1.8.8 fixes all confirmed bugs detected since the last 1.8.7 release, with a unique exception: a complex bug involving the PixelMath and Statistics tools, which still is present in this version. I'll try to fix this problem as soon as possible with an update to the core application.


Known Problems

FreeBSD

* Recent versions of the KDE Plasma desktop environment include a morphing popups desktop effect that causes problems with recent PixInsight versions. If this effect is enabled, it slows down some dragging operations in the PixInsight core application, such as dragging icons and view selectors. You should disable this effect, which is very easy from KDE's System Settings panel. This problem is also present on Linux.

Linux

* PixInsight is not compatible with the open-source Nouveau graphics driver. If your distribution is using Nouveau, you must remove and replace it with the proprietary Nvidia driver in order to use PixInsight.

* The same problem with KDE's morphing popups desktop effect exists on FreeBSD and Linux (see above).

macOS

* On Apple laptops with dual graphics cards, the integrated Intel graphics driver causes problems with recent versions of PixInsight. If you use one of these laptops, we recommend you disable the Automatic graphics switching option on System Preferences (Energy Saver section) before running the PixInsight core application. Otherwise you may experience some interface usability problems.

Windows

* There are problems with Intel graphics drivers on machines where the only graphics card available is an integrated Intel HD graphics GPU. This mainly affects laptops. This does not mean that PixInsight cannot work on these machines, just that you can expect screen rendering and usability issues. Unfortunately, there is nothing I can do to solve these problems, for now.

* On some laptops with nonstandard screen resolutions, such as the Microsoft Surface, PixInsight cannot find valid screen scaling factors automatically. On these machines, you may have to run the PixInsight core application with the --ui-scaling command line argument. For example, to apply a UI scaling factor of 2:

C:\Program Files\PixInsight\bin\PixInsight.exe --ui-scaling=2

You only have to do this once, since the scaling factor will be stored in application preferences automatically. Of course, if you already are using version 1.8.6 and the interface looks correct, then you don't need to do this; this is only required for new installations.

* The Export as PDF feature of the integrated web browser component does not work on Windows. I'll try to fix this in a future release.


Recommended Platforms and Supported Operating Systems

The reference implementations of PixInsight 1.8.8, where you may expect the maximum performance and best user experience, are the FreeBSD and Linux versions. Currently our primary development platforms are:

- Kubuntu Linux 18.04 LTS
- FreeBSD 12.0

On FreeBSD and Linux we strongly recommend running PixInsight on the KDE Plasma desktop environment. PixInsight 1.8.8 has been tested on the following Linux distributions:

Kubuntu 18.04 LTS
Kubuntu 19.04
Fedora 29
Fedora 30
Linux Mint 19.1

PixInsight 1.8.8 for Linux requires GLIBC 2.27 or a newer version.

PixInsight 1.8.8 for macOS is only compatible with macOS 10.12, 10.13, 10.14 and 10.15. Older versions are not supported. Our installation packages have been notarized by Apple.

PixInsight 1.8.8 for Windows is compatible with Windows 10 exclusively. Windows 8.1, Windows 7 and older versions are not supported. The application may run well on Windows 7, but there is no guarantee.


Hardware Requirements: Breaking Changes

The FreeBSD, Linux and macOS versions of PixInsight 1.8.7 and 1.8.8 require a processor with SSE4.2 instruction support.


Short-Term Development Lines

During the next months we plan on releasing the following new products on the current PixInsight 1.8 platform:

* MosaicGenerator. An astrometry based automatic mosaic construction tool.

* DynamicBackground. An improved background modeling/correction tool, which will be the successor to the current DBE tool.

* A new tool (name still unknown) for astrometry based measurements, integrated with the core application.

* A new high-performance format for storage of large star databases. The Gaia DR2 catalog will be available for download as one of these databases. This will greatly improve all of our astrometry based tools, such as the ImageSolver script and the new MosaicGenerator tool, which will be able to work with local files without the limitations imposed by online services.


___________________

Thank you for your attention and continued support. Enjoy!

5
Announcements / PixInsight 1.8.7 Released
« on: 2019 October 01 09:40:35 »
I am glad to announce that PixInsight 1.8.7 has been released today. This version is a particularly important milestone, and I'm proud of all the hard work we have put into it.

Installation packages for PixInsight 1.8.7 are now available to all licensed users for FreeBSD, Linux, macOS and Windows:

https://pixinsight.com/dist/

This version is a major update that you have to install manually. It is not available as an application update.

If you have version 1.8.6 already installed, this new version does not require a license reactivation. If you are still using a 1.8.5 version or older, see the official 1.8.6 version announcement for a detailed description of our new licensing system. See also FAQ 2.10 for additional information on license reactivations.


New Features

As always, our releases come with new features, bug fixes, and improvements. Here is a brief list with the most important changes.


PixInsight Platform: New Versioning System


So far PixInsight versions have consisted of four elements: major, minor, release and build version numbers. For example: 1.8.6.1475. Since version 1.8.7 onward, build version numbers will no longer be used. This applies to all components of the PixInsight platform, including the core application, all officially released modules, and our C++ and JavaScript development frameworks. So from now on you'll see new PixInsight versions released as 1.8.7, ..., 1.8.42, ... and so on.

For compatibility with some existing scripts and modules, the core application reports a fixed build number when requested from C++ or JavaScript code, which is higher than all previous versions. However, new scripts should not rely on build numbers anymore to check for existence of core features or other purposes.


Core Application: New Workspace Selectors


One of the most visible changes in the PixInsight core 1.8.7 application is its new Workspace Selector tool bar. Workspace selector items are now dynamic components that provide visual information on workspace contents. You'll see three small dots drawn on a selector with the following meaning:

- Top dot: The workspace contains process interface windows.
- Middle dot: The workspace contains process icons.
- Bottom dot: The workspace contains images.

The new workspace selectors provide you real-time feedback as your data and processes are being distributed throughout workspaces. This feature is particularly useful when you open a project. No more guessing about where icons, tools and images are located; now you know that at a glance.


Core Application: Improved Transfer View Zoom/Position Feature

When you drag a view selector and drop it on another selector, the position and zoom level of the source view are transferred to the target view. So far this only worked when both views had the same dimensions. Since version 1.8.7 this always works, irrespective of view geometry differences. When the views have different dimensions, target positions and zoom ratios are computed to approximate the source view conditions as best as possible. This is very useful to compare images at different scales, such as drizzle x2 and normal integration results.


StarAlignment: New Arbitrary Distortion Correction Algorithm


A considerable amount of research and development work has been done on the StarAlignment tool in PixInsight 1.8.7. The most important changes are the following:

* A new arbitrary distortion correction algorithm, redesigned and reimplemented from scratch. This two-stage algorithm (iterative global distortion and local distortion models) aims at achieving centipixel accuracy in most image registration tasks.

* Star positions and fluxes are now computed from robust PSF fittings, including a new statistical weighting system based on robust goodness-of-fit estimates. This largely improves reliability and accuracy of image registration, especially under strong distortions.

* Improved intersection computation, which is now more efficient, accurate and robust. Frame intersections are computed by default in mosaic generation modes, and can also be enabled manually in register/match mode to solve small overlapping issues automatically.

* Improved RANSAC model validation routines, which are now more efficient and resilient to ill-posed image registration problems.

* Generation of distortion maps, which are special control images where each pixel value is proportional to the difference between the applied image registration model and a projective transformation. These maps are useful to check and evaluate image distortions.

* New randomized mosaic combination feature. In register/union mosaic mode, instead of replacing reference image pixels with registered target image pixels, both images are now combined by selecting pixels from one of the images randomly. This works much better to produce seamless mosaics without visible texture differences.

* Improved star maps generated in detected/matched stars working modes. Star maps can now be used directly as masks.

* Metadata items describing center celestial coordinates and image scale are now replaced with reference image values in all registered target images. This includes RA/DEC, OBJCTRA/OBJCTDEC, XPIXSZ/YPIXSZ and FOCALLEN FITS keywords, as well as the corresponding Observation:Center:RA, Observation:Center:Dec, Instrument:Sensor:XPixelSize, Instrument:Sensor:YPixelSize and Instrument:Telescope:FocalLength XISF properties.

* The user interface has been simplified. Many advanced parameters have been removed and are only available by editing instance source code. This has been possible because the new distortion correction algorithm is much more robust and requires virtually no manual intervention. It uses much more parameters internally, but there is no reason to change their default values, except in very unusual cases.


ImageIntegration: New Winsorization Cutoff Parameter / Improved Linear Fit Clipping


Several improvements have also been implemented in the ImageIntegration tool. Besides other minor performance improvements, these are the main changes:

* New automatic buffer sizes feature. When this option is enabled, the ImageIntegration tool uses the largest possible buffer size and stack size values, calculated automatically from the amount of free physical memory currently available to PixInsight. Usually this is the best option to optimize image integration performance, especially because it is completely automatic. This option is enabled by default.

* New truncate on out-of-range parameter. When the output integrated image has saturated pixel samples out of the nominal [0,1] range, this option truncates saturated pixels instead of rescaling the whole image. No out-of-range values should occur after integration of a well-calibrated data set. However, with improperly calibrated data, saturated pixels may lead to out-of-range values after output normalization, depending on the frame selected as integration reference. When this happens, the best option for integration of light or science frames is a linear rescaling, which preserves all of the integrated data. However, in some cases altering all pixel values is not admissible, so a rescaling operation is not applicable. This is the case for integration of flat frames, where truncation is the only option available to preserve the correct illumination profile in the integrated master flat frame.

* New subtract pedestals option. When this option is enabled, existing (nonstandard) PEDESTAL keyword values are subtracted from input images. Some applications add small positive values (typically about 100 DN) systematically to calibrated light frames. These small pedestals should be subtracted from source integration pixels to refer all input data to the same zero point consistently. This option should be enabled under normal working conditions, and hence is enabled by default. PEDESTAL keywords generated by PixInsight always have positive values. Other applications may write negative values (another 'nice' example of FITS interoperability issue). For improved compatibility, when ImageIntegration finds a negative pedestal, it issues a warning message and assumes that the value is intended to be added.

* New Winsorization cutoff parameter. This is a cutoff point for the Winsorized sigma clipping rejection algorithm, expressed in sigma units. All pixel samples with absolute differences from the median larger than this parameter will be set equal to the median of the pixel stack in the first rejection iteration. This replaces extreme outliers, such as cosmics, hot and cold pixels, with plausible values instead of their nearest neighbors. This is more correct because allowing some influence from severe outliers does not make sense---after all, we know they are outliers without uncertainty, so Winsorizing them is a conceptual error. These errors, present in previous versions of the ImageIntegration tool, are insignificant statistically, so their practical influence is negligible. Nevertheless, we now have a fully correct implementation of Winsorized sigma clipping since PixInsight 1.8.7. The default Winsorization cutoff parameter value is 5 sigmas, which should be sufficient to detect extreme outliers without compromising the performance of the algorithm in terms of preservation of significant data.

* Improved implementation of linear fit clipping rejection. So far we have been using a slight simplification of the linear fit clipping algorithm. Instead of using the distance from each pixel value to the fitted straight line to make rejection decisions, we used only the vertical distance, for performance reasons. We now use accurate distance values, which is more correct mathematically, with a small computational cost. Again, the errors made in previous versions were negligible, mainly because fitted line slopes are usually small (for a nearly horizontal line, the vertical distance is a good approximation to the true distance from a point to the line). As a result of this change, you may notice small changes in the way linear fit clipping works, in terms of the required low and high clipping points, hopefully leading to a better rejection with more preservation of significant data.

* Improved preservation of existing metadata. Center celestial coordinates and geodetic observation coordinates are now averaged from the set of input images, and a large set of XISF properties and FITS keywords are preserved in the output integrated image. This greatly facilitates image analysis tasks, mainly for astrometry and photometry.


DrizzleIntegration: Improved Integration Geometry and Pixel Rejection / Local Distortion Support


* Improved integration geometry. Previous versions of the DrizzleIntegration tool had minor issues with the geometry of the final integrated image. As a result, drizzle-integrated and normal integrated images were not perfectly registrable, with differences up to 0.5 pixels. All of these issues have been fixed in the new version. The results of DrizzleIntegration and ImageIntegration for the same data set are now directly registered to centipixel accuracy, with an integer scaling factor equal to the applied drizzle scale.

* Improved pixel rejection. Previous versions of DrizzleIntegration made small pixel rejection mistakes sometimes. This has been fixed.

* DrizzleIntegration fully supports local distortion models generated by StarAlignment, which are now stored in .xdrz files. A new enable local distortion parameter has been added to provide control over this feature.

* Improved preservation of existing metadata, with the same functionality implemented in ImageIntegration.


PhotometricColorCalibration: New Narrowband Working Mode


The PhotometricColorCalibration tool implements a new narrowband working mode, along with the broadband mode already available in previous versions. For clarification, let's describe both modes and its associated working parameters:

* Broadband working mode: PCC calibrates the color of a picture acquired with broadband RGB filters. In this mode, the color calibration process equalizes the emissions of the specified white reference in the RGB filters. This means that, after performing the color calibration, the entire light coming from the white reference would have a proportion of 1:1:1. We base the color calibration on the photometry of the stars detected in the image. This photometry indicates the RGB weights needed to neutralize a white reference model, so we actually don't need an instance of the white reference inside the image.

* Narrowband working mode: Calibrate the color of a picture acquired with narrowband filters. Each color channel of the image should contain a single-waveband filter. This function equalizes the photons of the nebular emission lines in the different filters. As a result, the proportion of the emission line strengths, as emitted by the object, is preserved in the image. The wavelength and bandwidth of each narrowband filter should be specified, and to this purpose PCC has a new set of six parameters to define these values for the filters used in the red, green and blue channels of the target image. The default parameter values correspond to the frequently-used HOO combination (H-alpha for red and O-III for green and blue).

Both working modes implement algorithms designed by PTeam member Vicent Peris.


ImageSolver Script: New Advanced Alignment Mode


PixInsight 1.8.7 includes the latest version 5.4.1 of the ImageSolver script, written by PTeam member Andrés del Pozo. This version implements a new algorithm to model field distortions more accurately, especially on wide field images. Basically, when this special mode is enabled the solver evaluates field distortions separately on nine image regions distributed on a regular 3x3 grid. This generates more accurate distortion models, especially for strongly distorted images acquired with consumer short focal length lenses. Along with this improvement, ImageSolver includes small changes necessary to adapt the script to the new features implemented in the StarAlignment tool.


PixelMath: New rndselect Function

The rndselect function is formally described as:

rndselect( a, b[, ...] )

This function evaluates to a randomly selected value among the set of arguments {a, b, ...}. This function is fantastic to combine images without visible texture differences. For example, to combine two separate mosaic frames A and B, you can use the following expression:

iif( A && B, rndselect( A, B ), A + B )

This function has been borrowed from the new MosaicGenerator tool, where I am implementing a randomized multiscale sub-band blending algorithm.


Updated Databases and Third-Party Support Libraries

PixInsight 1.8.7 includes the following updates to critical data sources and support libraries:

* The RAW format support module integrates the latest LibRaw-201903 snapshot version.

* Integration of gnuplot version 5.2.7

* Core application built with the latest Qt version 5.12.5.

* Delta T database updated with the latest data available from IERS Rapid Service/Prediction Center online files, as of 2019 September 29. Delta T is the difference in seconds between the TT (Terrestrial Time) and UT1 timescales for a given date. It is an essential observational quantity for ephemeris calculations and reduction of astronomical positions.

* CIP-ITRS database updated with the latest data available from IERS Rapid Service/Prediction Center online files, as of 2019 September 29. This database provides the coordinates of the Celestial Intermediate Pole (CIP) referred to the International Terrestrial Reference System (ITRS). These coordinates are necessary to account for polar motion in calculation of topocentric coordinates of solar system objects.


Bug Fixes

PixInsight 1.8.7 fixes all confirmed bugs detected since the last 1.8.6 release, with a unique exception: a complex bug involving the PixelMath and Statistics tools, which still is present in this version. I'll try to fix this problem as soon as possible with an update to the core application.


Known Problems

FreeBSD

* Recent versions of the KDE Plasma desktop environment include a morphing popups desktop effect that causes problems with PixInsight 1.8.6 and 1.8.7. If this effect is enabled, it slows down some dragging operations in the PixInsight core application, such as dragging icons and view selectors. You should disable this effect, which is very easy from KDE's System Settings panel. This problem is also present on Linux.

Linux

* PixInsight is not compatible with the open-source Nouveau graphics driver. If your distribution is using Nouveau, you must remove and replace it with the proprietary Nvidia driver in order to use PixInsight.

* The same problem with KDE's morphing popups desktop effect exists on FreeBSD and Linux (see above).

macOS

* On Apple laptops with dual graphics cards, the integrated Intel graphics driver causes problems with PixInsight 1.8.6 and 1.8.7. If you use one of these laptops, we recommend you disable the Automatic graphics switching option on System Preferences (Energy Saver section) before running the PixInsight core application. Otherwise you may experience some interface usability problems.

Windows

* There are problems with Intel graphics drivers on machines where the only graphics card available is an integrated Intel HD graphics GPU. This mainly affects laptops. This does not mean that PixInsight cannot work on these machines, just that you can expect screen rendering and usability issues. Unfortunately, there is nothing I can do to solve these problems, for now.

* On some laptops with nonstandard screen resolutions, such as the Microsoft Surface, PixInsight cannot find valid screen scaling factors automatically. On these machines, you may have to run the PixInsight core application with the --ui-scaling command line argument. For example, to apply a UI scaling factor of 2:

C:\Program Files\PixInsight\bin\PixInsight.exe --ui-scaling=2

You only have to do this once, since the scaling factor will be stored in application preferences automatically. Of course, if you already are using version 1.8.6 and the interface looks correct, then you don't need to do this; this is only required for new installations.

* The Export as PDF feature of the integrated web browser component does not work on Windows. I'll try to fix this in a future release.


Recommended Platforms and Supported Operating Systems

The reference implementations of PixInsight 1.8.7, where you may expect the maximum performance and best user experience, are the FreeBSD and Linux versions. Currently our primary development platforms are:

- Kubuntu Linux 18.04 LTS
- FreeBSD 12.0

On FreeBSD and Linux we strongly recommend running PixInsight on the KDE Plasma desktop environment. PixInsight 1.8.7 has been tested on the following Linux distributions:

Kubuntu 18.04 LTS
Kubuntu 19.04
Fedora 29
Fedora 30
Linux Mint 19.1

PixInsight 1.8.7 for Linux requires GLIBC 2.27 or a newer version.

PixInsight 1.8.7 for macOS is only compatible with macOS 10.12, 10.13 and 10.14. Older versions are not supported. The next macOS 10.15 should be supported without problems, although this has not been tested yet. Our installation packages have been notarized by Apple.

PixInsight 1.8.7 for Windows is compatible with Windows 10 exclusively. Windows 8.1, Windows 7 and older versions are not supported. The application may run well on Windows 7, but there is no guarantee.


Hardware Requirements: Breaking Changes

The FreeBSD, Linux and macOS versions of PixInsight 1.8.7 require a processor with SSE4.2 instruction support.


Short-Term Development Lines

During the next months we plan on releasing the following new products on the current PixInsight 1.8 platform:

* MosaicGenerator. An astrometry based automatic mosaic construction tool.

* DynamicBackground. An improved background modeling/correction tool, which will be the successor to the current DBE tool.

* A new tool (name still unknown) for astrometry based measurements, integrated with the core application.

* A new high-performance format for storage of large star databases. The Gaia DR2 catalog will be available for download as one of these databases. This will greatly improve all of our astrometry based tools, such as the ImageSolver script and the new MosaicGenerator tool, which will be able to work with local files without the limitations imposed by online services.


___________________

Thank you for your attention and continued support. Enjoy!

6
Gallery / Excellent Images
« on: 2019 August 13 03:02:49 »
Just a note to say that you are posting absolutely wonderful images to this forum board recently. I normally feel that I must not comment on gallery images, unless there are technical or software-related questions.

This time I wanted to make an exception, if only collectively: if PixInsight has been of any help to achieve the results I'm seeing here, I am very proud. Excellent work!

7
If you want to consider yourself an intermediate/advanced PixInsight user, please don't use scroll bars (on a regular basis) to navigate image windows.

There are two ways to perform a temporary switch to Pan mode:

- Press the spacebar key and hold it down, then click the primary mouse button on the image and drag.

- Click the middle mouse button on the image and drag.

Both methods are much faster and more accurate than using scroll bars, plus you can navigate in both plane directions at the same time.

In similar ways, you can:

- Use the mouse wheel to zoom in/out the image.

- Use Ctrl + mouse wheel to zoom in/out centered at the current cursor position on the image.

- Use Ctrl+spacebar to switch to Zoom In mode temporarily. In this mode you can define a rectangular area to approximate the area of the image that will be zoomed in the view.

- Use Ctrl+Alt+spacebar to switch to Zoom Out mode temporarily.

On macOS, replace Ctrl with Cmd in the above list.

So let's save those kitties, please, especially when you record a video!

8
Announcements / PixInsight 1.8.6.1473 Released
« on: 2019 May 14 14:07:34 »
Hi all,

I am glad to announce a new version of PixInsight: 1.8.6.1473 for Linux, macOS, and Windows. This is an update/bugfix release. It solves most confirmed bugs discovered since the previous 1.8.6.1457 release and provides important new features, which I'll describe succinctly in this document.


Installation

As most new versions of the PixInsight core application, this one is not available as an automatic update. You have to uninstall the previous version, be it 1.8.6 or an older one, then download and install the new version manually. Of course, if you have already activated version 1.8.6 on your computer, no additional license activation will be required.


Bug Fixes

Version 1.8.6.1473 solves the following problems detected since the initial 1.8.6 version:

All platforms: All bug fixes in the previous 1.8.6.1457 version are included.

All platforms: All bug fixes in the previous 1.8.6.1448 version are included.

All platforms: Fixed a bug where a shaded (minimized) image window was unshaded spontaneously when the active window was closed. See the original bug report.

All platforms: File items were not being sorted correctly by file name in multiplatform file dialogs (non-native dialogs). This has been fixed. See the original bug report.

All platforms: FITS files with EXTNAME keywords in the first HDU were causing a crash upon file opening. This is now fixed. See forum bug reports here and here.

All platforms: The CometAlignment process was generating spurious data in areas uncovered by geometric transformations during alignment. This is now fixed thanks to a contribution by Franchesco Meschia.

All platforms: Fixed incorrectly elided text in the first column of a file list when more than 1000 files are included. This problem was affecting tools such as ImageCalibration, ImageIntegration, StarAlignment, SubframeSelector, etc., that is, all interfaces with files lists.

All platforms: Fixed a weird interaction between the Real-Time Preview window and the SampleFormatConversion process when a preview of the target image was selected on the R-T window. See the original bug report by Enzo de Bernardini.

All platforms: The ImageIntegration tool was not generating valid XPIXSZ, YPIXSZ, XBINNING and YBINNING FITS keywords in integrated images. These keywords are now generated correctly if the corresponding values are consistent for the entire set of input images.

All platforms: Fixed wrongly scaled icons on high-dpi screens in some dialogs of the update system.

Windows: The '--opengl=raster' command-line argument was not working correctly, potentially leading to crash upon startup. This is now fixed.


New Features

New version 5.3 of the ImageSolver script. This version implements a new local distortion modeling algorithm based on thin plate splines and shape-preserving surface simplifiers. This algorithm provides unprecedented accuracy in our astrometric solutions. I have written a dedicated tutorial which describes and tests the implemented algorithm with examples, usage recommendations, and a formal description.

New version 2.0 of the AnnotateImage script. The new version implements automatic annotation of planets and asteroids, with the implementation of state-of-the-art solar system ephemerides and position reduction algorithms. The new tutorial on ImageSolver includes some nice and interesting examples.

Fully functional Chromium-based web browser component, with multiple browser windows and file downloading support. There is a new Window > Web Browser Windows main menu item to control creation and selection of new web browser instances. There is also a new View > Downloads main menu item where you can control the list of downloaded files, which is persistent across core application executions.

PixInsight will now use the dedicated graphics card instead of the integrated card on machines with dual graphics on Windows (Nvidia Optimus or AMD Enduro). This should fix most graphics instability problems reported on these machines, mostly laptops, caused by incompatibilities with integrated Intel HD graphics drivers. Note that this won't work if you have created a profile for the application to use the integrated chipset.

New core JavaScript objects for data modeling and representation: GridInterpolation, PointGridInterpolation, ShepardInterpolation, SurfaceSimplifier. These objects are the JavaScript counterparts of their corresponding native PCL/C++ implementations.

Improved core JavaScript objects: New methods ImageWindow.celestialToImage(), ImageWindow.imageToCelestial(), ImageWindow.copyAstrometricSolution() and ImageWindow.astrometricSolutionSummary(). The SurfaceSpline.evaluate( Array ) method is now fully parallelized.

Support for the nonstandard FITS keywords BAYERPAT, XBAYROFF and YBAYROFF in the Debayer tool, for automatic Bayer pattern detection in FITS files.

ImageIntegration generates metadata for geodetic observer coordinates and acquisition time with LONG-OBS, LAT-OBS, ALT-OBS and DATE-OBS FITS keywords generated by averaging the corresponding keyword values found in the input data set. This facilitates astrometric solution of integrated images.

The Resources main menu is now dynamic and configurable. It is populated automatically upon startup with items read from the 'PixInsight/etc/startup/resources.xmnu' distribution file. Online resources are now opened on new integrated browser windows by default.

Source code syntax highlighting rules are now dynamic and configurable. Reserved words for different languages are now loaded from plain text files included in the 'PixInsight/rsc/shglt' distribution folder.

New command-line arguments. These new arguments control some advanced functions of the integrated web browser component. Excerpted from the command line help text:

         --accelerated-2d-canvas
         --no-accelerated-2d-canvas

               Enables and disables, respectively, the use of OpenGL framebuffers for
               HTML5 2D canvas in the integrated Chromium browser component. Implicitly
               forced to disabled state when --opengl=raster or --opengl=software are
               specified. Enabled by default otherwise.

         --webgl
         --no-webgl

               Enables and disables, respectively, support for HTML 5 WebGL in the
               integrated Chromium browser component. Implicitly forced to disabled
               state when --opengl=raster or --opengl=software are specified. Enabled
               by default otherwise.


New Preferences > Directories and Network > Proxy URL preferences setting. This is the proxy host that will be used for core network operations, with optional user authentication. This option only applies to core network operations, such as files downloaded with the File > Open Location menu command, the open terminal command, and the update system, among others. It does not apply to the integrated web browser component.

New Preferences > Main Window / Startup > Private web browsing mode preferences setting. Enable this option to keep normally persistent data in volatile memory when using the integrated web browser component, leaving no trace on disk. This includes cookies, the HTTP cache (documents, images, etc), and the browsing history.

Delta T database updated with the latest data available from IERS Rapid Service/Prediction Center online files, as of 2019 April 29. Delta T is the difference in seconds between the TT (Terrestrial Time) and UT1 timescales for a given date. It is an essential observational quantity for ephemeris calculations and reduction of astronomical positions.

CIP-ITRS database updated with the latest data available from IERS Rapid Service/Prediction Center online files, as of 2019 April 29. This database provides the coordinates of the Celestial Intermediate Pole (CIP) referred to the International Terrestrial Reference System (ITRS). These coordinates are necessary to account for polar motion in calculation of topocentric coordinates of solar system objects.


Breaking Changes

The macOS version of PixInsight requires now macOS 10.12 Sierra or later. OS X 10.11 El Capitan is no longer supported.

A new File > Quit (Ctrl+Q) main menu item replaces File > Exit (Ctrl+X) on Linux and Windows. This will prevent some issues with the Ctrl+X keyboard accelerator, which is the standard key combination for the 'Cut' command used in several components, such as Script Editor. In addition, the new File > Quit command on Linux and Windows is consistent with the macOS version of PixInsight.


Known Problems

All platforms. There is a confirmed complex bug involving the PixelMath and Statistics tools that I have not fixed yet. This problem has implications at a structural level within the PixInsight core application, which I need to study in detail. I'll try to solve this bug as soon as possible, but be aware that it is still present in this new version.

Windows. The Export as PDF feature of the integrated web browser component does not work on Windows. I'll try to fix this in a future release.

Windows. On machines where the only graphics card available is an integrated Intel HD graphics GPU, you may experience screen rendering problems and some instabilities on Windows. Unfortunately, the OpenGL implementation provided by some Intel HD graphics drivers on Windows is not fully compatible with PixInsight.

macOS. The macOS 10.14.4 update has changed 'something' in its OpenGL implementation that causes problems with Qt-based applications, such as PixInsight. The issues can be annoying but mostly not very important, including some problems while dragging items (such as clicking on a view selector and dragging) and unresponsive file items on the File Explorer window. Hopefully the just-released 10.14.5 update should fix these problems.

___________________

Thank you for your support and attention. Enjoy!

9
Hi all,

We are currently implementing new features in our plate solving and annotation scripts, and lack the necessary real-world data to test them thoroughly. We'd appreciate if you could provide us with images suitable for testing these features. We need images that comply with the following requisites:

- Required: Acquisition time metadata. We need to know the date the image was acquired, accurate to within one minute if possible in the case of inner planets (see below), or to within one hour or so for the rest of objects. For example, if your image has been acquired in FITS format and has a valid DATE-OBS header keyword generated by your acquisition software, that would be ideal.

- Required: Images with planets and/or asteroids. The new features that we are testing involve calculation of high-accuracy solar system ephemerides, which we must test against real data. We need images with:

- One or more of: Mercury, Venus, Mars, Jupiter, Saturn, Uranus, Neptune, and Pluto.

- One or more of the 343 most massive asteroids included in DE430's numerical integration—see the list attached to this post as a plain text file, which you can open in PixInsight's Script Editor. For example, if you have images covering relatively large areas of the Ecliptic, the probability that you have recorded one of these asteroids is high. In such case, even if you don't know whether you have one of these asteroids in the image or not, you can send it to us if it complies with the rest of requirements.

- Geodetic coordinates of the observer. It would be great if you could provide at least the approximate longitude and latitude (also height if possible) of the location where the image was acquired.

- Linear images. To perform the accurate plate solving and measurement tasks that we need to test the new features, we need unstretched (linear) images. We cannot perform valid PSF measurements on stretched images.

Thank you so much in advance!

11
Announcements / Open-Source Repositories Moved to GitLab
« on: 2019 February 20 04:26:02 »
Hi all,

Today we have moved our open-source Git repositories to GitLab:


The old GitHub repositories will still be available for a limited time, but no pull requests will be accepted from GitHub anymore. The migration to GitLab was planned since October 2018, but postponed until completing the PixInsight 1.8.6 release.

If you are one of our collaborators, or if you want to collaborate with us from now on, please create a GitLab account (it's free) if you don't already have one, then join us by letting me know your GitLab user name.

If you have contributed code to PixInsight, better use the same user name as on GitHub, so your commits can be associated with your new GitLab account. If you were following some of our repositories on GitHub, please follow them also on GitLab.

Thank you for your attention.

12
Announcements / Avast and AVG antivirus false positives
« on: 2019 January 27 12:44:28 »
We have recent reports that Windows users trying to install the latest version 1.8.6.1457 of PixInsight receive virus detection alerts with the Avast and AVG antivirus applications.

We run enterprise level virus protection solutions on all of our development and testing Windows machines. Currently we use McAfee Internet Security and McAfee LiveSafe. In addition, all of our installer packages, as well as all executable and .dll files included in these packages, are digitally signed with our Extended Validation (EV) code signing certificate. Changing any of these files in any way should of course invalidate the signatures.

So the chances are extremely low of a virus infecting our installer packages. For that to have happened, there would have to be a virus present on your system when you were downloading our installer, so that the virus could infect our files. You can always check if an installer package is valid by comparing the SHA-1 checksum computed for your downloaded file with the checksum published on our Software Distribution system. For your convenience, the SHA-1 checksums for the current 1.8.6.1457 packages are the following:

PI-windows-x64-01.08.06.1457-20190122-t.exe     5e445749306bafe717ca667b2c8dbcbfd83c3e8c
PI-windows-x64-01.08.06.1457-20190122-c.exe     4f6b780c05daea7c046c56106ea097bbe285c3dd
PI-macosx-x64-01.08.06.1457-20190122-t.pkg      1fbe90db4fbe9f2ea77c2c33cdcf846064659077
PI-macosx-x64-01.08.06.1457-20190122-c.pkg      754c7904bc4090030d8ad2aedcbee2475f341ca4
PI-linux-x64-01.08.06.1457-20190122-t.tar.gz    427533fab7c955c89f9139c25dfd06372ac14e1f
PI-linux-x64-01.08.06.1457-20190122-c.tar.gz    2c0620c00a8dae84f791424a8a3ac951ecb4818d


So these are just false positives. I encourage you to check the installer packages with a more reliable virus protection software.

13
Along with integrated solar system ephemerides, the PixInsight 1.8.6 platform includes new functionalities for the reduction of positions of solar system bodies and stars. In this document I am going to describe the JavaScript implementation at a basic level, sufficient for the practical calculation of astrometric, proper and apparent positions, among others. These reduced positions can be used for a variety of powerful applications, such as high-precision astrometry, drawing annotations on plate solved images, solar system simulations, and generation of high-level ephemerides such as occultations of stars by asteroids and the Moon, just to name a few.

The JavaScript implementation, available through the PJSR runtime in the PixInsight core application, uses the PCL/C++ implementation as its back end. For information on the entire functionality available with detailed descriptions of the implemented algorithms, see the corresponding sections of the official PCL documentation:

C++ documentation for the integrated solar system ephemerides system.

C++ documentation for the Position class.



StarPosition

This object is a simple structure to define positional data of a star. Positions and proper motions must be referred to ICRS/J2000.0. If out-of-range coordinates are specified, their values will be constrained to their proper ranges: right ascension to [0°,360°) and declination to [-90°,+90°].

   Number StarPosition.alpha

ICRS right ascension in degrees. Zero if not specified.

   Number StarPosition.delta

ICRS declination in degrees. Zero if not specified.

   Date StarPosition.epoch

Epoch of catalog coordinates. The fundamental J2000.0 epoch will be assumed if not specified.

   Number StarPosition.muAlpha

Proper motion in right ascension, in milliarcseconds per year, multiplied by the cosine of the declination. Zero if not specified.

   Number StarPosition.muDelta

Proper motion in declination, in mas/year. Zero if not specified.

   Number StarPosition.parallax

Parallax in arcseconds. Zero if not specified.

   Number StarPosition.radialVelocity

Radial velocity in km/s, positive away from Earth. Zero if not specified.



ObserverPosition

Geodetic coordinates of a terrestrial observer.

This structure provides the data necessary to calculate topocentric places of solar system bodies and stars. Typically, the values used should be WGS84 coordinates (for example, as distributed by GPS) or ITRF coordinates—both systems close together at the level of a few centimeters.

Geographic longitudes grow eastward, so longitudes are positive to the east and negative to the west of the central meridian. For ease of calculation, the ObserverPosition.longitude property converts assigned longitudes to the [0°,360°) range.

If out-of-range coordinates are specified, their values will be constrained to their proper ranges: longitude to [0°,360°), and latitude to [-90°,+90°].

   Boolean ObserverPosition.cioBased

Whether to compute CIO-based positions (if true) or equinox-based positions (if false). False by default, that is, equinox-based topocentric coordinates are computed by default.

   Number ObserverPosition.equatorialRadius

Equatorial radius of the reference spheroid in meters. By default this property is the IAU 2009/2012 equatorial radius of Earth: 6,378,136.6 m.

   Number ObserverPosition.flattening

Flattening of the reference spheroid. The default value is the IERS 2010 flattening of Earth: 1/298.25642.

   Number ObserverPosition.height

Geodetic height in meters. Zero by default.

   Number ObserverPosition.latitude

Geodetic latitude in degrees. Zero if not specified.

   Number ObserverPosition.longitude

Geodetic longitude in degrees. Zero if not specified.

   Vector ObserverPosition.regionalCenter

Geocentric rectangular coordinates of the center of the regional spheroid, in meters. A zero 3-D vector (that is, the geocenter) by default.



Position

This object implements algorithms for reduction of positions of solar system bodies and stars. It allows for calculation of geometric, astrometric, proper, apparent and intermediate places, including geocentric and topocentric coordinates.

The implemented vector astrometry and ephemeris calculation algorithms are rigorous and compliant with current IAU and IERS resolutions. Both equinox-based and CIO-based paradigms have been implemented for calculation of positions that depend on Earth's rotation. The apparent and intermediate places include the following corrections:

  • Light-travel time for solar system bodies.
  • Space motion for stars, including parallax, radial velocity and proper motions, with corrections for the relativistic Doppler effect that takes into account the change in light-travel time for stars.
  • Relativistic deflection of light due to solar gravitation.
  • Aberration of light, relativistic model.
  • Frame bias, precession and nutation. (equinox-based and CIO-based).
  • Accurate topocentric places with polar motion corrections.

Vector components are expressed in astronomical units (au) for stars and all solar system bodies except the Moon, for which positions are given in kilometers.

As of writing this document (January 2019), the IAU 2006/2000A precession-nutation theory is implemented (adjusted model with corrections to nutation angles, IAU 2006/2000AR). The standard fundamental ephemerides are JPL's DE438/LE438.

Constructor

   new Position( Date t[, String timescale="TT"] )
   new Position( String isoTime[, String timescale="TT"] )
   new Position( Number jd1[, Number jd2=0[, String timescale="TT"]] )


Constructs a new object for reduction of positions at the specified time point, which can be provided as a Date object, as an ISO 8601 date/time string, or as a Julian date with one or two components, JD=jd1+jd2. The timescale argument can be one of the following:

TTTerrestrial Time. This is the default timescale.
TDBBarycentric Dynamical Time.
TephEphemeris time, as defined by JPL DE/LE numerical integrations. For all purposes, this is equivalent to TDB.
UTCCoordinated Universal Time.
TAIAtomic International Time.
UT1Universal Time.
UTUniversal Time (same as UT1).

Properties

   ObserverPosition Position.observer

This property defines the geodetic positional and reference data necessary for calculation of topocentric positions of solar system objects and stars.

By default, an instance of the Position object calculates geocentric coordinates. After assigning a value to this property, subsequently calculated geometric, proper, astrometric, apparent and intermediate places will be topocentric, that is, will be referred to the location of the observer with respect to the center of the Earth.

By assigning a value to this property, all previously computed positional data will be erased with the exception of fundamental ephemerides and existing bias-precession-nutation matrices, which can always be preserved.

The ObserverPosition.cioBased property of the assigned object selects the celestial system and paradigm to be used in the calculation of positions that depend on Earth's rotation. If the cioBased property is true, equinox-based places cannot be calculated, and any of the apparent() methods will throw an exception if called. Conversely, if cioBased is false, CIO-based places cannot be calculated and no call to an intermediate() method will be allowed.

If polar motion corrections are enabled, the position of the Celestial Intermediate Pole (CIP) with respect to the ITRS is interpolated from the global CIP_ITRS database, if it provides data for the current time of calculation. In such case, polar motion is taken into account in the calculation of the observer's geocentric position and velocity. For the geocentric velocity a standard constant value for the rotation rate of the Earth is used; the velocity component due to precession and nutation is not taken into account since its effect is negligible. See the polarMotionEnabled property for more information and additional references.

   Boolean Position.polarMotionEnabled

This property is true if topocentric places take into account polar motion corrections to compute the geocentric position and velocity of the observer. This involves calculation of CIP (Celestial Intermediate Pole) coordinates with respect to the ITRS, as well as access to a database of CIP/ITRS positions, which is part of the official PixInsight distribution and is updated regularly as new observational data become available.

Polar motion introduces changes at the mas level for calculation of topocentric coordinates of the Moon. For the rest of objects, the effect of polar motion corrections is completely negligible. For topocentric positions of the Moon, polar motion can be necessary to achieve the highest accuracy, but in such case one may also have to take into account a regional geoid referred to the Earth's reference ellipsoid. See the ObserverPosition object.

   Number Position.epsA

Mean obliquity of the ecliptic, in radians.

Methods

   Vector Position.apparent( EphemerisHandle H )

Computes the apparent place of a solar system body. The returned vector is the apparent place of the object defined by the specified ephemeris handle H in geocentric or topocentric rectangular equatorial coordinates, calculated for the instant defined by this object in the TT timescale. The implemented reduction algorithm includes the following corrections:

  • Light-travel time.
  • Relativistic deflection of light due to solar gravitation (except for the Sun, the Moon, and any object closer from Earth than the Sun at the time of observation.
  • Aberration of light, including relativistic terms.
  • Frame bias, precession and nutation. The origin of right ascension is the true equinox of date.

   Vector Position.apparent( StarPosition S )

Computes the apparent place of a star. The returned vector is the apparent place calculated for the positional star data defined by the specified object S. Its components are geocentric or topocentric rectangular equatorial coordinates, calculated for the instant defined by this object in the TT timescale. The implemented reduction algorithm includes the following corrections:

  • Space motion, including parallax, radial velocity and proper motions, with corrections for the relativistic Doppler effect.
  • Relativistic deflection of light due to solar gravitation.
  • Aberration of light, including relativistic terms.
  • Frame bias, precession and nutation. The origin of right ascension is the true equinox of date.

   Number|null Position.apparentVisualMagnitude( EphemerisHandle H )

Returns the observed visual magnitude of a solar system body.

For objects with known H and G values (absolute magnitude and slope parameters, respectively; see EphemerisHandle.H and EphemerisHandle.G), the apparent visual magnitude is calculated applying the algorithm for minor planets described in Bowell et al. (1989). See also The Explanatory Supplement, Section 10.4.3.

For Mercury, Venus, Mars, Jupiter, Saturn and Neptune, we apply the equations described in the following paper:


For Saturn, we compute the apparent visual magnitude taking into account the planet's rings.

For Uranus, Pluto and the Galilean satellites of Jupiter, data from various sources are taken from Table 10.6 of the Explanatory Supplement.

If the required data are not available, or if no algorithm is known for the calculation of the apparent visual magnitude of the specified object, this method returns null.

A null value is also returned when the phase angle of the object at the time of calculation is beyond the limits of the set of observations used to generate the underlying models. For Mercury, apparent magnitudes are only calculated for phase angles 2° ? i ? 170°. For Venus, the magnitude is only calculated for 0° < i ? 163°.7. The valid range for Mars is i ? 50°.

See also Position.canComputeApparentVisualMagnitude()

   Vector Position.astrometric( EphemerisHandle H )

Computes the astrometric place of a solar system body. The returned vector is the astrometric place of the object defined by the specified ephemeris handle H in geocentric or topocentric rectangular equatorial coordinates, calculated for the instant defined by this object in the TT timescale. The implemented reduction algorithm includes the following corrections:

  • Light-travel time.
  • Relativistic deflection of light due to solar gravitation (except for the Sun, the Moon, and any object closer from Earth than the Sun at the time of observation).

An astrometric place does not include annual aberration, nutation and precession corrections. Hence it is referred to an 'hybrid' reference system, but similar to GCRS J2000.0.

   Vector Position.astrometric( StarPosition S )

Computes the astrometric place of a star. The returned vector is the astrometric place calculated for the positional star data defined by the specified object S. Its components are geocentric or topocentric rectangular equatorial coordinates, calculated for the instant defined by this object in the TT timescale. The implemented reduction algorithm includes the following corrections:

  • Space motion, including parallax, radial velocity and proper motions, with corrections for the relativistic Doppler effect.
  • Relativistic deflection of light due to solar gravitation.

An astrometric place does not include annual aberration, nutation and precession corrections. Hence it is referred to an 'hybrid' reference system, but similar to GCRS J2000.0.

   Boolean Position.canComputeApparentVisualMagnitude( EphemerisHandle H )

Returns true only if the apparent visual magnitude of the object represented by the specified handle H can be calculated with the current implementation, at the calculation time defined by this Position object.

Currently apparent visual magnitudes can be calculated for the following solar system bodies:

  • Objects providing valid H and G parameters (absolute magnitude and slope coefficient). This is true for most asteroids included in standard XEPH files.
  • Mercury, Venus, Mars, Jupiter, Saturn, Uranus, Neptune and Pluto.
  • The four Galilean satellites of Jupiter: Io, Europa, Ganymede and Callisto.

   Vector Position.geometric( EphemerisHandle H )

Computes the geometric position of a solar system body. The components of the returned vector are the geocentric or topocentric rectangular equatorial coordinates for the instant of calculation defined by this object in the TT timescale, accounting for light-travel time, for the body defined by the specified ephemeris handle H.

The implemented reduction algorithm includes just the correction for light-travel time, but no corrections for light deflection, annual aberration, nutation, or precession. The position so calculated allows to plot the specified body directly on an existing sky chart referred to GCRS/J2000.0. Note however, that for generation of new graphical representations for a given date using star catalog data, astrometric or proper places should be used instead.

   Vector Position.geometric( StarPosition S )

Computes the geometric position of a star. The components of the returned vector are the geocentric or topocentric rectangular equatorial coordinates for the instant of calculation defined by this object in the TT timescale, for the positional star data defined by the specified object S.

The implemented reduction algorithm includes just the corrections for space motion: parallax, radial velocity and proper motions, when the corresponding data items are nonzero in the specified object S. The space motion vector includes terms to account for the relativistic Doppler effect.

   void Position.initCIOBasedParameters()

Calculates all parameters and data structures necessary for CIO-based reduction of positions. This method starts by calling initEquinoxBasedParameters(), so it implicitly calculates all equinox-based parameters. Then it calculates the CIO-based combined bias-precession-nutation matrix.

Since all of these items depend exclusively on time, they are computed only once in the first call to this function, and subsequent calls will have no effect.

Normally, you don't have to call this function directly because it is invoked automatically when necessary by the different position reduction routines.

   void Position.initEquinoxBasedParameters()

Calculates all parameters and data structures necessary for equinox-based reduction of positions. This method calculates the following structures:

  • Precession+bias angles, IAU 2006 precession model, Fukushima-Williams parameterization.
  • Mean obliquity of the ecliptic, IAU 2006 precession model.
  • Nutation angles, IAU 2006/2000AR nutation model.
  • Combined bias-precession-nutation matrix, equinox-based.
  • Position of the Celestial Intermediate Pole (CIP).
  • Celestial Intermediate Origin (CIO) locator.
  • Equation of the origins (EO).
  • Earth rotation angle (ERA) for the UT1 time of calculation.
  • Greenwich Apparent Sidereal Time (GAST), IAU 2006.

Since all of these items depend exclusively on time, they are computed only once in the first call to this function, and subsequent calls will have no effect.

Normally, you don't have to call this function directly because it is invoked automatically when necessary by the different position reduction routines.

   Vector Position.intermediate( EphemerisHandle H )

Computes the intermediate place of a solar system body. The returned vector is the intermediate place of the object defined by the specified ephemeris handle H in geocentric or topocentric rectangular equatorial coordinates, calculated for the instant defined by this object in the TT timescale. The implemented reduction algorithm includes the following corrections:

  • Light-travel time.
  • Relativistic deflection of light due to solar gravitation (except for the Sun, the Moon, and any object closer from Earth than the Sun at the time of observation.
  • Aberration of light, including relativistic terms.
  • Frame bias, precession and nutation. The origin of right ascension is the Celestial Intermediate Origin (CIO), following the IAU recommendations since January 2003.

   Vector Position.intermediate( StarPosition S )

Computes the intermediate place of a star. The returned vector is the intermediate place calculated for the positional star data defined by the specified object S. Its components are geocentric or topocentric rectangular equatorial coordinates, calculated for the instant defined by this object in the TT timescale.  The implemented reduction algorithm includes the following corrections:

  • Space motion, including parallax, radial velocity and proper motions, with corrections for the relativistic Doppler effect.
  • Relativistic deflection of light due to solar gravitation.
  • Aberration of light, including relativistic terms.
  • Frame bias, precession and nutation. The origin of right ascension is the Celestial Intermediate Origin (CIO), following the IAU recommendations since January 2003.

   Array Position.nutationAngles()

Returns the nutation angles in radians as an Array object P, where P[0] is the nutation in longitude and P[1] is the nutation in obliquity. This method calls initEquinoxBasedParameters() to ensure that all data required for equinox-based reduction of positions is available.

   Vector Position.proper( EphemerisHandle H )

Computes the proper place of a solar system body. The returned vector is the proper place of the object defined by the specified ephemeris handle H in geocentric or topocentric rectangular equatorial coordinates, calculated for the instant defined by this object in the TT timescale. The implemented reduction algorithm includes the following corrections:

  • Light-travel time.
  • Relativistic deflection of light due to solar gravitation (except for the Sun, the Moon, and any object closer from Earth than the Sun at the time of observation.
  • Aberration of light, including relativistic terms.

A proper place does not include nutation and precession corrections, hence it is referred to the reference coordinate system: GCRS J2000.0.

   Vector Position.proper( StarPosition S )

Computes the proper place of a star. The returned vector is the proper place calculated for the positional star data defined by the specified object S. Its components are geocentric or topocentric rectangular equatorial coordinates, calculated for the instant defined by this object in the TT timescale. The implemented reduction algorithm includes the following corrections:

  • Space motion, including parallax, radial velocity and proper motions, with corrections for the relativistic Doppler effect.
  • Relativistic deflection of light due to solar gravitation.
  • Aberration of light, including relativistic terms.

A proper place does not include nutation and precession corrections, hence it is referred to the reference coordinate system: GCRS J2000.0.

   Vector Position.true( EphemerisHandle H )

Computes the true position of a solar system body. The components of the returned vector are the geocentric or topocentric rectangular equatorial coordinates for the calculation instant defined by this object in the TT timescale, without accounting for light-travel time, for the body defined by the specified ephemeris handle H.

This function calls Position.geometric( EphemerisHandle ) internally to compute, if necessary, the geometric position with correction for light time, that is, no separate calculation routine is implemented for true positions. The returned vector is only useful to compute the true geocentric or topocentric distance, and for verification purposes.

   Vector Position.true( StarPosition S )

Computes the geometric position of a star. This function has been implemented for completeness. It is a synonym for Position.geometric( StarPosition ). There are no known 'true' positions of stars, since their light-travel time is implicitly included in the space motion equations.

   Number Position.trueDistance( EphemerisHandle H )

Computes the true distance of a solar system body. The true distance is the actual distance from the body to the observer, geocentric or topocentric, at the instant of calculation. This excludes the light-travel time correction.

   Number Position.trueDistance( StarPosition S )

Computes the true distance of a star. The returned value is just the norm of the geometric position vector, that is:

   Position.geometric( S ).l2norm()

This should be an actual distance in au only for stars with known parallaxes. For stars where the parallax is unknown or undefined, this value is meaningless because in such cases position vectors are unit vectors, whose components are also known as direction cosines.

Static Methods

   Vector Position.equatorialToEcliptic( Vector r, Number eps )

Conversion from rectangular equatorial to rectangular ecliptic coordinates. r is a vector of rectangular equatorial coordinates. eps is the oliquity of the ecliptic in radians.

Returns a vector whose components are the rectangular ecliptic coordinates corresponding to the specified equatorial position r at the epoch where the specified obliquity has been calculated.

   Vector Position.equatorialToEcliptic( Vector r, Number se, Number ce )

This method is identical to the previous one, namely Position.equatorialToEcliptic( Vector, Number ), but the obliquity of the ecliptic is specified by its sine se and cosine ce.

   Vector Position.icrsEquatorialToGalactic( Vector r )

Conversion from ICRS rectangular equatorial to rectangular galactic coordinates. r is a vector of rectangular equatorial coordinates in the ICRS. Returns a vector whose components are the calculated rectangular galactic coordinates.

In this routine we adopt the proposed ICRS coordinates of the galactic pole in:

  • Jia-Cheng Liu, Zi Zhu, and Hong Zhang, Reconsidering the galactic coordinate system, Astronomy & Astrophysics manuscript no. AA2010, October 26, 2018.

The applied conventional definitions are as follows. The ICRS equatorial coordinates of the zero point of galactic coordinates are:

alpha = 17h45m40s.0400
delta = –29°00'28".138

The equatorial coordinates of the galactic pole, coherent with the ICRS, are:

alphap = 12h51m36s.7151981
deltap = +27°06'11".193172

Note that these definitions are not consistent with the conventional values currently accepted by the IAU. The current (as of October 2018) galactic coordinate system was defined by the IAU in 1959 in the FK4 B1950.0 reference system.

14
One of the most important new features in PixInsight 1.8.6 is the integration of a standardized system for calculation of ephemerides of solar system bodies. In this document I am going to describe the fundamentals of this implementation and how it can be exploited from the core JavaScript engine (PJSR) at a basic level. The C++ implementation, which is now part of the PixInsight Class Library (PCL), is very similar—is it actually the back end of the JavaScript implementation—and is already described in the official PCL documentation.

The PJSR front end of the integrated ephemerides system consists of a set of files and JavaScript objects that I'll describe briefly below.



EphemerisFile

This object provides access to ephemerides of solar system bodies stored in XEPH (Extensible Ephemeris Data format) files. On the PixInsight/PCL platform, XEPH is the standard file format for serialization and storage of ephemerides data. An XEPH file is similar to a monolithic XISF file: it consists of an XML file header document followed by a series of binary data blocks, where ephemerides data are stored as Chebyshev polynomial expansions. The XEPH header defines, along with ancillary data and properties describing the objects for which ephemerides can be calculated, a special file index for fast access to the Chebyshev coefficients required to compute ephemerides within a given time span.

XEPH files allow for calculation of rectangular coordinates (with the EphemerisHandle object, which I'll describe later) referred to the axes of the International Celestial Reference System (ICRS/J2000.0). Positions are given in au and velocities in au/day for all solar system objects, except planetocentric coordinates of natural satellites, including the geocentric Moon, for which positions and velocities are given in kilometers and km/day, respectively. Angles (nutations and librations) are given in radians, and time differences (such as TT-TDB), in seconds.

An XEPH file storing up-to-date JPL DE/LE ephemeris data is now part of all standard PixInsight distributions. As of writing this document, the standard XEPH file provides the complete JPL DE438/LE438 ephemerides.

In the following sections I'll describe just a few properties of the EphemerisFile object, which are the minimal set of elements required for a basic application. For a complete and detailed description of all properties and methods available for this object, see the corresponding documentation for the C++/PCL implementation.


Object Identifiers and Names

In an XEPH file, objects can be referenced in two ways:

  • By identifier. An object identifier is a short ASCII string, typically with three or four characters, which is treated as a case-sensitive string.

  • By name (optional, not always available). An object's name is an arbitrary Unicode string, normally the readable name of an object, treated as a case-insensitive string.
   
For example, all of 'Ju', 'Jupiter', 'jupiter' and 'JUPITER' refer to Jupiter in a standard XEPH file storing fundamental JPL DE/LE ephemerides. In this example, 'Ju' is a case-sensitive object identifier, thus 'ju' and 'JU' are not valid. 'SSB' is the special identifier reserved for the solar system barycenter.


Ephemeris Time Span

Each XEPH file provides ephemerides for a limited time span, which can be retrieved with the following properties:

   Date EphemerisFile.startTime

Starting point of the time span covered by the ephemerides file, or the earliest time point for which ephemerides can be calculated.

   Date EphemerisFile.endTime

Ending point of the time span covered by the ephemerides file, or the latest time point for which ephemerides can be calculated.


Retrieving the Set of Objects Available

To know the set of objects available in an XEPH file, one should use the following property:

   Array EphemerisFile.objects

The value of this property is an array where each element is an array A with the following elements:

A[0] : Object identifier
A[1] : Center identifier
A[2] : Object name (can be empty)

For example, one of the arrays in the value of this property for the standard fundamental ephemerides file is ["Ju","SSB","Jupiter"], which tells us that Jupiter (identifier 'Ju' and name 'Jupiter') is available for calculation of barycentric (origin='SSB') rectangular ICRS coordinates.


Standard Ephemeris Files

The following static properties of the EphemerisFile object provide access to essential XEPH files that should be available in every PixInsight 1.8.6 installation. There are more ephemeris files and databases in the integrated ephemerides system, but I'll describe here just the files necessary for practical ephemerides calculations.

   EphemerisFile EphemerisFile.fundamentalEphemerides

The global fundamental ephemerides file currently defined by the running PixInsight platform. Under normal working conditions, the returned object provides ephemeris data for at least the following objects:

IdentifierNameDescription
MeMercuryMercury's barycenter
VeVenusVenus' barycenter
EMBEarth-Moon barycenter
MaMarsMars' barycenter
JuJupiterJupiter's barycenter
SaSaturnSaturn's barycenter
UrUranusUranus' barycenter
NeNeptuneNeptune's barycenter
PlPlutoPluto's barycenter
MnMoonMoon's geometric center with respect to Earth's center.
SnSunSun's geometric center
EaEarthEarth's geometric center

With the only exception of the Moon ("Mn" identifier), ephemeris data for all of the objects above are provided relative to the solar system barycenter ("SSB" identifier). Additional items may also be available, depending on specific file versions and compilations:

IdentifierDescription
LbrLunar librations (Euler angles) in radians
NutNutation angles in radians
TT_TDBTT-TDB difference at the geocenter in seconds.

As of writing this document, the standard fundamental ephemerides file provides JPL's DE438/LE438 ephemerides, but nutations, librations and time differences are not included.

   EphemerisFile EphemerisFile.asteroidEphemerides

The global asteroid ephemerides file currently defined by the running PixInsight platform. Under normal working conditions, the returned object provides ephemeris data for a set of asteroids with relevant masses. In a standard asteroid ephemeris file, object identifiers are asteroid numbers and object names are asteroid designations; for example:

IdentifierName
1Ceres
2Pallas
3Juno
4Vesta
5Astraea
......
702Alauda
703Noemi
704Interamnia
......

Asteroid ephemeris data are provided relative to the solar system barycenter ("SSB" identifier), with position and velocity coordinates coherent with global fundamental ephemerides. As of writing this document, the standard asteroid ephemerides file provides the complete set of 343 asteroids used for the numerical integration of DE430 ephemerides, with barycentric coordinates calculated to be coherent with DE438.



EphemerisHandle

This object provides access to ephemeris data for a specific object available in an XEPH file. It can perform basic ephemeris calculations, including state vectors and its first derivatives, such as position and velocity vectors, and performs all the low-level file search, seek and read operations transparently and efficiently. This object is the JavaScript version of the C++ implementation in the pcl::EphemerisFile::Handle subclass.

Data stored in an XEPH ephemeris file generates rectangular coordinates referred to the axes of the International Celestial Reference System (ICRS/J2000.0). Positions are given in au and velocities in au/day for all solar system objects, except planetocentric coordinates of natural satellites, including the geocentric Moon, for which positions and velocities are given in kilometers and km/day, respectively. When available, angles (nutations and librations) are given in radians, and time differences (such as TT-TDB) in seconds.

For practical ephemeris calculations, the EphemerisHandle object is normally not used directly to compute celestial coordinates. The Position object, which I'll describe in a second article dedicated to reduction of astronomical positions, is much more efficient and versatile for calculation of places of solar system bodies and stars, including astrometric, proper and apparent positions, among others. The state vectors computed directly with EphemerisHandle are more appropriate for low-level applications, such as generation of ephemerides by numerical integration. These are more advanced topics that should be covered in separate documents.


Constructor

   new EphemerisHandle( EphemerisFile parent, String object, String origin )

Constructs a new EphemerisHandle object for calculation of state vectors for the specified object, with the specified origin of rectangular coordinates, with data retrieved from the specified parent ephemerides file. object and origin can be object identifiers or names, although the use of identifiers is recommended for robustness.


State Vectors

   Vector EphemerisHandle.stateVector( Date )
   Vector EphemerisHandle.stateVector( String isoTime )
   Vector EphemerisHandle.stateVector( Number jd1[, Number jd2=0] )


This method computes a state vector (typically a position vector) for the specified time point in the Barycentric Dynamical Time (TDB) timescale. The calculation time can be specified as a Date object, as an ISO 8601 date/time string representation, or as a Julian date, which can be specified as one or two components, JD=jd1+jd2 ( (specifying a JD as two components greatly improves the accuracy of time representation by increasing the effective bit length used to store time points).

The components of returned position vectors are ICRS rectangular equatorial coordinates in au, except planetocentric coordinates of natural satellites (including the geocentric Moon), for which positions are provided in km. Angles are provided in radians. TT-TDB differences are provided in seconds.

   Array EphemerisHandle.stateVectors( Date )
   Array EphemerisHandle.stateVectors( String isoTime )
   Array EphemerisHandle.stateVectors( Number jd1[, Number jd2=0] )


Computes state vectors (typically position and velocity vectors) for the specified time point in the Barycentric Dynamical Time (TDB) timescale. The calculation time can be specified as in the above stateVector() method.

The returned object is an Array with two elements, where the first element is the function value as a Vector object, and the second element is the first derivative, also as a Vector object. The components of returned position and velocity vectors are ICRS rectangular equatorial coordinates in au and au/day, respectively, except planetocentric coordinates of natural satellites (including the geocentric Moon), for which positions and velocities are provided in km and km/day, respectively. Angles and their variations are provided in radians and radians/day. TT-TDB differences and their variations are provided in seconds and seconds/day.


Asteroid Photometric and Diameter Data

   Number|null EphemerisHandle.H
   Number|null EphemerisHandle.G


These properties return the absolute magnitude and slope parameter, respectively, for the body represented by this EphemerisHandle object. These properties are only available for asteroids. If the corresponding data are unavailable in the parent ephemeris file, the value of each of these properties is null.

H is the visual magnitude of the object as seen at 1 au of the Earth, 1 au from the Sun, and with a phase angle of 0 degrees. G, the slope parameter, is used to compute phase angle corrections. For a detailed description and the algorithm for calculation of asteroid visual magnitudes, see:

  • E. Bowell et al., Asteroids II, R. P. Binzel et al. (eds.), The University of Arizona Press, Tucson, 1989, pp. 549-554.

  • Urban, Sean E., Kenneth Seidelmann, P., ed. (2013), The Explanatory Supplement to the Astronomical Almanac, 3rd Edition, Section 10.4.3.

The Position JavaScript object (which I describe in a separate document) provides implementations of the rigorous algorithms for calculation of visual magnitudes of planets and asteroids.

   Number|null EphemerisHandle.B_V

Johnson B-V color index in magnitudes. If the corresponding data are unavailable in the parent ephemeris file, the value of this property is null.

   Number|null EphemerisHandle.D

Diameter in km. When available, this is normally an IRAS asteroid diameter. If the corresponding data are unavailable in the parent ephemeris file, the value of this property is null.

15
As I described in the official announcement, PixInsight 1.8.6 ships with fully operational interprocess communication (IPC) functionality. Basically, this means that there can be several instances of the PixInsight core application running simultaneously on the same machine, and that all of them can send and receive messages and share data with each other. Although this feature may seem relatively 'simple', if you think on the kinds of things that can be done this way you'll realize that IPC extends PixInsight's flexibility, applicability and processing force enormously.

To demonstrate how IPC works in PixInsight 1.8.6, consider the following scripts:

sender.js
Code: [Select]
function main()
{
   console.abortEnabled = true;
   console.show();
   console.writeln( "<end><cbr><br>Sending messages ... " );

   for ( let count = 0; ; ++count )
   {
      processEvents();
      if ( console.abortRequested )
         break;

      if ( CoreApplication.isInstanceRunning( 2 ) )
         CoreApplication.sendMessage( 2, format( "Message %d", count ) );

      msleep( 100 );
   }

   console.writeln( "<end><cbr>end." );
}

main();


listener.js
Code: [Select]
function main()
{
   console.abortEnabled = true;
   console.show();
   console.writeln( "<end><cbr><br>Receiving messages ... " );

   let listener = new MessageListener;
   listener.onMessage = function( instance, uniqueId, message )
   {
      console.writeln( format( "<end><cbr>Received message from application instance %d with uuid = %s: %s", instance, uniqueId, message ) );
   };

   for ( ;; )
   {
      processEvents();
      if ( console.abortRequested )
         break;
      msleep( 10 );
   }

   listener.enabled = false;
   listener.onMessage = null;
   console.writeln( "<end><cbr>end." );

   console.writeln( format( "%u pending message(s).", CoreApplication.numberOfPendingMessages ) );
   CoreApplication.processPendingMessages();
}

main();

Copy and paste them in two new JavaScript documents (for example, using PixInsight's Script Editor) and save them as sender.js and listener.js, respectively. Now run a first instance of PixInsight in the usual way. Open Script Editor and load sender.js. Open the Process Console window and enter the following command to launch a second instance of PixInsight:

j CoreApplication.launchInstance( 2 )

Once launched, go to the second instance and load listener.js in Script Editor. Run it by pressing F9 (Ctrl+R on macOS). Go to the first instance and run sender.js in the same way. Go to the second instance and look at the console. As you'll see, the application instance #2 is receiving messages sent by the first instance and showing message data on the console. To stop the scripts, press Esc or click the Pause/Abort buttons. Now if you want to test IPC further, you can launch a third, fourth, ... application instance and run sender.js on each of them. Up to 255 instances of the PixInsight core application are supported.

These simple scripts let you grasp the significance of IPC in PixInsight. For example, a typical scenario could be an image acquisition procedure with asynchronous processing:

- Application instance #1 acquires a new image and writes it as a new file, then sends an IPC message to instance #2 with the corresponding file path.

- Application instance #2 receives the IPC message, loads the file, processes the image, and writes the processed image as a new file.

To sophisticate this example further, with a bit of additional work two or more application instances could be waiting for new images and processing them concurrently as soon as they are acquired. This parallel producer/consumer implementation would require just a simple protocol to differentiate busy and idle application states. Easy, clean, and extremely powerful!

The IPC functionality is available in the JavaScript runtime. As you can see in the scripts above, the key objects are CoreApplication and MessageListener. Both objects are very easy to use. Each IPC message transports a plain text payload, which can be received, along with a unique message identifier and the number of the sending instance (>= 1), in the onMessage event handler of a MessageListener (or derived from) object.

Each running application instance allocates an IPC segment, which is a block of contiguous memory dedicated to receive IPC messages. By default, IPC segments provide just 64 KiB of RAM. The maximum length of a message payload is smaller than that, about 60 KiB. This is indeed small, but ensures that we cannot have problems on machines with limited resources or custom configurations imposing strict limits to IPC resources. This default maximum message length is sufficient to send, for example, a file path, or other typical control messages. If a particular application of IPC requires more memory, the core application can be launched with two new command-line arguments:

--ipc-segment-size=<size>

      Set the size in bytes of the inter-process communication (IPC) segment. The
      valid range is [64KiB,1GiB]. The default IPC segment size is 64 KiB.

--ipc-index-length=<n>

      <n> is the length of the IPC message index. The minimum length is 16 and the
      maximum cannot exceed 1/4 of the IPC segment size. The default IPC message
      index length is 16.


The IPC message index is a dynamic data structure, allocated within the IPC segment, that allows receiving concurrent messages from more than one sender application. The default index length of 16 nodes is more than sufficient for most practical purposes.

_________________

Right now I cannot disclose more specific information, but successful experiments have already been done with new hardware control tools based on the new IPC functionality, and the results are promising. I hope more developers will find new opportunities of creativity thanks to this feature.

Pages: [1] 2 3 ... 26