PixInsight 1.5.5: Prerelease Information

[Juan Conejero]

Along with a large number of bug fixes and optimizations, the next version 1.5.5 of PixInsight includes some important new features that I'd like to review briefly in this post.

Some of these new features originate from a complete rewrite of the screen rendering engine in PixInsight. This reimplementation involves two main changes: a redesigned mask rendering system and a significant performance improvement, especially to work with very large images.

Let's describe the new mask rendering modes in PixInsight 1.5.5. So far masks have always been represented by simply multiplying screen image renditions in PixInsight. While this system was simple and efficient from a computational point of view, it is not the best way to represent masks and their interaction with masked images. Starting from version 1.5.5, PixInsight has several mask rendering modes:

http://forum-images.pixinsight.com/legacy/1.5.5-preview/MaskMode01.jpg

Overlay modes work by painting the mask as a colored overlay over the image. You can select a number of colors, which is useful to improve mask visibility as a function of image contents. In the example above, the red overlay mode is being used. This is the default mode.

Along with overlay rendering modes, there are two additional modes:

- Replace. In this mode, the image is replaced by its mask.

- Multiply. This is just the traditional mask rendering mode in PixInsight: the image is multiplied by its mask to form the screen rendition.

In PixInsight 1.5.5, we also introduce the new mask readouts. This means that you can obtain direct pixel readouts from masked images, as shown on the following screenshot:

http://forum-images.pixinsight.com/legacy/1.5.5-preview/MaskReadout01.jpg

The mask readout is labeled as "M:" in the example above.

Another consequence of the new screen rendering engine is a new fast screen rendering mode. Here you can see how fast renditions can be enabled/disabled through global preferences:

http://forum-images.pixinsight.com/legacy/1.5.5-preview/FastRenditions01.jpg

When fast renditions are enabled, PixInsight uses a special sparse interpolation algorithm to render images as bitmaps at reduction zoom ratios below 1:2. This has a huge repercussion in terms of performance of screen renditions (and other bitmap representations), which is especially significant when working with large images. For example, on an 8-core workstation a RGB image of 16000x16000 pixels in 32-bit floating point format can now be zoomed in/out almost in real time using the mouse wheel. The new sparse interpolation is of course less accurate than the high-quality mode, but the quality loss is barely noticeable except for very high reduction ratios. Of course, fast renditions are enabled by default.

Another change in PixInsight 1.5.5 is the extensive use of scientific notation to represent numerical data. For example, here is the new Statistics interface:

http://forum-images.pixinsight.com/legacy/1.5.5-preview/Statistics01.jpg

For developers interested in these tabular representations, the full source code of Statistics is available in the standard PCL distribution. PixInsight's Console objects support a large subset of HTML 4 and CSS 2, which the Statistics interface uses to generate the table shown above.

Also of interest to developers are the many changes and additions made to PixInsight's JavaScript runtime (PJSR). The complete list of changes and new features is very large; I'll comment just some of the most important ones. For example the new Vector and Matrix PJSR objects implement highly efficient, basic vector and matrix support directly from JavaScript code:

http://forum-images.pixinsight.com/legacy/1.5.5-preview/Vector01.jpg

http://forum-images.pixinsight.com/legacy/1.5.5-preview/Matrix01.jpg

The Math object has also a new static method, namely:

Code: [Select]

Array Math.solve( Matrix A, Matrix B )
that returns an array with the solution to the linear system A*X = B. Math.solve() returns the inverse matrix of A and the matrix of solution vectors X.

To complete a basic set of linear algebra tools, Math has also a new method:

Code: [Select]

Array Math.svd( Matrix A )
that performs the singular value decomposition (SVD) of a matrix A. The returned array contains the matrices U, W and V^T of the standard SVD:

A = U*W*V^T

All methods of Vector and Array, as well as the new Math.solve() and Math.svd() methods, invoke high-performance routines implemented as native code.

Other important feature is a completely new garbage collection mechanism. PixInsight scripts can now activate an automatic, asynchronous garbage collector through a new property of the Global object:

Code: [Select]

Boolean jsAutoGC
which is false by default (since it has a small but noticeable impact on performance). The Global.gc() method has also changed:

Code: [Select]

