Introducing N.I.N.A. 1.10

N.I.N.A. 1.10 contains several sizable new features as well as iterative improvements to existing features and functions. The full change log contains a fairly exhaustive list of all of the improvements and fixes that went into this release. It’s a pretty large list, so I have picked some personal favorites that I will cover in detail here.

Flat panel support

Flat panels, a new-to-N.I.N.A. class of hardware, are now able to be connected and utilized by the Flat Wizard. This functionality support includes flat panels that can also act as a motorized lens cover, such as the Alnitak Flip-Flat, which can be set to automatically open and close at the beginning and end of sequences and when taking dark, darkflat, or bias frames. Several popular models are supported directly by N.I.N.A. and are listed in the release notes.

The Flat Wizard drives flat panels under two different modes of operation:

1. Untrained mode, where the Flat Wizard will hunt for the combination of flat panel brightness that fits within the range of exposure times that are defined by the you. The panel is started at its brightest setting and is reduced in brightness by half each iteration until the brightness facilitates an exposure that fits within the prescribed parameters.
2. Trained mode, where the Flat Wizard will take the range of acceptable exposure times, the desired ADU+tolerance, and a prescribed flat panel brightness and record the results of what it arrives at, if it is able to do so given the constraints. These results can then be reused in the future to take instant flats using known values on a per-filter basis.

It is important to note that the next release of ASCOM, version 6.5, introduces flat panels as a new class of hardware which will allow vendors to create ASCOM drivers for their flat panel products. Such ASCOM drivers will obviate the need to create product-specific “native” drivers in N.I.N.A. and other applications for these devices. However, N.I.N.A. 1.10 will not support these new drivers as the 1.10 development cycle wound down before ASCOM 6.5 was released. Support for ASCOM 6.5 and flat panel ASCOM drivers will happen during the 1.11 development cycle, along with support for other changes that 6.5 brings. We encourage vendors of flat panel products to adopt ASCOM 6.5 and supply conformant drivers for their devices.

Lacerta MGEN-2

Teleskop Austria kindly provided a Lacerta MGEN-2 unit to project founder Stefan Berg last year and he integrated support for it into N.I.N.A. as a guiding device. The MGEN series of guiders is a popular line of hardware-based guiding that is designed to be user-friendly and very effective. The LCD display of the hand controller is replicated in N.I.N.A.’s UI with full implementation of its protocol, giving the user the ability to command dithers from sequences and so forth.

Lacerta released the MGEN-3 product in early 2020 and Stefan has recently gotten a sample of that in his possession. Many people have been inquiring about support for it and that support is currently being worked on, however it will have to wait for 1.11.

Autofocusing

BIG changes and improvements have been made to N.I.N.A.’s autofocusing capabilities in 1.10. Yannick (aka Cuiv the Lazy Geek – please check out his YouTube channel) has done incredible work by implementing and refining a lot of new features and capabilities for autofocusing systems based on his own research and a lot of good feedback from users.

First, the existing HFR (Half Flux Radius) based autofocusing system was improved by implementing a set of curve-fitting algorithms. These allow an autofocus operation to fit the average HFR values from the frames it takes to one of two types of curves – parabolic or hyperbolic. Which curve is most suitable for use depends on the equipment being used. Generally, faster optics would benefit from hyperbolic curves, and slower optics from the parabolic curve. Some experimentation is in order to determine which one will reliably work well for a given configuration. Cuiv has produced some excellent videos on this topic which may be viewed here and here.

A second focusing system based on contrast detection has also been added. This type of system is more like what you would find in a typical DSLR focusing system, with the algorithms analyzing the sharpness of the transitions between well-defined areas of contrasting light – a point source such as star for sure, but also, say, the edge of the illuminated moon against the blackness of space and so on. Since this system does not rely on stars, it may also be used in the daytime. This system is also computationally more expensive, so users of mini PCs that have low-power CPUs might want take note.

In addition to the autofocus methods, there are now more ways to specify when an autofocus operation is triggered. One may now have one done after a meridian flip. This may be useful for SCT users which may suffer from the dreaded mirror flop that is inherent to that OTA’s design.

