# Colour FITS

A draft of a technical description of FITS format specification to store of colour images in exactly defined colour spaces.

## Introduction

FITS format (image/fits) is one from the most flexible data storage formats. Unfortunately, there is no widely accepted convention for storing of colour pictures. For practical purposes of colour processing in Munipack, the specification described here is used.

The term "colour" may have different meaning for an ordinary man and an astronomer.

In the astronomical terminology, the term "in colours" designates any measurement or frames taken at more spectral bands, or "in colours" by a dialect. The spectral bands are commonly realised by some filters having distinct spectral sensitivity than human eye; their colours are false (unnatural) or instrumental colours. A single band frames are known as monochromatic, grey, or black and white.

In contrast with this, common term "in colours" means colour frames displaying scenes with all colours like red, orange, … included. By more specific, kids has colouring books with drawings; the drawings are transformed from monochromatic to colour by its painting by colour pens.

Colour pictures in astronomy are usually grouped as:

- false colour pictures
- natural colour pictures

The first group colourises images by a number of ways:

- A gray image is colourised by mapping of colours onto values (by colour tables), highlighting of pale details.
- A set of colour images is colourized by the way: all single exposures are colorized by a (randomly) selected color and result image is composed from the pictures. It is frequently used to opposite multi-wavelength images. An example is composite image in X-ray, optical and radio.

The color composition does no care about true colors of images. The colors are still false without try to do authentic representation of natural colors. That means, that humans will precipitate the colors differently than the colors visible by own eyeball (with help of a powerful telescope or a spacecraft).

The representation of natural colors is little bit complicated opposite to false colors because we must exactly known transitivity of filters and a transformation from the transitivity filters to a spectral sensitivity of human eye. Than we can reconstruct natural colors and the colors in pictures will close to colors as can be visible by own eyeball. Note that natural color imaging is limited on optical part of spectra.

The field of usage of both groups is complimentary. They are useful in different situations.

The color specification is not included in FITS conventions registry.

# The Specification

Munipack's specification of colour FITS format is fully compatible with FITS specification itself. A colour set specification is on base of a FITS header keyword. Color FITS specification must satisfy all following conditions:

- The image is fully stored in a single primary image HDU.
- CSPACE header record is presented. A valid string specifies of the color space of the stored data.
- The HDU contains 3D cube data: first two dimensions are space-like coordinates, the last dimension contains color bands in wavelengths increasing order.

This specification is relative restrictive. We can store just only 2D color images. The images are required to have unified world coordinates.

There is no limit to number of color bands.

The HDU header can contain both calibrated data or data without any calibration. The , or partly or nothing astrometrical, spectroscopical and photometrical calibration. The astrometrical calibration is bounded on the first two dimensions and must contain keyword WCSAXES set to value 2. The spectroscopical calibration can be provided as standard (by formula or table in an additional HDU), but also as the list of bands (see bellow in Calibration). There is a preferred way to calibrate a few bands by list of keywords and a many of by a formula). Any support to additional tables HDU is not planed. The photometric calibration is done separately for every band. Note that the calibration information is not used during color processing because CSPACE must contain the colorspace identifiers (filters designation).

## Description

FITS format offers more flexibility over conventional image formats. The crucial feature is possibility to store several bands (colours) into a single file. The property is widely used in high-energy astrophysics where data from single channels are stored in a FITS file (also additional auxiliary images are frequently included). The property can be also used for creating colour pictures storing frames into a single container The number of color bands is not limited.

FITS format also has no limits on machine representation of numbers. Therefore, it is contra-productive to deform data by a some non-linear transformation and it is preferred to store the original data.

As the key identification sign has been choose the record CSPACE which offers possibility to recognize an storing color space and provides an information for additional processing.

## Color space representation in Color FITS

    CSPACE = 'Johnson BVR'
    CTYPE3 = 'BAND-SET'
    CNAME3 = 'Color-space'
    CSBAND1 = 'Johnson B'
    CSBAND2 = 'Johnson V'
    CSBAND2 = 'Johnson R'

Key | Needs | Description
--- | --- | ---
CSPACE | mandatory | Colorspace of stored images
CTYPE3 | optional | Type of color part in 4-3 notation
CNAME3 | optional | Description
CSBANDi | optional | Color bands

Rules:

- NAXES = 3
- WCSAXES = 2
- NAXIS3 ≥ 2, index in CSBANDi is 1 < i ≤ NAXIS3
- All keywords (CSPACE, CTYPE3 and a set CSBANDs) are type of character.

A calibration coded-in to FITS headers suppose a unique mapping between pixels and a physical quantities. The single-valued function between two sets of numbers (usually integers and floats). The coding of colorspace requires mapping between different objects. Between a pixel and a filter. Note that a filter (the general approximation at least) is not a number but this is a function. From mathematical point of view, a function is a element of function set. The filter can be represented by a mathematical function like Gaussian with a parameters like center, half-width and height or as a a wavelength-transmisivity table. Therefore the filters can be difficulty identified by a float number like their wavelengths but the use of a human-readable string is preferred (indexes can be used too but they will more complicated for understand and will need additional look-up table). The processor must have additional information (from data tables) to render a image by the right way.

## Advantages

- More simple processing. Corrections, any operations and calibration data can be used directly and simply. Including of color transformation table is possible
- The store of data of images taken at the same time is more logically consistent.
- Using of data cube saves some storage space. Every HDU contains at least 2880 bytes in header. For a few bands the space is negligible, but for 3D spectroscopy with hundredth of channels the stored place can take significant space with no additional information.

## Disadvantages

