A Space & astronomy forum. SpaceBanter.com

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » SpaceBanter.com forum » Astronomy and Astrophysics » FITS
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

[fitsbits] Start of the FITS Region File Public Comment Period



 
 
Thread Tools Display Modes
  #1  
Old September 2nd 08, 06:55 PM posted to sci.astro.fits
William Pence[_2_]
external usenet poster
 
Posts: 44
Default [fitsbits] Start of the FITS Region File Public Comment Period

This is to announce the start of the 30-day Public Comment Period on
the FITS Region File convention which has been submitted for inclusion
in the Registry of FITS Conventions. This is the 12th in a growing
series of conventions submitted to the Registry which is maintained by
the IAU FITS Working Group.

Detailed information about this convention and a sample FITS file that
uses it are available for public review and comment from the FITS
registry web page at

http://fits.gsfc.nasa.gov/fits_registry.html

A FITS Region file is a FITS binary table that defines a spatial region
of a 2-dimensional image. The region file is often used to define an
area that is to be included or excluded from certain data processing
operations on the image. The region is specified as the union or
intersection of geometric shapes, such as 'circle' or 'rectangle'. The
REGION table is the FITS equivalent of the ASCII text region file that
has long been used by the ds9 image processing program and its
predecessor, SAOimage.

Comments may be posted here on the FITSBITS mail exploder or the
sci.astro.fits newsgroup. Minor typographical issues may be sent
directly to the authors of the convention.

Bill Pence
(on behalf of the IAU FITS Working Group)
--
__________________________________________________ __________________
Dr. William Pence
NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice)
Greenbelt MD 20771 +1-301-286-1684 (fax)
Ads
  #2  
Old September 3rd 08, 03:43 PM posted to sci.astro.fits
Craig Markwardt
external usenet poster
 
Posts: 232
Default [fitsbits] Start of the FITS Region File Public Comment Period



William Pence writes:

This is to announce the start of the 30-day Public Comment Period on
the FITS Region File convention which has been submitted for inclusion
in the Registry of FITS Conventions. This is the 12th in a growing
series of conventions submitted to the Registry which is maintained by
the IAU FITS Working Group.


Glad to see this is being documented!

Section 2
* "The names of the columns (TTYPEi) indicate the coordinate system in
use, in the usual way, and these coordinate names are to be identified
in the MFORM1 keyword (MFORM1='X,Y'); the mandatory keyword MTYPE1
provides a name for the coordinate pair."

Comment: I'm not sure what the "usual way" refers to. I think it
means, "using the CTYPEi coordinate labels of the source image."

I'm also unsure of what MFORM1 is meant to mean (this is a
Chandra-specific convention). Is 'X,Y' a placeholder or literal?
What are the allowed values of MTYPE1, or can it be anything?


* "The following columns are optional..."

Comment: Is there any convention for null values? It seems there
could be many 'unused' fields in a region file. For example, if there
is a region composed of the union of a circular and rectangle, the "R"
column will be used for the circle but not the rectangle. Also, the
rectangle will require X and Y to be 4-vectors, but the circle will
only use one X and Y value each. Are the extraneous values simply
ignored?


General comment: Region files are image and projection dependent. For
example, if someone lays down a circular region on a tangent plane
projection image in DS9, the same region will not be circular in
another projection. The situation is even more complicated for
non-circular regions. This means that region files are not globally
interchangeable, but rather specific to a particular analysis with a
known image and known projection. I think this should at least be
noted.

Craig Markwardt

--
--------------------------------------------------------------------------
Craig B. Markwardt, Ph.D. EMAIL:
--------------------------------------------------------------------------
  #3  
Old September 8th 08, 12:56 PM posted to sci.astro.fits
LC's NoSpam Newsreading account
external usenet poster
 
Posts: 3
Default [fitsbits] Start of the FITS Region File Public Comment Period

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

--
----------------------------------------------------------------------
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.
  #4  
Old September 8th 08, 05:22 PM posted to sci.astro.fits
Craig Markwardt
external usenet poster
 
Posts: 232
Default [fitsbits] Start of the FITS Region File Public Comment Period



William Pence writes:
A FITS Region file is a FITS binary table that defines a spatial region
of a 2-dimensional image. The region file is often used to define an
area that is to be included or excluded from certain data processing
operations on the image. The region is specified as the union or
intersection of geometric shapes, such as 'circle' or 'rectangle'. The
REGION table is the FITS equivalent of the ASCII text region file that
has long been used by the ds9 image processing program and its
predecessor, SAOimage.


Another comment:

The sample fits header lists TCRPXn, TCRVLn and TCDLTn as required
keywords for RA and DEC columns. Are these really required? Does
that mean that one cannot simple have a floating point (1E) column
describing the RA and Dec?

I note that X, Y and R are all in pixel space as well, which means
that one cannot define the position and radius in physical units?

Craig Markwardt

  #5  
Old September 9th 08, 03:04 AM posted to sci.astro.fits
Thierry Forveille[_3_]
external usenet poster
 
Posts: 3
Default [fitsbits] Start of the FITS Region File Public Comment Period

I agree with Lucio that this convention poses a policy/strategy
problem: all conventions we have examined to date either solved
a general problem for good (to quasi-unanimous satisfaction),
or (mostly) were clearly of historical or very specialized
interest. Here we instead have something which attacks
a problem of very broad interest for the first time, but
(quite naturally) has not yet converged to a generally
acceptable solution.

My strong preference would be for a small working group to start
work on a future standard for the general problem of specifying
regions within FITS (no, I am not volunteering ;-)), but I don't
know what to do with the existing convention in the mean time.
On the one hand such data files might be out in the wild and
documenting them can only be a good thing, but on the other
hand officializing the convention would spread usage of what
most likely will be an interim stage of the actual standard.

--
Thierry Forveille
Laboratoire d'Astrophysique (UMR 5571 CNRS)
Observatoire de Grenoble / U. Joseph Fourier
BP 53 F-38041 Grenoble Cedex 9 (France)

http://laog.obs.ujf-grenoble.fr/~forveille

Phone / Fax: +33 (0)4 76.51.42.15 / +33 (0)4 76.44.88.21


  #6  
Old September 23rd 08, 03:51 PM posted to sci.astro.fits
Boud Roukema
external usenet poster
 
Posts: 3
Default [fitsbits] Start of the FITS Region File Public Comment Period

hi fitsbits,

On Mon, 8 Sep 2008, LC's NoSpam Newsreading account wrote:

5) definition of polygon

seems unclear. I presume m cannot be 3 (should be said)


Digons (two-sided polygons) with a positive area exist on the 2-sphere
(and dihedrons exist on the 3-sphere). However, the proposal seems to deal
with the pixel space in the tangent plane, so m = 3 would be a
reasonable constraint to reduce the chance of accidental programming
errors.

http://en.wikipedia.org/wiki/Digon

cheers
boud
 




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
[fitsbits] Start of the FITS Euro3D Public Comment Period William Pence FITS 1 November 15th 07 12:25 PM
[fitsbits] Start of the CHECKSUM Public Comment Period William Pence FITS 0 May 31st 07 05:49 PM
[fitsbits] Start of the FITS 64-bit Integer "Public Comment Period" William Pence FITS 0 June 7th 05 10:15 PM
[fitsbits] Start of Public Comment Period on FITS Binary TableProposals William Pence FITS 2 October 19th 04 02:31 PM
[fitsbits] Start of the FITS MIME type Public Comment Period William Pence FITS 8 June 17th 04 06:08 AM


All times are GMT +1. The time now is 08:10 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright 2004-2020 SpaceBanter.com.
The comments are property of their posters.