Reading floating point FITS files

Hello all, I am a software developer and I was assigned the task of
importing FITS files. Among the files that I have got are 32, 64
floating point files. I don't know how to extract the R,G,B values
from the flaoting point data.

To make it more clear: I am restricted to using a toolkit for
displaying the images. To be able to display the images correctly, I
have got to pass to the toolkit a buffer containing RGB data for each
pixel. So for each pixel I have to provide the toolkit with 3 bytes:
one for red, one for green, one for blue.

I don't know how is the RGB values stored in the 32, 64 floating point
data types of FITS files.

John Green writes:

To make it more clear: I am restricted to using a toolkit for
displaying the images. To be able to display the images correctly, I
have got to pass to the toolkit a buffer containing RGB data for each
pixel. So for each pixel I have to provide the toolkit with 3 bytes:
one for red, one for green, one for blue.

I don't know how is the RGB values stored in the 32, 64 floating point
data types of FITS files.

FITS is a transport and archival format for representing tables and
multidimensional arrays of scientific measurements - it is not a display
format like GIF or JPEG, for instance. The astronomical community does
have tools for displaying FITS files - and even tools for displaying
full color representations of FITS and other astronomical images.
But these tools require either explicit or implicit decisions on the
part of the user about what values represent what grayscale levels or
colors.

Typically a FITS image might represent a grayscale image taken through
some UBVRI filter - the filter might be wideband and correspond to some
"color" - or the filter might be narrowband and really have meaning only
in reference to some spectral feature (at some relative radial velocity).
By taking three wideband FITS images roughly covering the blue, green
and red parts of the visible spectrum, software can composite a full
color image that roughly approximates what some astronomical object
would look like to the human eye - if the human eye were 8 meters
across :-) Perceived color only really means something for bright
objects.

To answer your specific question, a single FITS image is typically
displayed as a grayscale representation. Astronomical display clients
usually allow adjusting the brightness and contrast (or "window" and
"stretch") on the fly by moving sliders or even just the mouse. If
your toolkit requires RGB values, your default should likely be to
simply scale the image values into the 8 bit range and then write the
same number into each of the three bytes. You might also fiddle around
with fancier features such as mapping three different images to the
three different colors and overlaying them.

Rob Seaman
National Optical Astronomy Observatory

John Green writes:

To make it more clear: I am restricted to using a toolkit for
displaying the images. To be able to display the images correctly, I
have got to pass to the toolkit a buffer containing RGB data for each
pixel. So for each pixel I have to provide the toolkit with 3 bytes:
one for red, one for green, one for blue.

I don't know how is the RGB values stored in the 32, 64 floating point
data types of FITS files.

FITS is a transport and archival format for representing tables and
multidimensional arrays of scientific measurements - it is not a display
format like GIF or JPEG, for instance. The astronomical community does
have tools for displaying FITS files - and even tools for displaying
full color representations of FITS and other astronomical images.
But these tools require either explicit or implicit decisions on the
part of the user about what values represent what grayscale levels or
colors.

Typically a FITS image might represent a grayscale image taken through
some UBVRI filter - the filter might be wideband and correspond to some
"color" - or the filter might be narrowband and really have meaning only
in reference to some spectral feature (at some relative radial velocity).
By taking three wideband FITS images roughly covering the blue, green
and red parts of the visible spectrum, software can composite a full
color image that roughly approximates what some astronomical object
would look like to the human eye - if the human eye were 8 meters
across :-) Perceived color only really means something for bright
objects.

To answer your specific question, a single FITS image is typically
displayed as a grayscale representation. Astronomical display clients
usually allow adjusting the brightness and contrast (or "window" and
"stretch") on the fly by moving sliders or even just the mouse. If
your toolkit requires RGB values, your default should likely be to
simply scale the image values into the 8 bit range and then write the
same number into each of the three bytes. You might also fiddle around
with fancier features such as mapping three different images to the
three different colors and overlaying them.

Rob Seaman
National Optical Astronomy Observatory

On 10 Nov 2003, John Green wrote:

Hello all, I am a software developer and I was assigned the task of
importing FITS files. Among the files that I have got are 32, 64
floating point files. I don't know how to extract the R,G,B values
from the flaoting point data.

