A draft of a technical description of FITS format specification to store of color images.
FITS format (image/fits) is one from the most flexible data storage formats. Unfortunately, there is no widely accepted convention for storing of color pictures. For practical purposes of color processing in Munipack, the specification described here has been used.
The term "color" may have differend meaning for an ordinary man and an astronomer.
In the astronomical terminology, the term "in colors" designates any measurement or an image taken at two or more wavelengths (usually throughout a color filter set). To be able obtain some information from the pictures, the exact and formal definition of the spectral sensitivity of used devices is required. Moreover, the specification must be included in every color image.
Color picures in astronomy are usually grouped as:
The first group colorize 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 authnetic representation of natural colors. That means, that humans will precipitate the colors differnetly than the colors visible by own eyeball (with help of a powerfull telescope or a spacecraft).
The representation of natral colors is little bit complicated opposite to false colors because we must exactly known transmisitivty of filters and a transformation from the transmisitvity 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 iamging is limited on optical part of spectra.
The field of usage of both groups is complementar. They are usefull in different situations.
The color specification is not included in FITS conventions registry.
Munipack's specification of color FITS format is fully compatible with FITS specification itself. A color 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 all, partly or nothink astrometrcial, spectroscopical and photometrical calibration. The astrometrical calibration is bounded on the first two dimensions and must contain keyword WCSAXES set to value 2. The spectroscipilal calibration can be provided as standard (by formula or table in an adiditional HDU), but also as the list of bands (see bellow in Calibration). There is a preffered way to calibrate a few bands by list of keywrods and a many of by a formula). Any support to additional tables HDU is not planed. The photometric calibration is done separatelly for every band. Note that the calibration information is not used during color processing because CSPACE must contain the coloscpace identificators (filters designation).
FITS format offers more flexibility over conventional image formats. The crucial feature is possibility to store several bands (colors) 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 color pictures when one is naturally storing frames in different colors to 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 choosed the record CSPACE which offers possibility to recognize an storing color space and provides an information for additional processing.
CSPACE = 'Landolt BVR' CTYPE3 = 'BAND-SET' CNAME3 = 'Color-space' CSBAND1 = 'Landolt B' CSBAND2 = 'Landolt V' CSBAND2 = 'Landolt 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 betwwen pixels and a physical quantities. The single-valued function betweend two sets of numbers (usually integers and floats). The coding of colorspace requires mapping betwenn 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 matemtacial pouint of view, a function is a element of function set. The filter can be represneted by a matematical function like gaussian with a parameters like center, half-widt and hight or as a a wavelength-transmisivity table. Therefore the filters can be difficulty indentified by a float number like their wavelenths but the use of a human-readable string is preffered (indexes can be used too but they will more complicated for understand and will need additional look-up table). The processor must have additinal infomarion (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 powerfull 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). Just false colors imaging is supported.
Copyright © 1997-2011, F. Hroch (✉, Blog⤴), DTFA, Masaryk University.