From owner-fitsbits at marmoset.cv.nrao.edu Tue Dec 3 17:07:04 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id RAA00491; Tue, 3 Dec 1996 17:06:17 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id NAA00995; Tue, 3 Dec 1996 13:23:59 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id NAA27982 for ; Tue, 3 Dec 1996 13:23:58 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA29830; Tue, 3 Dec 96 13:23:55 EST To: fitsbits at fits.cv.nrao.edu Date: 3 Dec 1996 18:03:11 GMT From: Alain MAURY Message-Id: <581q0v$otb at rossini.obs-nice.fr> Organization: Observatoire de la Cote d 'Azur Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!hunter.premier.net!news.mathworks.com!howland.erols.net!math.ohio-state.edu!jussieu.fr!univ-angers.fr!ciril.fr!cnusc.fr!malibu.unice.fr!rossini.obs-nice.fr!news Subject: Visualisation thresholds KEYWORD in FITS ? Newsgroups: sci.astro.fits Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk We had a short discussion last week on the french speaking forum AUDE ( Association des Utilisateurs de Detecteurs Electroniques ), on why there was no keywords implemented in FITS that a display program could use to automatically recall the last visualisation thresholds used ( i.e. the "cuts" in Midas ). What would be the way to officially propose something like VISUHI and VISULO or whatever in the same order ? ( DISP_HI and DISP_LO ) Alain From owner-fitsbits at marmoset.cv.nrao.edu Fri Dec 6 12:42:56 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id MAA10239; Fri, 6 Dec 1996 12:42:10 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id XAA05697; Thu, 5 Dec 1996 23:46:52 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id XAA06538 for ; Thu, 5 Dec 1996 23:46:51 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA29167; Thu, 5 Dec 96 23:46:49 EST To: fitsbits at fits.cv.nrao.edu Date: 6 Dec 1996 04:24:02 GMT From: swalton at galileo.csun.edu (Stephen Walton) Message-Id: <588752$bv0 at csun1.csun.edu> Organization: Cal State Northridge, Dept. of Physics & Astronomy Path: solitaire.cv.nrao.edu!iraf!noao!ennfs.eas.asu.edu!cs.utexas.edu!math.ohio-state.edu!jussieu.fr!esiee.fr!news.sgi.com!newshub.sdsu.edu!newshub.csu.net!csun.edu!swalton Subject: WCS questions Newsgroups: sci.astro.fits,adass.iraf.misc Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk At the recent RISE 96 workshop at HAO in Boulder we discussed the possibility of adopting the standard in the solar community that the linear part of the WCS of a solar image result in (x, y) coordinates such that x**2 + y**2 = 1 at the solar limb, with (x=1, y=0) at the solar West limb and (x=0, y=1) at the solar North limb. This makes a good deal of sense from the perspective of solar astronomers, who often want to work with the radial distance from the center of the disk. At the workshop, I was asked to write a small sample program, probably in Fortran, to show how to add WCS information to a solar image whose geometry is given in the header in some other format. However, I am now unsure how to proceed. It is clear from the WCS draft spec that the units of (x,y) are to be degrees, which is far less convenient for solar (and I presume planetary) astronomers, for whom the center and the limbs of the object being observed are the logical reference points. On the other had, we also need the ability to map pixel coordinates to latitude and longitude, which is the intent of the AZP mapping. How much violence would it do to the WCS draft to have a new CTYPE pair, perhaps "PLAT----" and "PLON----" (Planetary latitude and longitude), for which the units of (x, y) would be normalized distance from object center rather than degrees? I'd prefer SLAT and SLON for "solar," of course, but these seem to have been reserved for other purposes :-) . A related comment, and the reason this is cross-posted, is which matrix to use, the PC matrix or the CD matrix. I ask because IRAF, at the moment, has the most complete and easy-to-use WCS implementation of which I'm aware, including automatic update of the WCS when images are magnified, rotated, or subsections copied, but is based on the CD matrix. This convenience within IRAF, and the recent WCS-based image matching tasks there, are, in my opinion, one of the major reasons for adopting a WCS convention. But I want to remain compatible with other software such as IDL, FITSIO, WCSLIB, and so on. It is also quite unclear from the WCS specification "how much" of the coordinate transformation should be in the PC matrix, and how much in the CDELT values. It seems as if the idea is that an image rotation, for example, would only require changing the PC matrix, but this should be made more precise in some manner. Sorry for the length of this. Thanks to those of you who've read to the end and care to comment. -- Stephen Walton, California State University, Northridge "Be careful what you wish for; you might get it." swalton at csun.edu From owner-fitsbits at marmoset.cv.nrao.edu Fri Dec 6 12:42:58 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id MAA10245; Fri, 6 Dec 1996 12:42:51 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id BAA05746; Fri, 6 Dec 1996 01:50:29 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id BAA06660 for ; Fri, 6 Dec 1996 01:50:28 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA03552; Fri, 6 Dec 96 01:50:25 EST To: fitsbits at fits.cv.nrao.edu Date: Wed, 4 Dec 1996 09:05:28 +0100 From: Lucio Chiappetti Message-Id: Organization: CNR - SIAM Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!goliath.montclair.edu!newsserver.jvnc.net!newsserver2.jvnc.net!howland.erols.net!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!newsserver.cilea.it!everest.siam.mi.cnr.it!poseidon.ifctr.mi.cnr.it!lucio References: <581q0v$otb at rossini.obs-nice.fr> Subject: Re: Visualisation thresholds KEYWORD in FITS ? Newsgroups: sci.astro.fits Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk On 3 Dec 1996, Alain MAURY wrote: > We had a short discussion last week on the french speaking forum AUDE ( > Association des Utilisateurs de Detecteurs Electroniques ), on why there was no > keywords implemented in FITS that a display program could use to automatically > recall the last visualisation thresholds used ( i.e. the "cuts" in Midas ). ...obviously because such a thing does not belong to the "archiving and *T*ransport" level for what FI*T*S is best suited. > What would be the way to officially propose something like > VISUHI and VISULO or whatever in the same order ? ( DISP_HI and DISP_LO ) ...nothing forbids to have "private" conventions about this, exactly like MIDAS does. ---------------------------------------------------------------------------- A member of G.ASS : Group for Astronomical Software Support ---------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR | Ma te' vugl' da' quost avis a ti' Orsign via Bassini 15 - I-20133 Milano | Buttet rabios intant te se' pisnign Internet: LUCIO at IFCTR.MI.CNR.IT | (Rabisch, II 46, 119-120) ---------------------------------------------------------------------------- For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html ---------------------------------------------------------------------------- From owner-fitsbits at marmoset.cv.nrao.edu Fri Dec 6 13:18:33 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id NAA10315; Fri, 6 Dec 1996 13:18:31 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id NAA10286; Fri, 6 Dec 1996 13:02:25 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with ESMTP id NAA07738 for ; Fri, 6 Dec 1996 13:02:24 -0500 (EST) Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109]) by cv3.cv.nrao.edu (8.8.3/8.8.0/CV-2.3) with SMTP id NAA00583 for ; Fri, 6 Dec 1996 13:02:20 -0500 (EST) Received: (from pence at localhost) by tetra.gsfc.nasa.gov (LHEA9504/950407.s1) id NAA06871; Fri, 6 Dec 1996 13:01:04 -0500 Date: Fri, 6 Dec 1996 13:01:04 -0500 From: William Pence Message-Id: <199612061801.NAA06871 at tetra.gsfc.nasa.gov> To: fitsbits at fits.cv.nrao.edu Subject: New CFITSIO Test Report Cc: white at adhoc.gsfc.nasa.gov, pence at tetra.gsfc.nasa.gov Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk Optimized Version of CFITSIO is Now Available --------------------------------------------- A new, much faster version of CFITSIO, the portable ANSI-C library for reading and writing FITS format data files, is now available. This new version (v1.11) achieves data throughputs of several megabytes per second on current generation workstations and, for example, can read or write a 1000 x 1000 integer*2 image or a binary table with 100,000 rows and 5 real*4 columns in under one second. The throughput is primarily limited by the I/O speed of the underlying magnetic disk which shows that there is no significant data throughput penalty for using FITS as a run-time data analysis format. A more detailed report on the current performance of CFITSIO is attached below for those that may be interested. Both the CFITSIO (ANSI C) and the older FITSIO (Fortran-77) software libraries may be obtained on the WWW from: http://heasarc.gsfc.nasa.gov/fitsio or by anonymous ftp from: legacy.gsfc.nasa.gov in the software/fitsio directory. ------------------------------------------------------------------------- William Pence High Energy Astrophysics Science Archive Research Center NASA/GSFC e-mail: pence at tetra.gsfc.nasa.gov phone: (301)286-4599 ------------------------------------------------------------------------- ------------------------------------------------------------------------- Performance Testing of CFITSIO December 1996 There has been considerable interest in the efficiency of using FITS as a data analysis format (as opposed to just a data archive format) therefore a series of tests have been performed on a variety of modern workstations to compare the speed of reading and writing FITS files with CFITSIO to that of reading and writing raw binary files using direct calls to the low-level fwrite and fread C library routines. The gcc compiler was used on the following test platforms: - a 133MHz pentium with 24MB RAM running Linux - a Silicon Graphics INDY workstation - a 300MHz Alpha OSF/1 workstation - a 167MHz SUN Ultra-2 workstation A test program called speed.c (included in the CFITSIO distribution) was written to measure the time required to first write then read back large (~25 MB) data files. Large files were used to minimize the affects of disk memory caching which can inflate the measured I/O speeds. The test results are summarized in the following table, where the throughput is give in MB/s followed by the percentage of CPU usage (i.e., CPU time / Elapsed time * 100) given in parentheses. There were sometimes large fluctuations in the measured throughput, especially for the raw binary files, so these figures represent an average of several runs of the program. CFITSIO Performance Benchmarks figures in MBytes/s (%CPU usage) 133-P5 Alpha SGI INDY SUN Ultra-2 System: Linux OSF/1 IRIX Solaris ----------------------------------------------- Raw Write 3.5(35) 4.5(20) 5.5(25) 5.5(15) Raw Read 2.4(35) 4.5(15) 5.5(25) 5.5(10) ----------------------------------------------- Write FITS Image 3.8(65) 4.5(55) 5.5(30) 5.5(15) Bintable 2.2(85) 3.5(70) 3.9(90) 4.5(85) ASCII Tbl .15(95) 0.8(90) 0.8(90) 1.0(90) ----------------------------------------------- Read FITS Image 3.0(55) 5.5(60) 5.0(20) 5.5(15) Bintable 2.3(80) 4.6(80) 3.4(70) 4.5(75) ASCII Tbl 1.4(90) 2.0(90) 1.4(85) 1.2(75) ----------------------------------------------- The following conclusions have been drawn from these figures: 1. When writing or reading FITS IMAGEs, the throughput of CFITSIO is virtually the same as that of the fast raw binary file I/O. Accessing FITS images requires relatively little CPU time (since the data are contiguous on disk) thus the throughput is mainly limited by the I/O speed of the magnetic disk. 2. CFITSIO's throughput for FITS binary tables is only slightly slower (about 20% less) than for FITS images. In this case the CPU usage is higher because the data in a FITS column are not stored consecutively on disk, and it requires more computation to jump to each successive row in the table. It appears that the CPU speed of the current generation of machines closely complements the disk access speed, so that neither factor is dominant in limiting the throughput to FITS binary tables. One would expect that in the future, as the CPU speeds continue to increase faster than disk access speeds, that the throughput of FITS tables will become more heavily disk I/O limited, just as in currently the case with FITS images. 3. The throughput for FITS ASCII tables is only about 1/3 as fast as for binary tables because of the extra CPU time required to format or parse the ASCII character fields. This, coupled with the fact that ASCII tables tend to be about twice as large as binary tables for the same information content means that the effective throughput for ASCII tables is about 5 times slower than for binary tables. Clearly, ASCII tables should not be used in applications which require maximum data I/O performance. 4. There is no apparent performance degradation on the machines that require byte swapping when accessing the FITS file (i.e., the Pentium and Alpha systems). This is not surprising because the CPU time to swap bytes is small compared to the disk I/O rates. Finally, a similar Fortran test program was written to compare the throughput of the FITSIO subroutine library (written in FORTRAN-77) with CFITSIO. As expected CFITSIO is currently faster, largely because it was designed using the experience gained from the older FITSIO code and to a lesser extent because it is sometimes easier and more efficient to perform low-level data manipulations in C rather than Fortran-77. These preliminary tests indicate that CFITSIO is about twice as fast as FITSIO when reading or writing FITS images and about 5 times faster when reading or writing FITS binary tables. Work is now in progress to improve the performance of FITSIO to bring it closer to that of CFITSIO. --------------------------- End of Report ---------------------------- From owner-fitsbits at marmoset.cv.nrao.edu Sun Dec 8 20:36:09 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id UAA12356; Sun, 8 Dec 1996 20:34:07 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id SAA12304; Sun, 8 Dec 1996 18:32:41 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id SAA12074 for ; Sun, 8 Dec 1996 18:32:39 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA03602; Sun, 8 Dec 96 18:32:37 EST To: fitsbits at fits.cv.nrao.edu Date: 8 Dec 96 01:15:40 GMT From: swalton at galileo.csun.edu (Stephen Walton) Message-Id: <32aa16bc.0 at newz.csun.edu> Organization: Cal State Northridge, Dept. of Physics & Astronomy Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!newshub.sdsu.edu!newshub.csu.net!newz.csun.edu!swalton Subject: WCS questions Newsgroups: sci.astro.fits,adass.iraf.misc Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk [Sorry if you see this twice; the first post didn't propagate very far, apparently.] At the recent RISE 96 workshop at HAO in Boulder we discussed the possibility of adopting the standard in the solar community that the linear part of the WCS of a solar image result in (x, y) coordinates such that x**2 + y**2 = 1 at the solar limb, with (x=1, y=0) at the solar West limb and (x=0, y=1) at the solar North limb. This makes a good deal of sense from the perspective of solar astronomers, who often want to work with the radial distance from the center of the disk. At the workshop, I was asked to write a small sample program, probably in Fortran, to show how to add WCS information to a solar image whose geometry is given in the header in some other format. However, I am now unsure how to proceed. It is clear from the WCS draft spec that the units of (x,y) are to be degrees, which is far less convenient for solar (and I presume planetary) astronomers, for whom the center and the limbs of the object being observed are the logical reference points. On the other had, we also need the ability to map pixel coordinates to latitude and longitude, which is the intent of the AZP mapping. How much violence would it do to the WCS draft to have a new CTYPE pair, perhaps "PLAT----" and "PLON----" (Planetary latitude and longitude), for which the units of (x, y) would be normalized distance from object center rather than degrees? I'd prefer SLAT and SLON for "solar," of course, but these seem to have been reserved for other purposes :-) . A related comment, and the reason this is cross-posted, is which matrix to use, the PC matrix or the CD matrix. I ask because IRAF, at the moment, has the most complete and easy-to-use WCS implementation of which I'm aware, including automatic update of the WCS when images are magnified, rotated, or subsections copied, but is based on the CD matrix. This convenience within IRAF, and the recent WCS-based image matching tasks there, are, in my opinion, one of the major reasons for adopting a WCS convention. But I want to remain compatible with other software such as IDL, FITSIO, WCSLIB, and so on. It is also quite unclear from the WCS specification "how much" of the coordinate transformation should be in the PC matrix, and how much in the CDELT values. It seems as if the idea is that an image rotation, for example, would only require changing the PC matrix, but this should be made more precise in some manner. Sorry for the length of this. Thanks to those of you who've read to the end and care to comment. -- Stephen Walton, California State University, Northridge "Be careful what you wish for; you might get it." swalton at csun.edu From owner-fitsbits at marmoset.cv.nrao.edu Mon Dec 9 09:41:12 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id JAA13353; Mon, 9 Dec 1996 09:41:01 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id HAA13263; Mon, 9 Dec 1996 07:05:21 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with ESMTP id HAA12908 for ; Mon, 9 Dec 1996 07:05:19 -0500 (EST) Received: from crux.rp.CSIRO.AU (crux.rp.CSIRO.AU [130.155.194.32]) by cv3.cv.nrao.edu (8.8.3/8.8.0/CV-2.3) with SMTP id HAA03435 for ; Mon, 9 Dec 1996 07:05:13 -0500 (EST) Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.rp.CSIRO.AU (8.6.10/8.6.10.A) with ESMTP id XAA13245; Mon, 9 Dec 1996 23:03:46 +1100 Message-Id: <199612091203.XAA13245 at crux.rp.CSIRO.AU> To: swalton at galileo.csun.edu (Stephen Walton) CC: fitsbits at fits.cv.nrao.edu Subject: Re: WCS questions In-reply-to: Your message of Fri 1996/12/06 04:24:02 GMT <588752$bv0 at csun1.csun.edu> Date: Mon, 09 Dec 1996 23:03:44 +1100 From: Mark Calabretta Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk On Fri 1996/12/06 04:24:02 GMT, Stephen Walton wrote in a message to: fitsbits at fits.cv.nrao.edu >How much violence would it do to the WCS draft to have a new CTYPE >pair, perhaps "PLAT----" and "PLON----" (Planetary latitude and >longitude), for which the units of (x, y) would be normalized distance >from object center rather than degrees? I'd prefer SLAT and SLON for >"solar," of course, but these seem to have been reserved for other >purposes :-) . You should be able to organize it so that the intermediate result obtained by applying the PC matrix (but not the CDELTn) give the required (x',y'). The CDELTn would then scale these to (x,y) in "degrees" as required by WCS. This could be made a defining characteristic of PLON/PLAT CTYPEs without needing to alter the current proposal. While WCSLIB does not provide the intermediate (x',y') directly it should be a simple matter to apply the linear transformation routines (linfwd(), and linrev()) to that end. >A related comment, and the reason this is cross-posted, is which matrix >to use, the PC matrix or the CD matrix. I ask because IRAF, at the >moment, has the most complete and easy-to-use WCS implementation of >which I'm aware, including automatic update of the WCS when images are >magnified, rotated, or subsections copied, but is based on the CD >matrix. This convenience within IRAF, and the recent WCS-based image >matching tasks there, are, in my opinion, one of the major reasons for >adopting a WCS convention. But I want to remain compatible with other >software such as IDL, FITSIO, WCSLIB, and so on. This is all historical. The CDELTn have to be retained for backwards compatibility with the widely used de facto AIPS WCS convention dating to the early 1980s. The original WCS document by Hanish and Wells proposed the CD matrix which would override the CDELTn if both were specified together. However, we were persuaded that the linear transformation matrix should be used in conjunction with the CDELTn. Since much STScI data had already been written with the CD convention we had to introduce a new name for the matrix elements, hence PC. This way we provided the means for IRAF to support both conventions for input (but hopefully only write PC headers). >It is also quite unclear from the WCS specification "how much" of the >coordinate transformation should be in the PC matrix, and how much in >the CDELT values. It seems as if the idea is that an image rotation, >for example, would only require changing the PC matrix, but this >should be made more precise in some manner. We couldn't get rid of the CDELTn because of backwards compatibility, as explained. To make the best of it, I view the PC matrix as providing dimensionless matrix elements which apply rotation and skew to the pixel coordinates producing transformed pixel coordinates, and the CDELTn as imparting a dimension to the result. However, we do not require any interpretation, the only requirement is that coefficients be chosen such that the specified algorithm produce correct results. Mark Calabretta ATNF From owner-fitsbits at marmoset.cv.nrao.edu Mon Dec 9 16:35:41 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id QAA13897; Mon, 9 Dec 1996 16:35:33 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id QAA13853; Mon, 9 Dec 1996 16:33:34 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id QAA14236 for ; Mon, 9 Dec 1996 16:33:33 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA13175; Mon, 9 Dec 96 16:33:31 EST To: fitsbits at fits.cv.nrao.edu Date: 9 Dec 1996 21:25:56 GMT From: thompson at orpheus.nascom.nasa.gov (William Thompson) Message-Id: <58i054$m13 at post.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!iraf!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson References: <32aa16bc.0 at newz.csun.edu> Subject: Re: WCS questions Newsgroups: sci.astro.fits,adass.iraf.misc Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk swalton at galileo.csun.edu (Stephen Walton) writes: >[Sorry if you see this twice; the first post didn't propagate >very far, apparently.] >At the recent RISE 96 workshop at HAO in Boulder we discussed the >possibility of adopting the standard in the solar community that the >linear part of the WCS of a solar image result in (x, y) coordinates >such that x**2 + y**2 = 1 at the solar limb, with (x=1, y=0) at the >solar West limb and (x=0, y=1) at the solar North limb. This makes a >good deal of sense from the perspective of solar astronomers, who often >want to work with the radial distance from the center of the disk. At >the workshop, I was asked to write a small sample program, probably in >Fortran, to show how to add WCS information to a solar image whose >geometry is given in the header in some other format. >How much violence would it do to the WCS draft to have a new CTYPE >pair, perhaps "PLAT----" and "PLON----" (Planetary latitude and >longitude), for which the units of (x, y) would be normalized distance >from object center rather than degrees? I'd prefer SLAT and SLON for >"solar," of course, but these seem to have been reserved for other >purposes :-) . Good luck. I'm personally not convinced that the WCS will ever be compatible with datasets that are not in some way related to the celestial sphere. It's just a completely different mindset. For example, the response from Mark Calabretta >You should be able to organize it so that the intermediate result obtained >by applying the PC matrix (but not the CDELTn) give the required (x',y'). >The CDELTn would then scale these to (x,y) in "degrees" as required by WCS. >This could be made a defining characteristic of PLON/PLAT CTYPEs without >needing to alter the current proposal. While WCSLIB does not provide the >intermediate (x',y') directly it should be a simple matter to apply the >linear transformation routines (linfwd(), and linrev()) to that end. still seems to me to be saying that the WCS folks expect to be able to project the data onto the sky. Otherwise, what is meant here by degrees? The idea of defining the coordinates to be in units of the solar radius seems like a good one, at least at first blush. There are some questions that do come to mind: 1. How do you define the solar limb? The solar radius differs depending on what wavelength one is observing in. The size of the sun in the EUV is significantly different from that in the visible. The most reasonable thing to do would appear to be to use the photospheric value, which is well known. On the other hand, some observers may prefer to determine the size of the sun using a limb fit. 2. If the official value for the (photospheric) solar radius changed, would that invalidate older FITS files? In spite of the above questions, there are some advantages to referencing all data to a normalized solar limb. It would allow for easier comparison of data taken at different points in the Earth's orbit, with different apparent solar sizes. Also, and probably more critical, it would simplify intercomparison of data taken from spacecraft not in Earth orbit with data taken from ground-based observatories. For example, the current Solar and Heliospheric Observatory (SOHO) spacecraft sits at the inner Langrange point, which is about 1% of the way towards the sun. This means that SOHO sees a 1% bigger sun than is seen from ground-based observatories. This difference can cause some confusion when pointing is discussed, and needs to be kept in mind in all data analysis. An alternative to expressing the data in solar radii is to use kilometers, or possibly megameters. I don't think I like the idea of using the terms PLAT and PLON to refer to a coordinate system which is not really a latitude/longitude system. I think those terms should be reserved for true latitude and longitude, e.g. S40WN9. In that case, the data should be expressed in degrees. There is, of course, the possibility of confusion between heliographic and Carrington coordinates. William Thompson From owner-fitsbits at marmoset.cv.nrao.edu Tue Dec 10 10:21:54 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id KAA16018; Tue, 10 Dec 1996 10:21:27 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id AAA14219; Tue, 10 Dec 1996 00:06:05 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with ESMTP id AAA14944 for ; Tue, 10 Dec 1996 00:06:03 -0500 (EST) Received: from crux.rp.CSIRO.AU (crux.rp.CSIRO.AU [130.155.194.32]) by cv3.cv.nrao.edu (8.8.3/8.8.0/CV-2.3) with SMTP id AAA16573 for ; Tue, 10 Dec 1996 00:06:00 -0500 (EST) Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.rp.CSIRO.AU (8.6.10/8.6.10.A) with ESMTP id QAA04872; Tue, 10 Dec 1996 16:04:27 +1100 Message-Id: <199612100504.QAA04872 at crux.rp.CSIRO.AU> To: thompson at orpheus.nascom.nasa.gov (William Thompson) CC: fitsbits at fits.cv.nrao.edu Subject: Re: WCS questions In-reply-to: Your message of Mon 1996/12/09 21:25:56 GMT <58i054$m13 at post.gsfc.nasa.gov> Date: Tue, 10 Dec 1996 16:04:25 +1100 From: Mark Calabretta Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk On Mon 1996/12/09 21:25:56 GMT, William Thompson wrote in a message to: fitsbits at fits.cv.nrao.edu >Good luck. I'm personally not convinced that the WCS will ever be compatible >with datasets that are not in some way related to the celestial sphere. It's >just a completely different mindset. For example, the response from Mark >Calabretta If you're saying that WCS doesn't account for spherical deformations such as oblateness then I agree, it wasn't designed for that purpose (although you could apply a first-order approximation for oblateness through the PC matrix). Otherwise, the difference between mapping a sphere from the inside (i.e. the celestial sphere) and mapping it from the outside (e.g. planetary cartography) is essentially just that of changing the sign of the native longitude. The following should work for a near-sided azimuthal perspective projection: 1) Choose the PC matrix to give (x',y') however you want it, with correction for rotation, skewness and unequal scaling. 2) Set the sign of CDELT1 to flip the coordinate system (seen from outside rather than inside) and also scale (x',y') to (x,y) in "degrees". 3) Use AZP with mu < -1 for a near-sided projection. If you want to transform pixel coordinates to (x',y') then just apply the PC matrix to (i,j). If you want (PLON,PLAT) then apply the whole WCS algorithm. >still seems to me to be saying that the WCS folks expect to be able to project >the data onto the sky. Otherwise, what is meant here by degrees? The scaling of (x,y) to "degrees" means that (PLON-PLON0, PLAT-PLAT0) is approximately equal to (x-x0, y-y0) for small deviations from the field centre (for default LONGPOLE). This AIPS WCS convention is retained for backwards compatibility. >The idea of defining the coordinates to be in units of the solar radius seems >like a good one, at least at first blush. There are some questions that do >come to mind: The main problem I see is that the limb in a near-sided perspective projection may fall short of a hemisphere. You might get into trouble comparing (x',y') coordinates of two AZP projections with differing mu if mu is not large enough (e.g. spacecraft-generated images). In this case you really would have to compare planetary lng/lat. Mark Calabretta ATNF From owner-fitsbits at marmoset.cv.nrao.edu Tue Dec 10 13:46:03 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id NAA16156; Tue, 10 Dec 1996 13:46:01 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id MAA16071; Tue, 10 Dec 1996 12:29:08 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with ESMTP id MAA15925 for ; Tue, 10 Dec 1996 12:29:06 -0500 (EST) Received: from web3.hq.eso.org (web3.hq.eso.org [134.171.7.4]) by cv3.cv.nrao.edu (8.8.3/8.8.0/CV-2.3) with ESMTP id MAA23086 for ; Tue, 10 Dec 1996 12:29:00 -0500 (EST) Message-Id: <199612101725.SAB20173 at ns2.hq.eso.org> To: fitsbits at fits.cv.nrao.edu cc: psb at ast.cam.ac.uk Subject: Re: DATE-OBS and the millennium; the proposal. Date: Tue, 10 Dec 1996 18:25:11 +0100 From: Preben Grosbol Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk It is a pleasure for me to announce that the European FITS Committee has voted unanimously in support of the following motion: "The European FITS Committee endorses the proposal for 'Precise re-definition of DATE-OBS Keyword' as described in the 'sci.astro.fits' News Groups posting: 'DATE-OBS and the millennium; the proposal.' of 1996-11-19T16:56:22+0000 by Peter Bunclark, RGO (Article: 1541 of sci.astro.fits) with the following comments: The European FITS Committee suggests 1) that UTC is made mandatory for all DATExxxx keywords including DATE-OBS, and 2) that the Appendix should not be a part of the proposal but only appended for information. It is recommended that the proposal is forwarded to the IAU FITS Working Group for final approval. It is recognized that minor technical changes and clarifications may be implemented in this process. This endorsement will first be effective when the North American FITS Group within the AAS WGAS and the Japanese FITS Group adopt similar resolution in support of this proposal." Best regards, Preben Grosbol, European FITS Committee, Chair. From owner-fitsbits at marmoset.cv.nrao.edu Tue Dec 10 18:03:46 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id SAA16582; Tue, 10 Dec 1996 18:03:36 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id SAA16569; Tue, 10 Dec 1996 18:02:28 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id SAA01294 for ; Tue, 10 Dec 1996 18:02:27 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA14334; Tue, 10 Dec 96 18:02:24 EST To: fitsbits at fits.cv.nrao.edu Date: 10 Dec 1996 22:45:08 GMT From: thompson at orpheus.nascom.nasa.gov (William Thompson) Message-Id: <58kp5k$cp2 at post.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!tezcat!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!newsfeed.internetmci.com!news.msfc.nasa.gov!centauri.hq.nasa.gov!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson References: <199612100504.QAA04872 at crux.rp.CSIRO.AU> Subject: Re: WCS questions Newsgroups: sci.astro.fits Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk Mark Calabretta writes: >On Mon 1996/12/09 21:25:56 GMT, William Thompson wrote >in a message to: fitsbits at fits.cv.nrao.edu >>Good luck. I'm personally not convinced that the WCS will ever be compatible >>with datasets that are not in some way related to the celestial sphere. It's >>just a completely different mindset. For example, the response from Mark >>Calabretta >If you're saying that WCS doesn't account for spherical deformations such as >oblateness then I agree, it wasn't designed for that purpose (although you >could apply a first-order approximation for oblateness through the PC matrix). >Otherwise, the difference between mapping a sphere from the inside (i.e. the >celestial sphere) and mapping it from the outside (e.g. planetary cartography) >is essentially just that of changing the sign of the native longitude. Now I understand what you're getting at. You expect to be able to map data to the solar surface. Many solar features can be expressed as having a latitude and longitude. For example, an active region could be said to be at position N30, W29 on a given date. Of course, the longitude must be adjusted with time to account for the (differential) solar rotation. The trouble is that the sun is not a simple sphere like a planetary body. It's a three dimensional object. Chromospheric structures such as prominences extend several tens of thousands of kilometers above the surface, and chromospheric loops extend well beyond that. The corona can be observed out to 30 solar radii. One has to be able to express data in a system which is valid both for pixels which are on the disk and for pixels which are above the limb. It's clear from Stephen Walton's original message that it's this kind of data which he was considering. When one is expressing data in solar latitude and longitude, such as a synoptic map, it's clear that the data must be expressed in degrees. The rationale for using degrees for solar images, however, is not so well established. In some sense we do something similar in that many data are expressed in arcseconds from disk center, with the "up" axis aligned with the solar northern rotational axis. That may not be an ideal solution, in that the apparent solar radius changes with the seasons, and is different for some spacecraft, such as SOHO. The scheme that Stephen Walton described, using coordinates normalized to the solar radius, would remove this dependence from the data. Another way to express the data would be in units of physical distance, rather than in arcseconds. The solar radius is 6.96x10^5 km, or 696 Mm. Expressing image pixels in units relative to the solar radius is really expressing it as a distance. Obviously, some other names need to be used for this Cartesian (X,Y) system rather than PLAT and PLON. It's evident that those names must be reserved for data which are actually in latitude and longitude coordinates. Let me throw out a suggestion here for debate. Suppose that we defined the following two CTYPEs as CARN---- Cartesian north, measured from disk center towards the solar north rotational axis, and perpendicular to the line of sight to the observer, in units of the solar photospheric radius. CARW---- Cartesian west, measured from disk center towards the west limb, in units of the solar photospheric radius, and at right angles to CARN----, such that CARW----, CARN----, and the line of sight to the observer form a right-handed coordinate system. William Thompson From owner-fitsbits at marmoset.cv.nrao.edu Wed Dec 11 10:10:08 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id KAA19399; Wed, 11 Dec 1996 10:09:24 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id IAA19187; Wed, 11 Dec 1996 08:59:21 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with ESMTP id IAA02680 for ; Wed, 11 Dec 1996 08:59:20 -0500 (EST) Received: from crux.rp.CSIRO.AU (crux.rp.CSIRO.AU [130.155.194.32]) by cv3.cv.nrao.edu (8.8.3/8.8.0/CV-2.3) with SMTP id IAA05687 for ; Wed, 11 Dec 1996 08:59:16 -0500 (EST) Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.rp.CSIRO.AU (8.6.10/8.6.10.A) with ESMTP id AAA14853; Thu, 12 Dec 1996 00:57:42 +1100 Message-Id: <199612111357.AAA14853 at crux.rp.CSIRO.AU> To: thompson at orpheus.nascom.nasa.gov (William Thompson) CC: fitsbits at fits.cv.nrao.edu Subject: Re: WCS questions In-reply-to: Your message of Tue 1996/12/10 22:45:08 GMT <58kp5k$cp2 at post.gsfc.nasa.gov> Date: Thu, 12 Dec 1996 00:57:40 +1100 From: Mark Calabretta Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk On Tue 1996/12/10 22:45:08 GMT, William Thompson wrote in a message to: fitsbits at fits.cv.nrao.edu >The trouble is that the sun is not a simple sphere like a planetary body. It's >a three dimensional object. Chromospheric structures such as prominences >extend several tens of thousands of kilometers above the surface, and >chromospheric loops extend well beyond that. The corona can be observed out to >30 solar radii. One has to be able to express data in a system which is valid >both for pixels which are on the disk and for pixels which are above the limb. Such a mapping from 2-D pixel coordinates (i,j) to 3-D spherical coordinates (r,phi,theta) is under-determined for a single image, although a sequence of such images taken at different viewing angles can be assembled via tomographic techniques into a data-cube representation of a 3-D object. See for example http://www.atnf.csiro.au/people/toosterl/jupiter/. However, such 3-D images do not require WCS since the transformation from (i,j,k) -> (x,y,z) -> (r,phi,theta) does not involve a spherical projection. In any case, there's still nothing to prevent using WCS for heliographic coordinates of the solar surface in a 2-D map even if it extends past the solar limb. The heliographic lng/lat of a feature beyond the limb would be undefined, which I believe makes sense. However, such features would still have meaningful (x',y') coordinates. >It's clear from Stephen Walton's original message that it's this kind of data >which he was considering. It wasn't clear to me. >Another way to express the data would be in units of physical distance, rather >than in arcseconds. The solar radius is 6.96x10^5 km, or 696 Mm. Expressing >image pixels in units relative to the solar radius is really expressing it as a >distance. How do you interpret this "distance" if you don't know the angle between the corresponding position vector and the plane of projection? The best you can say about the projected distance is that it is less than the true distance from the solar centre so I think it could be misleading to assign it units of metres. Also, since the sun's rotational axis is not perpendicular to the ecliptic the solar poles do not usually lie on the solar limb which means that not even they will have fixed coordinates in this Cartesian system. Mark Calabretta ATNF From owner-fitsbits at marmoset.cv.nrao.edu Thu Dec 12 16:07:57 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id QAA03333; Thu, 12 Dec 1996 16:07:27 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id UAA21576; Wed, 11 Dec 1996 20:09:27 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id UAA03722 for ; Wed, 11 Dec 1996 20:09:26 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA09484; Wed, 11 Dec 96 20:09:24 EST To: fitsbits at fits.cv.nrao.edu Date: 12 Dec 1996 00:15:16 GMT From: thompson at orpheus.nascom.nasa.gov (William Thompson) Message-Id: <58niqk$2uh at post.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!op.net!www.nntp.primenet.com!nntp.primenet.com!news.sgi.com!news.msfc.nasa.gov!centauri.hq.nasa.gov!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson References: <199612111357.AAA14853 at crux.rp.CSIRO.AU> Subject: Re: WCS questions Newsgroups: sci.astro.fits Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk Mark Calabretta writes: >On Tue 1996/12/10 22:45:08 GMT, William Thompson wrote >in a message to: fitsbits at fits.cv.nrao.edu >>The trouble is that the sun is not a simple sphere like a planetary body. It's >>a three dimensional object. Chromospheric structures such as prominences >>extend several tens of thousands of kilometers above the surface, and >>chromospheric loops extend well beyond that. The corona can be observed out to >>30 solar radii. One has to be able to express data in a system which is valid >>both for pixels which are on the disk and for pixels which are above the limb. >Such a mapping from 2-D pixel coordinates (i,j) to 3-D spherical coordinates >(r,phi,theta) is under-determined for a single image, ... Right, which is why it is incorrect to force solar data to be expressed in a spherical coordinate system. >In any case, there's still nothing to prevent using WCS for heliographic >coordinates of the solar surface in a 2-D map even if it extends past the >solar limb. The heliographic lng/lat of a feature beyond the limb would be >undefined, which I believe makes sense. ... Unless of course that's the data you're interested in. >... However, such features would still >have meaningful (x',y') coordinates. What if all the pixels in the image were off the limb? If I'm understanding things correctly, there would be no way to express the physical coordinates of that data in the WCS system. What we need to be able to do in solar physics is to express the data in a standardized way. Because the data can be both on and off the limb, this standardized coordinate system cannot be based on solar latitude and longitude. Of course, a parallel coordinate system for data such as synoptic maps which is organized by latitude and longitude makes sense, but I believe that's already accommodated within the WCS system. It's common in solar physics to refer to coordinates as a pair of distances from solar disk center, with one axis aligned with solar north, and the other perpendicular to that. If we can agree on a meaningful way to embed those kind of data into the WCS system, then we have something. >>Another way to express the data would be in units of physical distance, rather >>than in arcseconds. The solar radius is 6.96x10^5 km, or 696 Mm. Expressing >>image pixels in units relative to the solar radius is really expressing it as a >>distance. >How do you interpret this "distance" if you don't know the angle between the >corresponding position vector and the plane of projection? The best you can >say about the projected distance is that it is less than the true distance >from the solar centre so I think it could be misleading to assign it units of >metres. Obviously, it is a projected distance rather than a true distance from the center of the sun. That's immaterial. It still gives the correct X,Y positions in an X,Y,Z coordinate system. From a scientific viewpoint, the physical size in kilometers is the most relevant way to express the data. One wants to measure the height of a spicule, or the dimensions of a coronal loop. >Also, since the sun's rotational axis is not perpendicular to the ecliptic the >solar poles do not usually lie on the solar limb which means that not even >they will have fixed coordinates in this Cartesian system. You are absolutely correct that additional information is needed. Specifically, one needs the solar B angle, which is the tilt of the solar rotational axis out of the projected plane. For spacecraft such as SOHO which are not in low earth orbit this can be different from the same value as observed from earth. It's possible that we're talking at cross purposes. What I'm saying is that the most natural coordinate system for solar images is a projected one. It should be straightforward to determine the spherical coordinates of a pixel which is on the disk, but the coordinate system itself cannot be directly tied to those spherical coordinates because of the need to also meaningfully describe off-limb data. I don't see any reason why we couldn't adopt a convention where solar data were described in a coordinate system normalized to the solar photospheric radius, or one using kilometers. William Thompson From owner-fitsbits at marmoset.cv.nrao.edu Sat Dec 14 13:14:44 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id NAA04285; Sat, 14 Dec 1996 13:14:21 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id DAA03813; Sat, 14 Dec 1996 03:10:56 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id DAA08850 for ; Sat, 14 Dec 1996 03:10:54 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA07306; Sat, 14 Dec 96 03:10:50 EST To: fitsbits at fits.cv.nrao.edu Date: Fri, 13 Dec 1996 10:01:33 -0400 From: allen at eta.pha.jhu.edu (Dr. Marsha Allen) Message-Id: Organization: Dept. of Physics, Johns Hopkins University Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!news1.exit109.com!www.nntp.primenet.com!nntp.primenet.com!mindspring!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!cpk-news-feed4.bbnplanet.com!europa.chnt.gtegsc.com!boingo.amil.jhu.edu!news.jhu.edu!rocky.pha.jhu.edu!user Subject: A question about projections Newsgroups: sci.astro.fits Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk Greetings, I have been puzzling about astronomical projections for a while. Our group is working on data from the MSX satellite and we are going to be making FITS files that will (eventually) be available to the astronomical community. They are two-dimensional images with a reference point (ra0,dec0) not necessarily in the center of the image. The native coordinate system is rotated with respect to the ra/dec system by angle rot0. Also, all the pixels are the same size in the native system (in degrees/pixel). We want to make the headers as clear as possible to outside users, but I've been getting a little confused about just what needs to be in them. I would greatly appreciate some advice or some pointer to appropriate sources. Thanks, Marsha Allen From owner-fitsbits at marmoset.cv.nrao.edu Sun Dec 15 23:51:22 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) id XAA05540; Sun, 15 Dec 1996 23:51:00 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision:$) with ESMTP id XAA05527; Sun, 15 Dec 1996 23:49:29 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with ESMTP id XAA00674 for ; Sun, 15 Dec 1996 23:49:27 -0500 (EST) Received: from crux.rp.CSIRO.AU (crux.rp.CSIRO.AU [130.155.194.32]) by cv3.cv.nrao.edu (8.8.3/8.8.0/CV-2.3) with SMTP id XAA09576 for ; Sun, 15 Dec 1996 23:49:22 -0500 (EST) Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.rp.CSIRO.AU (8.6.10/8.6.10.A) with ESMTP id PAA19077; Mon, 16 Dec 1996 15:46:49 +1100 Message-Id: <199612160446.PAA19077 at crux.rp.CSIRO.AU> To: thompson at orpheus.nascom.nasa.gov (William Thompson) CC: swalton at galileo.csun.edu CC: fitsbits at fits.cv.nrao.edu Subject: Re: WCS questions In-reply-to: Your message of Thu 1996/12/12 00:15:16 GMT <58niqk$2uh at post.gsfc.nasa.gov> Date: Mon, 16 Dec 1996 15:46:48 +1100 From: Mark Calabretta Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk On Thu 1996/12/12 00:15:16 GMT, William Thompson wrote in a message to: fitsbits at fits.cv.nrao.edu >Right, which is why it is incorrect to force solar data to be expressed in a >spherical coordinate system. We appear to going around in circles here. We have a 2-D spherical surface embedded in a 3-D space seen in projection on the celestial sphere. We want to coordinatise points on the surface in one way and points in the surrounding space in another way. All I am saying is that, contrary to your original statement, and I believe answering Steven Walton's original query, WCS provides the tools to do this. If you have to have Cartesian coordinates with units of metres rather than solar radii, then use secondary axis descriptors. I'm not saying that you won't need to define a simple convention tied to the CTYPEn (e.g. PLON/PLAT) which describes this system to the extent that points outside the limb are valid and what their interpretation is to be. Mark Calabretta ATNF From owner-fitsbits at marmoset.cv.nrao.edu Tue Dec 17 15:08:41 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) id PAA08748; Tue, 17 Dec 1996 15:08:32 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) with ESMTP id PAA08733; Tue, 17 Dec 1996 15:02:32 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id PAA18236 for ; Tue, 17 Dec 1996 15:02:31 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA22987; Tue, 17 Dec 96 15:02:29 EST To: fitsbits at fits.cv.nrao.edu Date: 17 Dec 96 19:47:32 GMT From: swalton at galileo.csun.edu (Stephen Walton) Message-Id: <32b6f8d4.0 at newz.csun.edu> Organization: Cal State Northridge, Dept. of Physics & Astronomy Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!newsgate.nytimes.com!hammer.uoregon.edu!arclight.uoregon.edu!enews.sgi.com!news.sgi.com!newshub.sdsu.edu!newshub.csu.net!newz.csun.edu!swalton References: <199612111357.AAA14853 at crux.rp.CSIRO.AU> <58niqk$2uh at post.gsfc.nasa.gov> Subject: Re: WCS questions Newsgroups: sci.astro.fits Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk It is time for me to chime in again, now that finals are over. Thanks to William Thompson and Mark Calabretta for discussions that clarified many of the issues in my absence. I've trimmed the quotes quite a bit, I hope enough to provide context without misquoting anyone. In article <58niqk$2uh at post.gsfc.nasa.gov>, William Thompson wrote: >Mark Calabretta writes: > >>On Tue 1996/12/10 22:45:08 GMT, William Thompson wrote >>in a message to: fitsbits at fits.cv.nrao.edu > >Right, which is why it is incorrect to force solar data to be expressed in a >spherical coordinate system. My original goal was to explore a format for the header in which the linear part would translate to normalized distance from solar disk center along the north and west axes, and the non-linear part would allow one to take the additional step to solar longitude and latitude for features on the disk. In one of Mark's earlier posts, he pointed out that the PC matrix could define the former and the CDELT, CRVAL, and CTYPE values the latter. This sounds good to me. Mark also points out that the AZP projection is the appropriate one to describe the sun, though the negative value for "mu" (defined as the number of radii from the surface of the sphere to the viewer) for a sphere seen from the outside is an important clarification which is not at all obvious from the WCS draft, at least not to me. >>>Another way to express the data would be in units of physical distance, rather >>>than in arcseconds. > >>How do you interpret this "distance" if you don't know the angle between the >>corresponding position vector and the plane of projection? > >Obviously, it is a projected distance rather than a true distance from the >center of the sun. That's immaterial. I think distances in kilometers is an interesting alternative. It gets around the fact that the size of the solar limb depends on the wavelength of observation, and would only depend on the observer's distance to the Sun, which is known very accurately. The CDELT values would then be equal to (x degrees/solar radius), where x is the angle between the observer's tangent to the solar limb and the line from the solar disk center to the same point. >You are absolutely correct that additional information is needed. >Specifically, one needs the solar B angle, which is the tilt of the solar >rotational axis out of the projected plane. But if I read the WCS spec correctly, the values of CRVAL1 and CRVAL2 would simply be the values of latitude and longitude at the pixels given by CRPIX1 and CRPIX2. However, this raises another problem: for the linear WCS I propose, CRVAL1 and CRVAL2 would both be zero. It may still be that two WCS's in the same header would be needed. I'd like to address a couple of more points, more or less from memory, rasised in earlier posts. In a full-disk solar image, the position of the limb can be determined very accurately. An initial guess accurate to a fraction of a pixel can be found by fitting an ellipse to limb points found by looking for zero crossings of the Laplacian of the image, and can then be refined by the technique in Toner and Jefferies 1993, Ap.J. 415, 852. This measurement is at least as accurate as assumed sizes of the solar disk in kilometers or arc seconds from ephemerides. For data taken of a small portion of the disk, or of sky points only, the WCS would depend on the accuracy of one's offset pointing, but this is already the case. Mark made the point that the original goal of my proposal was not clear. It is to make easy intercomparisons between data from different sources. In particular, Lindsey Davis of the IRAF group has worked hard on an image matching package which, among many other things, will do the geometric rectifications required so that two images have matched WCS's. This is something I would find extremely useful, and I assume others would as well. To use this would, though, require coding in the CD matrix formalism, which I'd assume would be back-supported by any software developed once the present WCS draft is made final. Steve Walton ------------ Stephen Walton, California State University, Northridge "Be careful what you wish for; you might get it." swalton at csun.edu From owner-fitsbits at marmoset.cv.nrao.edu Tue Dec 17 15:50:05 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) id PAA08802; Tue, 17 Dec 1996 15:50:03 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) with ESMTP id PAA08776; Tue, 17 Dec 1996 15:44:31 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id PAA18621 for ; Tue, 17 Dec 1996 15:44:30 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA25170; Tue, 17 Dec 96 15:44:27 EST To: fitsbits at fits.cv.nrao.edu Date: 17 Dec 1996 20:25:27 GMT From: thompson at orpheus.nascom.nasa.gov (William Thompson) Message-Id: <596vjn$iq5 at post.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!op.net!www.nntp.primenet.com!nntp.primenet.com!enews.sgi.com!news.sgi.com!news.msfc.nasa.gov!centauri.hq.nasa.gov!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson References: <199612160446.PAA19077 at crux.rp.CSIRO.AU> Subject: Re: WCS questions Newsgroups: sci.astro.fits Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk Mark Calabretta writes: >On Thu 1996/12/12 00:15:16 GMT, William Thompson wrote >in a message to: fitsbits at fits.cv.nrao.edu >>Right, which is why it is incorrect to force solar data to be expressed in a >>spherical coordinate system. >We appear to going around in circles here. We have a 2-D spherical surface >embedded in a 3-D space seen in projection on the celestial sphere. We want >to coordinatise points on the surface in one way and points in the surrounding >space in another way. As a solar astronomer, I disagree with this. First of all, I don't believe that the characterization of the Sun as a 2-D spherical surface is entirely accurate. Nor do I think that it's the most important way to characterize solar data. There are two reasons for this: 1. As I have pointed out before, the Sun is a three dimensional object, with an atmosphere extending well beyond the solar photospheric "surface". You suggest referencing pixels on the disk in one way, and pixels off the disk in another way. However, these are not really separate and distinct data sets--solar features blend smoothly from one regime to the other. Often one wants to compare data which is on the disk to data which is off the disk. Also, the concept of a solar surface is a somewhat fuzzy concept. The apparent size of the Sun is different depending on what wavelengths one is looking at. If one is looking in visible light, then one is looking at the photosphere, which is what most people think of as the solar surface. However, at certain wavelengths such as hydrogen H-alpha line, one is looking at the chromosphere, which is above the photosphere. Even when discounting obviously elevated features such as prominences, the apparent size of the Sun is different. This is especially true in other wavelengths in the UV and EUV where one the solar radius is driven by the transition region and lower corona. 2. Although it is useful to convert pixels in image space to solar latitude and longitude, this is not the most accurate way to express the pointing of the data. In order to make the conversion, one must know exactly where the center of the Sun is in your field of view. This is not always a trivial task--many data come with only a rough determination of where disk center is. Inaccuracies in the absolute pointing will lead to ever increasing errors in the latitude/longitude calculation as one approaches the limb. Data given in a projected coordinate system as an X,Y pair of distances from disk center, either angular or kilometers, also have a built-in uncertainty. However, this uncertainty is easy to characterize, and is constant for all pixels. At this point, one might ask what reasons one might have for converting from projected coordinates to spherical coordinates. The following come to mind: a. To generate synoptic maps of an entire solar rotation. b. To produce "butterfly" maps showing the evolution of the distribution of features such as sunspots over the 22 year solar cycle. c. To correct for solar differential rotation when comparing two images taken at different times, or to project where a given feature will appear at the time an observation will be made. In the case of comparing two images, a conversion will be made from projected to d. To explore center-to-limb variations, such as limb darkening. Note that there are at least three different coordinate systems being discussed here. Items a, b, and c above all agree on the definition of latitude, while items a and c use different definitions of longitude. In fact, the latitude and longitude used in synoptic maps isn't really a spherical coordinate system, because the differential rotation of the sun has to be taken into account. Item d essentially uses a completely different coordinate system with the "pole" pointing straight at the observer. (Note by the way that Steven Walton's original query was primarily addressing item d. To that end, he suggested a projected coordinate system similar to the one I described in an earlier message. The only difference was the normalization to the solar (presumably photospheric) radius.) >All I am saying is that, contrary to your original >statement, and I believe answering Steven Walton's original query, WCS >provides the tools to do this. If you have to have Cartesian coordinates >with units of metres rather than solar radii, then use secondary axis >descriptors. >I'm not saying that you won't need to define a simple convention tied to the >CTYPEn (e.g. PLON/PLAT) which describes this system to the extent that points >outside the limb are valid and what their interpretation is to be. My understanding of the purpose of the World Coordinate System is to assist in the comparison of data taken at different sites and with different instruments. >From the standpoint of solar physics, we must ask ourselves what is the best way to characterize our data to assist in this goal. I agree with your earlier statement that the Sun is a three dimensional object seen projected onto the celestial sphere. To my mind, this is the most important starting point. Also, I think we can all agree that the ability to convert image pixel data to traditional celestial coordinates such as RA and DEC is rarely of any importance. To my mind, unless the data has already been projected into spherical coordinates, solar latitude and longitude has to be considered a secondary To a large respect, this is how most solar data is expressed, except that data tends to be expressed in arcseconds or arcminutes rather than degress. Also, generally speaking, the exact type of projection (e.g. TAN or ARC) has not always necessarily been made clear, because one is generally operating at small angles. Thus, the coordinate system that I argue makes the most sense for solar observations has the following properties: 1. The Sun would be at the equivalent of "RA" and "DEC" both being zero. 2. The Sun, the zenith, and the projection of the north solar rotational pole would all fall on the same great circle. Observed locally, this would be equivalent to the coordinate system I described before, with North being "up" and the west limb being to the "right". The contribution made by using the WCS formalism for this, besides standardization, would be in regularizing the description of exactly what projection system is used. I can imagine, as resolutions improve, that this could be a benefit in future solar data. Of course, the four letter designation that would appear in the CTYPE keyword needs to be established. Besides the above positions, the following information is also necessary when analyzing solar data. * The distance from the observer to the Sun. (If the data were expressed in kilometers, or in units relative to the solar photospheric radius, then there would be no need for this parameter. For groundbased and low-Earth-orbit satellites, the distance from the Earth to the Sun would suffice. Conversely, this could be expressed as the apparent size of the solar photospheric disk. * The tilt of the solar north axis towards or away from the observer, known as the B angle. * For observations made from vantage points other than the Earth's environs, one needs to know the latitude and longitude of the observers subsolar point, where the subsolar point of the Earth is at longitude zero. We need to standardize on what keywords will be used for these parameters. William Thompson P.S. I've looked at the most recent version of the WCS paper, and don't see the terms PLAT/PLON described anywhere. I can only imagine that they describe the normal kind of latitude and longitude when applied to the Earth. Where are these described and reserved? What about SLAT and SLON which was also described as being reserved in a previous message? From owner-fitsbits at marmoset.cv.nrao.edu Wed Dec 18 09:56:09 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) id JAA10562; Wed, 18 Dec 1996 09:55:32 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) with ESMTP id SAA08968; Tue, 17 Dec 1996 18:01:15 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with ESMTP id SAA19950 for ; Tue, 17 Dec 1996 18:01:13 -0500 (EST) Received: from crux.rp.CSIRO.AU (crux.rp.CSIRO.AU [130.155.194.32]) by cv3.cv.nrao.edu (8.8.3/8.8.0/CV-2.3) with SMTP id SAA08211 for ; Tue, 17 Dec 1996 18:01:09 -0500 (EST) Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.rp.CSIRO.AU (8.6.10/8.6.10.A) with ESMTP id JAA02600; Wed, 18 Dec 1996 09:59:45 +1100 Message-Id: <199612172259.JAA02600 at crux.rp.CSIRO.AU> To: swalton at galileo.csun.edu (Stephen Walton) CC: fitsbits at fits.cv.nrao.edu Subject: Re: WCS questions In-reply-to: Your message of Tue 1996/12/17 19:47:32 GMT <32b6f8d4.0 at newz.csun.edu> Date: Wed, 18 Dec 1996 09:59:43 +1100 From: Mark Calabretta Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk On Tue 1996/12/17 19:47:32 GMT, Stephen Walton wrote in a message to: fitsbits at fits.cv.nrao.edu >But if I read the WCS spec correctly, the values of CRVAL1 and CRVAL2 >would simply be the values of latitude and longitude at the pixels given >by CRPIX1 and CRPIX2. However, this raises another problem: for the >linear WCS I propose, CRVAL1 and CRVAL2 would both be zero. It may still >be that two WCS's in the same header would be needed. If you want to measure distances in metres, rather than solar radii as originally proposed, then use alternate axis descriptions (Section 2.3 of WCS paper). >well. To use this would, though, require coding in the CD matrix >formalism, which I'd assume would be back-supported by any software >developed once the present WCS draft is made final. The current draft recognises the CD matrix for backward compatibility but states that it must not be written. In particular, use of a CD matrix would imply that the CmDELTn secondary descriptor cards should be ignored (presumably, but in fact the behaviour is undefined) which is certainly not what you want in light of the above. Mark Calabretta ATNF From owner-fitsbits at marmoset.cv.nrao.edu Wed Dec 18 20:15:30 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) id UAA00962; Wed, 18 Dec 1996 20:15:12 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) with ESMTP id TAA00916; Wed, 18 Dec 1996 19:26:59 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id TAA01788 for ; Wed, 18 Dec 1996 19:26:57 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA21125; Wed, 18 Dec 96 19:26:55 EST To: fitsbits at fits.cv.nrao.edu Date: 17 Dec 1996 15:43 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger) Message-Id: <17DEC199615432154 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!hunter.premier.net!news.mathworks.com!howland.erols.net!feed1.news.erols.com!news.idt.net!psinntp!psinntp!news.intercon.com!news5.digex.net!haven.umd.edu!cs.umd.edu!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Reply-To: fits at nssdca.gsfc.nasa.gov Subject: Sources of FITS Information Newsgroups: sci.astro.fits,sci.answers,news.answers Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk Archive-name: astronomy/fits/info-sources Last-modified: 1996/09/25 -------- Sources of FITS Information Preface This material on sources of Flexible Image Transport System (FITS) information is posted and updated periodically by the FITS Support Office at the NASA Goddard Space Flight Center (GSFC). It discusses where general FITS information, including some answers to frequently asked questions, can be found, and provides sources for detailed information on FITS software and documentation. ------- FITS Support Office The FITS Support Office maintains a library of FITS information accessible from http://ssdoo.gsfc.nasa.gov/astro/fits/fits_home.html or ftp://nssdc.gsfc.nasa.gov/pub/fits/. The material available includes o "Definition of FITS," a codification of FITS for the NASA/Science Office of Standards and Technology (NOST), available in LaTeX, uncompressed PostScript, compressed PostScript and (usually) ASCII text (The ASCII text version may not be available for a short while after the announcement of a new version.) o "A User's Guide to FITS", published by the FITS Support Office, in LaTeX, and compressed and uncompressed PostScript o Revisions to version 1.0 of the "Definition of FITS" covering the specification of units that were incorporated into version 1.1 (text) o A current list of the extension type (structure) names registered with the International Astronomical Union FITS Working Group (IAUFWG) (text) o Rules for physical blocking on various media adopted by the IAUFWG (text) In the same directory but accessible directly via http://ssdoo.gsfc.nasa.gov/astro/fits/basics_info.html is the FITS Basics and Information that used to be regularly posted to sci.astro.fits and sci.data.formats. It continues to be revised to reflect current FITS developments. It contains the following material: o An overview of FITS o A list of FITS documents o A list of software packages that support FITS, including FITS <--> image converters for various platforms o A list of on-line FITS resources o A description of the FITS Support Office The hypertext version provides links to many of the documents, software, and network locations listed. The text version provides information on how to obtain much of this material. There is also a hypertext version of the List of Registered Extensions. Links from the Web page and subdirectories of the ftp directory contain o Software developed by the FITS Support Office. o Error test files: primary HDUs useful for testing the ability of software designed to read FITS files to cope with files that have errors or are non-standard. These files should be downloaded in binary form. Printed copies of the material in the FITS directory can be obtained from the Coordinated Request and User Support Office (CRUSO): (Postal) Coordinated Request and User Support Office Code 633 National Space Science Data Center NASA Goddard Space Flight Center Greenbelt MD 20771 USA (Electronic mail) request at nssdca.gsfc.nasa.gov (Telephone) +1-301-286-6695 8:00 A. M. - 4:30 P.M. U. S. Eastern Time (-0500 from the last Sunday in October through the first Saturday in April; -0400 the remainder of the year) When no one is available, messages can be left on voice mail. (FAX) +1-301-286-1635 ------- National Radio Astronomy Observatory (NRAO) A FITS Archive can be found at URL http://fits.cv.nrao.edu/ or at ftp://fits.cv.nrao.edu/fits, located at NRAO. This machine supports a WAIS server named nrao-fits which has an index of all of the FITS-related text files in the archive; the file nrao-fits.src is available at think.com and at ftp://fits.cv.nrao.edu/fits/wais-sources/nrao-fits.src. Some of the more noteworthy materials in this archive are o Drafts of proposed additions to the FITS standard and other drafts that may in the future be formally proposed o Text of any detailed proposals currently being discussed by the FITS committees o A collection of documents on World Coordinate Systems, including the current draft proposal o Conventions specific to particular projects or disciplines o Software for various environments and Usenet postings about code o Sample data and special test files designed to measure the ability of a FITS reader to handle a wide variety of FITS files o Archives of traffic on FITS-related newsgroups and exploders A separate NRAO site, http://www.cv.nrao.edu/~bcotton/fitsview.html, provides information on the FITSview family of software packages for display of FITS images on Microsoft Windows 3.1 and Windows 95, Apple Macintosh, and Unix/X-Windows, with links to the software. It also links to a number of sources of astronomical FITS images. ------- HEASARC The NASA/Goddard High Energy Astrophysics Science Archive Research Center (HEASARC) Web server at http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html and the anonymous ftp access through ftp://heasarc.gsfc.nasa.gov/fits_info/ provide FITS material. HEASARC has developed the FITSIO package of software routines for easily reading and writing FITS files, with FORTRAN and C versions available, portable to a wide variety of machines. There is also the FTOOLS collection of software tools and the VERIFITS FITS conformance verifier. HEASARC software is available directly through http://heasarc.gsfc.nasa.gov/docs/heasarc/tech_res_software.html or ftp://heasarc.gsfc.nasa.gov/fits_info/software/ . The HEASARC server also provides information from the HEASARC FITS Working Group, (HFWG) the internal legislative body on FITS-related matters within the Office of Guest Investigator Programs (OGIP) at NASA/GSFC, at http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg_intro.html or at ftp://heasarc.gsfc.nasa.gov/fits_info/ in the directories ofwg_minutes and ofwg_recomm. The HFWG has developed a number of FITS conventions that are more specific than the requirements of the FITS standards. Proposed conventions are publicized to the FITS community as a whole, with the goal of collaborative development of a set of conventions that will be accepted throughout the community as well as within OGIP/HEASARC. ------- Direct questions about this posting to Barry M. Schlesinger Coordinator, FITS Support Office Electronic mail: fits at nssdca.gsfc.nasa.gov Telephone: +1-301-441-4205 The FITS Support Office is operated under the guidance of the NASA/GSFC Astrophysics Data Facility. From owner-fitsbits at marmoset.cv.nrao.edu Thu Dec 19 10:26:49 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) id KAA04845; Thu, 19 Dec 1996 10:26:28 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) with ESMTP id FAA04458; Thu, 19 Dec 1996 05:55:35 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id FAA06184 for ; Thu, 19 Dec 1996 05:55:33 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA11732; Thu, 19 Dec 96 05:55:28 EST To: fitsbits at fits.cv.nrao.edu Date: 18 Dec 96 17:09:18 CST From: clscott at ualr.edu Message-Id: <1996Dec18.170918.1 at ualr.edu> Organization: University of Arkansas at Little Rock Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!news.monmouth.com!uunet!in2.uu.net!205.252.116.190!feed1.news.erols.com!news.idt.net!mr.net!news.mid.net!news.uark.edu!news.ualr.edu!athena.ualr.edu!clscott Subject: Magnitude Determination SW For FITS Images Newsgroups: sci.astro.fits,sci.astro.amateur Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk Can someone please recommend a program to use on a Windows 95 machine to determine the magnitude of stars in a FITS image? I appologize if this post is not appropriate for the "sci.astro.fits" newsgroup. Please e-mail responses to me at "clscott at ualr.edu". Thank you. Incidentally, this is the first time that I have tried to post on more than one group at a time. If this article is received by people on the "sci.astro.amateur" newsgroup, I would appreciate it if you could let me know that you received this article, even if you don't know the answer to my question. Thanks again. -- ============================================================================ Coy Scott | E-Mail: clscott at ualr.edu ============================================================================ From owner-fitsbits at marmoset.cv.nrao.edu Thu Dec 19 11:46:28 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) id LAA04956; Thu, 19 Dec 1996 11:46:23 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) with ESMTP id LAA04942; Thu, 19 Dec 1996 11:45:10 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id LAA08803 for ; Thu, 19 Dec 1996 11:45:09 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA23069; Thu, 19 Dec 96 11:45:07 EST To: fitsbits at fits.cv.nrao.edu Date: 19 Dec 1996 16:22:29 GMT From: thompson at orpheus.nascom.nasa.gov (William Thompson) Message-Id: <59bq45$3r3 at post.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!newshub.sdsu.edu!newshub.csu.net!www.nntp.primenet.com!nntp.primenet.com!news.bbnplanet.com!su-news-hub1.bbnplanet.com!arclight.uoregon.edu!enews.sgi.com!news.sgi.com!news.msfc.nasa.gov!centauri.hq.nasa.gov!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson References: <199612111357.AAA14853 at crux.rp.CSIRO.AU> <58niqk$2uh at post.gsfc.nasa.gov> <32b6f8d4.0 at newz.csun.edu> Subject: Re: WCS questions Newsgroups: sci.astro.fits Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk swalton at galileo.csun.edu (Stephen Walton) writes: >My original goal was to explore a format for the header in which the >linear part would translate to normalized distance from solar disk center >along the north and west axes, and the non-linear part would allow one to >take the additional step to solar longitude and latitude for features on >the disk. In one of Mark's earlier posts, he pointed out that the PC >matrix could define the former and the CDELT, CRVAL, and CTYPE values the >latter. This sounds good to me. I'm confused here. My reading of the WCS document is that the PC matrix must agree with the CDELT, CRVAL, and CTYPE values. Or did you mean CmELT, etc.? Bill From owner-fitsbits at marmoset.cv.nrao.edu Fri Dec 20 10:24:28 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) id KAA23982; Fri, 20 Dec 1996 10:23:39 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) with ESMTP id TAA00674; Thu, 19 Dec 1996 19:37:07 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with ESMTP id TAA12623 for ; Thu, 19 Dec 1996 19:37:06 -0500 (EST) Received: from crux.rp.CSIRO.AU (crux.rp.CSIRO.AU [130.155.194.32]) by cv3.cv.nrao.edu (8.8.3/8.8.0/CV-2.3) with SMTP id TAA12463 for ; Thu, 19 Dec 1996 19:36:59 -0500 (EST) Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.rp.CSIRO.AU (8.6.10/8.6.10.A) with ESMTP id LAA12919; Fri, 20 Dec 1996 11:35:33 +1100 Message-Id: <199612200035.LAA12919 at crux.rp.CSIRO.AU> To: thompson at orpheus.nascom.nasa.gov (William Thompson) CC: fitsbits at fits.cv.nrao.edu Subject: Re: WCS questions In-reply-to: Your message of Thu 1996/12/19 16:22:29 GMT <59bq45$3r3 at post.gsfc.nasa.gov> Date: Fri, 20 Dec 1996 11:35:32 +1100 From: Mark Calabretta Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk On Thu 1996/12/19 16:22:29 GMT, William Thompson wrote in a message to: fitsbits at fits.cv.nrao.edu >I'm confused here. My reading of the WCS document is that the PC matrix must >agree with the CDELT, CRVAL, and CTYPE values. Or did you mean CmELT, etc.? WCS is defined as a chain of independent algorithms as described in fig. 1 of the draft. What does it mean to say that one step in this chain "agrees" with another? The suggestion is to tap into the intermediate products of that chain. One point which does need clarifying though is whether the PC matrix is or is not used in conjunction with the secondary axis descriptors. I have assumed it is but the current draft does not say explicitly. Image rotation would be the main issue here. Mark Calabretta ATNF From owner-fitsbits at marmoset.cv.nrao.edu Fri Dec 20 10:24:30 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) id KAA23989; Fri, 20 Dec 1996 10:24:22 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) with ESMTP id WAA00920; Thu, 19 Dec 1996 22:52:58 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with ESMTP id WAA14060 for ; Thu, 19 Dec 1996 22:52:57 -0500 (EST) Received: from crux.rp.CSIRO.AU (crux.rp.CSIRO.AU [130.155.194.32]) by cv3.cv.nrao.edu (8.8.3/8.8.0/CV-2.3) with SMTP id WAA14485 for ; Thu, 19 Dec 1996 22:52:52 -0500 (EST) Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.rp.CSIRO.AU (8.6.10/8.6.10.A) with ESMTP id OAA01265 for ; Fri, 20 Dec 1996 14:51:33 +1100 Message-Id: <199612200351.OAA01265 at crux.rp.CSIRO.AU> To: fitsbits at fits.cv.nrao.edu Subject: PLON/PLAT Date: Fri, 20 Dec 1996 14:51:32 +1100 From: Mark Calabretta Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk Recent discussion on sci.astro.fits has indicated that it would be useful to formally recognize a PLON/PLAT coordinate system in WCS. While WCS was developed primarily for mapping the celestial sphere it is also well suited for other forms of cartography. The particular requirement which PLON/PLAT would address is that of describing off-limb phenomena in planetary, solar, lunar, etc. mapping. An image using PLON/PLAT coordinates for longitude and latitude on the sphere would have an implied Cartesian coordinate system which would apply to all pixels in the image, including those beyond the limb of the sphere. Secondary axis descriptors could optionally be used to define a scale and coordinate type for this Cartesian system. Note that PLON/PLAT is simply an application of the methods already defined in the WCS draft using the xLON/xLAT provision. The proposal here is effectively to register the name of this application; it does not constitute a fundamental change to WCS (for example, it won't require a change to WCSLIB). Examples of usage: a) Solar prominences. b) Volcanic plumes on Io. c) Terrestrial aurorae. d) Mapping of the positions of a planet's moons, rings, impacting comets, magnetic fields, radiation belts, spacecraft trajectories, etc. in relation to its disk. PLON/PLAT would have the following defining characteristics: 1) Used mainly in conjunction with the azimuthal perspective projection, AZP (with mu << -1), for planetary/solar mapping. 2a) The PC matrix is chosen so that the perimeter of the sphere has unit radius. 2b) The map is oriented so that the north pole is at x' = 0, y' >= 0, where x' and y' are the coordinate elements corresponding to the PLON and PLAT axes obtained after applying the PC matrix to a pixel coordinate. 2c) The CDELTn header cards scale (x',y') to (x,y) in the "degree" units required by WCS. Their signs are set to invert the native longitude as appropriate for a sphere observed from the outside as opposed to the usual case of the celestial sphere observed from the inside. 3) Secondary axis descriptors can be used to assign physical units in a complementary Cartesian coordinate system for all points in the image, including those beyond the perimeter of the sphere. Mark Calabretta ATNF From owner-fitsbits at marmoset.cv.nrao.edu Tue Dec 24 13:12:33 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) id NAA29290; Tue, 24 Dec 1996 13:12:12 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) with ESMTP id NAA29277; Tue, 24 Dec 1996 13:08:26 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id NAA01029 for ; Tue, 24 Dec 1996 13:08:24 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA00413; Tue, 24 Dec 96 13:08:18 EST To: fitsbits at fits.cv.nrao.edu Date: 24 Dec 1996 17:40:16 GMT From: seaman at noao.edu (Rob Seaman) Message-Id: <59p4i0$o9o at noao.edu> Organization: National Optical Astronomy Observatories, Tucson, AZ, USA Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!news.misty.com!www.nntp.primenet.com!nntp.primenet.com!howland.erols.net!feed1.news.erols.com!insync!uunet!in1.uu.net!128.196.139.12!news.Arizona.EDU!CS.Arizona.EDU!noao!seaman Subject: why we have FITS Newsgroups: sci.astro.fits Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk An article in the current issue of the Risks Digest struck me as a good reminder of the fundamental justification for FITS, as well as a caution that a portable standard requires portable documentation. The article is appended below or can reached at the URL: http://catless.ncl.ac.uk/Risks/18.71.html#subj11 I'm also going to take this chance to put in a strong plug for the Risks Digest. Astronomy in general, and the ADASS community in particular, are certainly not immune to computer risks. The Risks Digest can be read as the comp.risks newsgroup, as a mailing list, or from the general URL: http://catless.ncl.ac.uk/Risks The moderator of the Risks Forum is Peter G. Neumann, who also has a cautionary book derived from discussions in Risks: "Computer Related Risks", Peter G. Neumann New York: ACM Press; Reading, Mass.: Addison-Wesley, 1995. QA76.5 .N424 1995 Rob Seaman -- RISKS-LIST: Risks-Forum Digest Monday 23 December 1996 Volume 18 : Issue 71 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator [...] Date: Sat, 21 Dec 1996 06:29:39 -0500 (EST) From: "Darrin B. Jewell" Subject: Microsoft documents and Rosetta stones (Giersig, RISKS-18.70) This past summer I was getting increasingly frustrated by users who were sending me e-mail with Microsoft Word ".DOC" files attached to them via MIME encodings. I do not own a copy of Microsoft Word and did not want to purchase one simply so that I could read documents people send to me. Instead, I wanted the specification for Microsoft Word file format so that I would have a Rosetta stone for the documents I wished to read. I contacted Microsoft's customer support and was informed of the following: 1. The specification for Microsoft Word file format is unpublished proprietary information. However, I could download a free reader for Microsoft Word files which would run under one of Microsoft's operating systems. Source code for the reader was not available. 2. I could ask the sender of the message to send me the attachment encoded in Rich Text Format which is the official export format for Microsoft Word documents. The specification for Rich Text Format was publically available from Microsoft. Since I did not own a computer running one of Microsoft's operating systems, I asked Microsoft for the specification for Rich Text Format files. As a computer programmer, this was also a more useful and interesting form of Rosetta stone than a precompiled translating program. I was then directed to the file GC0165.EXE on the Microsoft ftp site, which I was able to download and unzip. (Itself another decoding adventure.) Included was the file GC0165.DOC, a Microsoft Word format file containing the specification I desired. The included README.TXT file contained the following comment in plain ASCII: The GC0165.DOC file included in this compressed file is the Rich Text Format (RTF) Specification version 1.3. The document is in Word 6.0 for Windows format. If you have neither Word 6.0 for Windows nor Word 2.0 for Windows with the 6.0-to-2.0 converter, you will need to call Microsoft Product Support Services at (206) 462-9673 to obtain a hard copy of the document. At this point, I decided it was fastest to have my friend who owned Microsoft Word print out the RTF specification for me. Since this experience, I usually ask people who wish to send me Word documents to send them in RTF format. When I explain to people the RISKS involved in using documents without open standards, I get comments about being ridiculous and pedantic or perhaps a blink and a "So what?" Even though Microsoft Word supports an "official export format", it is clearly not obvious to everyone why it should be used. Darrin Reused without explicit authorization under blanket permission granted for all Risks-Forum Digest materials. The author(s), the RISKS moderator, and the ACM have no connection with this reuse. -- seaman at noao.edu, http://iraf.noao.edu/~seaman NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248 PGP: 98 8D 8B 49 74 9A 41 88 3A 43 87 54 51 BF 30 4B From owner-fitsbits at marmoset.cv.nrao.edu Wed Dec 25 14:33:57 1996 Received: (from majdom at localhost) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) id OAA30879; Wed, 25 Dec 1996 14:33:40 -0500 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by marmoset.cv.nrao.edu (8.7.6/8.7.3: $Revision: 1.1 $) with ESMTP id PAA29321; Tue, 24 Dec 1996 15:12:03 -0500 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.8.3/8.8.0/CV-2.2) with SMTP id PAA01905 for ; Tue, 24 Dec 1996 15:12:01 -0500 (EST) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA04893; Tue, 24 Dec 96 15:11:58 EST To: fitsbits at fits.cv.nrao.edu Date: Tue, 24 Dec 1996 15:05:08 -0500 From: Grandpa Ewald Message-Id: Organization: LI Net (Long Island Network) Path: solitaire.cv.nrao.edu!in1.nntp.cais.net!www.nntp.primenet.com!nntp.primenet.com!ddsw1!news.mcs.net!in-news.erinet.com!en.com!uunet!in1.uu.net!199.171.6.16!li.net!linet01!alfie Subject: GIF & FITS access Newsgroups: sci.astro.fits Sender: owner-fitsbits at marmoset.cv.nrao.edu Precedence: bulk I've been an amateur astronomer for 40 years but I'm new to computers, and I would appreciate advise on what minimum equipment is necessary to get access to the wonderful astronomy pictures available on the net. Presently, I'm text based using an AT&T 6300 (640KB RAM, 32MB HDU) and Procomm Plus to connect. It seems impossible but is there any way I can get any kind of access with what I have, and beyond that what minimum is needed? I know I'm reaching, but astronomers have a way of dealing with distance, so I'm hopeful. Walter C. Ewald