John Green writes:

I don't face any problem reading 32 bits per pixel files for example
because it is a standard color depth, any developer involved in
imaging knows exactly how to deal with it ( just read the 4 bytes,
extract the 3 bytes related to color: R,G,B and feed them into the
bitmap )

Um - a 32 bpp integer image may imply something about the color model
for GIFs and JPEGs, but means nothing for FITS. A FITS image is a pure
array of numbers - it doesn't matter whether those numbers are integer
or real, or whether they are 8, 16, 32 or 64 bits. An astronomical
instrument, which might be the equivalent of a "camera" or might be
something quite a bit more peculiar, is simply a device for taking
measurements (of the flux of photons or some other physical quantity).
The axes of the 2-D array may not even correspond to spatial dimensions.
Heck, many astronomical images are 1-D or 3-D or have even higher
dimensionality.

In short, general FITS data has no color model attached to the file.
The color model exists in the display software. It would be possible
for a specific project or observatory to adopt some local addition
(or would it be, restriction) to the FITS standard that would convey
a color model in some fashion in either the metadata or the data
records - but this is not a widespread example of FITS usage even if
somebody later chimes in with an example.

But a -32 bit (32 bit floating point) color depth is something I have
never heard of. Simply I don't know how to extract the 3 color bytes
(R,G,B) from the floating point data.

1) A FITS pixel value means the same thing whatever the datatype,

2) each pixel value must be scaled into whatever data range is
appropriate for your display device - 2, 8, 16, 24 bits being the
most familiar,

3) each pixel typically "represents" a grayscale value,

4) instead of a grayscale lookup table, images are frequently displayed
using pseudocolor LUTs - there are dozens and dozens of these, and

5) "true color" FITS requires three input files - each file represents
red, green or blue data.

Here's some pseudocode, but any useful application would need to provide
much more access to the user to tweek the pixel mapping from FITS to
display:

minvalue = min (image);
maxvalue = max (image);

range = maxvalue - minvalue;
scale = 256 / range;

do i = 1 to xsize {
do j = 1 to ysize {
newimage[i,j] = scale * (image[i,j] - minvalue);
red[i,j] = max (0, min (255, newimage[i,j]));
green[i,j] = red[i,j];
blue[i,j] = red[i,j];
}
}

(I'm sure my ADASS buddies will be more than happy to point out any
mistakes I've made :-)

In general, this recipe will produce a very poor visual representation
of the image because the range of the pixels will be skewed by bad CCD
columns or other artifacts. A key concept is to first identify the
meaningful range of the image values and only second decide how to map
those values into the display device. Techniques such as histogram
equalization can help, but often the histogram is itself contaminated
by some huge spike (at zero, for instance). The best display technique
for one type of astronomical data may be entirely inappropriate for
other data.

Rob Seaman
National Optical Astronomy Observatory