I assume you refer to FITS images and not to other kind of FITS data
(tabular). The "I" in FITS originally meant "Image" but nowadays it
means just "Interchange" !

I don't know how is the RGB values stored in the 32, 64 floating point
data types of FITS files.

There is no such thing as "RGB values". The content of the image is some
arbitrary physical quantity (could be number of photons, flux, magnitude
[which in itself is proportional to log flux] or anything else).

The way it is usually displayed is first to apply some physical
transformation (e.g. applying low and high cut, then transforming the
values using a linear, log or other scale as some form of histogram
equalization into an array of integer values from 0 to n, say n=255).

Then apply a lookup table which makes a correspondence between the index
n and a triplet of RGB. But this purely for display. All the physics and
the capabilities of the observer are in the image content and in the
physical transformation !

There are many popular families of lookup tables. One could have a pure
grayscale ( R=G=B=n), other monochrome grayscales (e.g. R=0 G=n B-0), or
other conventional scales like a "heat" scale, a "rainbow" scale etc.
Each package has its own set of scales.

--
----------------------------------------------------------------------
is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

On 10 Nov 2003, John Green wrote:

Hello all, I am a software developer and I was assigned the task of
importing FITS files. Among the files that I have got are 32, 64
floating point files. I don't know how to extract the R,G,B values
from the flaoting point data.

I assume you refer to FITS images and not to other kind of FITS data
(tabular). The "I" in FITS originally meant "Image" but nowadays it
means just "Interchange" !

I don't know how is the RGB values stored in the 32, 64 floating point
data types of FITS files.

There is no such thing as "RGB values". The content of the image is some
arbitrary physical quantity (could be number of photons, flux, magnitude
[which in itself is proportional to log flux] or anything else).

The way it is usually displayed is first to apply some physical
transformation (e.g. applying low and high cut, then transforming the
values using a linear, log or other scale as some form of histogram
equalization into an array of integer values from 0 to n, say n=255).

Then apply a lookup table which makes a correspondence between the index
n and a triplet of RGB. But this purely for display. All the physics and
the capabilities of the observer are in the image content and in the
physical transformation !

There are many popular families of lookup tables. One could have a pure
grayscale ( R=G=B=n), other monochrome grayscales (e.g. R=0 G=n B-0), or
other conventional scales like a "heat" scale, a "rainbow" scale etc.
Each package has its own set of scales.

--
----------------------------------------------------------------------
is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

Thank you so much Rob, but actually I am already able to read and
display FITS files of 8,16,32 bits per pixel I just fail to do so for
those of -32, -64 bits per pixel.

32 bits per pixel means that a 32 bit integer represents each pixel
-32 bits per pixel means that a 32 bit float represents each pixel
-64 bits per pixel means that a 64 bit float represents each pixel

My exact problem in reading -32,-64 bits per pixel files is in reading
the image colors.

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 )

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.

To cut it short: I have just one specific problem: how to extract
R,G,B data from the -32 bits per pixel FITS images.

Thank you so much Rob, but actually I am already able to read and
display FITS files of 8,16,32 bits per pixel I just fail to do so for
those of -32, -64 bits per pixel.

32 bits per pixel means that a 32 bit integer represents each pixel
-32 bits per pixel means that a 32 bit float represents each pixel
-64 bits per pixel means that a 64 bit float represents each pixel

My exact problem in reading -32,-64 bits per pixel files is in reading
the image colors.

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 )

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.

To cut it short: I have just one specific problem: how to extract
R,G,B data from the -32 bits per pixel FITS images.

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

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

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 )

If you do that with a 32 bit/pixel FITS image you'll get a display, but
definitely not a meaningful one ;-) Integer FITS data are actually fixed
point numbers, not integers. The physical value is obtained by
float=BZERO+BSCALE*integer


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.

To cut it short: I have just one specific problem: how to extract
R,G,B data from the -32 bits per pixel FITS images.

Please read again what has been said to you, and try to understand it.
To cut it short: FITS IMAGES DO NOT CONTAIN RGB DATA in any hypothesis-free
form.