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
  #31  
Old November 24th 03, 11:26 PM
Steve Allen
external usenet poster
 
Posts: n/a
Default [fitsbits] Reading floating point FITS files

On Wed 2003-11-19T16:05:24 +0000, Rob Seaman hath writ:
It is possible to imagine extending FITS in both directions - to
implement color support within FITS or to permit foreign formats to be
accessed from within FITS. Both directions would require software to
be developed - and to be widely adopted - before the extensions would
be useful. Before we put resources into what would be a daunting task,
there should be a motivation stronger than purely a sense of esthetics.


My impression is that the protocols within WCS Papers I and II along
with some notions from Paper III might result in a conventional
multi-HDU representation for multi-wavelength data. With that in
place it is conceiveable that developers of plug-ins for tools such as
Adobe Photoshop (TM) might be motivated to write FITS import filters
which would provide handles for producing pretty pictures.

I see the current discussion as a roadmap which might be followed by
practitioners of multi-wavelength astronomy. Thanks for pointing
out the importance of having a demonstrated need before inventing
a new scheme and burdening every FITS implementor with handling it.

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

  #32  
Old November 25th 03, 07:55 AM
Mark Calabretta
external usenet poster
 
Posts: n/a
Default [fitsbits] Reading floating point FITS files


On Wed 2003/11/19 16:05:24 -0000, Rob Seaman wrote
in a message to:

somebody will actually use this feature. Are we really ready to see
FITS turned into some poor man's XML to be used only as a wrapper to
provide access to somebody else's data format?


I agree, it's a silly idea.

It might help if somebody could provide a use case for why this might be
a requirement of some astronomical project.


I already did. Look at
http://antwrp.gsfc.nasa.gov/apod/ap020920.html.
Does this image contain astrophysical content? Yes, phenomenal. Would
it work as a greyscale? No. Clearly the use of colour in this, and the
many other images like it that are starting to appear regularly, is more
than just aesthetic. It effectively provides a way of visualizing a
third dimension in the data. The particular use-case I suggested was to
overlay a celestial coordinate grid on it. Try getting PhotoShop to do
that!

Here's another. Consider a 4-D data cube: RA, DEC, FREQ, STOKES.
STOKES could be mapped to RGB as an alternate WCS and this 4-cube
visualized as a colour movie or other animation.

This thread started because John Green, a software developer, was
assigned the job of importing FITS files and innocently asked how to
extract the RGB components from floating point data. Clearly someone is
interested!

However, import of FITS into general image display and manipulation
packages such as xv, photoshop, etc., while important, is not as
interesting for astronomy as software which understands the other FITS
concepts such as coordinate systems, data cubes, and so on. There is no
shortage of these (kvis, aips++ viewer, etc.). Once colour FITS has
been defined they will eventually get around to implementing it - it's
really not that hard (and if not, well there just wasn't a pressing
need, but no harm done).

It's too bad we had to admit to John Green that FITS is colour-blind -
even worse if we have to admit that it's not considered a significant
shortcoming.

Mark Calabretta
ATNF


  #33  
Old November 25th 03, 07:55 AM
Mark Calabretta
external usenet poster
 
Posts: n/a
Default [fitsbits] Reading floating point FITS files


On Wed 2003/11/19 16:05:24 -0000, Rob Seaman wrote
in a message to:

somebody will actually use this feature. Are we really ready to see
FITS turned into some poor man's XML to be used only as a wrapper to
provide access to somebody else's data format?


I agree, it's a silly idea.

It might help if somebody could provide a use case for why this might be
a requirement of some astronomical project.


I already did. Look at
http://antwrp.gsfc.nasa.gov/apod/ap020920.html.
Does this image contain astrophysical content? Yes, phenomenal. Would
it work as a greyscale? No. Clearly the use of colour in this, and the
many other images like it that are starting to appear regularly, is more
than just aesthetic. It effectively provides a way of visualizing a
third dimension in the data. The particular use-case I suggested was to
overlay a celestial coordinate grid on it. Try getting PhotoShop to do
that!

Here's another. Consider a 4-D data cube: RA, DEC, FREQ, STOKES.
STOKES could be mapped to RGB as an alternate WCS and this 4-cube
visualized as a colour movie or other animation.

This thread started because John Green, a software developer, was
assigned the job of importing FITS files and innocently asked how to
extract the RGB components from floating point data. Clearly someone is
interested!

However, import of FITS into general image display and manipulation
packages such as xv, photoshop, etc., while important, is not as
interesting for astronomy as software which understands the other FITS
concepts such as coordinate systems, data cubes, and so on. There is no
shortage of these (kvis, aips++ viewer, etc.). Once colour FITS has
been defined they will eventually get around to implementing it - it's
really not that hard (and if not, well there just wasn't a pressing
need, but no harm done).

It's too bad we had to admit to John Green that FITS is colour-blind -
even worse if we have to admit that it's not considered a significant
shortcoming.

Mark Calabretta
ATNF


  #34  
Old November 29th 03, 01:31 AM
Stuart Levy
external usenet poster
 
Posts: n/a
Default [fitsbits] Reading floating point FITS files

In article , Rob Seaman wrote:
Don Wells says:

There is another way that we could support inclusion of color imagery
in FITS files: we could agree to permit XTENSION='JPEG', XTENSION='TIFF',
XTENSION='GeoTiff', XTENSION='PNG', etc. The XTENSION mechanism enables
FITS to wrap up any data object[*] and declare its type.


NOAO implemented a general purpose foreign file encapsulation scheme
several years ago. The interest in this has been very minimal. The
reality is that FITS is already general enough to permit the storage
of all the graphics formats mentioned above. Adding additional
functionality (explicit typing and presumably a keyword to convey
the size of the embedded object) only makes it more likely that
somebody will actually use this feature. Are we really ready to see
FITS turned into some poor man's XML to be used only as a wrapper to
provide access to somebody else's data format?