Each autofocus run is now also logged to its own file in JSON format in the %LOCALAPPDATA%\NINA\AutoFocus folder. This allows one to programmatically access and review their autofocus operations and do things such as chart and analyze them using a standard machine-readable format. Future plans for this data includes adding a Filter Offset wizard to aid in deriving filter offsets for one’s setup. Stefan also coded up a module for the N.I.N.A. project’s Discord bot which will produce a very pleasant graph of the autofocus log file by just dragging and dropping the JSON file into the chat window:

Plate solving

Prior to 1.10, N.I.N.A. plate solving reliability was good but sometimes suffered from unexplained problems in certain setups. By problems, I mean that a seemingly OK photo would sometimes fail to solve. Walking this back, we traced it to the fact that we were feeding the selected plate solving app a stretched JPEG of the image rather than an unstretched bitmap such as FITS or TIFF, and the lossy compression artifacts in the JPEG would sometimes confuse the star detection routine in the solver. Now, we just feed the plate solvers the image in unstretched FITS format, which is basically the pixel data as it was received from the camera. Things operate quite well now, and failures to solve are instead likely caused by exposure parameters, non-round stars, or other external-to-N.I.N.A. causes.

The behavior regarding syncing solved coordinates has also changed. A plate solve result is now always synced to the mount unless the “No Sync” option is switched on under Options > Equipment > Telescope. This option exists because coordinate syncs can interfere with some pointing model applications, such as Software Bisque’s T-Point. Why these pointing model apps don’t just ignore the syncs in order to protect their model is beyond me, but the option to not sync is present if one requires it.

Lastly, the “Center Target” option will cause all slews to a coordinate to be checked by plate solve and a sync and reslew will be commanded if the plate solve determines that the desired coordinates are not centered in the frame. When N.I.N.A. cannot sync the coordinates (such as when the aforementioned “No Sync” option is activated), N.I.N.A. will calculate the RA and declination offset and nudge the mount the required amount to that location.

XISF improvements

XISF (eXtensible Image Serialization Format) is the preferred image format of PixInsight and is starting to gain acceptance in other applications, such as the ASTAP plate solver. While both XISF and the more traditional FITS formats are bitmap-based file formats and the actual image data is, for all intents, the same between the two, the XISF format plugs a bunch of annoying semantic holes that FITS standards body has neglected to address. XISF defines a metadata structure that uses XML rather than very basic fixed-width fields, and it defines built-in compression capabilities that use modern and familiar compression algorithms. XISF also defines where the orientation of the image data array is, so there is no more “flipped image” situation that one might find themselves in with a FITS image.

N.I.N.A. 1.10 expands its XISF support by incorporating full support for XISF compression and data block checksums when both reading and writing XISF files. XISF compression may be useful for those who are storage-constrained and running out of disk space is a worry. It is also useful for those who do things such as transfer image data from a session over the network from their observatory computer to the one where they process the data, a very nice thing with ever-increasing sensor pixel counts. In some cases, compressed XISF images may even open quicker because there is less data being read from the hard drive. N.I.N.A. supports all three of the lossless compression algorithms defined in the XISF 1.0 specification:

• LZ4 is the most basic compression algorithm. It offers quick compression and decompression but the compression ratios achieved will be the lowest compared to the other two available algorithms. My personal experience with typical nebula data is in the 10% to 15% range in terms of file size reduction.
• LZ4-HC – This is the “High Compression” variant of LZ4. As the name implies, it focuses on better compression compared to basic LZ4 but at the expense of some speed, but it’s not a very noticeable impact. This is a good middle-of-the-road choice for those who are running on semi CPU-constrained systems such as mini PCs with the Apollo Lake or Gemini Lake Celeron CPUs. Decompression speed is still very fast.
• Zlib is the most aggressive compression algorithm available, completely throwing away any pretense of being gentle on CPU in its goal to compress data as much as possible. If best compression is your desired outcome, this is your best choice.

Additionally, there is an option called “Byte Swapping” that may be turned on and it affects all compression algorithms. Byte swapping rearranges the image data array prior to compression so that the least significant and most significant bytes of each pixel (a 16 bit pixel is 2 bytes of data) are grouped together in the image data array. This means that bytes that are likely to contain the same values are adjacent to each other which optimizes the data for better compression. This can introduce a further 5% to 10% improvement to image size reduction. Image data bytes are “unswapped” when a byte-swapped compressed file is opened.

