[fitsbits] Start of the FITS Region File Public Comment Period
LC's NoSpam Newsreading account
nospam at lambrate.inaf.it
Mon Sep 8 07:56:52 EDT 2008
> Comments may be posted here on the FITSBITS mail exploder or the
> sci.astro.fits newsgroup.
1) General.
The document submitted to the registry is rather informal and/or
project specific. It could be accepted as supplementary information
demonstrating the usage, but a more formal description should be
submitted as primary document for the registry
2) rotation angle
The direction and units of the rotation angle are either defined
too late with respect to the first mention, or not defined (I cannot
find a spec whether the angle shall be in degrees or can be in any
units specified in TUNITn
3) definition of header keywords
This is one place whether more formality is necessary not only
as a matter of writing style. One should define ONLY the kwds
really specific of this convention, more than give a complete
header dump.
Most of the keywords not flagged "r" or "o" (hence mandatory)
looks to me NOT specific of this convention but just mandated
by the binary table FITS standard.
Also columns like e.g. ORIGIN DATE CREATOR seems for mere
documentation purposes (less clear for CONTENT which is not
a FITS standard reserved kwd) and I doubt that their presence
or absence might invalidate the semantics of the region files.
Similarly for CHECKSUM and DATASUM.
I presume that these kwds, as most of the other "optional"
ones (with the exception of the LONGSTRN family, which is
referring to a *DIFFERENT* registered convention) might be
required in the specific project implementation (Chandra ?)
but are completely irrelevant for a general purpose image file
Similarly the reference to the SOURCE and GRATING kwds appears
totally project specific and should disappear from a general
purpose document (saying instead that additional project specific
columns might be associated to a region ?)
The issue of "WCS tie to the REGION" which is marked as merely
recommended is instead worth of a detailed description.
The function of the MTYPE and MFORM mandatory kwds is not
explained.
4) redundant shapes
It looks to me that some shape families are redundant, aren't
they just a different name or a different way to refer to the
same thing. This seems to add confusion in a standard.
What's the difference between a diamond and rhombus (or their rot
variants) ? Just the name ?
What's the difference between a box and rectangle (or their rot
variantes) ? They can be mapped into each other.
Also the diamond and rhombus could probably be mapped to a 45 deg
rotated square box, can't they ?
5) definition of polygon
seems unclear. I presume m cannot be < 3 (should be said)
Also do I interpret correctly that, if one uses a column depth
such that e.g. the polygon with the largest number of sides is
an hexagon, a triangle will be defined with
X0 X1 X2 NaN NaN NaN OR X0 X1 X2 X0 X0 X0 ?
6) example (tab. 2)
the role of "components" is unclear to me
7) example file region.fits
I have displayed the file with ds9 and I'm rather puzzled. I see
three regions (a circle, a rotated ellipse and an UNROTATED
rectangle). I see that the image is non-zero only in 3 areas,
the inside of the circle and ellipse and a different ROTATED
rectangle partially overlapping the rectangular region.
It is not clear to me whether the image is intrinsically non-zero
only in such area already in the HDU, or whether I'm being shown
the image filtered through the region.
And in general (see next item) whether I should expect a
REGION extension always to be tied to a primary image in the same
FITS file, or whether a FITS file with no primary HDU and just a
REGION extension could be applied to potentially any image.
8) scope and name of the convention
The comments above (with the exception of 2/4/5/6) may partly go
beyond the formal comments of the sort "is the document complete
and understandable enough to be included in the registry", but
may reflect my unability to understand whether the convention
proposed is a general or project-specific one, and how should be
used.
Now formally "usage comments" are not relevant for inclusion in
the registry, so I try to separate such comments in the next point.
However, my impression is that the convention is rather
project-specific (or context-specific) more than general. Now
it is perfectly legitimate to include in the registry a
project-specific convention. However one should not give a false
impression that such a convention is general, so I suggest to
use a different name (e.g. "Chandra spatial region file" convention
or any other choice at discretion of the authors)
9) usage of FITS Region binary table
So far I have used only, though extensively, ds9 region files in
ASCII form. And perhaps mainly in a non-customary way (not for
"data filtering" but for "display purposes"). I've also used the
region concept outside of ds9 (e.g. in some applets talking with
a database server).
For these reasons I fail to see whether the proposed convention
is general enough to cope with my way of using regions.
- a first comment is that using a FITS file for a region file
with respect to an ASCII file may not always be convenient :
- an ASCII file can be easily created manually with an editor
- a FITS file is convenient when it is more compact than an
ASCII file, which occurs (only) when the size of the file
is dominated by the data and not by the overhead of header kwds
- a FITS extension with the region could be attached to a
specific image (or family of image extension) into a single
file
- an ASCII file can be loaded onto several images (is this
possible in ds9 with FITS region files without primary data
array ?)
- a second comment is that I tend to use much more region files
in celestial coordinates than in pixels. And to overlay such
files onto DIFFERENT images taking advantage of the WCS of
the images.
Will this be possible with the convention under discussion ?
Is it just a matter of saying MFORM1='RA,DEC' and having the
shape reference points in two columns named RA,DEC and all
other info in appropriate TUNITs ?
- the other comment is more a question of the sort : could my
current usage model (described below) be mapped into the
convention under discussion ?
What I often do is the following :
- I have a database with a primary table (say a list of
X-ray sources with id,ra,dec etc. ... let's call them
Xid,Xra,Xdec)
- the same database contains other tables (say a list of
optical sources with Oid,Ora,Odec, a list of radio
sources with Rid,RRa,Rdec, etc. etc.
- then I have a "glorified correlation table" tying all
this together. Such a table may look like
row n Xid=1 Oid=22 Rid=123 ...
row n+1 Xid=1 Oid=24 Rid=null ...
row n+2 Xid=2 Oid=77 Rid=456 ...
i.e. X-ray source 2 has a single "counterpart set" associated
to it, while X-ray source 1 has here two "counterpart sets".
A counterpart set may have non-null entries in some of the
member tables only
- finally I have some data products which may vary from X-ray
images to various optical thumbnails or radio mini-maps in the
surrounding of the X-ray target.
- what I want to do is to display one thumbnail image, and
seeing all counterpart sets overlaid onto it e.g.
- a single red thick circle at the X-ray position with radius
the X-ray error radius (this applies to the unique common
Xid, one for all counterpart sets of the same object)
- a green rotated ellipse for each extended radio source
(Rid not null and flagged as extended in its db table)
with ellipse parameters being radio observation parameters
stored in the table
- a green box for the pointlike radio sources, with sizes
given by ra, dec errors from the radio db table
- a blue circle for sources in a given optical catalogue,
with radius function of the magnitude in the I band
(smaller when fainter)
- a white circle for sources in an IR catalogue with
radius function of flux
etc. etc.
- and of course I would need to tell that a particular white
circle is associated to a particular blue circle or green
box (their sources belong to the same "counterpart set")
I originally used to generate ASCII region files with tags
and using ds9 "region groups" for this purpose.
Now that was a little clumsy. It did not allow for instance
easy reverse interaction (clicking on a region on the image
and telling which object it is, or clicking on an entry in
a tabular listing and hilighting the region on the image).
I currently use an applet as client of a server, and pass
"logical regions" along a socket using a custom protocol.
Note that I do not need instead any custom protocol for
the images. The applet receives the URL of a FITS image
file, opens a stream to it, and implements a minimal image
reader.
So you can see that I'd appreciate the existence of a
GENERAL FITS convention for region files. I'd welcomed such
a thing !
But I fail to see whether the convention under examination is
general enough (I suspect not).
Note that in my usage some aspects of the shapes (the kind of
shape itself, or display items like the colour and thickess)
are associated to a particular database table (i.e. band or
kind of source), and some other spatial parameters of the shape
CAN be NOT associated to an intrinsic spatial characteristics
but map some other source property (e.g. magnitude or flux).
Lucio Chiappetti
--
----------------------------------------------------------------------
nospam at mi.iasf.cnr.it 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.
More information about the fitsbits
mailing list