|
|
|
Thread Tools | Display Modes |
|
#1
|
|||
|
|||
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. |
#2
|
|||
|
|||
Reading floating point 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 |
#3
|
|||
|
|||
Reading floating point FITS files
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. |
#4
|
|||
|
|||
Reading floating point FITS files
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 |
#5
|
|||
|
|||
[fitsbits] Reading floating point FITS files
On Wed 2003-11-12T05:02:49 -0800, John Green hath writ:
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 ) I hope that it will be instructive to read the caveats expressed in this soon-to-be Internet Draft which is aimed at being an RFC. http://www.ucolick.org/~sla/fits/mime/ in particular http://www.ucolick.org/~sla/fits/mime/rfcFITS.txt This document is being readied for approval by both the FITS community and the IETF community. If it does not make things clear then it needs to be improved. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93 |
#6
|
|||
|
|||
[fitsbits] Reading floating point FITS files
On Wed 2003/11/12 15:55:04 -0000, Rob Seaman wrote in a message to: 5) "true color" FITS requires three input files - each file represents red, green or blue data. WCS Paper I Sect. 5.4 admits "conventional coordinate types" and cites CTYPEi values of 'COMPLEX' and 'STOKES'. Paper II also introduces 'CUBEFACE'. Clearly 'RGB', 'CMYK', and possibly others (e.g. 'RYB', 'YIQ', 'HSI', 'HSV', 'HSB', 'HLS') would be useful additions - see http://www.efg2.com/Lab/Library/Colo...tm#ColorSpaces. Typically these would be used in conjunction with BITPIX = 8. Rather than three input files you'd then have one multi-dimensional image with an 'RGB' axis. This seems tidier to me. The semantics should not be too hard to define ('RGB' = WCS coordinate values red = 1, green = 2, blue = 3; pixel value ranges from 0.0 to 1.0, etc.). Seems to me that astronomy could do with something like this for storing pretty pictures from HST, etc. Mark Calabretta ATNF |
#7
|
|||
|
|||
[fitsbits] Reading floating point FITS files
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. |
#8
|
|||
|
|||
Reading floating point FITS files
On 12 Nov 2003, John Green wrote:
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. I do not understand the difference. If you can take byte values between 0 and 255, short integer values between -32768 and 32767, long integer values between -2147483648 and 2147483647 and scale them in a range 0-n corresponding to a lookup table ... you should be able to do the same for floating point values between +/-1E39 or double float between +/1E308 ! My exact problem in reading -32,-64 bits per pixel files is in reading the image colors. there are no such things as image colours in the FITS file, just a continuous range of measurement values. Colours are only a convention in the mind of the user ! 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 THAT is really what your FITS file contain, then whoever wrote them did something totally unlike what astronomers do ! -- ---------------------------------------------------------------------- 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. |
#9
|
|||
|
|||
Reading floating point FITS files
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 |
#10
|
|||
|
|||
[fitsbits] Reading floating point FITS files
On Wed 2003-11-12T05:02:49 -0800, John Green hath writ:
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 ) I hope that it will be instructive to read the caveats expressed in this soon-to-be Internet Draft which is aimed at being an RFC. http://www.ucolick.org/~sla/fits/mime/ in particular http://www.ucolick.org/~sla/fits/mime/rfcFITS.txt This document is being readied for approval by both the FITS community and the IETF community. If it does not make things clear then it needs to be improved. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93 |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Spacecraft Doppler&Light Speed Extrapolation | ralph sansbury | Astronomy Misc | 91 | August 1st 13 01:32 PM |
Pres. Kerry's NASA | ed kyle | Policy | 354 | March 11th 04 07:05 PM |
Ned Wright's TBBNH Page (C) | Bjoern Feuerbacher | Astronomy Misc | 24 | October 2nd 03 06:50 PM |
Invention: Action Device To Generate Unidirectional Force. | Abhi | Astronomy Misc | 21 | August 14th 03 09:57 PM |
Invention For Revolution In Transport Industry | Abhi | Astronomy Misc | 16 | August 6th 03 02:42 AM |