From fitsbits-request Thu Nov 5 19:00:57 1992 X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil X-VM-Bookmark: 2 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["5891" "Fri" "6" "November" "1992" "00:00:43" "GMT" "Don Wells" "dwells at fits.CV.NRAO.EDU " nil "115" "World Coordinate System proposal" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04773; Thu, 5 Nov 92 19:00:57 EST Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: World Coordinate System proposal Date: Fri, 6 Nov 1992 00:00:43 GMT A special session was held on FITS WCS [World Coordinate System] issues yesterday at the ADASS-92 meeting in Boston. The session was well attended, and it was clear that there is considerable interest in defining and implementing interoperable WCS implementations. Bob Hanisch distributed copies of a paper which he and I prepared in February 1988. This paper documented the conclusions reached during a WCS workshop held in Charlottesville in January 1988; it should be the starting point for a new round of discussions of WCS issues. Anyone who was not in the WCS session yesterday and who wants a copy of the paper will find it in the anonymous-FTP server fits.cv.nrao.edu [192.33.115.8] in directory /FITS/Documents: 101705 Nov 5 10:12 FITS_wcs88.ps 21856 Nov 5 10:07 FITS_wcs88.tex -- 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 fitsbits-request Fri Nov 6 17:41:28 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2085" "" "6" "November" "1992" "21:31:05" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "38" "Re: World Coordinate System proposal" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06982; Fri, 6 Nov 92 17:41:28 EST Return-Path: Message-Id: <1deo6pINNlj9 at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!wupost!emory!sol.ctr.columbia.edu!caen!saimiri.primate.wisc.edu!ames!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla References: From: sla at umbra.UCSC.EDU (Steve Allen) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: World Coordinate System proposal Date: 6 Nov 1992 21:31:05 GMT In article dwells at fits.cv.nrao.edu (Don Wells) writes: >Bob Hanisch distributed copies of a paper which he and I prepared in >February 1988. This paper documented the conclusions reached during a >WCS workshop held in Charlottesville in January 1988; it should be the >starting point for a new round of discussions of WCS issues. In looking over this paper I am left asking a question about the CRPIX1 and CRPIX2 values at the point of tangency on the sky. The question boils down to another question: Are FITS images representing binned data or sampled data? How do you tell? By binned data I mean that pixels are represented by adjacent rectangular regions and that the value of the pixel represents some kind of integral (i.e., of the surface brightness of the sky) of a pixel response function which is nearly uniform over the entire rectangle. By sampled data I mean that pixels are represented by point samples within each rectangle, or more precisely, that the pixel response function can be thought as being very much smaller than the inter-pixel spacing. In sampled data it is reasonable to think of the "middle" of the pixel as having an integral coordinate. In binned data there is some variance of convention, but many people consider that the "middle" of a pixel has a half-integral location (e.g., the boundaries between pixels are integral). There are some applications where the distinction between sampled and binned data should be made in order to assure a more rigorously correct interpretation. In either case, it is important to tell the next user of this data which convention of pixel numbering is used to specify the CRPIX values. For the sake of this WCS proposal, which convention is being used? _______________________________________________________________________________ Steve Allen | That was the equation! | sla at lick.ucsc.edu UCO/Lick Observatory | Existence!...Survival must | If the UC were opining, Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't tell me. From fitsbits-request Fri Nov 6 19:06:03 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["1430" "Fri" "6" "November" "1992" "22:12:11" "GMT" "Bob Hanisch, ST ScI" "hanisch at stsci.edu " nil "28" "Re: World Coordinate System proposal" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07317; Fri, 6 Nov 92 19:06:03 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Fri, 6 Nov 1992 22:12:11 GMT From: hanisch at stsci.edu (Bob Hanisch, ST ScI) Message-Id: <1992Nov6.221211.9536 at stsci.edu> Organization: Space Telescope Science Institute, Baltimore MD Path: cv3.cv.nrao.edu!uvaarpa!caen!destroyer!ncar!noao!stsci!iris.stsci.edu!hanisch References: <1deo6pINNlj9 at darkstar.UCSC.EDU> Reply-To: hanisch at stsci.edu Subject: Re: World Coordinate System proposal Sender: fitsbits-request at fits.CV.NRAO.EDU In article 1deo6pINNlj9 at darkstar.UCSC.EDU, sla at umbra.UCSC.EDU (Steve Allen) writes: >In article >dwells at fits.cv.nrao.edu (Don Wells) writes: >>Bob Hanisch distributed copies of a paper which he and I prepared in >>February 1988. This paper documented the conclusions reached during a >>WCS workshop held in Charlottesville in January 1988; it should be the >>starting point for a new round of discussions of WCS issues. > >In looking over this paper I am left asking a question about the >CRPIX1 and CRPIX2 values at the point of tangency on the sky. > >The question boils down to another question: Are FITS images representing >binned data or sampled data? How do you tell? > > etc.... This issue was discussed during the meeting in Boston, and it was agreed that the proposal has to be revised to indicate the conventions being used. The consensus was that for FITS, pixel (1,1) is the pixel in the lower left-hand corner of an image and that for the purpose of the WCS, this pixel represents data from 0.5 to 1.5 in pixel coordinates. This clarification will be added to the proposal. --- Robert J. Hanisch Tel. (410)338-4910 Fax. (410)338-5090 Space Telescope Science Institute NSI: hanisch at stsci.edu [130.167.1.2] 3700 San Martin Drive DECNet: STSCIC::HANISCH [6549::] Baltimore, MD 21218 USA Bitnet: hanisch at stsci From fitsbits-request Fri Nov 6 19:16:07 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["749" "" "6" "November" "92" "23:30:21" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "14" "Re: World Coordinate System proposal" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07331; Fri, 6 Nov 92 19:16:07 EST Return-Path: Message-Id: <1dev6dINNnkp at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory Path: cv3.cv.nrao.edu!uvaarpa!caen!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!olivea!hal.com!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla References: <1deo6pINNlj9 at darkstar.UCSC.EDU> <1992Nov6.221211.9536 at stsci.edu> From: sla at umbra.UCSC.EDU (Steve Allen) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: World Coordinate System proposal Date: 6 Nov 92 23:30:21 GMT In article <1992Nov6.221211.9536 at stsci.edu> hanisch at stsci.edu writes: >In article 1deo6pINNlj9 at darkstar.UCSC.EDU, sla at umbra.UCSC.EDU (Steve Allen) writes: >> >>The question boils down to another question: Are FITS images representing >>binned data or sampled data? How do you tell? > >This issue was discussed during the meeting in Boston, and it was agreed >that the proposal has to be revised to indicate the conventions being >used. The consensus was that for FITS, pixel (1,1) is the pixel in the lower >left-hand corner of an image and that for the purpose of the WCS, this >pixel represents data from 0.5 to 1.5 in pixel coordinates. This clarification >will be added to the proposal. It will be very important to add this clarification. >From my experience I infer that the astronomical community has pretty much established that the first pixel in an array is the pixel with the integer tag 1 which has floating point boundaries 0.5 and 1.5 (middle of pixel is integral). This is significantly different from the common practice in computer graphics (CG) where the first pixel in an array is the pixel with the integer tag 0 which has floating point boundaries 0.0 and 1.0 (edges of pixel are integral). If the astronomical community will be variant in this way it will be essential to clearly document the definition of a pixel. There will undoubtedly be some astronomical programmers who cling to the more widely used CG definitions of pixels, and interoperation of their software with other software will be difficult if these underlying assumptions are not made explicit in the documentation. _______________________________________________________________________________ Steve Allen | That was the equation! | sla at lick.ucsc.edu UCO/Lick Observatory | Existence!...Survival must | If the UC were opining, Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't tell me. From fitsbits-request Sat Nov 7 14:47:02 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["1024" "Sat" "7" "November" "1992" "19:45:04" "GMT" "Malcolm J. Currie" "cur at rlstar.bnsc.rl.ac.uk " nil "21" "Re: Proposal for World Co-ordinate System" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09619; Sat, 7 Nov 92 14:47:02 EST Return-Path: Message-Id: <9211071946.AA09613 at fits.cv.nrao.edu> Date: Sat, 7 Nov 1992 19:45:04 GMT Reply-To: cur at star.rl.ac.uk From: cur at rlstar.bnsc.rl.ac.uk (Malcolm J. Currie) To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Proposal for World Co-ordinate System X-Vms-To: SMTP%"fitsbits at fits.cv.nrao.edu" Sender: fitsbits-request at fits.CV.NRAO.EDU Steve Allen writes: >From my experience I infer that the astronomical community has >pretty much established that the first pixel in an array is the pixel with >the integer tag 1 which has floating point boundaries 0.5 and 1.5 >(middle of pixel is integral). In Starlink we use pixel indices that, by default, start at 1. However, our definition of pixel co-ordinates has the first pixel (index 1) between floating-point boundaries of 0.0 and 1.0, since we regard pixels as binned data. Isn't it more logical to start at the origin rather than 0.5? Our NDF data structure permits axis widths to be defined in addition to axis centres. So for sampled data the widths could be made much smaller than inter-pixel spacing. ----------------------------------------------------------------------- Malcolm J. Currie | Span: RLVAD::CUR Starlink Project | Janet: CUR at UK.AC.RUTHERFORD.STARLINK | +44-235-821900 x6735 ----------------------------------------------------------------------- From fitsbits-request Sat Nov 7 16:47:14 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2532" "Sat" "7" "November" "92" "16:47:56" "EST" "Eric Greisen" "egreisen at primate.CV.NRAO.EDU " nil "51" "World Coordinates Proposal" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09677; Sat, 7 Nov 92 16:47:14 EST Return-Path: Message-Id: <9211072147.AA03635 at primate.cv.nrao.edu> From: egreisen at primate.CV.NRAO.EDU (Eric Greisen) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: World Coordinates Proposal Date: Sat, 7 Nov 92 16:47:56 EST The current tempest over this question illustrates why the initial design of FITS deliberately remained silent on coordinates questions. It is my hope that I can codify and clarify the coordinates that have been in wide use in the FITS community and produce a proposal. In the mean time, I feel I am forced to address this question: Steve Allen writes >>The question boils down to another question: Are FITS images representing >>binned data or sampled data? How do you tell? Robert Hanisch replies: > This issue was discussed during the meeting in Boston, and it was agreed > that the proposal has to be revised to indicate the conventions being > used. The consensus was that for FITS, pixel (1,1) is the pixel in the lower > left-hand corner of an image and that for the purpose of the WCS, this > pixel represents data from 0.5 to 1.5 in pixel coordinates. This clarification > will be added to the proposal. Let me add my agreement. There is only one unique location in an N-dimensional voxel, its center in each of the N dimensions. This has always been the intent of CRPIXmmm in the FITS design. I do not understand how that decides one way or the other whether the data are sampled or binned - that is a separate question with an instrument-dependent answer. I disagree that FITS pixel (1,1) represents the "lower left-hand" of anything. (1,1) is the first pixel value in a Fortran-array sense. Where it is placed in a display depends on many things such as the sign of the coordinate increments and the like. If you send AIPS an image with a negative increment on the declination axis, it will display the image with (1,1) at the upper left corner, for example. Steve Allen writes > This is significantly different from the common practice in computer graphics > (CG) where the first pixel in an array is the pixel with > the integer tag 0 which has floating point boundaries 0.0 and 1.0 > (edges of pixel are integral). Mostly computer graphics ignores pixels and plots the whole universe - or its current instanciation - from 0.0 to 1.0. You are then defining coordinates to be at the upper side of the pixel since FITS does define the first pixel to be pixel number 1. Is that any more unique than the lower side? Only the center is unique. The coordinates given in CRVALnnn are at the center of pixel CRPIXnnn. Of course - things like this may explain some of the complaints about VLA positions and discrepancies between positions from various observatories. Eric W. Greisen egreisen at nrao.edu From dwells Sat Nov 7 19:52:44 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["1283" "Sat" "7" "November" "92" "19:52:43" "EST" "Malcolm J. Currie" "cur at rlstar.bnsc.rl.ac.uk " nil "28" "Re: World Coordinate System proposal" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09964; Sat, 7 Nov 92 19:52:44 EST Resent-Date: Sat, 7 Nov 92 19:52:43 EST Resent-From: dwells (Don Wells) Resent-Message-Id: <9211080052.AA09964 at fits.cv.nrao.edu> Return-Path: Date: Sat, 7 Nov 92 19:52:43 EST Message-Id: <9211080052.AA09958 at fits.cv.nrao.edu> From: cur at rlstar.bnsc.rl.ac.uk (Malcolm J. Currie) To: fitsbits Subject: Re: World Coordinate System proposal Resent-Sender: dwells Sender: fitsbits-request at fits.CV.NRAO.EDU ------- Start of forwarded message ------- From: cur at rlstar.bnsc.rl.ac.uk (Malcolm J. Currie) To: fitsbits-request at fits.CV.NRAO.EDU Subject: Re: World Coordinate System proposal Date: Sat, 7 Nov 1992 19:39:15 GMT Steve Allen writes: >From my experience I infer that the astronomical community has >pretty much established that the first pixel in an array is the pixel with >the integer tag 1 which has floating point boundaries 0.5 and 1.5 >(middle of pixel is integral). In Starlink we use pixel indices that, by default, start at 1. However, our definition of pixel co-ordinates has the first pixel (index 1) between floating-point boundaries of 0.0 and 1.0, since we regard pixels as binned data. Isn't it more logical to start at the origin rather than 0.5? Our NDF data structure permits axis widths to be defined in addition to axis centres. So for sampled data the widths could be made much smaller than inter-pixel spacing. - ----------------------------------------------------------------------- Malcolm J. Currie | Span: RLVAD::CUR Starlink Project | Janet: CUR at UK.AC.RUTHERFORD.STARLINK | +44-235-821900 x6735 - ----------------------------------------------------------------------- ------- End of forwarded message ------- From fitsbits-request Sun Nov 8 09:46:34 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["1811" "Sun" "8" "November" "1992" "14:11:49" "GMT" "Jeffrey J Bloch" "jjb at beta.lanl.gov " nil "37" "World Coordinate Systems standard for All-sky data" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11293; Sun, 8 Nov 92 09:46:34 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Sun, 8 Nov 1992 14:11:49 GMT From: jjb at beta.lanl.gov (Jeffrey J Bloch) Message-Id: <1992Nov8.141149.18485 at newshost.lanl.gov> Organization: Los Alamos National Laboratory Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!lanl!beta.lanl.gov!jjb Subject: World Coordinate Systems standard for All-sky data Sender: fitsbits-request at fits.CV.NRAO.EDU Newsgroups: sci.fits.astro Subject: World Coordinate Systems standard for All-sky data Summary: Followup-To: Distribution: world Organization: Los Alamos National Laboratory Keywords: At the ADASS BOF session on World Coordinate Systems, I volunteered to gather input for Bob Hanisch on the problem of dealing with all-sky data in the WCS context, namely things such as Hammer-Aitoff maps, Quad Cube maps, Equal Area Polar (Lambert) maps. For those of us dealing with generating and distributing all-sky data of moderate resolution and having existing packages treat these data properly is a real problem. ROSAT, COBE, GRO, EUVE, and in our case ALEXIS, will all be generating maps covering large sections of the sky with moderate resolution and demanding some type of equal area projections. The diffuse X-ray all sky maps from ROSAT will be generated in equal area polar projections according to Steve Snowden at MPE. The COBE folks seem to be going with Quad Cube maps. For the EUV maps generated with the ALEXIS experiment, we are experimenting also with Quad Cube, and EUVE is using Quad Cube. Neither Lambert or Quad cube is in the current WCS stanard, and the hooks for dealing with these types of data may not be there either, or may need some re-interpretation when dealing with maps of these types. I will be pulsing the people I know on these projects about their preferences and try to put a proposal for dealing with these all-sky maps onto this newsgroup in the comming weeks. Please send me any of your own thoughts on the subject as well. Cheers, Jeff Bloch Astrophysics and Radiation Measurement Group Los Alamos National Laboratory (505)665-2568 SPAN: ESSDP2::103283 Internet: 103283 at sstdp2.lanl.gov or: jbloch at alexis.lanl.gov From fitsbits-request Tue Nov 10 05:05:35 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["15356" "Mon" "9" "November" "1992" "22:29:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "293" "World Coordinates" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01990; Tue, 10 Nov 92 05:05:35 EST Return-Path: Message-Id: <9NOV199218295135 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!ukma!nsisrv!stars.gsfc.nasa.gov!thompson From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: World Coordinates Date: Mon, 9 Nov 1992 22:29:00 GMT After having read the world coordinates proposal, I am still unclear as to how the developers would describe this very simple problem: Given: A slit spectrograph with a single pointing position. The dimensions of the data are two: one spatial coordinate and one spectral coordinate. However, to describe the pointing, two spatial coordinates are needed, as well as the orientation of the slit, and the spectral dispersion and central wavelength. In other words, the data has only two dimensions, but it takes three dimensions to properly describe it. Secondly, it appears that this convention is only relevant to skymapped data--which I admit applies to most astronomical data. However, it's hard to see the relevance to solar images, for example. Bill Thompson From fitsbits-request Tue Nov 10 06:14:35 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["3110" "Tue" "10" "November" "1992" "02:12:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "65" "More comments on World Coordinates" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02017; Tue, 10 Nov 92 06:14:35 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 10 Nov 1992 02:12:00 GMT From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Message-Id: <9NOV199222125457 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!concert!rock!stanford.edu!ames!nsisrv!stars.gsfc.nasa.gov!thompson Subject: More comments on World Coordinates Sender: fitsbits-request at fits.CV.NRAO.EDU In the document "World Coordinate Systems Representations Within the FITS Format", it is stated. {\tt CTYPE1, CTYPE2} -- the type of world coordinate axes. The {\tt CTYPE} value strings are eight characters in length, and are constructed from two four-character segments. The first four characters give the type of world coordinate, and the second four characters give the type of projection geometry. The first four-character string is left-justified and filled out to a length of four characters by appending hyphens; the second four-character string is right-justified and filled out to a length of four characters by prepending hyphens. The following coordinate pairs and geometries are recognized: This is a new requirement for this keyword. I would like to know how software (e.g. AIPS) which is written to parse files written using world coordinates will handle data which does not follow the conventions outlined in the world coordinates document. This applies both to data written before this convention was devised, and to future data that does not conform to this convention. Our plans are to use a unified keyword system for all aspects of the SOHO data, both within FITS files and out. The values of the CTYPE keyword are supposed to be the names of valid SOHO keywords which represent the physical unit represented by that dimension, e.g. CTYPE1 = 'INS_Y ' /Instrument Y axis CTYPE2 = 'INS_Z ' /Instrument Z axis CTYPE3 = 'WAVELNTH' /Wavelength In other instances, depending on the kind of data being gathered, these same names could appear as FITS keywords INS_Y = 3 /Instrument Y pointing (arcsec) INS_Z = 5 /Instrument Z pointing (arcsec) WAVELNTH= 584.60 /Wavelength in Angstroms There is no way we could live within the restrictions of the world coordinate system as regards the CTYPE keyword. (Having to live with "WAVELNTH" instead of "WAVELENGTH" is bad enough!) The goals of the world coordinate system are important and quite laudable. However, the FITS community needs to recognize the existence of data sets that are and will be outside of this convention. Since our data will have no relationship to the celestial sphere, none of the coordinate systems (geocentric, galactic, or ecliptic) are relevant for our data set. Will future FITS readers such as AIPS be able to handle data outside of the new world coordinate system convention. It seems to me that CTYPE is now being asked to serve two functions. It specifies the physical meaning of the data, as has always been its function. It also is now being asked to specify the kind of data projection used as well, which is a totally new function. I believe that these should be separated into two separate sets of keywords. In other words, instead of CTYPE1 = 'DEC--TAN' you would have CTYPE1 = 'DEC ' CPROJ1 = 'TAN ' This would provide for more flexibility and capatibility with existing systems. Once that change is made, there's no reason why other data sets could be brought into at least *partial* agreement with this convention. Bill Thompson From fitsbits-request Tue Nov 10 08:58:10 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["7445" "Tue" "10" "November" "92" "08:58:54" "EST" "Eric Greisen" "egreisen at primate.CV.NRAO.EDU " nil "134" "World Coordinate Systems" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02527; Tue, 10 Nov 92 08:58:10 EST Return-Path: Date: Tue, 10 Nov 92 08:58:54 EST From: egreisen at primate.CV.NRAO.EDU (Eric Greisen) Message-Id: <9211101358.AA01257 at primate.cv.nrao.edu> To: fitsbits at fits.CV.NRAO.EDU Subject: World Coordinate Systems Sender: fitsbits-request at fits.CV.NRAO.EDU Bill Thompson writes > After having read the world coordinates proposal, I am still unclear as to how > the developers would describe this very simple problem: > > Given: A slit spectrograph with a single pointing position. The > dimensions of the data are two: one spatial coordinate and one > spectral coordinate. However, to describe the pointing, two > spatial coordinates are needed, as well as the orientation of > the slit, and the spectral dispersion and central wavelength. > In other words, the data has only two dimensions, but it takes > three dimensions to properly describe it. > > Secondly, it appears that this convention is only relevant to skymapped > data--which I admit applies to most astronomical data. However, it's hard to > see the relevance to solar images, for example. The method that has been used since day 1 in FITS is to specify 3 axes with only 1 pixel on the third axis. I have been disturbed by the title "World Coordinate Systems" given to the discussions since it implies some global solution to all problems. The original FITS paper did not even address this area since it is too vast and too filled with matters that raise peoples' blood pressure. All we are attempting to do now is to develop a nomenclature for representing various celestial coordinates including the types of projections used. We are not going to address the spectral domain even though that is a domain we all have in common. It appears that the solutions used are too diverse - and solutions which I regard as non-scientific are too widely used and defended - for us to expect much agreement in that area. William Thompson, code 682.1, x2040 also writes: > In the document "World Coordinate Systems Representations Within the FITS > Format", it is stated. > > {\tt CTYPE1, CTYPE2} -- the type of world coordinate axes. The {\tt CTYPE} > value strings are eight characters in length, and are constructed from > two four-character segments. The first four characters give the type > of world coordinate, and the second four characters give the type of > projection geometry. The first four-character string is left-justified > and filled out to a length of four characters by appending hyphens; the > second four-character string is right-justified and filled out to a length > of four characters by prepending hyphens. The following coordinate pairs and > geometries are recognized: > > This is a new requirement for this keyword. I would like to know how software > (e.g. AIPS) which is written to parse files written using world coordinates > will handle data which does not follow the conventions outlined in the world > coordinates document. This applies both to data written before this convention > was devised, and to future data that does not conform to this convention. > Again, this is intended to be a convention for celestial coordinates primarily, although it suggests a convention that one might wish to use in other areas. AIPS will handle any string in CTYPEn, but if that string is not of a recognizable type then AIPS will assume that the axis is linear in the coordinate, plot it as such, and label it with the value of the CTYPEn string. It seems to me that this is a reasonable compromise since one does have to recognize the type of coordinate before one can apply any non-linear function to its computation. For example, some institutions have written tapes that declare the spatial components to be "RA" and "DEC" with no special remarks. AIPS treats them - reasonable I would argue - as linear in RA, Dec with no cos(dec) terms. For some non-linear function to be applied we need to agree on some nomenclature to imply its use. > Our plans are to use a unified keyword system for all aspects of the SOHO data, > both within FITS files and out. The values of the CTYPE keyword are supposed > to be the names of valid SOHO keywords which represent the physical unit > represented by that dimension, e.g. > > CTYPE1 = 'INS_Y ' /Instrument Y axis > CTYPE2 = 'INS_Z ' /Instrument Z axis > CTYPE3 = 'WAVELNTH' /Wavelength > > In other instances, depending on the kind of data being gathered, these same > names could appear as FITS keywords > > INS_Y = 3 /Instrument Y pointing (arcsec) > INS_Z = 5 /Instrument Z pointing (arcsec) > WAVELNTH= 584.60 /Wavelength in Angstroms > > There is no way we could live within the restrictions of the world coordinate > system as regards the CTYPE keyword. (Having to live with "WAVELNTH" instead > of "WAVELENGTH" is bad enough!) I applaud the first usage (partly) and deplore the second. The whole reason for having very general and defined keywords was to attempt to convey information between sites (and over time) without having to have special codes for every 2-party connections. The first usage allows a general program to make some sense of the information provides, the second usage simply gets dumped to history files and ignored. The "(partly)" above is from my guess that you could in fact provide us with useful celestial coordinate information instead and thereby allow scientists to compare your imagery with those generated by other instruments. > > The goals of the world coordinate system are important and quite laudable. > However, the FITS community needs to recognize the existence of data sets that > are and will be outside of this convention. Since our data will have no > relationship to the celestial sphere, none of the coordinate systems > (geocentric, galactic, or ecliptic) are relevant for our data set. Will future > FITS readers such as AIPS be able to handle data outside of the new world > coordinate system convention. > > It seems to me that CTYPE is now being asked to serve two functions. It > specifies the physical meaning of the data, as has always been its function. > It also is now being asked to specify the kind of data projection used as well, > which is a totally new function. I believe that these should be separated into > two separate sets of keywords. In other words, instead of > > CTYPE1 = 'DEC--TAN' > > you would have > > CTYPE1 = 'DEC ' > CPROJ1 = 'TAN ' > > This would provide for more flexibility and capatibility with existing systems. > Once that change is made, there's no reason why other data sets could be > brought into at least *partial* agreement with this convention. This usage is quite old actually. It was first described in writing by me in April 1983 and has been used on the 1000's of VLA images ever since. It was picked up and used by many other sites over the years and the draft proposal you have read was dated in 1988. I am engaged as we speak in converting the old papers to LaTeX so that they can be re-released in a modern form. I intend also to review the proposal and flesh it out with better details. The draft proposal is fine for simple projections. However, I fear that a good description of more general coordinates (i.e. Aitoff) will not fit well in the proposal and that the CD.... matrix provides rotation information that would be better provided in another way. I am not sure about this as yet, but fear that we will end up with 2 rotations, one of which is in the CD matrix, which could have been given as only one. Eric Greisen Scientist National Radio Astronomy Observatory From fitsbits-request Tue Nov 10 14:21:15 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["2296" "Tue" "10" "November" "1992" "14:47:36" "GMT" "Bob Hanisch, ST ScI" "hanisch at stsci.edu " nil "39" "Re: World Coordinates" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA00269; Tue, 10 Nov 92 14:21:15 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 10 Nov 1992 14:47:36 GMT From: hanisch at stsci.edu (Bob Hanisch, ST ScI) Message-Id: <1992Nov10.144736.19273 at stsci.edu> Organization: Space Telescope Science Institute, Baltimore MD Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!europa.asd.contel.com!emory!sol.ctr.columbia.edu!destroyer!ncar!noao!stsci!iris.stsci.edu!hanisch References: <9NOV199218295135 at stars.gsfc.nasa.gov> Reply-To: hanisch at stsci.edu Subject: Re: World Coordinates Sender: fitsbits-request at fits.CV.NRAO.EDU In article 9NOV199218295135 at stars.gsfc.nasa.gov, thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes: >After having read the world coordinates proposal, I am still unclear as to how >the developers would describe this very simple problem: > > Given: A slit spectrograph with a single pointing position. The > dimensions of the data are two: one spatial coordinate and one > spectral coordinate. However, to describe the pointing, two > spatial coordinates are needed, as well as the orientation of > the slit, and the spectral dispersion and central wavelength. > In other words, the data has only two dimensions, but it takes > three dimensions to properly describe it. > >Secondly, it appears that this convention is only relevant to skymapped >data--which I admit applies to most astronomical data. However, it's hard to >see the relevance to solar images, for example. > >Bill Thompson The title of the draft probably should have been more restrictive, i.e., "Representation of Sky Projection Coordinate Systems Within FITS" or something like that. At the WCS meeting in Charlottesville in 1988 we decided to tackle this problem first, and that was again agreed upon at the Boston meeting last week. The example cited above is actually not so simple, since things are rarely this straightforward. The dispersion axis is usually not perpendicular to the spatial axis, and indeed is usually curved. The dispersion relation itself is frequently nonlinear. The simple case described above CAN be handled within FITS, and is supported within a number of systems (e.g., radio data cubes are really the same thing -- the dispersion axis is usually the third axis, but this need not be the case). At the Boston meeting there were volunteers to work on adding solar and planetary coordinate systems to the draft. If you are interested in participating in this effort, please contact Winnifred Williams at NOAO (wwilliams at noao.edu), who agreed to coordinate this work. --- Robert J. Hanisch Tel. (410)338-4910 Fax. (410)338-5090 Space Telescope Science Institute NSI: hanisch at stsci.edu [130.167.1.2] 3700 San Martin Drive DECNet: STSCIC::HANISCH [6549::] Baltimore, MD 21218 USA Bitnet: hanisch at stsci From fitsbits-request Tue Nov 10 14:21:14 1992 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["0" "" "10" "November" "92" "14:22:07" "GMT" "Jonathan McDowell" "mcdowell at head-cfa.harvard.edu " nil "0" "Re: World Coordinate System proposal" "^From:" nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA00263; Tue, 10 Nov 92 14:21:14 EST Return-Path: Message-Id: <1992Nov10.142207.21098 at head-cfa.harvard.edu> Organization: Smithsonian Astrophysical Observatory, Cambridge, MA, USA Path: cv3.cv.nrao.edu!uvaarpa!caen!zaphod.mps.ohio-state.edu!darwin.sura.net!ukma!hsdndev!cfa203!mcdowell References: <1dev6dINNnkp at darkstar.UCSC.EDU> From: mcdowell at head-cfa.harvard.edu (Jonathan McDowell) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: World Coordinate System proposal Date: 10 Nov 92 14:22:07 GMT >From article <1dev6dINNnkp at darkstar.UCSC.EDU>, by sla at umbra.UCSC.EDU (Steve Allen): > [... Does the center of pixel (1,1) have the coordinates (1.0,1.0) or (1.5,1.5)???] > If the astronomical community will be variant in this way it will be > essential to clearly document the definition of a pixel. There will > undoubtedly be some astronomical programmers who cling to the more widely > used CG definitions of pixels, and interoperation of their software with > other software will be difficult if these underlying assumptions are not > made explicit in the documentation. > _______________________________________________________________________________ > Steve Allen | That was the equation! | sla at lick.ucsc.edu > UCO/Lick Observatory | Existence!...Survival must | If the UC were opining, > Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't tell me. I agree that clear documentation is crucial. Here at SAO we have always used the "CG" definition (center of bottom corner pixel is at "0.5"); IRAF uses mostly "1.0" but not always; and historically FITS has left it up to the user to include a comment card to document how the coordinate system used by CRPIX is mapped on to the data array. We've run into awful trouble in the past by getting confused about this. I'm happy with the "1.0" choice, but we need to make it as explicit as possible. Make the distinction between the number of a pixel (an integer n-tuple) and the coordinates of its center (a real n-tuple) explicit, even if the choice of convention makes them numerically equal. I hope the standard will use lots of small and simple words and some examples (like: "The first data item in the array section is considered to be the pixel whose number is (1,1,1,...1). The number of the next pixel is (1,1,1,...,2). The coordinate value corresponding to the center of the pixel numbered (1,1,...1) is (1.0,1.0,...,1.0)." .-----------------------------------------------------------------------------. | Jonathan McDowell | phone : (617) 495-7176 | | Harvard-Smithsonian Center for | | | Astrophysics | | | 60 Garden St, MS4 | | | Cambridge MA 02138 | inter : mcdowell at urania.harvard.edu | | USA | inter : mcdowell at cfa.harvard.edu | '-----------------------------------------------------------------------------' From fitsbits-request Tue Nov 10 14:53:45 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["2744" "" "10" "November" "92" "17:31:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "51" "Re: World Coordinate Systems" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA00364; Tue, 10 Nov 92 14:53:45 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 10 Nov 92 17:31:00 GMT From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Message-Id: <10NOV199213310946 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!seismo!ukma!nsisrv!stars.gsfc.nasa.gov!thompson References: <9211101358.AA01257 at primate.cv.nrao.edu> Subject: Re: World Coordinate Systems Sender: fitsbits-request at fits.CV.NRAO.EDU In article <9211101358.AA01257 at primate.cv.nrao.edu>, egreisen at primate.CV.NRAO.EDU (Eric Greisen) writes... (stuff deleted) >Again, this is intended to be a convention for celestial coordinates primarily, >although it suggests a convention that one might wish to use in other areas. >AIPS will handle any string in CTYPEn, but if that string is not of a recognizable >type then AIPS will assume that the axis is linear in the coordinate, plot it as >such, and label it with the value of the CTYPEn string. It seems to me that this >is a reasonable compromise ... Sounds quite reasonable to me too, and addresses my concerns in this area. Eric Greisen also writes ... >I applaud the first usage (partly) and deplore the second. The whole reason for >having very general and defined keywords was to attempt to convey information >between sites (and over time) without having to have special codes for every >2-party connections. The first usage allows a general program to make some sense >of the information provides, the second usage simply gets dumped to history files >and ignored. The "(partly)" above is from my guess that you could in fact provide >us with useful celestial coordinate information instead and thereby allow scientists >to compare your imagery with those generated by other instruments. Could you clarify what you mean by "first" and "second". I'm unsure about what you're getting at here. In terms of "useful celestial coordinate" information, our plan is to provide the data in raw units, and in the coordinate system the data was actually taken in. The data needed to convert this into useful coordinates and scientific units will also be included, but not applied. Our feeling is that the calibration is a fluid thing, and that our understanding will change over time. The calibration information stored in the file will probably only represent a first quess. We will distribute the calibration data separately, which can be more easily updated. Eric Greisen goes on to say ... >This usage is quite old actually. It was first described in writing by me in >April 1983 and has been used on the 1000's of VLA images ever since. It was picked >up and used by many other sites over the years and the draft proposal you have >read was dated in 1988. I am engaged as we speak in converting the old papers to >LaTeX so that they can be re-released in a modern form. I intend also to review >the proposal and flesh it out with better details. ... By "new", I mean that it is not discussed within the confines of the FITS standard document. I'm surprised that you decided to add new functionality within a pre-existing structure. Future enhancements to the standard should avoid this trap. Bill Thompson From fitsbits-request Tue Nov 10 21:01:31 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["4840" "" "10" "November" "1992" "14:33" "PST" "Tim Pearson" "tjp at eccles.caltech.edu " nil "94" "Re: World Coordinate System proposal" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02262; Tue, 10 Nov 92 21:01:31 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 10 Nov 1992 14:33 PST From: tjp at eccles.caltech.edu (Tim Pearson) Message-Id: <10NOV199214335969 at eccles.caltech.edu> Organization: California Institute of Technology Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!nntp-server.caltech.edu!eccles.caltech.edu!tjp References: Subject: Re: World Coordinate System proposal Sender: fitsbits-request at fits.CV.NRAO.EDU I support the recommendations of Hanisch and Wells in their "World Coordinate Systems" document. It is not intended to provide a complete and final solution to this problem, but to establish conventions that will simplify the exchange of datasets that share similar characteristics. There are many possible ways of making images, and they may involve many different possible coordinate systems; but there are certain types of images that are common in astronomy for which it is desirable to establish uniform conventions. The recommendations address three issues: (1) The FITS standard conventions for rotated images are just plain wrong: you do not represent a rotation of an N-dimensional image by N rotation angles, one for each dimension. This has made the CROTAn keywords virtually useless. The document establishes a rational interpretation of CROTA1 and CROTA2 for two-dimensional images (ignore CROTA1!); and suggests a better method (CDiiijjj) for the general linear transformation between pixel numbers and world coordinates. This new method is applicable to all images which are sampled on a regular grid (with equal-size pixels) in the world-coordinate system. (2) Astronomical images are samples of the celestial sphere, for which no regular gridding (with equal-size pixels) is possible. The document establishes conventions (which can be extended) for images that are obtained by regular gridding of a plane projection of part or all of the sphere. It is appropriate to include information about the projection in the CTYPE keywords, because in such cases the coordinate that is sampled at equal intervals is not DEC (declination) but a function of both RA and DEC. I do have some reservations about the use of these conventions with rotation, however: e.g., in an Aitoff projection with tangent point not on the equator, I am not sure that the two axes can be meaningfully called GLON-AIT and GLAT-AIT or RA---AIT and DEC--AIT. Additional clarification is needed as to precisely how to calculate sky coordinates of a pixel in such cases. It is worth emphasizing the distinction between world coordinates (linear functions of pixel number, derived by applying CRVAl, CRPIX, CDELT, and CROTA; _or_ the CDiiijjj matrix) and sky coordinates (two angles derived from the world coordinates by an additional non-linear transformation specified by CTYPE). I think this distinction might best be made by putting the description of the CDiiijjj convention in a separate section, before the description of conventions for projections of the celestial sphere. (3) The conventions proposed for coordinate reference frames (equinox, epoch, etc.) should be adopted as widely as possible to clear up a lot of confusion and misunderstanding in this area. In addition to the proposals of the Hanisch-Wells document, I think it would be useful to adopt the following conventions. I do not think they should be part of a legalistic "standard", but I think they should be strong recommendations to FITS writers. (1) In the absence of any information to the contrary, FITS readers should display two-dimensional images with the first pixel in the lower-left corner, with the first axis increasing to the right and the second axis increasing upwards. This would not preclude a program from looking at the axis descriptions and overriding this convention (as AIPS does for RA/DEC axis pairs), or the user from requesting a different display. Uniform adoption of this convention would I think remove a lot of the frustration involved when a program displays an image "upside-down" or "back-to-front". (2) The world-coordinates (x,y) of a pixel (i,j), computed according to the FITS conventions from CRVAL, CRPIX, CDELT, CROTA apply to the _center_ of the pixel. I agree with Eric Greisen that this is the only rational choice. Assuming that the image P(i) is a discrete representation of an idealized continuous function S(x), the pixelization operation can be described mathematically (for the one-dimensional case) as a convolution: +inf P(i) = Integral F(x-i) S(x) dx -inf where the convolution kernel F(x) would be delta function for an ideal "sampling" operation (e.g., a radio aperture-synthesis CLEAN map); or a top-hat function F(x) = 1 (-0.5 < x <= 0.5) 0 (otherwise) for an ideal "binning" operation (e.g., a perfect CCD). In practice F(x) is almost always going to be a symmetrical function, and it seems sensible to choose the center of symmetry as the origin. Tim Pearson, Astronomy Dept 105-24, Caltech, Pasadena, California 91125, USA Internet: TJP at Deimos.Caltech.Edu, Pearson_T at caltech.edu BITNET/EARN: TJP at CITDEIMO NSI-Decnet (SPAN): Deimos::TJP or 15237::TJP Telephone: +1 818 356-4980 FAX: +1 818 568-9352 From fitsbits-request Wed Nov 11 17:31:29 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["1953" "Wed" "11" "November" "92" "11:38:55" "GMT" "Daniel Briggs" "dbriggs at zia.aoc.nrao.edu " nil "31" "Re: World Coordinate Systems" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04402; Wed, 11 Nov 92 17:31:29 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Wed, 11 Nov 92 11:38:55 GMT From: dbriggs at zia.aoc.nrao.edu (Daniel Briggs) Message-Id: <1992Nov11.113855.8652 at zia.aoc.nrao.edu> Organization: National Radio Astronomy Observatory, Socorro NM Path: cv3.cv.nrao.edu!uvaarpa!caen!batcomputer!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!spool.mu.edu!news.cs.indiana.edu!lynx!zia.aoc.nrao.edu!dbriggs References: <9211101358.AA01257 at primate.cv.nrao.edu> Subject: Re: World Coordinate Systems Sender: fitsbits-request at fits.CV.NRAO.EDU In article <9211101358.AA01257 at primate.cv.nrao.edu> egreisen at primate.CV.NRAO.EDU (Eric Greisen) writes: >The method that has been used since day 1 in FITS is to specify 3 axes with >only 1 pixel on the third axis. Yes, but in some situations this has proved an unfortunate choice. I've never been happy with the practice of stuffing additional information about the image into 1 pixel pseudo-axes. In the case of a spectral instrument, one might plausibly make the argument that the fundamental data is really an M x N x 1 cube, but to stuff things like Fourier transform axis conjugation information in as pseudo-axes is really deplorable. To make things more concrete, suppose that I have a set of matrix routines in my favorite imaging package, and that I'd like it to operate on the arbitrary contents of a FITS image. In such a case, it really does make a difference whether there are 1 or 2 "real" dimensions. Is it a one dimensional image that should be treated as a vector, (but with some number of pseudo axes following it), or is it a two dimensional image that merely happens to have one pixel in the second dimension? As it stands now, there is really no way to tell, without building in a list of recognized axis types. I've always felt that in an ideal world NAXIS would represent the true dimensionality of the data, not simply the number of entries in the coordinate arrays. Or perhaps the other way around, and we could have an RNAXIS keyword to hold the real number of axes. It's not a major problem, and I'm not seriously suggesting the above as a fix, but in a few cases I have had to make some real kludges to get around this problem. -- | Daniel Briggs (dbriggs at nrao.edu) | USPA B-14993 | New Mexico Tech / National Radio Astronomy Observatory | DoD #387 | P.O. Box O / Socorro, NM 87801 (505) 835-7391 | Support the League for Programming Freedom (info from lpf at uunet.uu.net) From fitsbits-request Mon Nov 16 03:18:19 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["375" "" "16" "November" "1992" "08:01:46" "GMT" "Hanan M. Herzog" "herzog at ux5.lbl.gov " nil "15" "FITS compression -- best ratios" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05422; Mon, 16 Nov 92 03:18:19 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 16 Nov 1992 08:01:46 GMT From: herzog at ux5.lbl.gov (Hanan M. Herzog) Message-Id: <1e7khaINNldf at overload.lbl.gov> Organization: Lawrence Berkeley Laboratory Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!spool.mu.edu!agate!overload.lbl.gov!ux5.lbl.gov!herzog Subject: FITS compression -- best ratios Sender: fitsbits-request at fits.CV.NRAO.EDU Hi, What compression programs will provide me with the best compression ratios for FITS? FITS in the compressed format do not necessarily have to be usable, until extraction (decompression). I am currently exploring FITSPRESS. Any info on FITS compression would be appreciated. Thanks, Please reply by e-mail. Hanan Herzog Lawrence Berkeley Laboratory herzog at lbl.gov From fitsbits-request Mon Nov 16 12:48:50 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["6136" "Mon" "16" "November" "92" "12:49:26" "EST" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "122" "FTOOLS - A FITS Utility Package" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06211; Mon, 16 Nov 92 12:48:50 EST Return-Path: Date: Mon, 16 Nov 92 12:49:26 EST From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9211161749.AA28712 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: FTOOLS - A FITS Utility Package Sender: fitsbits-request at fits.CV.NRAO.EDU FTOOLS - A Package of FITS Utility Programs The HEASARC (High Energy Astrophysics Science Archive Research Center) at NASA/GSFC has developed a set of software tools to create, examine, or modify FITS format data files which are now publicly available via anonymous ftp. These programs have been written during the past year by a small team of programmers as part of the analysis system for the Astro-D X-ray satellite. Most of these programs are very general in nature, however, and may be useful for dealing with a wide variety of FITS files. The FTOOLS package is available from tetra.gsfc.nasa.gov in the pub/ftools/ subdirectory. User's should be warned that this is a beta release, so some bugs and unusual features can be expected. We will respond to any problem reports or suggested enhancements as soon as possible. New interium releases of the FTOOLS package will be made approximately every 2 - 4 weeks, so users wishing to have the latest version should periodicly check the ftp area for updates. Users may build the FTOOLS package to run in 2 different environments: as an IRAF package, or as a set of standalone executable programs. Either or both versions may be built, but we recommend using the IRAF version because it offers better on-line help facilities and provides more flexibility in running the tasks and linking them together in scripts to perform more complicated tasks. Currently, FTOOLS has only been run and tested on SUN and DECstation workstations, but we plan to release a VAX/VMS version within the next couple months. (In principle, the IRAF version of FTOOLS should work on any IRAF platform, but this has not been tested). The following is a brief summary of the FTOOLS tasks that are currently available: -------------------------------------------------------------------- flcol - List column information in a FITS table extension fstruct - List a description of the structure of a FITS file fdump - Dump contents of a FITS table to an ASCII file fimgdmp - Dump contents of a FITS image to an ASCII file fcreate - Create a FITS table from ASCII input files fappend - Append a FITS extension onto another FITS file fextract - Copy a FITS extension from a file into a new file fmerge - Merge rows from several FITS tables into one FITS table fproject - Copy specified columns of a FITS table to a new table fselect - Create a new table from selected rows of a table fsort - Sort a FITS table in place fstat - Calculate mean, standard deviation, min, and max for a column farith - Perform arithmetic on 2 FITS images fcarith - Preform arithmetic on FITS image with a constant fhisto - Make a histogram of a column in a table fcurve - Make a light curve histogram from a column in a table f2dhisto - Make a 2-D histogram (an image) from 2 columns in a table fim2lst - Convert a 2D image to a pixel list (inverse of f2dhisto) fmrgmsk - Merge 2 or more spatial masks findex - Create an index file for a FITS table column fparkey - Copy a parameter value to a FITS header keyword fkeypar - Copy a FITS header keyword to a parameter value fpartab - Copy a parameter value to a FITS table element ftabpar - Copy a FITS table element to a parameter value ftabkey - Copy a FITS table element to a FITS header keyword fkeytab - Copy a FITS header keyword to a FITS table element fmodhead - Modify the header keywords in a FITS file fkeyprint - Display keyword(s) in FITS header(s) Astro-D specific tasks: fmktime - Calculate time intervals (GTIs) from housekeeping (HK) data fmgtime - Merge 2 or more time interval (GTI) files ffltime - Filter an event list within given time intervals (GTIs) fhkexpd - Expand a compressed format housekeeping (HK) data file fhkuexpd - Compress an expanded format houskeeping (HK) data file ffaint - Convert AstroD faint mode data to a bright mode format sec2time - Convert time offset to absolute time time2sec - Convert absolute time to a time offset -------------------------------------------------------------------- Dr. William Pence Telephone: (301) 286-4599 HEASARC (SPAN) LHEAVX::PENCE or 15407::PENCE Code 668 (Internet) pence at tetra.gsfc.nasa.gov NASA/Goddard Space Flight Center Greenbelt, MD 20771 From fitsbits-request Mon Nov 16 20:25:56 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA00520; Mon, 16 Nov 92 20:25:56 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Mon, 16 Nov 1992 23:28:00 GMT From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Message-Id: <16NOV199219280348 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!caen!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!nsisrv!stars.gsfc.nasa.gov!thompson References: <1992Nov16.211426.8939 at sol.UVic.CA> Subject: Re: comment field Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1992Nov16.211426.8939 at sol.UVic.CA>, durand at dao.nrc.ca writes... >We are trying to desing special fits ingesters for moving headers content into a >database system when we encounter the following case: > >CARD = 'data 2.5' ' / 10 ' > >This card (I just type in the worst case we could imagine) has no comment but how to detect >that. It seams that each case we have with a single quote following a slash will create an >ambigous situation. Is there any solution to this?. > >We have checked within the standard FITS document and haven't found anything which will >remove this ambiguity. Is this a recommended FITS entry? I would have thought that you wanted either: CARD = 'data 2.5'' / 10 ' or CARD = 'data 2.5'' '' / 10 ' Quote characters inside character strings are supposed to be doubled to signal that the string doesn't end there--that should remove the ambiguity. Bill Thompson From fitsbits-request Tue Nov 17 11:02:15 1992 Status: O X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["399" "Tue" "17" "November" "1992" "10:01:57" "-0600" "MAJUMDAR at ssl.msfc.nasa.gov" "MAJUMDAR at ssl.msfc.nasa.gov" nil "9" "Read/write variable length array in Fits" nil nil nil "11"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01472; Tue, 17 Nov 92 11:02:15 EST Return-Path: Date: Tue, 17 Nov 1992 10:01:57 -0600 (CST) From: MAJUMDAR at ssl.msfc.nasa.gov Message-Id: <921117100157.24801f72 at ssl.msfc.nasa.gov> Subject: Read/write variable length array in Fits To: fitsbits at fits.CV.NRAO.EDU X-Vmsmail-To: SMTP%"fitsbits at fits.cv.nrao.edu" Sender: fitsbits-request at fits.CV.NRAO.EDU Hi, I am currently working on variable length array using Fitsio routines for NASA/GRO/BATSE project. The array size is large - over 40000 elements. Any information on the use of variable length array in Fits would be appreciated. Thank you. Krishna Majumdar BCSS/MSFC E-mail address : majumdar at ssl.msfc.nasa.gov From fitsbits-request Fri Nov 20 11:56:21 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07391; Fri, 20 Nov 92 11:56:21 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Fri, 20 Nov 1992 16:19:00 GMT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Message-Id: <20NOV199211191671 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!nsisrv!nssdca.gsfc.nasa.gov!bschlesinger Subject: FITS basics and information (periodic posting) Sender: fitsbits-request at fits.CV.NRAO.EDU 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 provide a means for 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 also provide additional information, for example, about the instrument or the history of the data. 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; it does not incorporate "FITS viewers", packages for decoding the data into an image. Users must develop or obtain separate software to convert 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. However, support is not guaranteed for all FITS files where the data are in the form of an image. In particular, there may be problems when the data matrix members are in IEEE floating point format (BITPIX<0) or the matrix has more than two dimensions (NAXIS>2). Archie Warnock and Ron Baalke have announced release of version 7.8 of the IMDISP program. IMDISP is an interactive image processing program that runs on an IBM PC computer and supports FITS input. IMDISP 7.8 is available via anonymous ftp at ames.arc.nasa.gov [128.102.18.3] in a file called imdisp78.zip in the pub/SPACE/SOFTWARE subdirectory and at hypatia.gsfc.nasa.gov in the pub/software/imdisp subdirectory. It is also available through Simtel-20 [192.88.110.20] at PD1:IMDISP78.ZIP. Additional 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) FITS Support Office. 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 expressed in FITS. 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 NASA draft 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. Additional material can be obtained by anonymous ftp from the National Radio Astronomy Observatory, from fits.cv.nrao.edu, in the directory FITS. The Documents subdirectory (case is significant) contains copies of the BINTABLE Binary Tables extension proposal, which is now under consideration by the FITS committees, and a draft describing a suggested method for data compression under FITS. It also contains text of a paper summarizing conclusions of a workshop on World Coordinates held in Charlottesville in 1988, which is serving as the basis for continuing discussion of world coordinates issues, some of which appears on this newsgroup from time to time. These documents are available in both LaTeX and PostScript forms. A number of additional documents are available in ASCII text form, including the proposal on physical blocking of FITS files on media other than tape and material on FITS, its history, and the FITS community. 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 NOST 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 NOST can be reached as follows: (Postal) NASA/OSSA Office of Standards and Technology Code 633.2 Goddard Space Flight Center Greenbelt MD 20771 USA (Internet) nost at nssdca.gsfc.nasa.gov (DECnet) NCF::NOST Telephone: (301)286-3575 8 a. m. - 5 p. m., U. S. Eastern Time If the Librarian is unavailable, a phone mail system takes the call after four rings. 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 fitsbits-request Mon Nov 23 11:21:02 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA00684; Mon, 23 Nov 92 11:21:02 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Mon, 23 Nov 1992 15:34:32 GMT From: hanisch at stsci.edu (Bob Hanisch, ST ScI) Message-Id: <1992Nov23.153432.3502 at stsci.edu> Organization: Space Telescope Science Institute, Baltimore MD Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!ncar!noao!stsci!iris.stsci.edu!hanisch Reply-To: hanisch at stsci.edu Subject: WGAS FITS Committee (WFC) Sender: fitsbits-request at fits.CV.NRAO.EDU As chair of the AAS Working Group on Astronomical Software I have appointed a standing committee under the WGAS that will be the formal voting authority on issues related to the FITS standard. As many WGAS members know, in the past our votes on FITS issues have been rather informal, including those WGAS members who were able to attend our meetings during the summer AAS meeting. The WGAS FITS Committee is analogous to the European and Japanese FITS Committees, both of which have a formal voting membership. It is my intention to include all interested parties in the discussion of FITS issues via the FITS newsgroup, WGAS meetings, ad hoc committees on specific issues (e.g., the world coordinate systems that are now being discussed), BoF sessions at the ADASS conferences, etc. However, in order to assure that all major data producing and data archiving institutions are represented when issues come to a vote, the WFC has been constituted. I have tried to make sure that everyone is properly represented, but I would appreciate it if people would bring to my attention any major omissions or oversights. I have appointed Don Wells of NRAO as chair of this committee, and he will organize the voting for the FITS proposals that are now before us (binary tables extension, image extension, and agreement on FITS on media other than 9-track magnetic tape). Voting will be carried out by e-mail. Approval of any issue will require at least 13 positive votes. In practice we will strive to work out any substantive disagreements so that votes can be unanimous. The WGAS FITS Committee membership is attached below. Bob Hanisch Chair, AAS Working Group on Astronomical Software hanisch at stsci.edu WGAS FITS Committee, November 1992 Don Wells, NRAO (Chair) dwells at nrao.edu Lee Brotzman, NSSDC brotzman at ndadsa.gsfc.nasa.gov Dennis Crabtree, DAO/CADC crabtree at dao.nrc.ca Eric Greisen, NRAO egreisen at nrao.edu Bob Hanisch, ST ScI (ex officio) hanisch at stsci.edu Arne Henden, OSU henden at mps.ohio-state.edu William Lupton, Keck Obs. wlupton at keck.hawaii.edu Eric Mandel, SAO eric at cfa.harvard.edu Bob Narron, IPAC bob at ipac.caltech.edu Bill Pence, HEASARC pence at tetra.gsfc.nasa.gov Jeff Percival, U.Wis. jwp at sal.wisc.edu Skip Schaller, U.Ariz. skip at as.arizona.edu Barry Schlesinger, NASA FITS Office bschlesinger at nssdca.gsfc.nasa.gov Peter Teuben, U. Md. teuben at astro.umd.edu Doug Tody, NOAO tody at noao.edu Michael Van Steenberg mev at ndadsa.gsfc.nasa.gov Archie Warnock, NSSDC warnock at hypatia.gsfc.nasa.gov Winifred Williams, NSO wwilliams at noao.edu Preben Grosbol, ESO, IAU (non-voting) pgrosbol at eso.org --- Robert J. Hanisch Tel. (410)338-4910 Fax. (410)338-5090 Space Telescope Science Institute NSI: hanisch at stsci.edu [130.167.1.2] 3700 San Martin Drive DECNet: STSCIC::HANISCH [6549::] Baltimore, MD 21218 USA Bitnet: hanisch at stsci To all members of the FITS community: From fitsbits-request Tue Nov 24 09:53:51 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02806; Tue, 24 Nov 92 09:53:51 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 24 Nov 1992 13:36:34 GMT From: phjj at ruchem.ru.ac.za Message-Id: <1992Nov24.133506.11664 at hippo.ru.ac.za> Organization: Rhodes University, Grahamstown, SA Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!haven.umd.edu!uunet!psgrain!hippo!ruchem.ru.ac.za!PHJJ Reply-To: phjj at ruchem.ru.ac.za Subject: VAX file utility Sender: fitsbits-request at fits.CV.NRAO.EDU Before our recent disasterous disk crash I used to have a utility that converted 512 byte block files to 2880 byte record files. I seem to remember it was a fdl script. Please e-mail me where I can recover this utility. Thanks Justin From fitsbits-request Tue Nov 24 11:51:26 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02876; Tue, 24 Nov 92 11:51:26 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 24 Nov 1992 16:13:05 GMT From: hanisch at stsci.edu (Bob Hanisch, ST ScI) Message-Id: <1992Nov24.161305.29948 at stsci.edu> Organization: Space Telescope Science Institute, Baltimore MD Path: cv3.cv.nrao.edu!uvaarpa!caen!destroyer!ncar!noao!stsci!iris.stsci.edu!hanisch References: <1992Nov24.133506.11664 at hippo.ru.ac.za> Reply-To: hanisch at stsci.edu Subject: Re: VAX file utility Sender: fitsbits-request at fits.CV.NRAO.EDU Here's a copy of the VMS command file that reblocks files to 2880 byte records. $!---------------------------------------------------------------------- $! FIXFITS filename $! FIXFITS CONVERTs a file to the desired AIPSFITS disk format $!---------------------------------------------------------------------- $ create/fdl=sys$input: temp.dat RECORD CARRIAGE_CONTROL NONE SIZE 2880 FORMAT FIXED $! now convert - old fails some $! convert/append 'P1' TEMP.DAT $! now convert - new method $ copy 'P1' TEMP.DAT/overlay $ rename temp.dat 'P1' $! clean up $ purge 'P1' $! --- Robert J. Hanisch Tel. (410)338-4910 Fax. (410)338-5090 Space Telescope Science Institute NSI: hanisch at stsci.edu [130.167.1.2] 3700 San Martin Drive DECNet: STSCIC::HANISCH [6549::] Baltimore, MD 21218 USA Bitnet: hanisch at stsci From fitsbits-request Tue Nov 24 18:02:35 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03274; Tue, 24 Nov 92 18:02:35 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Tue, 24 Nov 1992 22:10:00 GMT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) Message-Id: <24NOV199217101339 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!caen!zaphod.mps.ohio-state.edu!darwin.sura.net!ukma!nsisrv!nssdca.gsfc.nasa.gov!bschlesinger References: <1992Nov19.214524.6479 at organpipe.uug.arizona.edu> <1992Nov19.225316.24612 at nrao.edu> <1992Nov23.215025.22192 at organpipe.uug.arizona.edu> Subject: Re: st6 images wanted Sender: fitsbits-request at fits.CV.NRAO.EDU I'm coming in here in the middle, as I somehow missed the earlier posts in this thread. I'm repeating the whole previous text, because I'm crossposting to sci.astro.fits, whose readers may not have seen the earlier discussion. In article <1992Nov23.215025.22192 at organpipe.uug.arizona.edu>, newberry at aquarius.as.arizona.edu (Mike Newberry) writes... >In article <1992Nov19.225316.24612 at nrao.edu> cflatter at nrao.edu writes: >>In article 6479 at organpipe.uug.arizona.edu, newberry at kepler.as.arizona.edu (Mike Newberry) writes: >>>Skip the first 2880 bytes of the file, as this contains the file information >>>"header" in FITS format. For the files under discusssion here, that procedure might work but for regular FITS files, the header should not be skipped as it is where the information on data type and matrix dimensions is supposed to be found. >>>Starting at byte offset 2880 will be found binary, >>>uncompressed, unpadded pixel data. The pixels are unsigned 16-bit integers, >> ^^^^^^^^^^^^^^^^^^^^^^^^ >>>so watch out if unsigned integers might choke your software--these images do >>>have values above 32767. To turn this binary raster file into a 2-dimensional >>>image, note that there are 375 2-byte pixels in each row. There are 242 rows. >> >>If this description is accurate the files do not conform to accepted FITS >>standards. Either 16-bit integers are twos complement or SIMPLE = F. >> >> Chris Flatters >> cflatter at nrao.edu > >Absolutely, Chris. And that should be the rule. >I don't know how many images you've seen lately coming >out of CCD systems at major observatories, but images with values above >32767 in short integer format and the header flag SIMPLE='T' are typical. >They do not conform to FITS standards. Period. >On the other hand, since 16 bit A/D >converters are the de facto standard for professional CCD cameras as well as >for many used by amateurs these days, you'll have to get used to seeing >16 bit unsigned pixels. I've complained about the problem and tried holding >out on writing software that would accomodate it. Keep complaining. >The problem is that people >who write the CCD controller software refuse to chop values above 32767 and >allow their "WFITS" programs to write files or tapes that have SIMPLE='T', >thereby assuming that the image processing software will know how to deal >with it. If observers want to keep pixels in short integer format throughout >data reduction to save disk space and provide much faster processing speed, >then they will need to allow for the negative values given by signed integers. >With unsigned integer data, they'll either have to live with big negative >holes in the centers of bright images or they will have to manually chop >their pixels values at 32767 anyway! Since real world images must allow for >negative intensity, the founding fathers of FITS, Wells and Griesen, made >the right decision in allowing only for signed integers for 2-byte pixels. >However, the world hasn't followed the rules. The "world", the IAU, has endorsed FITS as the standard data transfer system in astronomy, as defined in the four FITS papers and the Floating Point Agreement. SIMPLE=T as described in the first FITS paper is the signature of FITS; it implies to the reader who picks up the file that the format is FITS. If the file following is out of conformance, then whoever is creating the file is not following the IAU standard. What the producers of the files could do is to have the original file in a local format with SIMPLE=F and then create a file in proper FITS format with a proper data type, using BZERO and BSCALE if necessary to keep the full range. > >To accomodate this ambiguity with 2-byte integers, we have a flag for >specifying unsigned integer data in the "read FITS file" function of MIRA. >This is better than forcing people to write their data using SIMPLE='F'. >Recall that setting SIMPLE='F' doesn't then tell the FITS translator >specifically what in the heck is wrong with the image format. For this >reason, it is better, I think, to simply allow the user to use SIMPLE='T' >and then specify with a flag that their images contain unsigned 16 bit >integers. The reader can then chop the values at 32767 to get the pixels >into the domain of signed integers. No, because then SIMPLE=T is meaning whatever the writer wants it to mean rather than being precisely defined. Readers should return non-compliant files with SIMPLE=T to the sender. If a file is sent with SIMPLE=F, then it is up to the sender to define the format for readers. SIMPLE=T has documentation -- the FITS literature. >This is an issue I had planned on >bringing up at the FITS committee meeting at the AAS in January. I don't think there is a formal WGAS meeting until the summer AAS. However, this posting to sci.astro.fits will serve the same purpose. Much of the discussion is by electronic mail. Until such time as some provision may be made for unsigned 16-bit integers, they should not appear in the primary data array of a file with SIMPLE = T. >It would make life easy again if people would use only 15 bits of their >16 bit A/D converts, but that doesn't seem to be in the cards yet. > >Mike Newberry >Axiom Research, Inc. >.. Standards are developed so that readers know what to expect. If people create data sets in the form of the standard that are not in compliance, then they defeat the purpose of creating the standard. Barry Schlesinger NOST FITS Support Office From fitsbits-request Tue Nov 24 19:50:12 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03482; Tue, 24 Nov 92 19:50:12 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 24 Nov 92 23:40:11 GMT From: newberry at kepler.as.arizona.edu (Mike Newberry) Message-Id: <1992Nov24.234011.7663 at organpipe.uug.arizona.edu> Organization: University of Arizona, Tucson, AZ Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!jvnc.net!yale.edu!yale!gumby!destroyer!ncar!noao!amethyst!organpipe.uug.arizona.edu!kepler.as.arizona.edu!newberry References: <1992Nov19.225316.24612 at nrao.edu> <1992Nov23.215025.22192 at organpipe.uug.arizona.edu> <24NOV199217101339 at nssdca.gsfc.nasa.gov> Subject: Re: st6 images wanted Sender: fitsbits-request at fits.CV.NRAO.EDU In article <24NOV199217101339 at nssdca.gsfc.nasa.gov> bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) writes: >I'm coming in here in the middle, as I somehow missed the earlier >posts in this thread. I'm repeating the whole previous text, because >I'm crossposting to sci.astro.fits, whose readers may not have seen >the earlier discussion. > > In article <1992Nov23.215025.22192 at organpipe.uug.arizona.edu>, newberry at aquarius.as.arizona.edu (Mike Newberry) writes... >>In article <1992Nov19.225316.24612 at nrao.edu> cflatter at nrao.edu writes: >>>In article 6479 at organpipe.uug.arizona.edu, newberry at kepler.as.arizona.edu (Mike Newberry) writes: >>>>Skip the first 2880 bytes of the file, as this contains the file information >>>>"header" in FITS format. > >For the files under discusssion here, that procedure might work but >for regular FITS files, the header should not be skipped as it >is where the information on data type and matrix dimensions is >supposed to be found. > >>>>Starting at byte offset 2880 will be found binary, >>>>uncompressed, unpadded pixel data. The pixels are unsigned 16-bit integers, >>> ^^^^^^^^^^^^^^^^^^^^^^^^ >>>>so watch out if unsigned integers might choke your software--these images do >>>>have values above 32767. To turn this binary raster file into a 2-dimensional >>>>image, note that there are 375 2-byte pixels in each row. There are 242 rows. >>> >>>If this description is accurate the files do not conform to accepted FITS >>>standards. Either 16-bit integers are twos complement or SIMPLE = F. >>> >>> Chris Flatters >>> cflatter at nrao.edu >> >>Absolutely, Chris. > >And that should be the rule. > >>I don't know how many images you've seen lately coming >>out of CCD systems at major observatories, but images with values above >>32767 in short integer format and the header flag SIMPLE='T' are typical. >>They do not conform to FITS standards. > >Period. > >>On the other hand, since 16 bit A/D >>converters are the de facto standard for professional CCD cameras as well as >>for many used by amateurs these days, you'll have to get used to seeing >>16 bit unsigned pixels. I've complained about the problem and tried holding >>out on writing software that would accomodate it. > >Keep complaining. > >>The problem is that people >>who write the CCD controller software refuse to chop values above 32767 and >>allow their "WFITS" programs to write files or tapes that have SIMPLE='T', >>thereby assuming that the image processing software will know how to deal >>with it. If observers want to keep pixels in short integer format throughout >>data reduction to save disk space and provide much faster processing speed, >>then they will need to allow for the negative values given by signed integers. >>With unsigned integer data, they'll either have to live with big negative >>holes in the centers of bright images or they will have to manually chop >>their pixels values at 32767 anyway! Since real world images must allow for >>negative intensity, the founding fathers of FITS, Wells and Griesen, made >>the right decision in allowing only for signed integers for 2-byte pixels. >>However, the world hasn't followed the rules. > >The "world", the IAU, has endorsed FITS as the standard data transfer >system in astronomy, as defined in the four FITS papers and the >Floating Point Agreement. SIMPLE=T as described in the first FITS >paper is the signature of FITS; it implies to the reader who picks up >the file that the format is FITS. If the file following is out of >conformance, then whoever is creating the file is not following the >IAU standard. > >What the producers of the files could do is to have the original file >in a local format with SIMPLE=F and then create a file in proper FITS >format with a proper data type, using BZERO and BSCALE if necessary to >keep the full range. > >> >>To accomodate this ambiguity with 2-byte integers, we have a flag for >>specifying unsigned integer data in the "read FITS file" function of MIRA. >>This is better than forcing people to write their data using SIMPLE='F'. >>Recall that setting SIMPLE='F' doesn't then tell the FITS translator >>specifically what in the heck is wrong with the image format. For this >>reason, it is better, I think, to simply allow the user to use SIMPLE='T' >>and then specify with a flag that their images contain unsigned 16 bit >>integers. The reader can then chop the values at 32767 to get the pixels >>into the domain of signed integers. > >No, because then SIMPLE=T is meaning whatever the writer wants it to >mean rather than being precisely defined. Readers should >return non-compliant files with SIMPLE=T to the sender. If a file is >sent with SIMPLE=F, then it is up to the sender to define the format >for readers. SIMPLE=T has documentation -- the FITS literature. Barry, you are absolutely correct; I have no argument with anything you've said. My point is not that I'm endorsing the violation of FITS format (and I do understand the details--I have all of the documents), but people are producing 16 bit unsigned data "right and left" these days. How would you respond if you were deluged with telephone calls by cranky, wild-eyed guys on the other end of the line complaining about "holes" in the middle of all bright objects? You can explain to them that their FITS images aren't true FITS images. You can tell them that it`s not the fault of your FITS reading software because it conforms to the NOST standard. You can tell them that it's the fault of their camera control software or FITS *writing* software. When enough of them want to send *your* software back, you tell them "yes, we can write in a quick fix that will allow you to work with the not-to-true FITS images you have". That was my point. I am not endorsing violation of the FITS standard. What I am doing is allowing people to work with data they have or produce using software someone else wrote for them or sold to them. Meanwhile, we have to keep harping on camera manufacturers and software writers about modifying their software to use only 15 bits of the 16 bit A/D converter. I believe this to be the only practical solution for the time being. Mike Newberry From fitsbits-request Tue Nov 24 20:54:17 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03600; Tue, 24 Nov 92 20:54:17 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 25 Nov 92 00:19:44 GMT From: newberry at kepler.as.arizona.edu (Mike Newberry) Message-Id: <1992Nov25.001944.8002 at organpipe.uug.arizona.edu> Organization: University of Arizona, Tucson, AZ Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!spool.mu.edu!sdd.hp.com!caen!uunet!news.claremont.edu!ucivax!news.service.uci.edu!cerritos.edu!arizona.edu!arizona!amethyst!organpipe.uug.arizona.edu!kepler.as.arizona.edu!newberry Subject: 16 bit unsigned data is taking over the world! Sender: fitsbits-request at fits.CV.NRAO.EDU This is a lengthy thread, but I thought it sould be of use to readers to know the history of this discussion. The original posting regarded someone wanting to read FITS format images without actually having FITS reading software. I told them how to do this and noted that the pixels were unsigned 16 bit integers. This has opened up a related, important discussion which needs to be addressed: what to do with the proliferation of 16 bit unsigned "FITS" data. Unsigned 16 bit pixels are quite common nowadays, masquerading in images having ostensible FITS headers and blocking structure. This results from the widespread use of 16 bit A/D converters, especially in the commercial CCD camera market. Software authors who don't have the FITS documents look at a FITS header and naively say "Yes, I see how this is coded". Then they write software to drive CCD cameras or to write CCD images into "FITS" format. The problem is that quasi-FITS data is proliferating and we need to do something about it! I have seen a number of other problems with image headers masquerading as FITS format which I won't go into here. -------- In article <24NOV199217101339 at nssdca.gsfc.nasa.gov> bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) writes: >I'm coming in here in the middle, as I somehow missed the earlier >posts in this thread. I'm repeating the whole previous text, because >I'm crossposting to sci.astro.fits, whose readers may not have seen >the earlier discussion. > > In article <1992Nov23.215025.22192 at organpipe.uug.arizona.edu>, newberry at aquarius.as.arizona.edu (Mike Newberry) writes... >>In article <1992Nov19.225316.24612 at nrao.edu> cflatter at nrao.edu writes: >>>In article 6479 at organpipe.uug.arizona.edu, newberry at kepler.as.arizona.edu (Mike Newberry) writes: >>>>Skip the first 2880 bytes of the file, as this contains the file information >>>>"header" in FITS format. > >For the files under discusssion here, that procedure might work but >for regular FITS files, the header should not be skipped as it >is where the information on data type and matrix dimensions is >supposed to be found. > >>>>Starting at byte offset 2880 will be found binary, >>>>uncompressed, unpadded pixel data. The pixels are unsigned 16-bit integers, >>> ^^^^^^^^^^^^^^^^^^^^^^^^ >>>>so watch out if unsigned integers might choke your software--these images do >>>>have values above 32767. To turn this binary raster file into a 2-dimensional >>>>image, note that there are 375 2-byte pixels in each row. There are 242 rows. >>> >>>If this description is accurate the files do not conform to accepted FITS >>>standards. Either 16-bit integers are twos complement or SIMPLE = F. >>> >>> Chris Flatters >>> cflatter at nrao.edu >> >>Absolutely, Chris. > >And that should be the rule. > >>I don't know how many images you've seen lately coming >>out of CCD systems at major observatories, but images with values above >>32767 in short integer format and the header flag SIMPLE='T' are typical. >>They do not conform to FITS standards. > >Period. > >>On the other hand, since 16 bit A/D >>converters are the de facto standard for professional CCD cameras as well as >>for many used by amateurs these days, you'll have to get used to seeing >>16 bit unsigned pixels. I've complained about the problem and tried holding >>out on writing software that would accomodate it. > >Keep complaining. > >>The problem is that people >>who write the CCD controller software refuse to chop values above 32767 and >>allow their "WFITS" programs to write files or tapes that have SIMPLE='T', >>thereby assuming that the image processing software will know how to deal >>with it. If observers want to keep pixels in short integer format throughout >>data reduction to save disk space and provide much faster processing speed, >>then they will need to allow for the negative values given by signed integers. >>With unsigned integer data, they'll either have to live with big negative >>holes in the centers of bright images or they will have to manually chop >>their pixels values at 32767 anyway! Since real world images must allow for >>negative intensity, the founding fathers of FITS, Wells and Griesen, made >>the right decision in allowing only for signed integers for 2-byte pixels. >>However, the world hasn't followed the rules. > >The "world", the IAU, has endorsed FITS as the standard data transfer >system in astronomy, as defined in the four FITS papers and the >Floating Point Agreement. SIMPLE=T as described in the first FITS >paper is the signature of FITS; it implies to the reader who picks up >the file that the format is FITS. If the file following is out of >conformance, then whoever is creating the file is not following the >IAU standard. > >What the producers of the files could do is to have the original file >in a local format with SIMPLE=F and then create a file in proper FITS >format with a proper data type, using BZERO and BSCALE if necessary to >keep the full range. > >> >>To accomodate this ambiguity with 2-byte integers, we have a flag for >>specifying unsigned integer data in the "read FITS file" function of MIRA. >>This is better than forcing people to write their data using SIMPLE='F'. >>Recall that setting SIMPLE='F' doesn't then tell the FITS translator >>specifically what in the heck is wrong with the image format. For this >>reason, it is better, I think, to simply allow the user to use SIMPLE='T' >>and then specify with a flag that their images contain unsigned 16 bit >>integers. The reader can then chop the values at 32767 to get the pixels >>into the domain of signed integers. > >No, because then SIMPLE=T is meaning whatever the writer wants it to >mean rather than being precisely defined. Readers should >return non-compliant files with SIMPLE=T to the sender. If a file is >sent with SIMPLE=F, then it is up to the sender to define the format >for readers. SIMPLE=T has documentation -- the FITS literature. Barry, you are absolutely correct; I agree with everything you've said. I don't want to be misinterpreted as endorsing the violation of FITS format (and I do understand the details--I have all of the documents), but people are producing 16 bit unsigned data "right and left" these days. Let's look at a not-so-hypothetical situation: How would you respond if you were deluged with telephone calls by cranky, wild-eyed astronomers on the other end of the line complaining about large negative "holes" in the middle of all bright objects? You can explain to them that their FITS images aren't true FITS images. You can tell them that it`s not the fault of your FITS reading software because it conforms to the NOST standard. You can tell them that it's the fault of their camera control software or FITS *writing* software. When enough of them want to send your software back for a refund, you tell them "Yes, we can write a quick fix that will allow you to work with the quasi-FITS images you have". I think you get my intent here. The problem here is that astronomers are stuck with image files which are claimed to be genuine FITS format (i.e., SIMPLE='T'). Our intermediate solution, which I believe to be the only practical one, is to allow people to specify whether they have 16 bit unsigned data. This way, they can use the images produced by something they have no control over. Meanwhile, we have to keep harping on camera manufacturers and software authors about modifying their software to use only 15 bits of the 16 bit A/D converter. I believe this to be the only practical solution for the time being. I propose that FITS might adopt a value of -16 for BITPIX which would signify unsigned 16 bit pixel values, just as we've standardized -32 as meaning short real floating point while 32 signifies 32 bit long integer pixel values. Mike Newberry From fitsbits-request Tue Nov 24 21:52:45 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03751; Tue, 24 Nov 92 21:52:45 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Wed, 25 Nov 1992 01:25:00 GMT From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Message-Id: <24NOV199221252383 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!darwin.sura.net!ukma!nsisrv!stars.gsfc.nasa.gov!thompson References: <1992Nov19.225316.24612 at nrao.edu> <1992Nov23.215025.22192 at organpipe.uug.arizona.edu> <24NOV199217101339 at nssdca.gsfc.nasa.gov> <1992Nov24.234011.7663 at organpipe.uug.arizona.edu> Subject: Re: st6 images wanted Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1992Nov24.234011.7663 at organpipe.uug.arizona.edu>, newberry at kepler.as.arizona.edu (Mike Newberry) writes... (stuff deleted) >Barry, you are absolutely correct; I have no argument with anything you've >said. My point is not that I'm endorsing the violation of FITS format (and >I do understand the details--I have all of the documents), but people are >producing 16 bit unsigned data "right and left" these days. How would you >respond if you were deluged with telephone calls by cranky, wild-eyed guys on >the other end of the line complaining about "holes" in the middle of all >bright objects? You can explain to them that their FITS images aren't true >FITS images. You can tell them that it`s not the fault of your FITS reading >software because it conforms to the NOST standard. You can tell them that >it's the fault of their camera control software or FITS *writing* software. >When enough of them want to send *your* software back, you tell them "yes, >we can write in a quick fix that will allow you to work with the not-to-true >FITS images you have". > >That was my point. I am not endorsing violation of the FITS standard. What >I am doing is allowing people to work with data they have or produce using >software someone else wrote for them or sold to them. Meanwhile, we have to >keep harping on camera manufacturers and software writers about modifying >their software to use only 15 bits of the 16 bit A/D converter. I believe >this to be the only practical solution for the time being. The idea of changing the science to accomodate FITS files just floors me. One either needs to change FITS files to meet the needs of the science, or (gasp!) use something other than FITS, like CDF, HDF, etc. However, as Barry pointed out, there are ways to write the data out to FITS files, and still be legal. You could, 1. Write the data out as SIMPLE=F. You have to do this anyways unless you fix the problem in some way consistent with FITS. 2. Subtract 32767 from the data, and set BZERO = -32767. 3. Divide the data by 2 to scale it into 15 bits, if that's all you want. 4. Write the data out in 32 bit long integers. 5. Define a FITS extension that does allow for unsigned 16 bit integers. However, if you don't solve it in a "legal" way, then you *have* to set SIMPLE to F, because it *isn't* a FITS file. Bill Thompson From fitsbits-request Wed Nov 25 03:34:48 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03812; Wed, 25 Nov 92 03:34:48 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 25 Nov 1992 07:26:20 GMT From: sla at umbra.UCSC.EDU (Steve Allen) Message-Id: <1ev9qsINNp21 at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!spool.mu.edu!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla References: <24NOV199217101339 at nssdca.gsfc.nasa.gov> <1992Nov24.234011.7663 at organpipe.uug.arizona.edu> <24NOV199221252383 at stars.gsfc.nasa.gov> Subject: 16-bit FITS integers (was Re: st6 images wanted) Sender: fitsbits-request at fits.CV.NRAO.EDU In article <24NOV199221252383 at stars.gsfc.nasa.gov> thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes: >However, as Barry pointed out, there are ways to write the data out to FITS >files, and still be legal. You could, > 2. Subtract 32767 from the data, and set BZERO = -32767. >However, if you don't solve it in a "legal" way, then you *have* to set SIMPLE >to F, because it *isn't* a FITS file. It might be better to subtract 32768 from the data and set BZERO=-32768 The advantage of this is that no subtraction is actually required, you need merely bit flip the most significant bit (or XOR with -32768, as you prefer to visualize it). This is likely to be *much* quicker than subtraction depending on the hardware that is doing the arithmetic. This solution is likely to be the one implemented in the DSP units that will be reading out the CCDs on the Keck telescope. The bit flip merely introduces one clock cycle of delay in the data pipeline, which is unnoticeable when reading out several million pixels. _______________________________________________________________________________ Steve Allen | That was the equation! | sla at lick.ucsc.edu UCO/Lick Observatory | Existence!...Survival must | If the UC were opining, Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't tell me. From fitsbits-request Wed Nov 25 05:56:21 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03830; Wed, 25 Nov 92 05:56:21 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Wed, 25 Nov 92 07:47:29 GMT From: dbriggs at zia.aoc.nrao.edu (Daniel Briggs) Message-Id: <1992Nov25.074729.5341 at zia.aoc.nrao.edu> Organization: National Radio Astronomy Observatory, Socorro NM Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!umn.edu!lynx!zia.aoc.nrao.edu!dbriggs References: <1992Nov23.215025.22192 at organpipe.uug.arizona.edu> <24NOV199217101339 at nssdca.gsfc.nasa.gov> <1992Nov24.234011.7663 at organpipe.uug.arizona.edu> Subject: Re: st6 images wanted Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1992Nov24.234011.7663 at organpipe.uug.arizona.edu> newberry at kepler.as.arizona.edu (Mike Newberry) writes: >Meanwhile, we have to >keep harping on camera manufacturers and software writers about modifying >their software to use only 15 bits of the 16 bit A/D converter. I believe >this to be the only practical solution for the time being. Hmmmm. Wouldn't setting BZERO to 32768 and BSCALE to 1.0 map the range of the signed integer into the range of an unsigned integer? Granted, you'll lose some of the distinction between array values and true physical values. But for any desired mapping of 16 bit unsigned array values into physical values, there will be a proper BZERO and BSCALE that operates on 16 bit signed array values instead. I grant you that having the pixel values be true unsigned integers is aesthetically cleaner, but at least this way we've got valid FITS files. -- | Daniel Briggs (dbriggs at nrao.edu) | USPA B-14993 | New Mexico Tech / National Radio Astronomy Observatory | DoD #387 | P.O. Box O / Socorro, NM 87801 (505) 835-7391 | Support the League for Programming Freedom (info from lpf at uunet.uu.net) From fitsbits-request Wed Nov 25 10:21:40 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04468; Wed, 25 Nov 92 10:21:40 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Wed, 25 Nov 1992 13:59:00 GMT From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) Message-Id: <25NOV199209594231 at stars.gsfc.nasa.gov> Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!spool.mu.edu!agate!ames!nsisrv!stars.gsfc.nasa.gov!thompson References: <1992Nov25.001944.8002 at organpipe.uug.arizona.edu> Subject: Re: 16 bit unsigned data is taking over the world! Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1992Nov25.001944.8002 at organpipe.uug.arizona.edu>, newberry at kepler.as.arizona.edu (Mike Newberry) writes... (lengthy thread deleted) >I propose that FITS might adopt a value of -16 for BITPIX which would signify >unsigned 16 bit pixel values, just as we've standardized -32 as meaning >short real floating point while 32 signifies 32 bit long integer pixel values. I agree that this is a valuable suggestion. Currently we use 12 bit A/Ds for our CCDs, but would like to be able to use 16 bit A/Ds in the future. Having an unsigned 16-bit integer type would be very helpful. (I currently can't imagine a use for an unsigned 32-bit integer type.) Let me also suggest that there be an unsigned 16-bit integer type in binary tables (BINTABLE). This could be identified as the type "U" in TFORM records. Programming environments that don't support unsigned integer types, such as Fortran and IDL, could read 16-bit integer types into 32 bit integer arrays. Please note that currently, as far as I am aware, using 'BITPIX=-16' as suggested above would still require 'SIMPLE=F'. Bill Thompson From fitsbits-request Fri Nov 27 10:17:57 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09116; Fri, 27 Nov 92 10:17:57 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Fri, 27 Nov 1992 13:23:57 GMT From: zrepachol at cc.curtin.edu.au Message-Id: <1992Nov27.222357.1 at cc.curtin.edu.au> Organization: Curtin University of Technology Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!haven.umd.edu!uunet!munnari.oz.au!uniwa!cujo!cc.curtin.edu.au!zrepachol References: <1992Nov19.225316.24612 at nrao.edu> <1992Nov23.215025.22192 at organpipe.uug.arizona.edu> <24NOV199217101339 at nssdca.gsfc.nasa.gov> <1992Nov24.234011.7663 at organpipe.uug.arizona.edu> Subject: Re: st6 images wanted Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1992Nov24.234011.7663 at organpipe.uug.arizona.edu>, newberry at kepler.as.arizona.edu (Mike Newberry) writes: > In article <24NOV199217101339 at nssdca.gsfc.nasa.gov> bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) writes: ... >> In article <1992Nov23.215025.22192 at organpipe.uug.arizona.edu>, newberry at aquarius.as.arizona.edu (Mike Newberry) writes... >>>In article <1992Nov19.225316.24612 at nrao.edu> cflatter at nrao.edu writes: >>>>In article 6479 at organpipe.uug.arizona.edu, newberry at kepler.as.arizona.edu (Mike Newberry) writes: ... > That was my point. I am not endorsing violation of the FITS standard. What > I am doing is allowing people to work with data they have or produce using > software someone else wrote for them or sold to them. Meanwhile, we have to > keep harping on camera manufacturers and software writers about modifying > their software to use only 15 bits of the 16 bit A/D converter. I believe > this to be the only practical solution for the time being. > So do you keep using 15 of your 16, next year 18, then 20 bit converters? If it does not conform to the standard, its NOT FITS. Beat the daylights out of the supplier, cancel the cheque or what ever it takes to pound through the skulls of the programers to get it right. There is a right way and a wrong way to fix something thats broken. Fixing it when its not broken is one of the more stupid... ~Paul From fitsbits-request Fri Nov 27 20:18:34 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09429; Fri, 27 Nov 92 20:18:34 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 27 Nov 1992 21:15:38 GMT From: carl at SOL1.GPS.CALTECH.EDU (Carl J Lydick) Message-Id: <1f635qINN16i at gap.caltech.edu> Organization: HST Wide Field/Planetary Camera Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!zaphod.mps.ohio-state.edu!caen!uunet!elroy.jpl.nasa.gov!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL References: <1992Nov24.133506.11664 at hippo.ru.ac.za>,<1992Nov24.161305.29948 at stsci.edu> Reply-To: carl at SOL1.GPS.CALTECH.EDU Subject: Re: VAX file utility Sender: fitsbits-request at fits.CV.NRAO.EDU In article <1992Nov24.161305.29948 at stsci.edu>, hanisch at stsci.edu (Bob Hanisch, ST ScI) writes: =Here's a copy of the VMS command file that reblocks files to 2880 byte =records. = =$!---------------------------------------------------------------------- =$! FIXFITS filename =$! FIXFITS CONVERTs a file to the desired AIPSFITS disk format =$!---------------------------------------------------------------------- =$ create/fdl=sys$input: temp.dat =RECORD = CARRIAGE_CONTROL NONE = SIZE 2880 = FORMAT FIXED =$! now convert - old fails some =$! convert/append 'P1' TEMP.DAT =$! now convert - new method =$ copy 'P1' TEMP.DAT/overlay =$ rename temp.dat 'P1' =$! clean up =$ purge 'P1' =$! A cleaner way to do it under version 5 VMS is: $ IF P1 .EQS. "" THEN - $ READ/PROMPT="Input file: " SYS$COMMAND P1 $ IF P2 .EQS. "" THEN - $ READ/PROMPT="Output file: " SYS$COMMAND P2 $ EXCHANGE/NETWORK/FDL=SYS$INPUT: 'P1' 'P2' RECORD FORMAT FIXED SIZE 2880 CARRIAGE_CONTROL NONE $ EXIT -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL at SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. From fitsbits-request Fri Nov 27 20:18:35 1992 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09436; Fri, 27 Nov 92 20:18:35 EST Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 27 Nov 1992 21:10:27 GMT From: carl at SOL1.GPS.CALTECH.EDU (Carl J Lydick) Message-Id: <1f62s3INN16i at gap.caltech.edu> Organization: HST Wide Field/Planetary Camera Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!haven.umd.edu!uunet!elroy.jpl.nasa.gov!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL Reply-To: carl at SOL1.GPS.CALTECH.EDU Subject: cmsg cancel <1f62daINN16i at gap.caltech.edu> Sender: fitsbits-request at fits.CV.NRAO.EDU