From pence at heawk1.gsfc.nasa.gov Mon Nov 4 17:38:10 1991 X-VM-Message-Order: (1 2 3 4 5 7 8 9 11 12 14 10 15 16 13 6) X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n" X-VM-Labels: nil X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil X-VM-Bookmark: 16 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2914" "" " 4" "November" "1991" "19:06:29" "GMT" "pence at heawk1.gsfc.nasa.gov ( William Pence)" "pence at heawk1.gsfc.nasa.gov ( William Pence)" "<8366034 at toto.iv>" "71" "FITSIO Version 3.10 Release" "^From:" nil nil "11" "1991110419:06:29" "FITSIO Version 3.10 Release" (number " " mark " pence at heawk1.gsfc Nov 4 71/2914 " thread-indent "\"FITSIO Version 3.10 Release\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Summary: FITSIO Version 3.10 is now available Keywords: FITS Organization: Goddard Space Flight Center Nntp-Posting-Host: heawk1.gsfc.nasa.gov From: pence at heawk1.gsfc.nasa.gov ( William Pence) Subject: FITSIO Version 3.10 Release Date: 4 Nov 91 19:06:29 GMT FITSIO - Version 3.10 4 November 1991 This is to announce that Version 3.10 of the FITSIO package is now available for general use. FITSIO is a Fortran-77 subroutine interface for reading and writing files in the FITS (Flexible Image Transport System) format. This major new version of FITSIO contains many improvements over the previous Version 3.01 release: - Added support for the 'variable length array' feature in binary tables. This includes three new subroutines: FTPTHP, FTGDES, and FTPDES. Note that this feature has only recently been proposed and is not yet an approved FITS standard. - Added suppport for running fitsio on IBM mainframe computers. - Added subroutines to make it more convenient to write HISTORY and COMMENT keywords to a FITS header. - Made a number of small efficiency improvements. - Fixed a number of bugs reported by users. - Changed the format of floating point keyword value fields to produce one more significant digit in the field. - Changed the way single quote characters are handled in keyword values to conform to the recommended FITS standard. - Removed the limitation on the number of 'random groups' in a FITS file. Previously, FITSIO could only read files with less than 256 groups. This new version of FITSIO is upwardly compatible with code written for the previous 3.xxx versions of FITSIO, except that now the parameter scaling variables (BSCALE and BZERO, TSCAL and TZERO) have been changed >from REAL*4 to DOUBLE PRECISION. This was done to provide increased accuracy when scaling the data. This affects the FTPSCL, FTTSCL, FTGACL and FTGBCL subroutines. To get a copy of the FITSIO software, documentation, and example programs use anonymous ftp to connect to: ftp tetra.gsfc.nasa.gov or ftp 128.183.8.77 Then type the following: ftp> user anonymous Password: [type your username as a password] ftp> cd pub/fitsio3 [to move to the version 3 subdirectory] ftp> ls [to see a list of the available files] ftp> get read.me [contains latest information about FITSIO] ftp> get fitsio.doc [complete user documentation] ftp> get ... [get any additional desired files] ftp> quit Alternatively, the FITSIO files may be copied from following SPAN node: NDADSA::HEASARC:[EXOSAT.XANADU.FITSIO.VERSION3] -------------------------------------------------------------------------- Dr. William Pence (Internet) pence at tetra.gsfc.nasa.gov HEASARC (SPAN) LHEAVX::PENCE Code 668 Telephone: (301)286-4599 NASA/Goddard Space Flight Center Greenbelt, MD 20771 -------------------------------------------------------------------------- From dwells at fits.cx.nrao.edu Mon Nov 11 18:12:08 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["5317" "Mon" "11" "November" "1991" "23:10:08" "GMT" "Don Wells" "dwells at fits.cx.nrao.edu" "<467375 at toto.iv>" "116" "FP Test File Available" "^From:" nil nil "11" "1991111123:10:08" "FP Test File Available" (number " " mark " Don Wells Nov 11 116/5317 " thread-indent "\"FP Test File Available\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Organization: National Radio Astronomy Observatory, Charlottesville, VA Distribution: alt From: dwells at fits.cx.nrao.edu (Don Wells) Subject: FP Test File Available Date: Mon, 11 Nov 1991 23:10:08 GMT Dear FITS Friends, Preben Grosbol (MIDAS Group at European Southern Observatory, Chairman European FITS Committee, Chairman IAU FITS Working Group) is visiting in Charlottesville today, on his way home from the data analysis meeting in Tucson. He brought two FITS test tapes with him, a DDS DAT tape and a Exabyte tape, with the same 11 files on each in order to test interoperability between our various systems in the two media. I have copied the DAT tape to the anonymous-FTP server on fits.cx.nrao.edu [192.33.115.8] in directory FITS/TestFiles/PG91: -rw-r--r-- 1 dwells vlb 43200 Nov 11 16:54 f01 -rw-r--r-- 1 dwells vlb 1148 Nov 11 17:02 f01.list -rw-r--r-- 1 dwells vlb 25920 Nov 11 16:54 f02 -rw-r--r-- 1 dwells vlb 1371 Nov 11 17:02 f02.list -rw-r--r-- 1 dwells vlb 152640 Nov 11 16:56 f03 -rw-r--r-- 1 dwells vlb 1150 Nov 11 17:02 f03.list -rw-r--r-- 1 dwells vlb 48960 Nov 11 16:57 f04 -rw-r--r-- 1 dwells vlb 1148 Nov 11 17:03 f04.list -rw-r--r-- 1 dwells vlb 112320 Nov 11 16:57 f05 -rw-r--r-- 1 dwells vlb 1158 Nov 11 17:03 f05.list -rw-r--r-- 1 dwells vlb 8640 Nov 11 16:58 f06 -rw-r--r-- 1 dwells vlb 2580 Nov 11 17:03 f06.list -rw-r--r-- 1 dwells vlb 8640 Nov 11 16:58 f07 -rw-r--r-- 1 dwells vlb 2989 Nov 11 17:03 f07.list -rw-r--r-- 1 dwells vlb 14400 Nov 11 16:58 f08 -rw-r--r-- 1 dwells vlb 2329 Nov 11 17:03 f08.list -rw-r--r-- 1 dwells vlb 14400 Nov 11 16:58 f09 -rw-r--r-- 1 dwells vlb 1903 Nov 11 17:03 f09.list -rw-r--r-- 1 dwells vlb 25920 Nov 11 16:58 f10 -rw-r--r-- 1 dwells vlb 3527 Nov 11 17:03 f10.list -rw-r--r-- 1 dwells vlb 267840 Nov 11 16:58 f11 -rw-r--r-- 1 dwells vlb 1422 Nov 11 17:03 f11.list Remember to specify "binary" when you fetch the FITS files! I want to call special attention to file f06, which tests the BITPIX=-32 (single-precision IEEE floating point) datatype. This Basic FITS file is a 1-D matrix with 38 pixels, whose values explore the difficult cases in IEEE arithmetic. The 38 values are listed in comments in the header, which I reproduce below (file f06.list): SIMPLE = T / Standard FITS format BITPIX = -32 / 32-bit IEEE Floating Point format NAXIS = 1 / Just one dimension NAXIS1 = 38 / No. of values in matrix ORIGIN = 'ESO ' / Created at ESO Garching DATE = '22/03/91' / Date of creation COMMENT This is a test file containing special 32-bit IEEE FP values COMMENT such as: COMMENT 00000000 ! pos. zero +0.0 COMMENT 80000000 ! neg. zero -0.0 COMMENT COMMENT 00400000 ! pos. underflow 5.8774718e-39 COMMENT 007f2345 ! pos. underflow 1.1675760e-38 COMMENT 0000efce ! pos. underflow 8.6025713e-41 COMMENT 00000001 ! pos. underflow 1.4012985e-45 COMMENT 80400000 ! neg. underflow -5.8774718e-39 COMMENT 80372345 ! neg. underflow -5.0636046e-39 COMMENT 8000efce ! neg. underflow -8.6025713e-41 COMMENT 80000001 ! neg. underflow -1.4012985e-45 COMMENT COMMENT 7f800000 ! Infinity COMMENT ff800000 ! -Infinity COMMENT COMMENT 7f810000 ! NaN COMMENT 7f800001 ! NaN COMMENT 7fffffff ! NaN COMMENT ff810000 ! -NaN COMMENT ff800001 ! -NaN COMMENT ffffffff ! -NaN COMMENT COMMENT 3f800000 ! 1.0000000e+00 COMMENT 40000000 ! 2.0000000e+00 COMMENT 40400000 ! 3.0000000e+00 COMMENT 40800000 ! 4.0000000e+00 COMMENT 40e00000 ! 7.0000000e+00 COMMENT 43f23b1d ! 4.8446182e+02 COMMENT 3cc77e3a ! 2.4352182e-02 COMMENT 3fffffff ! 1.9999999e+00 COMMENT 00800000 ! 1.1754944e-38 COMMENT 7f7fffff ! 3.4028235e+38 COMMENT COMMENT bf800000 ! -1.0000000e+00 COMMENT c0000000 ! -2.0000000e+00 COMMENT c0400000 ! -3.0000000e+00 COMMENT c0800000 ! -4.0000000e+00 COMMENT c0e00000 ! -7.0000000e+00 COMMENT c3f23b1d ! -4.8446182e+02 COMMENT bcc77e3a ! -2.4352182e-02 COMMENT bfffffff ! -1.9999999e+00 COMMENT 80800000 ! -1.1754944e-38 COMMENT ff7fffff ! -3.4028235e+38 COMMENT So best of luck with the decoding END =-=-= End of header. 57 cards (2 FITS records) =-=-= =-=-= Skipped 2880 bytes (1r0 FITS records) =-=-= =-=-= End-of-File, 8640 bytes in file (3r0 FITS records) =-=-= I recommend that this file be executed with all FITS readers, and that any errors in the file be reported to alt.sci.astro.fits so that these tests can be definitive. -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From elwin at hubcap.clemson.edu Fri Nov 15 20:17:09 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1192" "" "14" "November" "1991" "17:41:30" "GMT" "lawrence brown" "elwin at hubcap.clemson.edu" "<527563 at toto.iv>" "24" "saoimage on a DECstation 3100" "^From:" nil nil "11" "1991111417:41:30" "saoimage on a DECstation 3100" (number " " mark " lawrence brown Nov 14 24/1192 " thread-indent "\"saoimage on a DECstation 3100\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Distribution: alt Organization: Clemson University From: elwin at hubcap.clemson.edu (lawrence brown) Subject: saoimage on a DECstation 3100 Date: 14 Nov 91 17:41:30 GMT In article dwells at fits.cx.nrao.edu (Don Wells) writes: >Dear FITS Friends, > >Preben Grosbol (MIDAS Group at European Southern Observatory, Chairman >European FITS Committee, Chairman IAU FITS Working Group) is visiting >in Charlottesville today, on his way home from the data analysis >meeting in Tucson. He brought two FITS test tapes with him, a DDS DAT >tape and a Exabyte tape, with the same 11 files on each in order to >test interoperability between our various systems in the two media. I >have copied the DAT tape to the anonymous-FTP server on >fits.cx.nrao.edu [192.33.115.8] in directory FITS/TestFiles/PG91: > Well I got the files and this finally motivated me to try to fix my saoimage program. Saoimage on the DECstation seems incapable of reading fits files with real numbers. It does fine with "psuedo fits" files with the numbers in the wrong (Little Endian) byte order. The "-dfits" flag which is supposed to take care of this (?) seems to have no effect at all. Has anyone gotten this to work on a DECstation or a VAX themselves? Does anyone have any ideas? Anything is appreciated. Larry Brown elwin at gamma.phys.clemson.edu From thompson at stars.gsfc.nasa.gov Mon Nov 18 17:03:33 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["11587" "Mon" "18" "November" "1991" "20:07:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov" "<7168384 at toto.iv>" "370" "FITS plans for SOHO." "^From:" nil nil "11" "1991111820:07:00" "FITS plans for SOHO." (number " " mark " William Thompson, Nov 18 370/11587 " thread-indent "\"FITS plans for SOHO.\"\n") nil] nil) Newsgroups: alt.sci.astro.fits News-Software: VAX/VMS VNEWS 1.4-b1 Nntp-Posting-Host: stars.gsfc.nasa.gov Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Subject: FITS plans for SOHO. Date: Mon, 18 Nov 1991 20:07:00 GMT The following LaTeX document (landscape orientation) shows some slides I used recently to present some possibilities of using FITS for the data from the upcoming Solar Heliospheric Observatory (SOHO). We were discussing FITS from a standpoint of not only using FITS as a data distribution standard, but also possibly as a standard for sharing and using data between the different instruments during operations. Some concerns that people had about FITS were: * That FITS is wasteful of disk space. Some of this was a misconception of the FITS standard, which I managed to clear up. Also, in making up my samples, I rejected any possibilities that required padding arrays. * That FITS is better tuned for writing files to tape than for using files from disk. The driver for this seemed to be VMS. I discussed the possibility of storing files on disk in an "SDAS-like" format, with the FITS header and binary data in separate files, with the binary data in the native format of the machine rather than in IEEE format. Then the process of converting this to true FITS should be trivial. * That FITS is out of date. Somebody at the meeting compared writing FITS files with eight character keywords to trying to program in FORTRAN II. People seemed to prefer the more flexible approach used by PDS/ODL, or by PVL in the SFDU formalism. * That FITS is not flexible enough to store the complex data structures that we will be generating. A real concern--this was the crux of my presentation. What I emphasized in my presentation, and what people seemed to agree on, was that the best way to store the data from our particular instrument--the CDS Normal Incidence Spectrograph--was to use the "TDIMnnn" approach from Appendix A of the Binary Tables document. This was because it is the most straightforward approach, and because it allows us to easily distinguish between information that applies to an exposure, and information that applies to a window array that is part of that exposure. Information that applies to an exposure as a whole--such as start and stop times--would appear as separate columns in the table; and information that applies to a window--such as position on the CCD--would appear in the table header as keywords. With the other possibilities considered, this would not have been possible without a lot of needless repetition. It was decided that when the observation mode changed--i.e. when the number, positions, and/or sizes of the windows on the CCD changed--then we would either start a new FITS file or a new binary table extension within the same FITS file. So the SOHO community is currently planning on using the binary tables extensions together with the optional "TDIMnnn" keywords. It also looks like we will also be using other keywords with the "KEYWORD = '(a,b,c)'" structure to associate other information with the dimensions of our data. The following LaTeX document should be printed in landscape orientation. Bill Thompson Applied Research Corporation NASA Goddard Space Flight Center. ---------------------------------CUT HERE----------------------------------- \documentstyle[12pt]{article} \special{landscape()} \setlength{\oddsidemargin}{0in} \setlength{\topmargin}{-0.5in} \setlength{\textwidth}{9in} \setlength{\textheight}{6.5in} \addtolength{\parskip}{0.5\baselineskip} % The environment centerpage centers text vertically on the page. This is % useful within a titlepage environment. \newenvironment{centerpage}{\mbox{} \protect\vspace*{\fill}}{ \protect\vspace*{\fill} \mbox{} \protect\\ \mbox{}} % The environment quotetable combines the quote environment with the tabular % environment for unnumbered tables that appear within the text. The % environment centertable does the same, except that tables are centered % instead of indented. \newenvironment{quotetable}[1]{\begin{quote}\begin{tabular} { at {}#1}}{\end{tabular}\end{quote}} \newenvironment{centertable}[1]{\begin{center}\begin{tabular} {#1}}{\end{tabular}\end{center}} \begin{document} \pagestyle{empty} \large \begin{centerpage} \centerline{\huge\bf Storing SOHO Data in FITS Files} \begin{description} \item[The problem:] Traditional FITS files are unable to handle data sets with multiple arrays of different sizes, data types, and dimensions. \item[Possible solutions:] The use of the EXTEND keyword permits additional capabilities to the FITS format. Possible extensions that could be used are: \begin{itemize} \item the ``IMAGE'' extension, \item the ``BINTABLE'' extension with the ``Multidimensional Array'' convention, \item the ``BINTABLE'' extension with the ``Virtual FITS'' convention, \item the ``BINTABLE'' extension with the ``Variable Dimensions'' convention. \end{itemize} \end{description} \end{centerpage} \pagebreak \begin{centerpage} \centerline{\huge\bf The ``IMAGE'' Extension} \begin{itemize} \item Proposed by the IUE community. \item Each array has its own separate FITS header. Essentially a series of FITS files concatenated together into one file. \item Example: \begin{centertable}{l} Main FITS header, contains ``EXTEND = T''.\\ Binary array\\ Extension FITS header, contains ``XTENSION = 'IMAGE' ''.\\ Binary array\\ \hspace{3em} \vdots \end{centertable} \item Advantages: Easily read. Supported by IUE. \item Disadvantages: Wasteful of disk space. \end{itemize} \end{centerpage} \pagebreak \begin{centerpage} \centerline{\huge\bf The ``Binary Tables'' Extension} \begin{itemize} \item Based on tables model used by relational database and spreadsheet software. \item Data organized into rows and columns. The columns represent different data objects (e.g. time, pitch, yaw, etc.) and the rows represent different entries (e.g. successive observations). \item Richer selection of data types than in ordinary fits, including string variables as columns in the binary tables. \item Columns can be arrays. Columns can be defined as either having a fixed or variable size. \item There is no official way to assign dimensional information to entries in binary tables. However, there are several proposed conventions as to how to do this. \item Example: \begin{centertable}{l} Main FITS header, contains ``EXTEND = T''.\\ Binary array (optional)\\ Extension FITS header, contains ``XTENSION = 'BINTABLE' ''.\\ Binary table arrays\\ \end{centertable} \end{itemize} \end{centerpage} \pagebreak \begin{centerpage} \centerline{\huge\bf The ``Multidimensional Array'' Convention} \begin{itemize} \item Described in the Binary Tables proposal document. \item Assigns a keyword to a column of the form ``TDIMnnn = '(l,m,n)' ''. Dimensional information derived by parsing character string. \item Advantages: Straightforward, referencable standard. Uses disk space well. Easy to concatenate similar observations together. \item Disadvantages: May not be supported by all FITS readers. However, the data itself will be readable---it's just a question of interpretation. \end{itemize} \end{centerpage} \pagebreak \begin{centerpage} \centerline{\huge\bf Example using ``TDIMnnn''} \begin{centertable}{|c|l|l|l|} \hline & \multicolumn{3}{|c|}{Columns}\\ \cline{2-4} & 1 & 2 & 3\\ \cline{2-4} & TFORM1='1000I' & TFORM2='2000I' & TFORM3='2500I'\\ Rows & TTYPE1='Window\_1' & TTYPE2='Window\_2' & TTYPE3='Window\_3'\\ & TDIM1='(10,100)' & TDIM2='(20,100)' & TDIM3='(50,50)'\\ & XPOS1=10 & XPOS2=200 & XPOS3=500\\ & YPOS1=10 & YPOS2=10 & YPOS3=100\\ \hline 1 & Image & Image & Image\\ 2 & Image & Image & Image\\ \vdots & \vdots & \vdots & \vdots\\ \hline \end{centertable} \end{centerpage} \pagebreak \begin{centerpage} \centerline{\huge\bf The ``Virtual FITS'' Convention} \begin{itemize} \item Also known as the ``Green Bank'' convention. Definition document not available yet. \item Defines a binary table where each column is associated with a keyword in an ordinary FITS file, but with slightly different names. Parameters which would be the same for each row can be substituted with a keyword. \item The optional variable length array facility should be used if one wants to minimize file size. Otherwise, padding would be required. \item Advantages: Somewhat more FITS-like than the ``TDIMnnn'' convention. Supported by Green Bank. \item Disadvantages: Less straightforward than ``TDIMnnn'' convention. Only allows for one multidimensional array per record. The variable length array facility may not be supported by all FITS readers. Difficult to associate auxiliary data with different observations. \end{itemize} \end{centerpage} \pagebreak \begin{centerpage} \normalsize \centerline{\huge\bf Example using ``Virtual FITS''} \mbox{} \centerline{\large (Note that keyword ``MAXIS = 2'' is included in table header)} \begin{centertable}{|c|l|l|l|l|l|} \hline & \multicolumn{5}{|c|}{Columns}\\ \cline{2-6} & 1 & 2 & 3 & 4 & 5\\ \cline{2-6} Rows & TFORM1='1I' & TFORM2='1I' & TFORM3='1I' & TFORM4='1I' & TFORM5='1PI(2500)'\\ & TTYPE1='MAXIS1' & TTYPE2='MAXIS2' & TTYPE3='XPOS' & TTYPE4='YPOS' & TTYPE5='ARRAY'\\ \hline 1 & 10 & 100 & 10 & 10 & Pointer\\ 2 & 20 & 100 & 200 & 10 & Pointer\\ 3 & 50 & 50 & 500 & 100 & Pointer\\ \vdots & \vdots & \vdots & \vdots & \vdots & \vdots\\ \hline N+1 & 10 & 100 & 10 & 10 & Pointer\\ N+2 & 20 & 100 & 200 & 10 & Pointer\\ N+3 & 50 & 50 & 500 & 100 & Pointer\\ \vdots & \vdots & \vdots & \vdots & \vdots & \vdots\\ \hline \vdots & \vdots & \vdots & \vdots & \vdots & \vdots\\ \hline \multicolumn{6}{|c|}{Variable array 1 (2000 bytes)}\\ \multicolumn{6}{|c|}{Variable array 2 (4000 bytes)}\\ \multicolumn{6}{|c|}{Variable array 3 (5000 bytes)}\\ \multicolumn{6}{|c|}{\vdots}\\ \hline \end{centertable} \end{centerpage} \pagebreak \begin{centerpage} \centerline{\huge\bf The ``Variable Dimensions'' Convention} \begin{itemize} \item Most general case. Not only allows any column to be multidimension, but also allows the dimensions to be different for each row. \item Dimensions for one column stored in another column, with a keyword pointing between them. Keyword is of the form ``TNDIMnnn = mmm'' where nnn is the column with the multidimensional array, and mmm is the column with the shape information. The first number in each row of column mmm is the number of dimensions, and the following numbers are the dimension sizes. \item The optional variable length array facility should be used if one wants to minimize file size. Otherwise, padding would be required. Again, this may not be supported by all FITS readers. \item Similar advantages and disadvantages as the ``TDIMnnn'' convention, but more general. In fact, this convention is more general than the CDS example requires. \end{itemize} \end{centerpage} \pagebreak \begin{centerpage} \normalsize \centerline{\huge\bf Example using ``TNDIMnnn''} \begin{centertable}{|c|l|l|l|l|l|} \hline & \multicolumn{5}{|c|}{Columns}\\ \cline{2-6} & 1 & 2 & 3 & 4 & $\cdots$\\ \cline{2-6} & TFORM1='1000I' & TFORM2='3I' & TFORM3='2000I' & TFORM4='3I' & \\ Rows & TTYPE1='Window\_1' & TTYPE2='Window\_1\_Dims' & TTYPE3='Window\_2' & TTYPE4='Window\_2\_Dims' & \\ & TNDIM1=2 & & TNDIM3=4 & & $\cdots$\\ & XPOS1=10 & & XPOS2=200 & & \\ & YPOS1=10 & & YPOS2=10 & & \\ \hline 1 & Image & 2, 10, 100 & Image & 2, 20, 100 & \\ 2 & Image & 2, 10, 100 & Image & 2, 20, 100 & $\cdots$\\ \vdots & \vdots & \vdots & \vdots & \vdots & \\ \hline \end{centertable} \end{centerpage} \end{document} From baalke at kelvin.jpl.nasa.gov Mon Nov 18 19:28:37 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1160" "" "18" "November" "1991" "22:43:42" "" "Ron Baalke" "baalke at kelvin.jpl.nasa.gov" "<3476084 at toto.iv>" "18" "Re: FITS plans for SOHO." "^From:" nil nil "11" "1991111822:43:42" "FITS plans for SOHO." (number " " mark " Ron Baalke Nov 18 18/1160 " thread-indent "\"Re: FITS plans for SOHO.\"\n") nil] nil) Newsgroups: alt.sci.astro.fits News-Software: VAX/VMS VNEWS 1.3-4 Nntp-Posting-Host: kelvin.jpl.nasa.gov Reply-To: baalke at kelvin.jpl.nasa.gov Organization: Jet Propulsion Laboratory From: baalke at kelvin.jpl.nasa.gov (Ron Baalke) Subject: Re: FITS plans for SOHO. Date: 18 NOV 91 22:43:42 In article <18NOV199116070809 at stars.gsfc.nasa.gov>, thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes... >The following LaTeX document (landscape orientation) shows some slides I used >recently to present some possibilities of using FITS for the data from the >upcoming Solar Heliospheric Observatory (SOHO). The SOHO data will be Reed Solomon encoded when it is transmitted by the spacecraft, and then decoded at the tracking station. However, the check symbols will still be in place at the end of each frame of data. Does FITS provide some mechanism to ignore portions of the data, in this case the check symbols? If the check symbols are removed and the data pieced together before being converted to FITS, then this wouldn't be a problem. ___ _____ ___ /_ /| /____/ \ /_ /| Ron Baalke | baalke at kelvin.jpl.nasa.gov | | | | __ \ /| | | | Jet Propulsion Lab | ___| | | | |__) |/ | | |__ M/S 301-355 | The two hardest things to /___| | | | ___/ | |/__ /| Pasadena, CA 91109 | handle in life are success |_____|/ |_|/ |_____|/ | and failure. From pence at heawk1.gsfc.nasa.gov Mon Nov 18 19:28:50 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["878" "" "18" "November" "1991" "23:02:00" "GMT" "pence at heawk1.gsfc.nasa.gov ( William Pence)" "pence at heawk1.gsfc.nasa.gov ( William Pence)" "<3456136 at toto.iv>" "18" "byte swapping subroutines needed" "^From:" nil nil "11" "1991111823:02:00" "byte swapping subroutines needed" (number " " mark " pence at heawk1.gsfc Nov 18 18/878 " thread-indent "\"byte swapping subroutines needed\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Organization: Goddard Space Flight Center Nntp-Posting-Host: heawk1.gsfc.nasa.gov From: pence at heawk1.gsfc.nasa.gov ( William Pence) Subject: byte swapping subroutines needed Date: 18 Nov 91 23:02:00 GMT Can anyone tell me where I can find some efficient code for byte swapping on VAX/VMS and DECstations machines? Ideally I would like assembly lanuage routines which are callable from Fortran to swap the byte order in an array of Integer*2 data, and to reverse the byte order in an array of Integer*4 data (from 1234 to 4321). I also need an efficient routine to convert between the single and double floating point formats used on a VAX and the IEEE formats used by FITS. It would be useful if these routines also handled the IEEE special values such as NaN, Infinity, etc. Thanks in advance for any help. --------------------------------------------------------------------------- Bill Pence pence at tetra.gsfc.nasa.gov HEASARC/GSFC LHEAVX::PENCE --------------------------------------------------------------------------- From thompson at stars.gsfc.nasa.gov Tue Nov 26 20:29:01 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1741" "" "21" "November" "1991" "22:49:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov" "<3775929 at toto.iv>" "39" "Possible additional keywords for binary tables." "^From:" nil nil "11" "1991112122:49:00" "Possible additional keywords for binary tables." (number " " mark " William Thompson, Nov 21 39/1741 " thread-indent "\"Possible additional keywords for binary tables.\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics News-Software: VAX/VMS VNEWS 1.4-b1 Nntp-Posting-Host: stars.gsfc.nasa.gov From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Subject: Possible additional keywords for binary tables. Date: 21 Nov 91 22:49:00 GMT I've been looking into the question of using the binary tables extension for SOHO data, and it seems to me that there are capabilities in basic FITS that are not replicated in the binary tables extension, namely the keywords CTYPEn, CRPIXn, CROTAn, CRVALn, CDELTn, DATAMAX, and DATAMIN. However, I believe that I can overcome this problem by defining additional keywords for the binary tables extension, such that DATAMIN --> TDMINm DATAMAX --> TDMAXm CTYPEn --> TDESCm CRPIXn --> TRPIXm CROTAn --> TROTAm CRVALn --> TRVALm CDELTn --> TDELTm I separate out the first two keywords because these are fairly simple ones. However, the other keywords are more complicated. The index n on the left refers to a dimension in an array, while the index m on the right refers to columns in a binary table. There aren't enough characters in an eight-character FITS keyword to allow including both n and m in the name of the keyword. If one sticks to the convention that arrays in a binary table are one-dimensional vectors, then there's no real confusion. If, on the other hand, one wants to use binary tables to represent more complicated data structures as we do, then a problem seems to arise. However, we also intend to use the TDIMm keyword as described in Appendix A of the binary tables proposal. This keyword has the structure TDIMm = '(l,m,n) ' Hence, it manages to get all the shape information for a multidimensional array in a binary table into one keyword. One could also use this same structure for the keywords TDESCm, TRPIXm, TROTAm, TRVALm, and TDELTm, and that is what we are currently thinking about doing. William Thompson From leb at gsfc.nasa.gov Tue Nov 26 20:29:09 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3225" "" "22" "November" "1991" "15:34:22" "GMT" "Lee E. Brotzman" "leb at gsfc.nasa.gov" "<4367902 at toto.iv>" "65" "Re: Possible additional keywords for binary tables." "^From:" nil nil "11" "1991112215:34:22" "Possible additional keywords for binary tables." (number " " mark " Lee E. Brotzman Nov 22 65/3225 " thread-indent "\"Re: Possible additional keywords for binary tables.\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Organization: Goddard Space Flight Center Nntp-Posting-Host: hypatia.gsfc.nasa.gov From: leb at gsfc.nasa.gov (Lee E. Brotzman) Subject: Re: Possible additional keywords for binary tables. Date: 22 Nov 91 15:34:22 GMT thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes: >I've been looking into the question of using the binary tables extension for >SOHO data, and it seems to me that there are capabilities in basic FITS that >are not replicated in the binary tables extension, namely the keywords CTYPEn, >CRPIXn, CROTAn, CRVALn, CDELTn, DATAMAX, and DATAMIN. However, I believe that >I can overcome this problem by defining additional keywords for the binary >tables extension, such that > > DATAMIN --> TDMINm > DATAMAX --> TDMAXm >William Thompson I have considered these two keywords for our ASCII tables as well. It's a good thing to know the allowable range of values for a given field. When posing a database query against a table, it can save a lot of time if the software can first determine if the query is within the bounds for the field. Also, there would be a built-in "example" of what the data in the field look like, so users unfamiliar with a particular dataset can pose sensible queries right away. The EPOCH and/or EQUINOX keywords can also be put to use in field-specific fashion: TEPOCn TEQNXn Astronomical catalogs sometimes have more than one set of coordinates, especially now that we are in the "cross-over" period from B1950 to J2000. There is currently no way for software to inspect a table and determine the epoch and equinox of the coordinate fields. Another thing I worry about with binary tables is the loss of precision information that is found in their ASCII counterparts. For instance, a magnitude field can be given as "10. ", "10.0 ", or "10.00" depending on the precision of the measurement. The value is read in correctly and the concerned scientist can recover the precision of the number by inspecting the ASCII representation. The binary version throws away this information. There is no way to remedy the problem with a simple keyword, since the precision information can change from row to row. I strongly recommend that scientists generating binary tables pay attention to the precision of the data going into them. Fields where precision is important should be followed by a field that is an unsigned byte containing the number of significant figures in the primary data field. For example, TTYPE1 = 'Mag ' / Magnitude field TFORM1 = '1E ' / Single precision floating point TUNIT1 = 'mag ' / Units are magnitudes TTYPE2 = 'Mag_Prec' / Number of sig figs in Mag TFORM2 = '1B ' / Unsigned byte This may not be the most convenient of things to do, but it's important to keep the binary tables "honest". Authors of catalog data generally take great pains to make sure the machine-readable versions of their data truly reflect the actual values that were measured. We can't let the expedience of binary representations outweigh the importance of accurate scientific interpretation of the numbers. -- -- Lee E. Brotzman Internet: brotzman at nssdca.gsfc.nasa.gov -- Hughes STX SPAN: NSSDCA::BROTZMAN -- National Space Science Data Center BITNET: ZMLEB at SCFVM -- NASA Goddard Space Flight Center From hanisch at stsci.edu Tue Nov 26 20:29:14 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1904" "" "22" "November" "1991" "23:15:52" "GMT" "Bob Hanisch,N406,4910" "hanisch at stsci.edu" "<6072798 at toto.iv>" "42" "Re: Possible additional keywords for binary tables." "^From:" nil nil "11" "1991112223:15:52" "Possible additional keywords for binary tables." (number " " mark " Bob Hanisch,N406, Nov 22 42/1904 " thread-indent "\"Re: Possible additional keywords for binary tables.\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Organization: Space Telescope Science Institute Originator: hanisch at iris.stsci.edu From: hanisch at stsci.edu (Bob Hanisch,N406,4910) Subject: Re: Possible additional keywords for binary tables. Date: 22 Nov 91 23:15:52 GMT >From article <21NOV199118492538 at stars.gsfc.nasa.gov>, by thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040): > I've been looking into the question of using the binary tables extension for > SOHO data, and it seems to me that there are capabilities in basic FITS that > are not replicated in the binary tables extension, namely the keywords CTYPEn, > CRPIXn, CROTAn, CRVALn, CDELTn, DATAMAX, and DATAMIN. However, I believe that > I can overcome this problem by defining additional keywords for the binary > tables extension, such that > > DATAMIN --> TDMINm > DATAMAX --> TDMAXm > > CTYPEn --> TDESCm > CRPIXn --> TRPIXm > CROTAn --> TROTAm > CRVALn --> TRVALm > CDELTn --> TDELTm > > I separate out the first two keywords because these are fairly simple ones. > However, the other keywords are more complicated. The index n on the left > refers to a dimension in an array, while the index m on the right refers to > columns in a binary table. There aren't enough characters in an > eight-character FITS keyword to allow including both n and m in the name of the > keyword. > This approach seems overly complex and misses one of the more elegant aspects of binary tables, i.e., using the columns and column labels themselves to store information that was formerly in the main header. That is, rather than define a new keyword for CTYPEn, make CTYPEn a column LABEL, i.e., TFORM3 = '8A' TTYPE3 = 'CTYPE1' TFORM4 = '1D' TFORM4 = 'CRVAL1' etc. This is essentially identical to the indirect naming scheme we use in STSDAS data files for group parameters. The real virtue of this method is that you don't have to make up new names for things that have standard usages already defined. As I recall, this idea is included in the 'Green Bank' convention for binary tables. Bob Hanisch ST ScI From thompson at stars.gsfc.nasa.gov Tue Nov 26 20:29:23 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3696" "" "25" "November" "1991" "17:31:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov" "<6696205 at toto.iv>" "71" "Re: Possible additional keywords for binary tables." "^From:" nil nil "11" "1991112517:31:00" "Possible additional keywords for binary tables." (number " " mark " William Thompson, Nov 25 71/3696 " thread-indent "\"Re: Possible additional keywords for binary tables.\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics News-Software: VAX/VMS VNEWS 1.4-b1 Nntp-Posting-Host: stars.gsfc.nasa.gov From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Subject: Re: Possible additional keywords for binary tables. Date: 25 Nov 91 17:31:00 GMT In article <1991Nov22.231552.12194 at stsci.edu>, hanisch at stsci.edu (Bob Hanisch,N406,4910) writes... >From article <21NOV199118492538 at stars.gsfc.nasa.gov>, by thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040): >> ... I can overcome this problem by defining additional keywords for the binary >> tables extension, such that >> >> DATAMIN --> TDMINm >> DATAMAX --> TDMAXm >> >> CTYPEn --> TDESCm >> CRPIXn --> TRPIXm >> CROTAn --> TROTAm >> CRVALn --> TRVALm >> CDELTn --> TDELTm >> > ...This approach seems overly complex and misses one of the more elegant >aspects of binary tables, i.e., using the columns and column labels themselves >to store information that was formerly in the main header. That is, rather >than define a new keyword for CTYPEn, make CTYPEn a column LABEL, i.e., > >TFORM3 = '8A' >TTYPE3 = 'CTYPE1' >TFORM4 = '1D' >TFORM4 = 'CRVAL1' > >etc. This is essentially identical to the indirect naming scheme we use in >STSDAS data files for group parameters. The real virtue of this method is >that you don't have to make up new names for things that have standard usages >already defined. As I recall, this idea is included in the 'Green Bank' >convention for binary tables. It seems that in the FITS world, one person's overly complex is another person's simple. My reaction is that the above approach is more complex than putting everything into one keyword. I guess it depends on what you're used to. We, in fact, will be using that exact approach for certain keywords. Our binary tables will be organized so that each row represents a different exposure, and then the columns will be the individual parts of that exposure (for instance separate readout windows on the CCD). If a keyword parameter changes from exposure to exposure, then the above approach will be used. If, however, the keyword expresses a property of an entire column, then reproducing that information over and over again would be very wasteful, and would be more confusing than putting the information into a simple keyword. A lot of people seem to think the whole TDIMnnn approach is complex, and then come up with what I think are much more complex schemes to get around using it. What we've decided is that the TDIMnnn is the simplest, most direct way of entering multidimensional data into a binary table. Once we decided to use TDIMnnn, then the extensions to TDESCnnn, etc., fall out naturally. Certainly, the "Green Bank" approach is more traditionally FITS-like. If you want to think of your data as a series of basic FITS images, then the "Green Bank" approach expresses that situation well, and I can think of cases where that would be useful. In fact, I prefer to call it the "Virtual FITS" convention. However, that is not the case with our data. To use the binary tables effectively, we have to be able to store multidimensional arrays into a number of columns. We've looked at the "Green Bank" (or "Virtual FITS") approach, and there are real problems with fitting our data into that format. The problem is that it has no real way of separating out information that applies to an array that is part of an observation, and information that applies to an observation as a whole. One can do it, but it's very sloppy and inefficient. I don't believe we're alone in that situation either. One thing that the FITS community has to realize that there are a lot of people who've held off from using FITS because it doesn't meet their needs. I've talked to other people who've also been frustrated by the restrictive data model used by FITS in the past. Bill Thompson From dwells at fits.cx.nrao.edu Tue Nov 26 20:29:34 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4280" "Mon" "25" "November" "1991" "22:26:12" "GMT" "Don Wells" "dwells at fits.cx.nrao.edu" "<924276 at toto.iv>" "81" "Re: Possible additional keywords for binary tables." "^From:" nil nil "11" "1991112522:26:12" "Possible additional keywords for binary tables." (number " " mark " Don Wells Nov 25 81/4280 " thread-indent "\"Re: Possible additional keywords for binary tables.\"\n") nil] nil) Newsgroups: alt.sci.astro.fits In-Reply-To: thompson at stars.gsfc.nasa.gov's message of 25 Nov 91 17: 31:00 GMT Organization: National Radio Astronomy Observatory, Charlottesville, VA From: dwells at fits.cx.nrao.edu (Don Wells) Subject: Re: Possible additional keywords for binary tables. Date: Mon, 25 Nov 1991 22:26:12 GMT In article <25NOV199113313863 at stars.gsfc.nasa.gov> thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes: WT> ... It seems that in the FITS world, one person's overly complex WT> is another person's simple... Many things in life are like that. WT> ...Our binary tables will be organized so that each row WT> represents a different exposure, and then the columns will be the WT> individual parts of that exposure (for instance separate readout WT> windows on the CCD). If a keyword parameter changes from WT> exposure to exposure, then the above approach will be used. If, WT> however, the keyword expresses a property of an entire column, WT> then reproducing that information over and over again would be WT> very wasteful, and would be more confusing than putting the WT> information into a simple keyword. An alternative model is the relational database in 3rd-Normal-Form. Use *two* tables, one for exposure parameters, and one for the parts of the exposure. A unique exposure_id implicitly binds the two tables together. The result is an elegant combination of efficiency and homogeneity in the design, with additional advantages such as easy support for variable number of parts per exposure. If your instrument observes multiple sources you might want to have a third table for source parameters and use a unique source_id to implicitly bind sources to exposures. If you object to two (or three) tables, then "join" the tables and let the duplicate values of exposure (and source) parameters appear in the rows for the parts; the part matricies are probably big enough that the loss in efficiency will not be too bad. WT> ... If you want to think of your data as a series of basic FITS WT> images, then the "Green Bank" approach expresses that situation WT> well, and I can think of cases where that would be useful... The "Green Bank Convention" has two enormous advantages: (1) it inherits all of the accumulated design experience of the community, and the programmer training associated with that experience, so it stops the endless arguing and reduces documentation requirements, and (2) general programs can be specified which will transform a set of Basic FITS images into a table and then can invert that transformation, thus making the data available to a wider range of datasytems. WT> ... To use the binary tables effectively, we have to be able to WT> store multidimensional arrays into a number of columns... The WT> problem is that [the Green Bank Convention] has no real way of WT> separating out information that applies to an array that is part WT> of an observation, and information that applies to an observation WT> as a whole. One can do it, but it's very sloppy and inefficient. I don't agree with several of the assertions in this paragraph. See the discussion above. -=-=- Relational vs. Hierarchical -=-=- This difference of opinion is a special case of a traditional argument in the database community. Before 1970 almost all databases with technical problems like yours were designed in essentially the same manner that you are proposing. I say "before 1970" because that was when Codd presented the relational model of database design. Proponents of the older heirarchical model made arguments analogous to yours (and there are other arguments that you haven't yet made), and some of these people still make these arguments today. One by one many of the older systems have been redesigned using the relational model, essentially because practical experience during the 80s has shown that the resulting designs are easier to maintain and easier to use for applications development. The FITS BINTABLE extension is flexible enough to permit designers to build in either the heirarchical or the relational styles (the present discussion proves this), but because the usual heirarchical machinery is not explicitly included in the BINTABLE design it will usually be simpler to use the relational model. -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From markus at mso.anu.edu Tue Nov 26 20:29:41 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1706" "" "26" "November" "1991" "00:56:58" "GMT" "Markus Buchhorn" "markus at mso.anu.edu" "<6009076 at toto.iv>" "47" "Re: Possible additional keywords for binary tables." "^From:" nil nil "11" "1991112600:56:58" "Possible additional keywords for binary tables." (number " " mark " Markus Buchhorn Nov 26 47/1706 " thread-indent "\"Re: Possible additional keywords for binary tables.\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Organization: Mt. Stromlo Observatory, Canberra, Australia From: markus at mso.anu.edu (Markus Buchhorn) Subject: Re: Possible additional keywords for binary tables. Date: 26 Nov 91 00:56:58 GMT thompson at stars.gsfc.nasa.gov (William Thompson) wrote: [he didn't write the >>> stuff, I think.. sorry] >>> ... I can overcome this problem by defining additional keywords for the binary >>> CRVALn --> TRVALm >>> CDELTn --> TDELTm >>> >It seems that in the FITS world, one person's overly complex is another >person's simple. My reaction is that the above approach is more complex than >putting everything into one keyword. I guess it depends on what you're used >to. [Discussion about putting single values into n format, or putting multiple values into a single ...] > >Bill Thompson It appears that either approach has its benefits, depending who wants to use it for what type of data. Perhaps a case could be made for the following: Where a FITS file contains more than a single data-block (multiple exposures, whatever), the user can decide to use either approach for keywords, as long as they follow this convention: (i) A single keyword containing multiple values, or a single value applicable to all the data blocks under that header should have the form 0 (e.g. CDELT0) (ii) Whereas separate keywords containing a single value for a particular data block should have the form n (e.g. CDELT1, CDELT2, etc.) As far as I can tell ( which isn't all that far :-) ) this should be quite easy to implement in any FITS reader that has to handle either format anyway. Possibly something can be done to split case (i) if needs be - perhaps m and s for multiple or single values for that keyword. Cheers, Markus markus at mso.anu.edu.au #include /* Maybe I misread the intent of what you wrote :-)*/ From dc at stars.gsfc.nasa.gov Tue Nov 26 20:29:45 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["281" "Tue" "26" "November" "1991" "16:13:00" "GMT" "Dave Cottingham" "dc at stars.gsfc.nasa.gov" "<5661617 at toto.iv>" "8" "Need a FITS reader that supports binary table extensions" "^From:" nil nil "11" "1991112616:13:00" "Need a FITS reader that supports binary table extensions" (number " " mark " Dave Cottingham Nov 26 8/281 " thread-indent "\"Need a FITS reader that supports binary table extensions\"\n") nil] nil) Newsgroups: alt.sci.astro.fits News-Software: VAX/VMS VNEWS 1.4-b1 Nntp-Posting-Host: stars.gsfc.nasa.gov Reply-To: dc at cobi.gsfc.nasa.gov Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics From: dc at stars.gsfc.nasa.gov (Dave Cottingham) Subject: Need a FITS reader that supports binary table extensions Date: Tue, 26 Nov 1991 16:13:00 GMT As I mentioned in the subject line, I need a FITS reader that supports the binary table extensions. In case it matters, I need to use it on VMS, and one that works on a Unix box would also come in handy. All hints much appreciated. Thanks, Dave Cottingham dc at cobi.gsfc.nasa.gov From oneel at heasfs.gsfc.nasa.gov Tue Nov 26 20:29:56 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["217" "Tue" "26" "November" "1991" "18:30:12" "GMT" "oneel at heasfs.gsfc.nasa.gov ( Bruce Oneel )" "oneel at heasfs.gsfc.nasa.gov ( Bruce Oneel )" "<6640439 at toto.iv>" "7" "Need a FITS reader that supports binary table extensions" "^From:" nil nil "11" "1991112618:30:12" "Need a FITS reader that supports binary table extensions" (number " " mark " oneel at heasfs.gsfc Nov 26 7/217 " thread-indent "\"Need a FITS reader that supports binary table extensions\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Organization: National Radio Astronomy Observatory From: oneel at heasfs.gsfc.nasa.gov ( Bruce Oneel ) Subject: Need a FITS reader that supports binary table extensions Date: Tue, 26 Nov 1991 18:30:12 GMT I've written one which uses bill pence's FITSIO libraryies on tetra.gsfc.nasa.gov. I'd be happy to send you the fits reader, though it's still a little rough around the edges (think of it as a beta version). bruce From thompson at stars.gsfc.nasa.gov Sat Nov 30 13:41:03 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1402" "" "26" "November" "1991" "23:17:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov" "<8221832 at toto.iv>" "25" "Re: Possible additional keywords for binary tables." "^From:" nil nil "11" "1991112623:17:00" "Possible additional keywords for binary tables." (number " " mark " William Thompson, Nov 26 25/1402 " thread-indent "\"Re: Possible additional keywords for binary tables.\"\n") nil] nil) Newsgroups: alt.sci.astro.fits Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics News-Software: VAX/VMS VNEWS 1.4-b1 Nntp-Posting-Host: stars.gsfc.nasa.gov From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Subject: Re: Possible additional keywords for binary tables. Date: 26 Nov 91 23:17:00 GMT There seem to be several people who think that the multidimensional array proposal from Appendix A of Cotton and Tody's Binary Table Extension proposal is a bad idea, and that the community should standardize on the "Green Bank" convention instead. To summarize, The multidimensional array proposal says that there should be additional keywords, TDIM1, TDIM2, etc. for the various binary table columns to describe them as being multidimensional. The structure of the keyword (and this seems to be the sticking point) is that it defines a 20x30 array in column 1 (for example) with the statement TDIM1='(20,30)'. Some people don't like the idea of having to parse this string to get the dimensions. The "Green Bank" proposal turns a binary table into a series of ordinary basic FITS files, with a column for NAXIS, a column for NAXIS1, etc., and a column for the data itself. One could also have columns for other items that would ordinarily be keywords in a basic FITS file. I say that the "Green Bank" proposal is fine if your data fits a model based on a simple series of arrays. I can see where that would be very useful. But I argue that our data more complex than that, and that we want to use the full power of binary tables. Therefore, I am throwing my support behind Appendix A >from the Cotton and Tody proposal. I don't see any problem in parsing character strings. Bill Thompson From thompson at stars.gsfc.nasa.gov Tue Nov 19 22:07:09 1991 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1130" "Tue" "19" "November" "1991" "21:06:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov" "<859946 at toto.iv>" "23" "Re: FITS plans for SOHO." "^From:" nil nil "11" "1991111921:06:00" "FITS plans for SOHO." (number " " mark " William Thompson, Nov 19 23/1130 " thread-indent "\"Re: FITS plans for SOHO.\"\n") nil] nil) Newsgroups: alt.sci.astro.fits News-Software: VAX/VMS VNEWS 1.4-b1 Nntp-Posting-Host: stars.gsfc.nasa.gov Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Subject: Re: FITS plans for SOHO. Date: Tue, 19 Nov 1991 21:06:00 GMT In article <1991Nov18.225256.4063 at elroy.jpl.nasa.gov>, baalke at kelvin.jpl.nasa.gov writes... >In article <18NOV199116070809 at stars.gsfc.nasa.gov>, thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes... > >>The following LaTeX document (landscape orientation) shows some slides I used >>recently to present some possibilities of using FITS for the data from the >>upcoming Solar Heliospheric Observatory (SOHO). > >The SOHO data will be Reed Solomon encoded when it is transmitted by the >spacecraft, and then decoded at the tracking station. However, the check >symbols will still be in place at the end of each frame of data. Does FITS >provide some mechanism to ignore portions of the data, in this case the >check symbols? If the check symbols are removed and the data pieced together >before being converted to FITS, then this wouldn't be a problem. I was only talking about level-1 data products generated by the P.I. teams in the Experiment Operations Facility, e.g. the summary data, etc. This has nothing to do with the way the level-0 data is formatted for telemetry purposes. Bill Thompson