[iaufwg] FITS conventions

[Lucio Chiappetti]

On Mon, 13 Feb 2006, William Pence wrote:

> The technical group that we have talked about appointing to clarify the 
> current FITS standard would not be the appropriate group to develop 
> major new FITS conventions.

Agreed.

Let me however add my 2 euro-cents to the short discussion on colour.

On Fri, 10 Feb 2006, Steve Allen wrote:
SA> I remain unmotivated, but not immovable.

SA> If amateurs are motivated only by stunning color pictures then let 
SA> them discard FITS.

On Fri, 10 Feb 2006, Doug Tody wrote:

DT> Like Steve I have always felt that color support was unimportant for 
DT> FITS and probably better left to the established graphics formats.

I rather agree with the above statements.

Personally I've always considered colour representation vs data in a way 
similar to format vs binary representation, i.e. something which the user 
chooses (but which could be suggested to him, like with the TDISPn 
keywords, which do exist but are in fact not mandatory at all).

I do not feel at all the lack of a fixed or mandatory colour 
representation for a standard (NAXIS=2) FITS image, since I can obtain 
whatever look I want with a display program like ds9 (incidentally, after 
having written in the past some homegrown stuff [not to talk of IHAP and 
MIDAS], and done some use of IDL, I would say I've personally now settled 
on almost exclusive use of ds9).

I do appreciate (although I might almost no use of them) false colour 
images in which one tries to combine (three) different physical quantities 
(NAXIS=3 NAXIS3=3 ?) "as if" they were R, G and B as a way of providing 
extra visualization to scientific information, but regard them as a sort 
of specialized thing. 

There is instead one thing which has been sort of lacking to me (but the 
fact I've lived without since the old times I tried to have something 
similar in my old Exosat data analysis system, and nobody else came out 
with a similar convention may mean is not important), that would be a FITS 
convention to describe colour tables (LUT, ITT etc.) ... in such a way one 
could "pre-load" the colour table in the display program to be applied to 
all future images being displayed.


Changing slightly, I wonder whether the following idea by Steve Allen
means the same by Doug Tody reported just below ...

SA> XTENSION = 'MIME; image/jpeg; charset=us-ascii'

DT> would probably have to be considered as well.  A simple solution here 
DT> however, might be to adopt a standard graphics format (one is probably 
DT> enough) and incorporate it into FITS wholesale,

i.e. de facto means to incorporate a, say PNG preview or JPEG preview into 
a FITS file, in the same way EPS files can incorporate a preview (this is 
the sort of thing I usually "disable" when generating an EPS :-) ).

This could be viable (a glorified TDISPn ?) ... with some issues to be 
defined

 - how to incorporate the other format into a FITS HDU (that's probably
   simple, one 2880 header block with the XTENSION and the minimum number
   of necessary keywords possible (e.g. size), then n 2880 blocks with the 
   "other file" as a byte stream, with zero padding at the end).

 - support any MIME (image ?) type as extension (no), a selection of
   graphic types (possibly) or only one (simpler) ?

 - and in the latter case which to choose ? There can also be problems
   of proprietary rights ... I remember there was a PNG vs GIF issue for
   instance


DT> Currently within VO we routinely deal with both FITS and graphics 
DT> images of the same field.  To overlay the two we have to restort to 
DT> the SIA query response to pass WCS information for the graphics 
DT> formats

Would you mind to elaborate on this ? 

One of the reason I like to use FITS is that it contains information which 
is useful to science (WCS and data) instead of aesthetic one (colour). 
However there are cases (maybe because of contrived data rights in complex 
multi-consortia collaborations) one may want to overlay, say, a ds9 region 
file onto a JPEG image ... because, despite asking, one cannot get a FITS 
image.   

I've then tried (not being interested in the actual values of the science 
data on the z axis) using the FITS extension to GIMP to crop the JPEG 
image (which include also a plot axes and labels !), save it as FITS, and 
adding WCS keywords inputting manually the (known) field centre and hoping 
the pixel and image size were constant ...

----------------------------------------------------------------------------
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
----------------------------------------------------------------------------