Moravian instruments
Main menu
Main page
Price list
CMOS & CCD cameras
Online Shop

Main pageProductsSoftware

New version 2.3.3 of the SIPS software package available in both 32ábit and 64ábit variant
 64ábit version of the Scientific Image Processing System package was tested for several months and it is now released for free download with the minor SIPS release v2.3.3. Software variant supporting 64ábit memory addressing (this means not limited to 4GB) is not the only new feature. This minor release added support for new hardware, allows much better control of attached telescopes, broadened compatibility with FITS standard etc. It was also significantly updated to work much better on HI-DPI displays.

64ábit computing

“64ábits” seems to be a buzzword of current mobile computing, but it is quite common in the PC space. Despite we use 64ábit systems for a couple of years, general understanding what this exactly means is low. Let us explain a few terms before we describe 64ábit version of SIPS.

64ábit CPU is a computer processor with internal registers, holding and processing individual pieces of information (integer numbers, memory pointers, ...), up to 64ábits long. The first microprocessor ever was 4ábit (Intel 4004), but it was soon replaced by 8ábit version (Intel 8008). 8ábit CPUs become widely popular and numerous models appeared (Intel 8080, Zilog Z80, Motorola 6800, MOS Technology 6502, ...) and they powered first truly personal computers. In a chase for greater computing power and the ability to access more memory 16ábit and later 32ábit processors appeared, some of them created as extension of existing architectures, some designed from the scratch to be directly 16áor even 32ábit.

Continuous demand for more memory caused the 4áGB limit, allowed by 32ábit processors (2^32á=á4G) was exceeded and a room for 64ábit processors opened. And similarly, some of them were natural extension of older 32ábit architectures, some of them were newly designed as 64ábit.

But processor architectures have tough life. They either become successful and widely spread or die soon. Currently only two architectures dominates (Intel x86-64 and ARM v7/v8) and both are available in 64ábit variant. And both evolved from previous 32ábit versions, so they are able to run both 32ábit and 64ábit code.


Intel x86 evolved from 16ábit to 32ábit first and only later 64ábit mode was added. It is worth noting that 64ábit version of the ancient x86 architecture was not introduced by Intel, which was busy promoting now dead Intel Itanium processors, completely incompatible with x86 standard. Instead AMD, another manufacturer of x86 processors, invented 64ábit x86-64 extensions and when Microsoft started to support it, even Intel has to accept this standard. The key feature was the ability of 64ábit x86 CPUs to run all existing 32ábit software. Completely 32ábit environment was used first (operating system, applications) and only later 64ábit operating systems started to be common, running a mix of 32ábit and 64ábit applications.

64ábit x86 CPUs were marked x86-64, which was later reduced to x64 only. So “x86” means 32ábit Intel architecture, while “x64” means 64ábit Intel architecture (invented by AMD :).

64ábit operating system needs 64ábit CPU to run. While a purely 64ábit OS, requiring 64ábit applications only, could be designed, it is almost impossible to succeed on the market. People need to run existing applications, so a backward compatibility is a key to success.

To achieve compatibility, both hardware (CPU) and software (operating system) must support it. And all major players do this (x64 and ARM, Windows and Android).

  • 64ábit CPU can run both 32ábit and 64ábit operating system and applications. If 32ábit OS is run, the whole system acts as purely 32ábit, including memory address space limitations. It is not possible to use any 64ábit piece of code, 64ábit applications do not work.

  • When 64ábit CPU runs 64ábit OS, it is possible to run both 32ábit and 64ábit applications.


    Here is a source of confusion among many users. They have 64ábit CPU and 64ábit version of Windows, so they think all they run is 64ábit. In fact, only a very few applications are 64ábit, absolute majority are still (2014/2015) in 32ábit form only. And because they never need more than 4áGB of memory and work seamlessly, there is no pressure to rebuild them to 64ábit version.

    So 64ábit Windows can run both 32ábit and 64ábit SIPS without any problems.

  • But there is one important limitation. It not possible to mix 32ábit and 64ábit code in one process. One process is either completely 32ábit or completely 64ábit, including all DLLs, drivers and other components. The same is true for the operating system kernelŚif it is 64ábit version, all device drivers must be 64ábit, too.


    This is why Gx camera system drivers are available as 32ábit and 64ábit versions for quite a long time. It is necessary to use 64ábit version of the system driver if 64ábit OS is used, despite the user application controlling the camera is 32ábit only.

    Similarly drivers for user applications must be 32ábit if the application is 32ábit (rememberŚmajority of applications are still 32ábit), despite the application runs on 64ábit CPU and OS.

The fact that 32ábit and 64ábit code cannot be mixed and 64ábit code is always newly translated/modified allowed CPU designers to more or less modify the instruction set. Both AMD with x86-64 and ARM with v8 took advantage of introduction of a new 64ábit mode and upgraded the respective architectures. x64 somewhat reorganized register set, making it more regular, and doubled number of registers (from 8 to 16). ARM similarly removed conditional execution of all instructions and used the saved space in the instruction word to address twice as much registers (32 instead of 16). So it is not exaggeration to say that 64ábit ARM v8 is a completely new architecture, only similar to 32ábit ARM v7 (similarly like 16ábit Intel 8086 remotely resembled 8ábit Intel 8080).


This is also source of confusion even among journalists focused to ITŚ64ábit code does not bring greater accessible memory only. Because of architectural updates the code also can run faster even if less that 4áGB memory is used.

64ábit SIPS

