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