A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Astronomy and Astrophysics » FITS
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

Reading floating point FITS files



 
 
Thread Tools Display Modes
  #11  
Old November 12th 03, 09:14 PM
Thierry Forveille
external usenet poster
 
Posts: n/a
Default [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  
Old November 12th 03, 10:06 PM
Steve Allen
external usenet poster
 
Posts: n/a
Default [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  
Old November 12th 03, 10:06 PM
Steve Allen
external usenet poster
 
Posts: n/a
Default [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  
Old November 13th 03, 12:27 AM
Mark Calabretta
external usenet poster
 
Posts: n/a
Default [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  
Old November 13th 03, 12:27 AM
Mark Calabretta
external usenet poster
 
Posts: n/a
Default [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  
Old November 13th 03, 08:34 AM
Steve Allen
external usenet poster
 
Posts: n/a
Default [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  
Old November 13th 03, 08:34 AM
Steve Allen
external usenet poster
 
Posts: n/a
Default [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  
Old November 13th 03, 09:16 AM
LC's No-Spam Newsreading account
external usenet poster
 
Posts: n/a
Default 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  
Old November 13th 03, 09:16 AM
LC's No-Spam Newsreading account
external usenet poster
 
Posts: n/a
Default 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  
Old November 14th 03, 03:38 AM
Mark Calabretta
external usenet poster
 
Posts: n/a
Default [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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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 08: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


All times are GMT +1. The time now is 02:31 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 SpaceBanter.com.
The comments are property of their posters.