When examining and experimenting with Seestar S50 FITS format image files, it is useful to dive down into some of the characteristics of those files. Of importance is the numerical type of the data. Some of the characteristics of a stacked Seestar S50 FITS format file can be summarised as follows:
- FITS format - this commonly used data format in astronomy stands for 'Flexible Image Transport System'
- Data organised in rows and columns. Care needed as applications differ in the order of row/column read out - can result in a 'flipped' image.
- Information concerning details of the observation, equipment, etc, are contained in a header. Header overhead for a stacked Seestar S50 FITS file is 8,640 bytes.
- Data is stored in three 2D tables corresponding to the 1080 by 1920 pixels in the image - one table for each of the red, green and blue components of RGB data forming a 3D array.
- Data values are stored as a 16-bit signed integer commonly referred to a short in programming languages which have fixed-bit integers types. Another common reference is int16. The range of values for a short is -32,768 to 32,767.
- As the magnitude of the optical data is always positive (i.e., minimum value = 0) an offset value of 32,768 needs to be added in applications reading the data such that -32,768 = 0. This converts the data range to a 0 to 65,535 magnitude range - in programming languages commonly called an unsigned short (ushort).
- The FITS header specifies the 32,768 offset in a text field called 'BZERO'. Associated with that text field is one called 'BSCALE' - which has a value of 1 in all stacked files examined. In terms of C# code, the conversion from the short values read from the file into ushort magnitude values is done using this relation...
ushort theValue = (ushort)(bZero + bScale * shortDataArray[colour, row, column]);
It should be noted that the data in the single stacked FITS file from the Seestar S50 has been de-bayered (de-mosaiced), a correction made for field rotation, stacked and then converted into 16-bit RGB data. The text field 'BAYERPAT' with a value 'GRBG' found in the stacked FITS file header is not needed as the data has already been de-bayered internally in the Seestar S50.
The individual sub-frame files, which can also be downloaded for stacking in external applications, are the raw data from the Bayer matrix in the sensor - which needs de-bayering. Therefore, the text field 'BAYERPAT' with a value 'GRBG' found in the sub-frame FITS file header is needed by any external program. The processing and creation of a single RGB image from this sub-frame FITS file data is not trivial as is evidenced by different external programs not agreeing on what Bayer pattern should be applied. In some applications it is necessary to select a different Bayer matrix pattern to what is specified in the FITS file due to that application reversing the read order of the row data - which flips the image and changes the effective Bayer matrix pattern. Due to this complexity, activity here - as far as analysis and processing is concerned - is restricted to stacked FITS files.
NOTE: My initial understanding of how data was stored in the sub-frame files was incorrect. I went down a path assuming the data was stored as RGB as is done in the stacked files. This lead to all manner of confusion on my part w.r.t. how many bits were allocated to each of R. G and B. Fortunately there was help to found on the Seestar S50 (Official ZWO Group) facebook group which educated me about de-bayering, etc. Thanks Chris G. !!!