|
|
Thread Tools | Display Modes |
#31
|
|||
|
|||
[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
|
|||
|
|||
[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
|
|||
|
|||
[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
|
|||
|
|||
[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
|
|||
|
|||
[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 | |
|
|
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 |