|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
[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. |
#12
|
|||
|
|||
[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 |
#13
|
|||
|
|||
[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 |
#14
|
|||
|
|||
[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 |
#15
|
|||
|
|||
[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 |
#16
|
|||
|
|||
[fitsbits] Reading floating point FITS files
On Thu 2003-11-13T10:27:08 +1100, Mark Calabretta hath writ:
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 WCS papers have covered a variety of ways to attribute meaning to axes 1 through N of a FITS array and how to interpret CUNITn keywords. This calls into question the interpretation of the 0th axis, by which I mean the array data values themselves, and the BUNIT keyword. Seems to me that astronomy could do with something like this for storing pretty pictures from HST, etc. It is not obvious how physical data values would be preserved and documented when doing this. Most pretty pictures have been clipped, stretched, mapped, and/or scaled in ways that obliterate physical meaning in the data values. At best this seems an awful lot like reinventing TIFF in FITS. There should be strong justifications before doing this. -- 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 |
#17
|
|||
|
|||
[fitsbits] Reading floating point FITS files
On Thu 2003-11-13T10:27:08 +1100, Mark Calabretta hath writ:
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 WCS papers have covered a variety of ways to attribute meaning to axes 1 through N of a FITS array and how to interpret CUNITn keywords. This calls into question the interpretation of the 0th axis, by which I mean the array data values themselves, and the BUNIT keyword. Seems to me that astronomy could do with something like this for storing pretty pictures from HST, etc. It is not obvious how physical data values would be preserved and documented when doing this. Most pretty pictures have been clipped, stretched, mapped, and/or scaled in ways that obliterate physical meaning in the data values. At best this seems an awful lot like reinventing TIFF in FITS. There should be strong justifications before doing this. -- 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 |
#18
|
|||
|
|||
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. |
#19
|
|||
|
|||
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. |
#20
|
|||
|
|||
[fitsbits] Reading floating point FITS files
On Wed 2003/11/12 23:34:27 -0800, Steve Allen wrote in a message to: FITSbits It is not obvious how physical data values would be preserved and documented when doing this. Most pretty pictures have been clipped, stretched, mapped, and/or scaled in ways that obliterate physical meaning in the data values. Preserve physical data values? This image may help to clarify matters - http://antwrp.gsfc.nasa.gov/apod/ap020920.html At best this seems an awful lot like reinventing TIFF in FITS. There should be strong justifications before doing this. Can TIFF put a celestial coordinate grid on the above image? Mark Calabretta ATNF |
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 |