A draft of a technical description of FITS format specification to store of colour images in exactly defined colour spaces.
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:
The first group colourises images by a number of ways:
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.
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:
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).
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.
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:
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.
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.
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.
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:
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.
The description of the obsolete specification is just only for documentation purposes to show a wrong way.
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.
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.
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.
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.