- The data used in color cube must be homogenized by to recomputing on the same world coordinates. There is no possibility to directly use of images with offset.
- The unification would be also used for any photometric information. Multi-band images are probably more worse represented (principally).
- From physical point of view, the mixing of different quantities is correct. Just only a appropriate constant must be used to convert quantities to common units.

The separation of data on tree distinguishing physical parts requires more memory for processing against to (standardly used) interlaced (RGBRGBRGB...) data storage. The wavelength-like (or analogical quantity) separation is preferred with respect to a specific data storage. However, an interlaced data store would break the harmony of FITS world.

Color FITS processors needs to be advanced tools. Complex algorithms must be available. They also requires more powerful processors for rendering of images.

## Data Input/Output

A sample Fortran code is pretty simple:

    character(len=80) :: cspace
    real,dimension(:,:,:),allocatable :: ccd

    call ftnopn(25,'color.fits',0,status)
    call ftgkys(25,'CSPACE',cspace,buf,status)
    call ftghpr(25,naxis,simple,bitpix,naxis,naxes,pcount,gcount,extend,status)
    width = naxes(1)
    height = naxes(2)
    nbands = naxes(3)
    allocate(ccd(width,height,nbands))
    call ftg3de(25,1,minvalue,width,height,width,height,nbands,ccd,anyf,status)
    call ftclos(25,status)

More complex (and complicated) example of a general multi-HDU FITS in C/C++ can be found in source code of `xmunipack/fits.cpp` (constructor of FitsFile).

The main advantage of the choosed format is its very simple usage. The code is very close to a code for 2D images.

## Color Rendering

The CSPACE keyword has been choosed in analogy of the `color_type` key of PNG format. The value specifies a color space of the stored data. An output color space is not specified. It is supposed that the image processor will convert the input colors to a color space of a display device.

Frequently used color spaces are:

sRGB or AdobeRGB
  The standard RGB or AdobeRGB. Colors can be directly displayed. The tune of colors, luminance, etc. is strongly limited.
CIE 1931 XYZ
  Preprocessed colors. Colors are partially limited in color space appropriate to human eye. Colors can be relative freely tuned.
Landolt UBVRI, Johnson UBVRI, ubvy, ....
  A general (astronomical) color space. To be displayed, additional transformation to CIE 1931 XYZ (or any RGB) is required. Relative sophistical algorithm is required. Parameters are highly tunable. This is preferred format due to preserving of the photometric information.

Color spaces are mutually convertible. Unfortunately, the conversion of RGB to/from XYZ is strongly nonlinear and an important part of the photometric information is lost. Therefore, use of RGB is not recommended. The XYZ format is useful for a rapid tuning. The preferred color space is carefully defined photometric system like Landolt's UBVR or the surface spectrophotometry (3D spectroscopy).

The color bands can be also prescaled to reflect exposure times, different instruments, sky levels in different filters, etc.

The additional information for displaying of a general color space is a projection matrix from the color space to XYZ. The information would take form of an external table. The original information is separated from specific displaying device (eye, LCD). The same way is widely used for Web environment as method for formatting of HTML code by using CSS also LaTeX uses styles etc.

There are technical difficulties of including the transformation matrix to color images. The transformation can be included as table to the first HDU. The way violates standard use of FITS tables with first dummy HDU. The adding of conversion table to the header records is possible but not too elegant way. Use a table HDU following the image data complicates adding of everything others.

The color processing is in detail described on Color space page.

# An obsolete specification

The description of the obsolete specification is just only for documentation purposes to show a wrong way.

- The first HDU is a primary image HDU. It contains no data. The record with keyword COLORTYP is presented with a string value specifying of the color space of the stored data.
- It has at least two additional image extensions with images in different spectral bands. The extensions are sorted in wavelength increase order.

As one can see, that codding operations are relative complicated. Therefore, more simple specification can be developed.

Note that there is no a dirrect connection between the colorspace and the HDU image. There is no an identifier which connect the proper HDUs.

## Data Input/Output

To give an illustration of code for color FITS load, the relevant simplified part of code is presented:

    character(len=80) :: cspace
    real,dimension(:,:,:),allocatable :: ccd

    call ftnopn(25,'color.fits',0,status)
    call ftthdu(25,nbands,status)
    call ftmahd(25,1,hdutype,status)
    call ftgkys(25,'COLORTYP',cspace,buf,status)

    do i = 1, nbands

      call ftmahd(25,i+1,hdutype,status)
      call ftghpr(25,naxis,simple,bpix,n,naxes,pcount,gcount,extend,status)

      if( i == 1 ) then
         width = naxes(1)
         height = naxes(2)
         allocate(ccd(width,height,nbands-1))
      endif

      call ftg2de(25,1,minvalue,width,width,height,ccd(:,:,i),anyf,status)
      ! just only for information, rather use 2D buffer
    enddo
    call ftclos(25,status)

Note that the format will very difficult to parse for any home-made FITS reader. In the example, cfitsio library has been used. Note that the color processing is of course the same as above.

## Advantages

- The specification is pretty compatible to other applications.
- It is possible to provide single-image specific information for every HDU.

## Disadvantages

The band by band FITS storage has significant disadvantages for post-processing. Their complex structure affects algorithms and also strongly complicates addition of another HDUs.

- The storage of another calibration data as dark frames is relative complicated because a full list of bands needs to be stored by n-times.
- Any elemental operations leads to extensive computations.
- The principial difficulty is storing of at a time (single exposure) images as a serie of bands (for example, digital camera or 3D spectroscopy images). The separation on single HDUs is highly artificial. On the other side, it is natural for images separated by time or by another reasons.

## References

HDF (Hierarchical Data Format) is a format similar to FITS.

ds9 also implements RGB pictures. Ones can be stored by both described alternatives (as cube or in separated HDUs). The false colors imaging is just supported.