From leb at Hypatia.gsfc.nasa.gov Wed Jul 1 12:11:59 1992 X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil X-VM-Bookmark: 25 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1382" "" "1" "July" "92" "14:37:29" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "27" "Re: ODL and ASN.1" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Keywords: Data interchange, standards Organization: Goddard Space Flight Center Nntp-Posting-Host: hypatia.gsfc.nasa.gov From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Subject: Re: ODL and ASN.1 Date: 1 Jul 92 14:37:29 GMT Both Bill Thompson and Chris Flatters are correct in their assessment of ODL and ASN.1, and I'm not suggesting that they be used to completely replace FITS (at least not yet, anyway). I just want the FITS people to know that there are other, richer, data description languages out there. I also posted my original letter to the WGAS mailing list, and I think that I'll pursue further discussion over there. The astronomical community may find that it has a use for other commonly used data transfer formats -- heretical as that thought may be. By the way, I'll be starting up a newsgroup to accompany the WGAS mail exploder called alt.sci.astro.wgas as soon as I can get the attention of the Goddard newsfeed lords long enough to set up the two-way link to the mail exploder. If you don't get the alt. news hierarchy, you can subscribe to the WGAS mail exploder by sending E-mail to listserv at hypatia.gsfc.nasa.gov. In the body of the mail message (not the subject line) put the command: SUBSCRIBE WGAS Your Name where "Your Name" is your name, not your E-mail address. LISTSERV will get the mailing address from the mail headers. -- -- Lee E. Brotzman Internet: leb at hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- National Space Science Data Center BITNET: ZMLEB at SCFMVS -- NASA Goddard Space Flight Center From hybl at umbc4.umbc.edu) Wed Jul 1 20:34:48 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2395" "Wed" "1" "July" "1992" "23:54:48" "GMT" "UMAB-BIOPHYS" "hybl at umbc4.umbc.edu (Dr. Albert Hybl )" nil "45" "On using .fits as a file extension" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Organization: University of Maryland Baltimore Campus From: hybl at umbc4.umbc.edu (Dr. Albert Hybl (UMAB-BIOPHYS)) Subject: On using .fits as a file extension Date: Wed, 1 Jul 1992 23:54:48 GMT The extension '.fits' does not guaranty anything about the contents of the file. The contents of the file must be examined to validate that it conforms with the FITS standard. The extension is just a lazy man's way to remember something. I have seen the extensions: '.f', '.F', '.for', '.ftn' and others used to identify F77 Fortran source code. I _store_ my FITS files with the extension '.fits.Z' where the '.Z' indicates that the files are compressed. I don't think that I can present an 'image.fits.Z' file to IRAF. Why not? The '.Z' extension is more standard than '.fits'; I would like to have the programs look for '.Z' and if the program finds that the file isn't a standard FITS file after uncompressing, if necessary, then the program can take some error action. When the 'uncompress' program tries to uncompress a fake 'file.Z,' it outputs the message: "file.Z: not in compressed format." Surely IRAF and other programs could do likewise after examination of the contents of the file. The driving force for this thread seems to be a desire to supplement or perhaps supplant the use of magnetic tape as the standard image trans- port modality and to begin to consider the _general_ availability of astronomy images from internet archives and/or on CD-ROM. Clearly one must begin to consider conforming specifications for archiving image data and especially for an efficient retrieval system. Perhaps there already is such a system, I'm not the person who would know. (See the discussion of ODL and ASN.1 etc.) Here are two tidbits of information I have read in other newsgroups: Two CD-ROM Filesystem Formats: High Sierra and Rock Ridge. ========================== The High Sierra format is common and also known as ISO-9660 and characterized by MS-DOS file naming conventions and an 8-level deep MAXIMUM directory hierarchy. The Rock Ridge format is newer and permits UNIX-style file-naming conventions and directory depths. Filesystem Name lengths: DOS/8+3 S5/14 BSD/255 bytes. ===================================== The 14-byte length limit for filenames and path component names plus the lack of symbolic links are two deficiencies extant in my S5 UNIX system for things I would like to do with my AT&T 3B1 computer. Regards, Albert Hybl (hybl at umbc3.umbc.edu) From dwells at azalea.cx.nrao.edu Thu Jul 2 12:24:22 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2633" "Thu" "2" "July" "1992" "17:23:33" "GMT" "Don Wells" "dwells at azalea.cx.nrao.edu " nil "47" "Re: ODL and ASN.1" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits In-Reply-To: leb at Hypatia.gsfc.nasa.gov's message of 1 Jul 92 14: 37:29 GMT Organization: National Radio Astronomy Observatory, Charlottesville, VA. From: dwells at azalea.cx.nrao.edu (Don Wells) Subject: Re: ODL and ASN.1 Date: Thu, 2 Jul 1992 17:23:33 GMT In article leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) writes: LEB> ... I'm not suggesting that [ODL and ASN.1] be used to LEB> completely replace FITS (at least not yet, anyway). I just want LEB> the FITS people to know that there are other, richer, data LEB> description languages out there.. The astronomical community may LEB> find that it has a use for other commonly used data transfer LEB> formats.." ODL and ASN.1 are fine ideas, but they are not necessarily superior to the current FITS agreements for the purposes of interchange and archiving of astronomical datasets. The BINTABLE format (descriptive language) is strong enough to describe most object types currently used in astronomy, and the cases which it does not explicitly support can be implemented by conventions layered on top of BINTABLE (I am not aware of any interesting exceptions to this assertion). In particular, the vector fields (blobs) will permit encapsulation of other objects (BINTABLEs inside BINTABLEs) and the character fields can be used to "point" to other BINTABLEs (trees of sets of objects). The proposed Appendix-B pointer convention will support variable-sized objects. The ODL and ASN.1 notations for describing objects are much more terse than the equivalent FITS notations, but terseness of description has never been the primary design objective in FITS negotiations. Our goal has always been to produce archival-quality self-describing (paperless) datasets for interchange and archiving. An important property of our architecture is that it does not depend on an (ephemeral?) central registry of object descriptions. There are indeed interchange formats which solve problems for which FITS does not currently have good solutions. The GIS [Geographic Information Systems] community has developed a format used by USGS and others to digitize the information carried in maps. At present I do not believe that astronomy has applications of this type, but if it did I would advocate that the FITS community simply declare XTENSION='' to encapsulate the bitstream of the GIS standard inside FITS files. In a similar fashion I believe that there may be a good argument for agreeing to use XTENSION='TIFF' to attach quick-look overview renderings of FITS objects to the files containing those objects. -- 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 fischer at physun.physics.mcmaster.ca Sun Jul 5 17:58:56 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["359" "" "5" "July" "92" "17:59:20" "GMT" "Phil Fischer" "fischer at physun.physics.mcmaster.ca " nil "12" "Converting Fits to an SGI RGB file" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Organization: Dept. of Physics & Astronomy, McMaster University Nntp-Posting-Host: physun.physics.mcmaster.ca From: fischer at physun.physics.mcmaster.ca (Phil Fischer) Subject: Converting Fits to an SGI RGB file Date: 5 Jul 92 17:59:20 GMT If anybody has a program which converts fits to Silicon Graphics RGB format I would be very grateful if he/she would send me a copy. Thank You Phil Phil Fischer | Hamilton, Ont. Fischer at Crocus.Physics.McMaster.Ca | Canada Dept. of Physics and Astronomy | L8S 4M1 McMaster University | 416-525-9140 X 4574 From dwells at azalea.cx.nrao.edu Mon Jul 6 17:44:50 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2037" "Mon" "6" "July" "1992" "22:39:05" "GMT" "Don Wells" "dwells at azalea.cx.nrao.edu " nil "44" "Re: VLBA UV-data FITS test files" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits In-Reply-To: mcs at goblin.caltech.edu's message of Sat, 27 Jun 1992 03: 42:59 GMT Organization: National Radio Astronomy Observatory, Charlottesville, VA. From: dwells at azalea.cx.nrao.edu (Don Wells) Subject: Re: VLBA UV-data FITS test files Date: Mon, 6 Jul 1992 22:39:05 GMT In article <1992Jun27.034259.18877 at cco.caltech.edu> mcs at goblin.caltech.edu (Martin Shepherd) writes: "... I have just been reading the draft proposal for the new FITS format for interferometer UV data exchange. Does anybody know if there are any FITS test files in this format - available by anonymous ftp?..." anonFTP fits.cx.nrao.edu[192.33.115.8]:/FITS/SampleData/VLBA contains: 1485 Jul 6 16:19 README 318012 Jun 19 12:32 VLBA_format.ps 8663040 Jun 23 16:23 j000015.fits 12426 Jul 6 15:40 j000015.lis The README says: -*- Sample VLBA distribution file -*- The FITS file in this directory, j000015.fits, was produced by the VLBA Correlator in late June 1992, just before the machine was disassembled for shipment to New Mexico. The file contains fringe visibilities from an astronomical source observed by a five-station array in early April. The file format is described in the document VLBA_format.ps; it is a set of binary tables ('BINTABLE' extensions). Current TST versions of AIPS are said to be able to read this file. Those who are interested solely in the header syntax, not in the visibility data, should get the file j000015.lis, which contains an ASCII listing of the headers of all the tables plus size information for the binary records. This sample distribution file does *not* conform exactly to the format described in the document. In particular, the UV data table does not have the integration time column which is specified in the document. Both the document and the file format should be regarded as *DRAFT*; details will be subject to change in the coming months. Send comments or questions about the VLBA format to John Benson (jbenson at nrao.edu) and/or Phil Diamond (pdiamond at nrao.edu). -- 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 pence at heawk1.gsfc.nasa.gov Fri Jul 10 22:56:30 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2302" "" "8" "July" "92" "20:49:34" "GMT" " William Pence" "pence at heawk1.gsfc.nasa.gov " nil "59" "FITSIO V3.21 is available" "^From:" nil nil "7"]) Newsgroups: 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: FITSIO V3.21 is available Date: 8 Jul 92 20:49:34 GMT FITSIO - Version 3.21 8 July 1992 This is to announce that Version 3.21 of the FITSIO package is now available. FITSIO is a powerful yet simple to use Fortran subroutine interface for reading and writing files in FITS format. This 3.21 version of FITSIO is 100% upwardly compatible with the previous 3.20 version and contains the following new features: NEW SUBROUTINES: - support for Lehey Fortran on IBM PCs - new more robust family of subroutines to read and write the required header keywords - 3 additional subroutines to make it easier to read or modify header keywords ENHANCEMENTS: - improved documentation file - changed the way FITSIO handles arrays of ASCII strings to be compatible with the proposed binary table format - rewrote several of the previously machine-specific subroutines in portable Fortran-77, to make it easier to port FITSIO to new machines. - improved the functionality of several other subroutines BUG FIXES: - fixed 9 (relatively small) bugs in various FITSIO subroutines For further details on these new features, see the 'release.doc' file in the FITSIO distribution directory. The FITSIO software, documentation, and example programs are available via anonymous ftp from: ftp tetra.gsfc.nasa.gov (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/DECnet node: NDADSA::HEASARC:[EXOSAT.XANADU.FITS.FITSIO] -------------------------------------------------------------------------- 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 thompson at stars.gsfc.nasa.gov Tue Jul 14 14:42:42 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["5548" "Tue" "14" "July" "1992" "15:39:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "124" "Summary: Storing long keywords in FITS files" "^From:" nil nil "7"]) Newsgroups: 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: Summary: Storing long keywords in FITS files Date: Tue, 14 Jul 1992 15:39:00 GMT A while back I had asked the following question Is there any kind of defacto way to store keywords longer than eight characters in a FITS header? Someone suggested using the COMMENT keyword followed by the non-standard keyword, although another possibility is using the null keyword (eight blanks). Is this what other people do? I'm not talking about keywords essential to reading and scientifically processing the data. I'm more interested in storing engineering information about the state of the instrument. It would be desirable to retain the original mnemonic names used by the engineers. Important information could also be replicated using more standard FITS keywords. Although it's obviously legal to put anything in a COMMENT field, I'm interested in knowing what other people do. I think that the problem of storing and manipulating keywords of greater than eight characters in length is important for the future growth of FITS, particularly if one wants to be able to move data back and forth between FITS and other scientific file formats such as SFDU/PVL. The functionality I was looking for was not simply to store the information, but to be able to retrieve and manipulate that information as well. Of the responses I got back, I was attracted to one in particular. First, because it is already in use at at least one major site, and second because it seems to offer the kind of functionality and expandability I need. That response, from Eric Greisen at NRAO, is as follows: The solution we have used at NRAO (at it is even quietly present in the original FITS paper!) is to have HISTORY cards. As the first word in the HISTORY we put an identifier that says that we have written the card, e.g. NRAO or AIPS. Then we put one or more keyword=value pairs, with any old arbitrary choice of keywords. Our FITS readers check each HISTORY card's next word and if it is one of a few magic ones they parse the rest of the card. Otherwise, they ignore the card as non-NRAO readers are expected to do with all our cards as well. I like this idea. However, I think I would make the magic work something unusual so that it wouldn't be confused with some ordinary text message. For instance, I think I would preface it with "K_" to represent special keyword. Thus, I could have something like HISTORY K_SOHO MYSTRINGKEY = "This is a string" /Comment HISTORY K_SOHO MYINTEGERKEY = 3 /Another comment I don't know if HAO does it or not, but I would even allow for FITS-like comments, delimited by slashes, as shown above. I wouldn't be picky about the number of spaces between the various elements, or exactly which columns the values occur in. The only trouble I would anticipate would be with complex values, because the FITS standard has the real and imaginary parts occuring in specific columnar regions, which wouldn't be possible here. A somewhat similar solution, from David Robinson, is shown below. However, I'm less attracted to it because it doesn't seem to be oriented toward recovering and manipulating the data electronically. It seems clear to me that the keywords should be reserved for storing information that is essential for the processing of the data. Information that records how the data was generated (such as instrument settings, options given to the processing software etc.) should properly be stored in HISTORY records. For example, here is the FITS header for an output file from an image processing program that I have written: SIMPLE = T BITPIX = -32 NAXIS = 2 NAXIS1 = 512 NAXIS2 = 1 DATE = '29/05/92' HISTORY Written by TOY3 HISTORY set nrand 1 HISTORY set tol 0.1 HISTORY set background 5 HISTORY set entropy standard HISTORY set image "line.dat" HISTORY set psf "psf1.dat" HISTORY var chisq 196.25 HISTORY var iter 6 HISTORY var sigma 2.78645 HISTORY command write image "out.dat" END The HISTORY cards record the program used, the parameters given by the user (set..), the variables that the program found, (var...) and the command given to write out the file. Simon Ellingsen writes: Instead of putting this type of none standard information in the header, why don't you use a binary extension table. Then you effectively store the keywords in the TFORMn value which doesn't have the eight character restriction. I agree, and intend to do just that when appropriate. However, some data would apply to the table as a whole, or to a primary FITS HDU. A couple of people suggested converting the long keywords to an eight-character equivalent, and then storing the real name in the comment. Edward J. Groth >from Princeton writes: How about KKKKKKKK=value / Engineering keyword here And Thierry Forveille of the Observatoire de Grenoble writes: Althought I never had to face that specific problem, I would suggest you store the information with a standard keyword and append the original mnemonic as an end of line comment (after the /). This is standard too, and the information will be easier to extract for a general FITS handling program if you later want to plot this engineering information. Extracting the information from a COMMENT or blank keyword would probably need ad hoc (though trivial) modifications of the program. Of course the standard keyword need not be particularly informative and something line ENGIN001 to ENGIN999 would work. I thank everybody for their input. Bill Thompson From thompson at stars.gsfc.nasa.gov Tue Jul 14 16:12:18 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2663" "Tue" "14" "July" "1992" "17:57:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "53" "Variable length character string arrays." "^From:" nil nil "7"]) Newsgroups: 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: Variable length character string arrays. Date: Tue, 14 Jul 1992 17:57:00 GMT A while back there was a bunch of discussion about devising a standard for denoting the length of character strings in an array of character strings in a binary table. It started off when Bill Pence suggested using TFORMn = 'rAw' where 'r' is the total number of characters in the array, and 'w' is the number of characters in each character string element of the array. However, it was also pointed out (by Doug Tody?) that character strings could also be variable length, delimited by a particular byte value. I believe the suggestion for that was TFORMn = 'rA\ooo' where 'ooo' was the octal representation of the delimiting byte. I myself suggested using separate keywords, TCLENn and TCDELn, to express either the fixed length, or variable length delimiter. I've been thinking some more about storing variable length strings in binary tables. I've convinced myself that two pieces of information have to be supplied to allow all readers to be able to parse the information. The first piece, of course, is the value of the delimiter byte. The second desirable piece of information is the maximum length of the character string. I have worked with environments which could only handle string arrays where each element of the array had the same string length as all the others (e.g. the original VMS version of IDL). While I don't currently work with anything that has this limitation, I'm not sure we can guarantee that all environments won't be so limited. In such a situation, it would be an advantage to know a priori the largest size the string element could obtain, so that the string array could be properly initialized. I think that this approach is similar to that taken by the "Variable Length Array Facility" described in the binary tables proposal, where the number of elements of the array is variable, but the maximum possible number of elements is stored in the TFORM keyword. Hence, the most desirable standard for delimiting the individual character strings in a character string array would have the following characteristics: 1. It would work for both fixed-length and variable-length (byte-delimited) character strings. 2. It would work for both direct (TFORM='rA') and pointer (TFORM='PA') binary table columns. 3. For fixed-length strings, it would specify the character length. 4. For byte-delimited strings, it would specify both the byte code used to delimit the strings, and a maximum length that the string will not exceed. A remaining question is whether this information is best appended to the TFORM keyword, or stored in one or more separate keywords. Bill Thompson From stoll at ocf.berkeley.edu Wed Jul 15 06:43:24 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["635" "" "15" "July" "92" "04:01:03" "GMT" "Cliff Stoll" "stoll at ocf.berkeley.edu " nil "16" "minus signs in Fits keywords" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Organization: U. C. Berkeley Open Computing Facility NNTP-Posting-Host: headcrash.berkeley.edu From: stoll at ocf.berkeley.edu (Cliff Stoll) Subject: minus signs in Fits keywords Date: 15 Jul 92 04:01:03 GMT The Fits standard originally aimed at Fortran Namelist compatabilty with header file keywords. I don't think anyone's using Fortran namelist utilities to read Fits header files, but it's still an admirable goal. It's also useful to map fits keywords directly onto program variables. As written, however, Fits permits (and encourages) embedded minus signs in keywords, for instance, MAX-RA. Such keywords are incompatible with namelist reading and cannot be mapped onto program variables in most languages. This problem's been around for a while, but I trip over it every couple years. -Cliff Stoll stoll at ocf.berkeley.edu From pence at heawk1.gsfc.nasa.gov Wed Jul 15 16:47:43 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1765" "Wed" "15" "July" "1992" "18:02:00" "GMT" " William Pence" "pence at heawk1.gsfc.nasa.gov " nil "42" "Re: Variable length character string arrays." "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Nntp-Posting-Host: heawk1.gsfc.nasa.gov Organization: Goddard Space Flight Center From: pence at heawk1.gsfc.nasa.gov ( William Pence) Subject: Re: Variable length character string arrays. Date: Wed, 15 Jul 1992 18:02:00 GMT Here is how I would implement Bill Thompson's requirements for string arrays: >Hence, the most desirable standard for delimiting the individual character >strings in a character string array would have the following characteristics: > > 1. It would work for both fixed-length and variable-length > (byte-delimited) character strings. TFORM1 = 'rAw' / fixed length strings; r = total no. of characters / and w = length of each fixed-length string TFORM1 = 'rA\ooo' / byte delimited strings where 'ooo' is the octal byte > 2. It would work for both direct (TFORM='rA') and pointer (TFORM='PA') > binary table columns. TFORM1 = 'rAw' / fixed length strings, direct TFORM1 = 'rA\ooo' / byte delimited strings, direct TFORM1 = 'PAw(r)' / fixed length strings, pointer TFORM1 = 'PA\ooo(r)' / byte delimited strings, pointer > 3. For fixed-length strings, it would specify the character length. The 'w' integer field in all the above examples represents the fixed-length > 4. For byte-delimited strings, it would specify both the byte code > used to delimit the strings, and a maximum length that the string > will not exceed. The integer 'r' field in all the above cases is the maximum length of a delimited string. In general, a single string could fill the entire field >A remaining question is whether this information is best appended to the TFORM >keyword, or stored in one or more separate keywords. I strongly believe all this information should be encoded into the single TFORM keyword. Otherwise, FITS readers/writers have to be made more complicatd to handle the extra keywords, which are not needed for columns with any other datatype. -Bill Pence From thompson at stars.gsfc.nasa.gov Thu Jul 16 06:58:30 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2184" "" "15" "July" "92" "21:24:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "49" "Re: Variable length character string arrays." "^From:" nil nil "7"]) Newsgroups: 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: Variable length character string arrays. Date: 15 Jul 92 21:24:00 GMT In article , pence at heawk1.gsfc.nasa.gov ( William Pence) writes... > >Here is how I would implement Bill Thompson's requirements for string arrays: > (stuff deleted) >> 4. For byte-delimited strings, it would specify both the byte code >> used to delimit the strings, and a maximum length that the string >> will not exceed. > >The integer 'r' field in all the above cases is the maximum length of a >delimited string. In general, a single string could fill the entire field If one has > TFORM1 = 'rA\ooo' / byte delimited strings, direct > TFORM1 = 'PA\ooo(r)' / byte delimited strings, pointer and I want to read this into a string array, then I don't know how many string elements to assign to the array, nor do I know many characters to allocate for each string, if my environment required me to do it. The extremes are that there could be as many as r/2 strings of one character each (if r is even), or one string with r characters. The most conservative approach would be to allocate an array of r/2 elements, each of which with r characters, leading to a total of r^2/2 characters for the resulting array, which is ridiculous. I guess that I don't just want to know how big the string can get; I also want to know how many strings there are. Note that this is not a problem with the simpler approach > TFORM1 = 'rAw' / fixed length strings, direct > TFORM1 = 'PAw(r)' / fixed length strings, pointer For my own part, it's this kind of string I would most expect to store in FITS files. It's worth thinking about variable length strings, though. Finally, >I strongly believe all this information should be encoded into the >single TFORM keyword. Otherwise, FITS readers/writers have to be >made more complicatd to handle the extra keywords, which are not needed >for columns with any other datatype. The philosophy behind the TFORM keyword seems to be to define things at an atomic level. The question then comes up: is one atom of character string data a string or a character? From a user's point of view, it should be the former, but the answer may be software sensitive. Bill Thompson From thompson at stars.gsfc.nasa.gov Thu Jul 16 06:58:54 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["909" "" "15" "July" "92" "20:57:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "22" "Re: minus signs in Fits keywords" "^From:" nil nil "7"]) Newsgroups: 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: minus signs in Fits keywords Date: 15 Jul 92 20:57:00 GMT In article <1407tvINNje9 at agate.berkeley.edu>, stoll at ocf.berkeley.edu (Cliff Stoll) writes... >The Fits standard originally aimed at Fortran Namelist compatabilty >with header file keywords. I don't think anyone's using >Fortran namelist utilities to read Fits header files, but it's >still an admirable goal. It's also useful to map fits keywords >directly onto program variables. > >As written, however, Fits permits (and encourages) embedded minus >signs in keywords, for instance, MAX-RA. > >Such keywords are incompatible with namelist reading and cannot >be mapped onto program variables in most languages. > >This problem's been around for a while, but I trip over it every >couple years. > >-Cliff Stoll stoll at ocf.berkeley.edu For similar reasons, I'm recommending to the SOHO project that all keywords not use embedded minus sign characters, but use underscores instead. Bill Thompson From bschlesinger at nssdca.gsfc.nasa.gov Thu Jul 16 20:23:08 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1742" "" "16" "July" "92" "21:33:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "43" "Re: minus signs in Fits keywords" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Organization: NASA - Goddard Space Flight Center News-Software: VAX/VMS VNEWS 1.41 Nntp-Posting-Host: nssdca.gsfc.nasa.gov From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Subject: Re: minus signs in Fits keywords Date: 16 Jul 92 21:33:00 GMT In article <15JUL199216574340 at stars.gsfc.nasa.gov>, thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes... >In article <1407tvINNje9 at agate.berkeley.edu>, stoll at ocf.berkeley.edu (Cliff Stoll) writes... >>The Fits standard originally aimed at Fortran Namelist compatabilty >>with header file keywords. I don't think anyone's using >>Fortran namelist utilities to read Fits header files, but it's >>still an admirable goal. It's also useful to map fits keywords >>directly onto program variables. >> >>As written, however, Fits permits (and encourages) embedded minus >>signs in keywords, for instance, MAX-RA. In FITS Paper I (A&A 1981, 44,363) the reserved and recommended DATE-OBS keyword uses the hyphen (ASCII hexadecimal 2D). Because, "we are not permitted to alter the basic format in such a way as to make existing FITS tapes invalid" (Paper III, A&A 1988, 73, p. 360, section 4) and the hyphen appears on many FITS data sets that use Paper I as a model, its use cannot be forbidden now. I wouldn't say that future use is necessarily being encouraged. A straw in the wind is the ASCII Tables paper (A&A 1988 73,359) recommendation that only letters (upper case) numbers, and underscore be used for values of the TTYPEn keywords. >> >>Such keywords are incompatible with namelist reading and cannot >>be mapped onto program variables in most languages. >> >>This problem's been around for a while, but I trip over it every >>couple years. > >For similar reasons, I'm recommending to the SOHO project that all keywords not >use embedded minus sign characters, but use underscores instead. > I would endorse this approach for user-defined keywords. Barry Schlesinger FITS Support Office From zarate at scivax.stsci.edu Fri Jul 17 13:40:47 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1504" "Fri" "17" "July" "1992" "17:13:58" "GMT" "zarate at scivax.stsci.edu" "zarate at scivax.stsci.edu" nil "54" "TNULL's in TABLEs." "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Organization: Space Telescope Science Institute Distribution: na From: zarate at scivax.stsci.edu Subject: TNULL's in TABLEs. Date: Fri, 17 Jul 1992 17:13:58 GMT Hello I would like to ask the opinion of those who have written FITS programs with TABLE extension, or have good idea what is the interpretation of the FITS NOST document when dealing with null strings on overlapping fields. For example: A FITS TABLE descriptors for columns 6,7,8 are: TTYPE6 = 'Class ' TBCOL6 = 54 TFORM6 = 'A5 ' TNULL6 = '* ' TTYPE7 = 'Type ' TBCOL7 = 54 TFORM7 = 'A1 ' TNULL7 = '* ' TTYPE8 = 'Class_No' TBCOL8 = 55 TFORM8 = 'I4 ' TNULL8 = ' ' The FITS table data in one of the lines that have a null value is: ....... * 32 where the '*' is at column 54. My thougths about this are as follows: 1) The column 6 descriptor specified a width of 5 characters; so the data entry for the column is null, right? 2) The column 7 descriptor specified a width of 1 character; so the data entry for the column is null, right? 3) The column 8 descriptor specified a width of 4 character; so the data entry for the column is 32. If the above is correct, that this means that a correct null entry for a 'A5' format is '* &+(' or it has to be '* '; because '32' is garbage for the column 6 specification since the fields overlap. The NOST document in 8.1.2 says "TNULLn Keywords. ....The string is implicitly blank filled to the width of the field". Thank you Nelson Zarate (nelson at stsci.edu) Space Telescoope Science Institute Baltimore MD 21218 From leb at Hypatia.gsfc.nasa.gov Sat Jul 18 21:23:34 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2556" "Sat" "18" "July" "1992" "20:22:45" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "77" "Re: TNULL's in TABLEs." "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Nntp-Posting-Host: hypatia.gsfc.nasa.gov Organization: Goddard Space Flight Center Distribution: na From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Subject: Re: TNULL's in TABLEs. Date: Sat, 18 Jul 1992 20:22:45 GMT zarate at scivax.stsci.edu writes: > For example: A FITS TABLE descriptors for columns 6,7,8 are: > >TTYPE6 = 'Class ' >TBCOL6 = 54 >TFORM6 = 'A5 ' >TNULL6 = '* ' > >TTYPE7 = 'Type ' >TBCOL7 = 54 >TFORM7 = 'A1 ' >TNULL7 = '* ' > >TTYPE8 = 'Class_No' >TBCOL8 = 55 >TFORM8 = 'I4 ' >TNULL8 = ' ' > > The FITS table data in one of the lines that have a null value >is: > > ....... * 32 > >where the '*' is at column 54. > > My thougths about this are as follows: > > 1) The column 6 descriptor specified a width of 5 characters; so the > data entry for the column is null, right? Wrong. The NULL value given for field Class is "* ", the given field is "* 32" which doesn't match. > 2) The column 7 descriptor specified a width of 1 character; so the > data entry for the column is null, right? Right. This field matches it's (one character) null value specification. > 3) The column 8 descriptor specified a width of 4 character; so the > data entry for the column is 32. Right. This field has a valid data value. The null value for field Class_No is " " (exactly four blank characters). > If the above is correct, that this means that a correct null entry >for a 'A5' format is '* &+(' or it has to be '* '; because '32' is >garbage for the column 6 specification since the fields overlap. >The NOST document in 8.1.2 says "TNULLn Keywords. ....The string is >implicitly blank filled to the width of the field". Personally I think that this is a case of an error in the table data (although I can't be sure, since the example is taken out of context). If the Class Type is NULL, then it seems to me that there shouldn't be a Class Number. Also, I think that the header is ill-formed (God, I hope that it isn't one of *my* headers from the ADC CD-ROM :-). Overlapping fields, while legal, can be confusing as this case shows. I think that this table would be better specified as: TTYPE6 = 'Class_Type' TBCOL6 = 54 TFORM6 = 'A1 ' TNULL6 = '* ' TTYPE7 = 'Class_No' TBCOL7 = 55 TFORM7 = 'I4 ' TNULL7 = ' ' >Thank you >Nelson Zarate (nelson at stsci.edu) >Space Telescoope Science Institute >Baltimore MD 21218 -- -- Lee E. Brotzman Internet: leb at hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- National Space Science Data Center BITNET: ZMLEB at GIBBS -- NASA Goddard Space Flight Center From bschlesinger at nssdca.gsfc.nasa.gov Mon Jul 20 17:42:38 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1260" "Mon" "20" "July" "1992" "21:40:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "29" "FITS error test files" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits News-Software: VAX/VMS VNEWS 1.41 Keywords: FITS, software, readers Nntp-Posting-Host: nssdca.gsfc.nasa.gov Organization: NASA - Goddard Space Flight Center From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Subject: FITS error test files Date: Mon, 20 Jul 1992 21:40:00 GMT In response to the requests at the Columbus meeting of the WGAS, a number of "FITS" files originally created to test the NOST FITS Product Conformance Tester (FPCT) are now available. These files provide an opportunity to test the ability of FITS readers to cope with errors in primary headers of the input files. All the files except one are variations on a theme; they are the same except that different kinds of errors have been introduced. Some types of errors included are improper keyword order, incorrect card image syntax, and incorrect values. The remaining file is designed to test the response of software to a file that doesn't even resemble FITS, as might occur if the software were used by mistake on the wrong file. These files are available from nssdca.gsfc.nasa.gov by anonymous ftp or by DECnet copy from NSSDCA. They are in the FITS directory, ERRTEST subdirectory. NSSDCA is a VAX; case is not significant. The README.FIRST file describes the others in more detail. Answers to any questions, and copies of the prototype FPCT itself, can be obtained from the FITS Support Office: Internet: fits at nssdca.gsfc.nasa.gov DECnet NCF::FITS Telephone: (301)513-1634 Barry Schlesinger Coordinator FITS Support Office From bhill at stars.gsfc.nasa.gov Mon Jul 20 17:43:04 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["657" "Mon" "20" "July" "1992" "21:52:00" "GMT" "Robert S. Hill" "bhill at stars.gsfc.nasa.gov " nil "12" "Re: FITS error test files" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits News-Software: VAX/VMS VNEWS 1.4-b1 Keywords: FITS, software, readers Nntp-Posting-Host: stars.gsfc.nasa.gov Organization: Hughes STX Corp./NASA Goddard Space Flight Center From: bhill at stars.gsfc.nasa.gov (Robert S. Hill) Subject: Re: FITS error test files Date: Mon, 20 Jul 1992 21:52:00 GMT In article <20JUL199216405756 at nssdca.gsfc.nasa.gov>, bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) writes... > In response to the requests at the Columbus meeting of the >WGAS, a number of "FITS" files originally created to test the NOST >FITS Product Conformance Tester (FPCT) are now available. These files Inquiring minds want to know: is the FPCT itself available? ------------------------------------------------------------------------ Robert S. Hill | Internet: BHILL at STARS.GSFC.NASA.GOV Hughes STX Corp. | Phone: 301/286-3624 ------------------------------------------------------------------------ From bschlesinger at nssdca.gsfc.nasa.gov Mon Jul 20 17:43:15 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6422" "Mon" "20" "July" "1992" "21:46:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "131" "FITS basics and information (periodic posting)" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits News-Software: VAX/VMS VNEWS 1.41 Nntp-Posting-Host: nssdca.gsfc.nasa.gov Organization: NASA - Goddard Space Flight Center From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Subject: FITS basics and information (periodic posting) Date: Mon, 20 Jul 1992 21:46:00 GMT This basic FITS information is posted and updated periodically for the benefit of new readers and the reference of old readers. FITS (Flexible Image Transport System) is a data format designed to allow convenient exchange of astronomical data between installations whose standard internal formats and hardware differ. A FITS file is composed of a sequence of Header Data Units (HDUs). The header consists of keyword=value statements, which describe the format and organization of the data in the HDU and may contain other information such as information about the instrument or the history of the data or data set. The data follow, structured as the header specifies. The data section of the HDU may contain a digital image, but, except for the first, IT DOESN'T HAVE TO. Other possible formats include tables and multidimensional matrices that are not images. The first HDU must contain a multidimensional matrix or no data at all; the data in subsequent HDUs, called extensions, may be of any type, consistent with certain rules. The "Image" in the name comes from the original use of the format to transport digital images, but it's not just for images any more. FITS is not principally a graphics format designed for the transfer of pictures with standard support for many platforms included as part of the package for decoding the image. Separate software must be developed or obtained for converting the data from the FITS file into a form that can be readily displayed. As has been discussed in this newsgroup, and in alt.sci.astro.fits before it, the Extended Portable Bitmap Toolkit (pbm+) can be used for converting many FITS files to such a format, but support for all FITS files where the data are in the form of an image, in particular those where the data matrix members are in IEEE floating point format (BITPIX<0) or the matrix has more than two dimensions (NAXIS>2), is not guaranteed. Discussion of FITS - image converters appears in this newsgroup from time to time. The fundamental references on FITS are the following four papers, often referred to collectively as the "Four FITS Papers". These papers are the formal standard for FITS, endorsed by the International Astronomical Union (IAU). Wells, D. C., Greisen, E. W., and Harten, R. H., "FITS: a flexible image transport system," Astronomy and Astrophysics Supplement Series, 44, 363-370, 1981. Greisen, E. W. and Harten, R. H., "An extension of FITS for small arrays of data," Astronomy and Astrophysics Supplement Series, 44, 371-374, 1981. (NOTE: The format described in this paper has been used almost exclusively to transport radio interferometry and is likely to be replaced by other formats in the future. Writing data other than radio interferometry data using this format is not recommended.) Grosbol, P., Harten, R. H., Greisen, E. W., and Wells, D. C., "Generalized extensions and blocking factors for FITS," Astronomy and Astrophysics Supplement Series, 73, 359-364, 1988. Harten, R. H., Grosbol. P., Greisen, E. W., and Wells, D. C., "The FITS tables extension, Astronomy and Astrophysics Supplement Series, 73, 365-372, 1988. A User's Guide for FITS, commissioned by NASA Headquarters, is maintained by the NASA/OSSA Office of Standards and Technology (NOST). This Guide is intended to be a tutorial for new FITS users. In addition to presenting the rules of FITS, it provides some of the history and reasoning behind the choice of the rules, adds recommendations on good practices, and discusses current developments in FITS. This document is available only in hard copy form. NASA is sponsoring development of a formal standard for FITS. The goal of this process is a document consistent with FITS as endorsed by the IAU, eliminating some contradictions and ambiguities in the original FITS papers, that can be endorsed by the IAU FITS Working Group as the FITS standard. The document is being developed by a Technical Panel chaired by Dr. Robert J. Hanisch (STSci), with review by the astronomical community. Only minor revisions are expected to the current draft, version 0.3b, but the form of the standard is not final, and it does not supersede the four papers and Floating Point Agreement endorsed by the IAU as the official standard for FITS. The IAU has endorsed the Floating Point Agreement, which defines how floating point numbers are to be stored in the data matrix defined in the first of the four papers. The basic agreement appears verbatim in the User's Guide, and the substance is incorporated in the Draft NASA Standard. The NOST maintains a file of FITS information available by anonymous ftp from nssdca.gsfc.nasa.gov or DECnet copy from NSSDCA, in the directory FITS. It includes copies of the current draft NASA Standard in flat ASCII, PostScript, and LaTeX. Style and index files are provided for the LaTeX form. A current list of the extension type (structure) names registered with the IAU FITS Working Group is maintained. Also available, in LaTeX form, is the text of the proposal for one of these new extension types, IMAGE. A README. file describes the contents of the directory. A SOFTWARE subdirectory, described by an included README.FIRST file, contains a program in C to read and list the headers of a FITS file and another file with information on publicly available FITS software packages. The ERRTEST subdirectory contains several versions of the same FITS file, a valid one and several with different kinds of header errors, for use in testing software to read FITS files. An included README.FIRST file contains details. Paper copies of many of the documents listed above can be obtained from the NOST Librarian. Paper copies of the User's Guide and either paper or electronic copies of the Draft Implementation Standard, for those without ftp access, are available. Because of restrictions set by the copyright holder, NOST can send copies of the four FITS papers only to non-profit organizations. The addresses of the NOST are as follows: (Postal) NASA/OSSA Office of Standards and Technology Code 933 Goddard Space Flight Center Greenbelt MD 20771 USA (Internet) nost at nssdca.gsfc.nasa.gov (DECnet) NCF::NOST Please mention this posting in your request. Barry M. Schlesinger Coordinator, NASA/NSSDC NOST FITS Support Office (301) 513-1634 fits at nssdca.gsfc.nasa.gov NCF::FITS From bschlesinger at nssdca.gsfc.nasa.gov Tue Jul 21 17:31:02 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["425" "" "21" "July" "92" "19:04:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "15" "Re: FITS error test files" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Summary: Test prototype only Keywords: FPCT Organization: NASA - Goddard Space Flight Center News-Software: VAX/VMS VNEWS 1.41 Nntp-Posting-Host: nssdca.gsfc.nasa.gov From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Subject: Re: FITS error test files Date: 21 Jul 92 19:04:00 GMT In article <20JUL199216523472 at stars.gsfc.nasa.gov>, bhill at stars.gsfc.nasa.gov (Robert S. Hill) writes... > >Inquiring minds want to know: is the FPCT itself available? > A prototype of the first build is available for testing, to check for portability and errors. The first build is limited to Primary HDU Integer data Twos complement Copies can be obtained from the FITS Support Office Barry Schlesinger From pence at heawk1.gsfc.nasa.gov Wed Jul 22 16:14:35 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2006" "" "22" "July" "92" "17:36:45" "GMT" " William Pence" "pence at heawk1.gsfc.nasa.gov " nil "74" "Re: FITS error test files" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Keywords: FITS, software, readers Organization: Goddard Space Flight Center Nntp-Posting-Host: heawk1.gsfc.nasa.gov From: pence at heawk1.gsfc.nasa.gov ( William Pence) Subject: Re: FITS error test files Date: 22 Jul 92 17:36:45 GMT I tried reading the test defective FITS files generated by Barry Schlesinger (see previous post to this newsgroup) to see if the FITSIO subroutine package detected the errors. I tried reading each pseudo FITS file with a simple program that just lists the header of a FITS file. The following list shows the error message that was returned by FITSIO for each file. FITSIO did very well and found all the errors, except one: it didn't complain if the first keyword was 'SIMPLE = W'; it just assumed that if SIMPLE was not true, then it must be false. I'll add this check to the next version of FITSIO. -Bill Pence -------------------------------------------------------------------------- List of error responses generated by FITSIO when trying to read test defective FITS files generated by Barry Schlesinger FILENAME FITSIO RESPONSE -------- --------------- good.tst No errors detected; OK since this is a legal FITS file different.tst: Error Status Returned : 210 Missing "= " in cols 9-10 nosimple.tst Error Status Returned : 221 SIMPLE keyword not found simplew.tst No errors detected; didn't detect SIMPLE = W; FITSIO should have complained about this. simplef.tst No errors detected; didn't complain about SIMPLE = F; OK bitpixq2 Error Status Returned : 211 Illegal BITPIX keyword value bitpix13 Error Status Returned : 211 Illegal BITPIX keyword value noequal.tst Error Status Returned : 210 Missing "= " in cols 9-10 qin10.tst Error Status Returned : 210 Missing "= " in cols 9-10 extraxis.tst No errors detected; OK since this is a legal FITS file missaxis.tst Error Status Returned : 224 NAXISnnn keywords not found simple2nd.tst Error Status Returned : 210 Missing "= " in cols 9-10 shuffle.tst Error Status Returned : 222 BITPIX keyword not found latenaxis.tst Error Status Returned : 223 NAXIS keyword not found endequal.tst No errors detected; OK since this is a legal FITS file (?). From bschlesinger at nssdca.gsfc.nasa.gov Thu Jul 23 11:59:28 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1928" "" "23" "July" "92" "13:59:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "56" "Re: FITS error test files" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Keywords: FITS, software, readers Organization: NASA - Goddard Space Flight Center News-Software: VAX/VMS VNEWS 1.41 Nntp-Posting-Host: nssdca.gsfc.nasa.gov From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Subject: Re: FITS error test files Date: 23 Jul 92 13:59:00 GMT In article , pence at heawk1.gsfc.nasa.gov ( William Pence) writes... > >I tried reading the test defective FITS files generated by Barry >Schlesinger (see previous post to this newsgroup) to see if the FITSIO >subroutine package detected the errors. I tried reading each pseudo >FITS file with a simple program that just lists the header of a FITS >file. The following list shows the error message that was returned by >FITSIO for each file. FITSIO did very well and found all the errors, >except one: it didn't complain if the first keyword was 'SIMPLE = >W'; it just assumed that if SIMPLE was not true, then it must be false. >I'll add this check to the next version of FITSIO. > >-Bill Pence >-------------------------------------------------------------------------- > >List of error responses generated by FITSIO when trying to read test defective >FITS files generated by Barry Schlesinger > >FILENAME FITSIO RESPONSE >-------- --------------- >good.tst > No errors detected; OK since this is a legal FITS file > >different.tst: > Error Status Returned : 210 > Missing "= " in cols 9-10 > This is something of an understatement, as the file isn't close to FITS. > ... [results for other files] ... . >shuffle.tst > Error Status Returned : 222 > BITPIX keyword not found Actually there is a BITPIX keyword in the file, just in the wrong place. But a reader shouldn't be expected to find it. >latenaxis.tst > Error Status Returned : 223 > NAXIS keyword not found As above. >endequal.tst > No errors detected; OK since this is a legal FITS file (?). Not exactly. The = in column 9 of the END card image shouldn't be there. Readers probably should provide a warning. Validation software certainly should. As is noted in the README.FIRST, Don Wells reports that some readers have crashed on this syntax. Barry Schlesinger FITS Support Office From teuben at lynx.astro.umd.edu Tue Jul 28 14:14:59 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1250" "" "28" "July" "92" "15:27:13" "GMT" "Peter Teuben" "teuben at lynx.astro.umd.edu " nil "28" "BSCALE/BZERO" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Distribution: sci Organization: University of Maryland, Astronomy Department From: teuben at lynx.astro.umd.edu (Peter Teuben) Subject: BSCALE/BZERO Date: 28 Jul 92 15:27:13 GMT The NOST fits panel report states that for BITPIX < 0 (i.e. when the data is stored in IEEE floating point format) the usage of BSCALE and BZERO not recommended. We never (wanted to) forbid or explicitly state that it should or should not be applied in section 6.3 (though section 5.2.2.5 does state this). The FITS users guide (also published by NOST) does explicitly states that BSCALE and BZERO be applied in the BITPIX<0 case, with the danger of producing overflows/underflows of course (hence the reason that BSCALE and BZERO should not be present). I've indeed noted that the AIPS and MIRIAD readers 'correctly' apply BSCALE and BZERO in the floating point cases, but the problem arose when we imported a FITS file generated by IDL. The idl procedure 'WRITEFITS' seems to write images with BSCALE not 1.0, which has caused some readers to read in the wrong datavalues. Perhaps Wayne Landsman can comment on this. Has anybody seen fits readers which skip BSCALE and BZERO if BITPIX < 0? Peter -- Peter J. Teuben | INTERNET : teuben at astro.umd.edu Astronomy Department | FAX: (301) 314-9067 University of Maryland | MA-BELL : (301) 405-1540 (office) College Park, MD 20742 | (301) 405-1502 (secr.) From thompson at stars.gsfc.nasa.gov Wed Jul 29 14:59:40 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2238" "" "29" "July" "92" "18:36:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "43" "Re: BSCALE/BZERO" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Distribution: sci 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: BSCALE/BZERO Date: 29 Jul 92 18:36:00 GMT In article , teuben at lynx.astro.umd.edu (Peter Teuben) writes... > >The NOST fits panel report states that for BITPIX < 0 (i.e. when >the data is stored in IEEE floating point format) the usage of >BSCALE and BZERO not recommended. We never (wanted to) forbid >or explicitly state that it should or should not be applied >in section 6.3 (though section 5.2.2.5 does state this). > >The FITS users guide (also published by NOST) does explicitly >states that BSCALE and BZERO be applied in the BITPIX<0 case, with >the danger of producing overflows/underflows of course (hence the >reason that BSCALE and BZERO should not be present). > >I've indeed noted that the AIPS and MIRIAD readers 'correctly' apply >BSCALE and BZERO in the floating point cases, but the problem arose >when we imported a FITS file generated by IDL. The idl procedure >'WRITEFITS' seems to write images with BSCALE not 1.0, which has >caused some readers to read in the wrong datavalues. >Perhaps Wayne Landsman can comment on this. > >Has anybody seen fits readers which skip BSCALE and BZERO if BITPIX < 0? I don't want to talk for Wayne Landsman as to what the IDL routines do or don't do when writing FITS files. I do want to address the issue inherent in the last question, though. I believe that there is a valid usage for BSCALE and BZERO when applied to floating point data. Most people probably think of these variables as just a way of packing floating point numbers into integer arrays. However, the FITS documentation simply states that these parameters are used to convert array values into scientifically useful physical values. Thus, another possible use of BSCALE and BZERO is to convert raw detector values into calibrated values. Thus, both levels of information are retained, and changing the calibration at a later date is fairly trivial. The IDL FITS reader routines do, by default, apply the BSCALE and BZERO parameters to the data. This occurs for both integer and floating point arrays. However, this behavior can be overridden by including the /NOSCALE keyword. That way, the user can also access the "raw" data. It doesn't matter whether or not BITPIX is > 0 or < 0. Bill Thompson From hyatt at tsc.cs.unc.edu Fri Jul 31 09:01:47 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["135" "" "30" "July" "92" "21:42:29" "GMT" "Brant Hyatt" "hyatt at tsc.cs.unc.edu " nil "8" "FITS->gif,jpg,tiff etc" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits Keywords: FITS gif jpg From: hyatt at tsc.cs.unc.edu (Brant Hyatt) Subject: FITS->gif,jpg,tiff etc Date: 30 Jul 92 21:42:29 GMT Does anyone know of or have written a utility that converts fits to any other format? Thanks, Brant Hyatt brant at sloth.astro.unc.edu From pmurphy at nrao.edu Fri Jul 31 09:02:54 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1535" "Fri" "31" "July" "1992" "03:25:02" "GMT" "Pat Murphy" "pmurphy at nrao.edu " nil "32" "Re: FITS->gif,jpg,tiff etc" "^From:" nil nil "7"]) Newsgroups: sci.astro.fits In-Reply-To: hyatt at tsc.cs.unc.edu's message of 30 Jul 92 21: 42:29 GMT Organization: National Radio Astronomy Observatory From: pmurphy at nrao.edu (Pat Murphy) Subject: Re: FITS->gif,jpg,tiff etc Date: Fri, 31 Jul 1992 03:25:02 GMT In article <14259 at borg.cs.unc.edu> hyatt at tsc.cs.unc.edu (Brant Hyatt) writes: > Does anyone know of or have written a utility that converts > fits to any other format? The pbmplus package that we have installed here (Dec 91 vintage I believe) has fitstopgm, and once there you can use the pgm utilities to convert it to just about whatever you want. A quick run of archie shows that pbmplus is available on ftp.uu.net: Location: /usenet/comp.sources.misc/volume26/pbmplus Directory drwxr-xr-x 00000512 1991 Dec 14 00:00:00 GMT pbmplus I'm sure it's available elsewhere. I don't keep track of the comp.sources.misc newsgroup so I don't know if this is the latest version or not. That said, I should say that it is NOT a sophisticated fits reader. It knows about SIMPLE, BITPIX, NAXIS, NAXISn (n up to 3), DATAMIN, DATAMAX, BZERO and BSCALE (but may not use them) and END. That's it. I have extracted the source for this from our pbmplus installation; email me if you want it. - Pat -- ========================================================================== | Patrick P. Murphy, Ph.D. Scientific Programming Analyst | | National Radio Astronomy Observatory Net: pmurphy at nrao.edu | | 520 Edgemont Road or: uunet!nrao.edu!pmurphy | | Charlottesville, VA 22903-2475 Phone: (804) 296-0372 | | "I don't believe in the no-win scenario" --- James T. Kirk | ==========================================================================