64ábit version of SIPS is essentially the same as 32ábit version. It is naturally able to use much more memory, which comes handy especially when SIPS uses image sets with hundreds of images and the PC is equipped with more than 4áGB of memory. And it of course needs 64ábit versions of all device drivers, but all supported drivers comes with the program itself so this is not a problem.

As was noted in the previous chapter, 64ábit applications keep pointers (addresses of data in memory) in twice as long registers compared to 32ábit programs. So naturally 64ábit programs are somewhat longer and they need to operate larger amount of data even if they do not use memory above 4áGB. This is kind of performance penaltyŚlonger code means larger memory traffics and effectively shrinks sizes of fast cache memory. But on the other side, 64ábit code can use twice as much registers to keep various variables (in the case of x64) and it does not need to access memory so often, which causes performance gain. So the question isŚis the 64ábit code faster or slower compared to 32ábit code? In reality it can be both faster and slower, depending on the algorithm:

  • When the algorithm is very simple and mainly moves data in memory, the 32ábit code is typically faster. x86 CPU has enough registers for simple algorithms and operating just 32ábit pointers naturally needs less resources compared to 64ábit pointers.

    Typical example is Median filter, which goes through large number of pixels, but the most complex operation performed is simple comparison of pixel values. 32ábit version of SIPS is somewhat faster than 64ábit version in this case.

    Median filter test on 16ábit and 32ábit FITS files shows slowdown of 64ábit code (x64) compared to its 32ábit counterpart

    Median filter test on 16ábit and 32ábit FITS files shows slowdown of 64ábit code (x64) compared to its 32ábit counterpart

  • More complex algorithms, which can utilize all 16 registers available in 64ábit mode of x64 CPUs on the other side run significantly faster compared to 32ábit version.

    Such complex algorithm is for instance searching for stars within an image. Numerous tests are performed to determine whether each particular pixel is a part of star image or if it is solitary hotpixel etc. Also numerous floating point operations are performed (calculation of standard deviation of aperture area etc.). 64ábit code is significantly faster here compared to 32ábit code and even a medium-class Core i5 CPU running 64ábit code can outperform top-of-the-class Core i7 running 32ábit code.

    Star search algorithm running on single core (left) and multi core (right), 64ábit version (x64) is considerably faster

    Star search algorithm running on single core (left) and multi core (right), 64ábit version (x64) is considerably faster

Naturally integer calculations using whole 64ábit integers are much faster on x64 CPU. While x86 CPU can of course perform such calculations, several instructions are necessary to handle single 64ábit calculation in 32ábit mode, while 64ábit CPU needs only single instruction. Unfortunately SIPS has no use for such large integers, so potential speed gain is not utilized here.

Hi-DPI display support

While support for high DPI (high resolution) displays were added to previous SIPS versions, some tools (Histogram and Stretch, Cooling tab in the Camera tool, ...) remained fixed to 96 DPI displays. But high resolution displays provide much smoother image and they are more and more common even in the case of cheap 2áiná1 and convertible computers.

Beside flexible adjustment of Cooling tab to Hi-DPI displays, the temperature range was increased up to -75C, because new EC (Enhanced Cooling) models of Gx cameras provide temperature drop up to 60C below ambient and -50C minimum temperature was no low enough.

Other enhancements

New SIPS finally brought all features to the Telescope (mount) drivers and control tools. Beside basic functions (coordinates, goto, ...), it is now possible to control:

  • Park and Unpark the mount, as well as SetPark position.

  • Read and update mount location information (possibly obtained from a GPS receiver attached to PC).

  • Read and set mount tracking (on/off) and choose tracking speed (sideral, solar, lunar).

  • Synchronize mount time with PC time (again possibly obtained from a GPS receiver attached to PC or synchronized over the Internet with Time Servers).

Evolution of the Telescope tool from SIPS v2.0 (left) to SIPS v2.3.3 (right)

The New FITS Header tool allowed manual, semi-automatic or fully automatic entry of some headers:

  • Manual entry headers are for instance OBJECT or TELESCOP. User simply have to check the header and fill the particular edit box. Then the header appears in FITS file.

  • Semi-automatic headers are for instance observatory location (LONG-OBS, LAT--OBS and ELEV-OBS). It is possible to fill these headers manually or click the Get Location from GPS button to read them from GPS receiver.

  • Fully automatic headers do not allow any intervention from the user, e.g. EXPTIME, FILTER or IMAGETYP. Values of these headers are assigned by software upon image acquisition.

New version of SIPS introduced updated New FITS Header tool, which clearly distinguishes between automatic and manual filling of respective headers. Such headers allow user to define their value in the edit box, but also allow to check the option to update the value upon image acquisition, providing the proper information is available.

Let's take newly introduced RA and DEC headers as example. They should contain equatorial coordinates of the image center. It is possible to enter their value manually, but if the telescope driver is active and provides telescope coordinates, it is possible to check the option R.A./Dec. from telescope to fill these headers each time the new image is downloaded from the camera automatically.

The New FITS Header tool allows optional automatic filling of selected header values

The New FITS Header tool allows optional automatic filling of selected header values

Camera tool now supports guiding not only through guider camera with “AutoGuider” port, but also through a telescope driver, providing the driver supports PulseGuide interface.

SIPS now properly handles FITS “blank comment” lines. Lines beginning with no keyword at all (only spaces) have to be considered as comment lines and SIPS was updated to work properly with FITS files using this feature.

SIPS is a freeware and can be downloaded from the Download section of this web site.

 | Main page | Products |