void gc( [Boolean hardGC=true] )
The hardGC parameter of gc() allows performing a soft garbage collection. When hardGC is false, gc() performs an actual garbage collection only if the amount of collected space is worth the required computational effort. This is a strong performance improvement, especially in large and complex scripts. The amount of memory being wasted by garbage (inaccessible) data can be known in advance thanks to a new method:

Code: [Select]

Number gcBytes()
Finally, scripts can be now asynchronously abortable via a new global property:

Code: [Select]

Boolean jsAbortable
which again is false by default, since it has a slight impact on performance.

There are new standard PJSR objects implemented as pure JavaScript code. An example is ColorComboBox:

http://forum-images.pixinsight.com/legacy/1.5.5-preview/ColorComboBox01.jpg

and SimpleColorDialog:

http://forum-images.pixinsight.com/legacy/1.5.5-preview/SimpleColorDialog01.jpg

Besides these, there are lots of changes made to the PJSR. I'll try to document them appropriately after the release of PI 1.5.5.

There are also some new scripts that will be included with the standard set of utility scripts in version 1.5.5. Along with Niall Saunders' CMYG batch deBayer script and Juan M. Gómez's DeconvolutionPreview, I have written MathTranClient, a script to render TeX formulas as images, using the MathTran public web service:

http://forum-images.pixinsight.com/legacy/1.5.5-preview/MathTranClient01.jpg

http://forum-images.pixinsight.com/legacy/1.5.5-preview/MathTranClient02.jpg

That's all for now. There are much more things that must be documented, as a new multiscale noise evaluation algorithm, and important new features of ImageIntegration and StarAlignment. I'll update this information with more feature descriptions during the release of PI 1.5.5.

[Nocturnal]

This sounds great Juan. How about following through on the suggestion I made earlier to create a separate page with release notes for each version? This is golden information that should be trivial to find. A url embedded in the PI interface (a help (gasp!) menu entry perhaps?).

In other words I don't think this crucial information belongs in a forum post. Please consider starting with improved documentation with this release even if it means removing features (we can't keep up anyway) or pushing out the release a few days (1.5 works fine).

My suggestion: a new menu entry in the list on the left hand side of the main PI site. Something like 'PixInsight Release Notes' under PCL Documentation. A single page with release notes that get added on top of each other, perhaps with links at the top to each separate release notes should be easy and quick to do. And IMNSHO (in my not so humble opinion) this would make a huge difference.

Thank you for considering this.

[bitli]

Juan, thanks for all this work
Sander, I second (strongly)
bitli

[georg.viehoever]

Sander, I second too.

[Jordi Gallego]

Great work Juan!!

Regards
Jordi

[David Serrano]

The Global.gc() method has also changed:

Code: [Select]

void gc( [Boolean hardGC=true] )
The hardGC parameter of gc() allows performing a soft garbage collection. When hardGC is false, gc() performs an actual garbage collection only if the amount of collected space is worth the required computational effort. This is a strong performance improvement, especially in large and complex scripts. The amount of memory being wasted by garbage (inaccessible) data can be known in advance thanks to a new method:

Code: [Select]

Number gcBytes()

So, if I'm understanding it, this:

Code: [Select]

gc (0);
is equivalent to this:

Code: [Select]

if (gcBytes() > some_magical_number) { gc (1); }
but faster, isn't it?

BTW I agree with Nocturnal's suggestion, too .

[Juan Conejero]

So, if I'm understanding it, this:

Code: [Select]

gc (0);
is equivalent to this:

Code: [Select]

if (gcBytes() > some_magical_number) { gc (1); }
but faster, isn't it?

Not exactly. "Soft" garbage collection is actually more sophisticated. The JavaScript engine evaluates the computational cost of performing a thorough garbage collection work, versus the resulting amount of freed memory bytes. Then it decides whether the increment in free memory is worth the effort, and it takes the decision to perform a full gc(), a partial one, or even no gc() at all. Quite complex, but it usually works very well, AFAIK.   

BTW I agree with Nocturnal's suggestion, too .

Me too I've created the Release Information board to implement those suggestions. I'll try to keep that board up-to-date. I also want to create a wiki, but I need to enable PHP 5 on the main website first, and this could cause some problems with existing scripts. When I find the time to fix them, I'll install the wiki software and you'll be busy!