Update for 0.99.x
Line 1: Line 1:
=Supported FITS files by [[Siril]]=
=Supported FITS files by [[Siril]]=


In versions 0.9.x, the native image file format of [[Siril]] is unsigned 16-bit FITS (USHORT), one or three layers only, ordered bottom-up. This is the format in which other images are converted to when using the conversion tab, the internal representation of images loaded in  Siril and which it processes, the format in which processing results are saved and the format used in FITS sequence export.
In versions 0.9.x, the native image file format of [[Siril]] was unsigned 16-bit FITS (USHORT), one or three layers only, with data [[Siril:FITS_orientation|stored bottom-up]].
 
Since the introduction of the 0.99.x series, a second native image file format has been introduced, the 32-bit floating point FITS (FLOAT), normalized to 1, so with values between 0 and 1, one or three layers only and with data [[Siril:FITS_orientation|stored bottom-up]] as well. It was a widely requested feature, and its main purposes are to increase the precision that results from image processing and to support negative values on bias/dark subtraction.
 
This new 32 bits format became the default format since its introduction, but since it doubles the requirements for available memory and disk space and slows the processing down, it can be disabled in the preferences. In that case, the behaviour is the same as in older 0.9.x versions.
 
The 32 bits format is not used in conversion when not needed. In general, acquired images are 8 or 16 bits deep, so for these, Siril still uses the 16 bits format. For preprocessing, the images are then converted to 32 bits.
 
Siril can also use FITS compression. It is disabled by default, see the preferences to enable it. It saves disk space, but requires more processing power to compress images when writing them and to decompress them when reading them back.


==Bitpix: pixel precision==
==Bitpix: pixel precision==


But Siril can also work with other FITS formats, meaning that it can load, display and process them just like the file format above, but the internal representation, results and exports will still be the native FITS USHORT format, starting with version 0.9.9:
Siril can work with other FITS formats, meaning that it can load, display and process them just like the file formats above, but they will be converted to either formats on loading:
* 8-bit integers per channel: the images are converted to 16 bits in memory, no problem
* 8-bit integers per channel: the images are converted to 16 bits (USHORT) in memory, no problem
* 16-bit integers per channel: the signed SHORT images are converted to unsigned short, and no problem either for 15 bits formats. USHORT is in fact [https://heasarc.gsfc.nasa.gov/docs/software/fitsio/c/c_user/node23.html stored as SHORT] with a 2^15 offset.
* 16-bit integers per channel: the signed SHORT images are converted to unsigned short, and no problem either for 15 bits formats. USHORT is in fact [https://heasarc.gsfc.nasa.gov/docs/software/fitsio/c/c_user/node23.html stored as SHORT] with a 2^15 offset.
* 32-bit integers per channel: only the 16 most significant bits are kept, equivalent to dividing by 65536, in consequence some precision is lost. If in the 32-bit integers contain small data, like values between 0 and 65535, the result will be between 0 and 1 as integer, in other words useless. We may add in the future a way to specify how the conversion is made.
* 32-bit integers per channel: the image is converted to the floating point 32-bit format. Data is normalised with the maximum value, and the minimum value is used as an offset. This is fine to use a single image, but not for a sequence, as min and max value change among frames, the consistency of the data is not preserved.
* 64-bit integers per channel: not currently supported, it would almost be sure to give unusable data.
* 64-bit integers per channel: not currently supported, it would almost be sure to give unusable data.
* 32-bit and 64-bit floating point numbers: they are loaded by multiplying their value with 2^16, so if they are stored with values between 0 and 1 it's usable with some precision loss. If they are stored with values between arbitrary DATAMIN and DATAMAX FITS header keywords values, this will not be usable.
* 32-bit and 64-bit floating point numbers: the image is loaded as Siril's 32-bit image format, but if the input data is not normalized to 1, the data is divided by 65535.


'''Siril 1.0 will switch to a floating point representation of data''', providing better precision and support of most formats.
==FITS cube==


==FITS groups==
Since the 0.99.x versions, Siril provides another way to save a sequence of images with the FITS format: the ''FITS cube'', or fitseq as we call it sometimes; it is a single FITS file containing several FITS images. Siril only uses these files to store its own sequences, meaning that all images inside the file must have the same type of data, or the same dimensions and pixel format. The same FITS formats are supported as for regular FITS images.


Siril is currently unable to load most FITS images from professional observatories because they contain a lot of metadata and the image data is not registered as the primary content of the file. It is in a subgroup of data, but Siril reads only the first group. Maybe in the future we will handle these formats, but this and the precision of versions 0.9 make Siril '''unsuitable for professional use'''.
Professional observatories provide data in form of a FITS cube, with a lot of metadata and various types of data. Often, the image data is not registered as the primary content of the file. Siril may be able to open the file as a sequence, and may be able to display an image from it. Using a sequence of these files will not work, it may only be possible to display or extract an image from such a file.

Revision as of 23:42, 22 February 2021

Supported FITS files by Siril

In versions 0.9.x, the native image file format of Siril was unsigned 16-bit FITS (USHORT), one or three layers only, with data stored bottom-up.

Since the introduction of the 0.99.x series, a second native image file format has been introduced, the 32-bit floating point FITS (FLOAT), normalized to 1, so with values between 0 and 1, one or three layers only and with data stored bottom-up as well. It was a widely requested feature, and its main purposes are to increase the precision that results from image processing and to support negative values on bias/dark subtraction.

This new 32 bits format became the default format since its introduction, but since it doubles the requirements for available memory and disk space and slows the processing down, it can be disabled in the preferences. In that case, the behaviour is the same as in older 0.9.x versions.

The 32 bits format is not used in conversion when not needed. In general, acquired images are 8 or 16 bits deep, so for these, Siril still uses the 16 bits format. For preprocessing, the images are then converted to 32 bits.

Siril can also use FITS compression. It is disabled by default, see the preferences to enable it. It saves disk space, but requires more processing power to compress images when writing them and to decompress them when reading them back.

Bitpix: pixel precision

Siril can work with other FITS formats, meaning that it can load, display and process them just like the file formats above, but they will be converted to either formats on loading:

  • 8-bit integers per channel: the images are converted to 16 bits (USHORT) in memory, no problem
  • 16-bit integers per channel: the signed SHORT images are converted to unsigned short, and no problem either for 15 bits formats. USHORT is in fact stored as SHORT with a 2^15 offset.
  • 32-bit integers per channel: the image is converted to the floating point 32-bit format. Data is normalised with the maximum value, and the minimum value is used as an offset. This is fine to use a single image, but not for a sequence, as min and max value change among frames, the consistency of the data is not preserved.
  • 64-bit integers per channel: not currently supported, it would almost be sure to give unusable data.
  • 32-bit and 64-bit floating point numbers: the image is loaded as Siril's 32-bit image format, but if the input data is not normalized to 1, the data is divided by 65535.

FITS cube

Since the 0.99.x versions, Siril provides another way to save a sequence of images with the FITS format: the FITS cube, or fitseq as we call it sometimes; it is a single FITS file containing several FITS images. Siril only uses these files to store its own sequences, meaning that all images inside the file must have the same type of data, or the same dimensions and pixel format. The same FITS formats are supported as for regular FITS images.

Professional observatories provide data in form of a FITS cube, with a lot of metadata and various types of data. Often, the image data is not registered as the primary content of the file. Siril may be able to open the file as a sequence, and may be able to display an image from it. Using a sequence of these files will not work, it may only be possible to display or extract an image from such a file.