On the other hand, the original discussion focused on the exact opposite
feature - how to use native FITS to provide color handling (and perhaps
other features) similar to the various non-astronomical picture formats.
It might help if somebody could provide a use case for why this might be
a requirement of some astronomical project.


There are an awful lot of pretty pictures published, with generally
no attempt made to preserve their geometric alignment with the sky.
As a computer-graphics person with an interest in astronomy, I've dealt
with at least three groups of people who would like to be able to embed
such images in larger pictures of the sky, or to compare them with images
taken in other wavebands, or to match features in them against object
catalogs. And we can't!

These pictures are rarely published in FITS form. Finding out just
how they're aligned on the sky generally would involve going back to
the person who created the image (probably from a collection of
FITS images in the first place!) or trying to compute the transformation
by identifying objects and matching against catalog positions.
That's often impractical.

An elaborate color model embedded in a FITS standard,
as Rob Seaman suggests, might be nice to have, but I don't think it's
necessary at all to make FITS useful for exchanging sky-registered
color images.

I imagine that many pretty pictures get processed in programs
like Photoshop, which don't respect FITS information and aren't likely to.
But suppose all geometric transformations (rectification/rotation/scaling/
cropping/etc.) were handled in FITS, yielding a collection of aligned
single-plane images. The user would convert these to something Photoshop
(or whatever) could read, combine them, adjust color and so on, and
write out a non-FITS full-color image, whose pixels were geometrically
matched to the FITS originals. Then it'd be nice to be able to
represent the result as another FITS image for publication.

This could be done without special FITS library support, say with
a specialized tool that took geometric information from an existing
FITS single-channel image, color data from a non-FITS color image
(which had better have the same size in pixels as the FITS input image),
and wrote some sort of multichannel FITS output.

So the only support FITS would really need to provide is a convention
for naming channels of a multichannel image with names that'd be
meaningful to picture-processing programs, like "R", "G", "B", "A",
or "C", "M", "Y", "K". If FITS viewers could automatically
display those images with the given channel assignments, so much the better.
But even without that, the above convention plus a couple of batch-style
conversion tools should make practical trading pretty pictures in sky-aligned
FITS form -- and if made easy, it might well happen.

I think this is what Mark Calabretta is saying -- I'm just cheering him on
and plodding through some of the details.

Stuart
  #35  
Old November 29th 03, 01:31 AM
Stuart Levy
external usenet poster
 
Posts: n/a
Default [fitsbits] Reading floating point FITS files

In article , Rob Seaman wrote:
Don Wells says:

There is another way that we could support inclusion of color imagery
in FITS files: we could agree to permit XTENSION='JPEG', XTENSION='TIFF',
XTENSION='GeoTiff', XTENSION='PNG', etc. The XTENSION mechanism enables
FITS to wrap up any data object[*] and declare its type.


NOAO implemented a general purpose foreign file encapsulation scheme
several years ago. The interest in this has been very minimal. The
reality is that FITS is already general enough to permit the storage
of all the graphics formats mentioned above. Adding additional
functionality (explicit typing and presumably a keyword to convey
the size of the embedded object) only makes it more likely that
somebody will actually use this feature. Are we really ready to see
FITS turned into some poor man's XML to be used only as a wrapper to
provide access to somebody else's data format?

On the other hand, the original discussion focused on the exact opposite
feature - how to use native FITS to provide color handling (and perhaps
other features) similar to the various non-astronomical picture formats.
It might help if somebody could provide a use case for why this might be
a requirement of some astronomical project.


There are an awful lot of pretty pictures published, with generally
no attempt made to preserve their geometric alignment with the sky.
As a computer-graphics person with an interest in astronomy, I've dealt
with at least three groups of people who would like to be able to embed
such images in larger pictures of the sky, or to compare them with images
taken in other wavebands, or to match features in them against object
catalogs. And we can't!

These pictures are rarely published in FITS form. Finding out just
how they're aligned on the sky generally would involve going back to
the person who created the image (probably from a collection of
FITS images in the first place!) or trying to compute the transformation
by identifying objects and matching against catalog positions.
That's often impractical.

An elaborate color model embedded in a FITS standard,
as Rob Seaman suggests, might be nice to have, but I don't think it's
necessary at all to make FITS useful for exchanging sky-registered
color images.

I imagine that many pretty pictures get processed in programs
like Photoshop, which don't respect FITS information and aren't likely to.
But suppose all geometric transformations (rectification/rotation/scaling/
cropping/etc.) were handled in FITS, yielding a collection of aligned
single-plane images. The user would convert these to something Photoshop
(or whatever) could read, combine them, adjust color and so on, and
write out a non-FITS full-color image, whose pixels were geometrically
matched to the FITS originals. Then it'd be nice to be able to
represent the result as another FITS image for publication.

This could be done without special FITS library support, say with
a specialized tool that took geometric information from an existing
FITS single-channel image, color data from a non-FITS color image
(which had better have the same size in pixels as the FITS input image),
and wrote some sort of multichannel FITS output.

So the only support FITS would really need to provide is a convention
for naming channels of a multichannel image with names that'd be
meaningful to picture-processing programs, like "R", "G", "B", "A",
or "C", "M", "Y", "K". If FITS viewers could automatically
display those images with the given channel assignments, so much the better.
But even without that, the above convention plus a couple of batch-style
conversion tools should make practical trading pretty pictures in sky-aligned
FITS form -- and if made easy, it might well happen.

I think this is what Mark Calabretta is saying -- I'm just cheering him on
and plodding through some of the details.

Stuart
 




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 12:03 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.