One important note about compression is that compressors will usually take longer to compress a file the more compressible its data is. This means that creating dark, dark-flat, or bias frames with will likely see rather long file save times due to how consistent that kind of image data is.

Data block checksums are useful for ensuring the integrity of the image data in an XISF file and detecting files which might have suffered from bit rot. The XISF specification defines several SHA-based checksums, and all are equally good for this purpose. They are also computationally cheap, so there’s no real reason not to use one. One thing to note is that PixInsight, at least as of version 1.8.8-5, does not verify checksums when opening an XISF file that contains one. It is expected to in the future. N.I.N.A. does verify checksums in XISF files that it opens and an error notification will be presented to inform the user that the image data is potentially corrupted if the calculated and stated checksums do not match.

Framing Wizard

Framing Wizard, where the typical sequence begins life, has gotten some subtle but very useful quality of life improvements.

First, the notoriously blown-out images that are served by the NASA Sky Survey server now have a stretch applied to them which brings them down to earth in terms of brightness, so users of that may rejoice in not being blinded at 3am when loading one. There is still no cure for its speed, however, as that’s an issue on the NASA image server itself.

The greatest improvement to Framing Wizard is it leverages the N.I.N.A.’s new image metadata system to actually use the FITS or XISF keywords inside images now. It used to be that loading an image into Framing Wizard would always kick off a blind plate solve so that the wizard could place the image in the sky. As we know, blind plate solves can take ages, even with fast solvers such as ASTAP. Using the RA and declination metadata in an images speeds this up by turning the blind solve into a hinted one which, given accurate coordinates, almost always returns instantly or at least very quickly.

If the file contains WCS metadata due to it being solved externally by another application which then inserted that data into the image’s metadata, N.I.N.A. will utilize this info instead plate solving the image and using the solver to just annotate the objects in the image. Big applause to project founder Stefan Berg for implementing this, which greatly improves the framing process.

Persistent camera settings

Project contributors Jokogeo and darkarchon both made a huge quality of life improvement by implementing the ability for N.I.N.A. to save many camera settings to the profile and ensuring that they are accurately displayed in various places around the app. This means that preferred readout modes, gain, offsets, temperature setpoints, and other settings are saved to the profile and are applied when N.I.N.A. loads the profile. If you’ve been annoyed by having to set these settings back up every time you opened N.I.N.A., this improvement is for you.

Bayer Patterns

Before 1.10, N.I.N.A. dealt with OSCs in a basic way with RGGB being the only supported bayer pattern when debayering an image for display. Cameras with non-RGGB patterns would still have their images displayed, but the color would completely wrong. N.I.N.A. now understands all the possible permutations of the Bayer matrix and cameras that have patterns such as GBRG or BGGR and so on will now display correctly. Note that N.I.N.A. debayers images only for display purposes. It does not write debayered image files and will always write the bayered, raw data as it comes off the sensor.

The Bayer pattern information is also written to FITS and XISF headers using the BAYERPAT FITS keyword. This will allow for automatic debayering in applications such as PixInsight’s Debayer process or the forthcoming release of Deep Sky Stacker 4.2.4. N.I.N.A. will utilize the Bayer pattern that is supplied by the camera drivers, however the user may override this by selecting the desired Bayer pattern from a list of choices under Options > Equipment > Camera. This may need to be done in the case where FITS files are used and are opened in applications that expect a bottom-up orientation of data.

In closing…

N.I.N.A. has come a long way since its inception and 1.10 is probably one of the largest periods of maturation so far. Many thanks to all the contributors to the project, and this includes those who translate N.I.N.A.’s UI into may different languages as well! Of course, special thanks to project founder Stefan Berg for shepherding the project, tirelessly guiding and advising those who wish to contribute, and choosing to make this an open source application that all may freely use and enjoy. If you wish to support the project in non-technical ways, donations are one way to do so. These donations fund the hard costs such as website hosting and other costs involved in keeping the project running.

This new version is not a destination, but just a stop along the way. There are already major plans in store for 1.11, including support for Domes and a complete reenvision of the sequencer that will address some complaints and satisfy a lot of requests. If you enjoy using N.I.N.A. or have questions that the documentation does not address, please feel join us on our Discord chat server where you can interact with developers and users directly.