From owner-fitsbits at kochab.cv.nrao.edu Tue Jul 7 22:18:35 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id WAA02315 for fitsbits-spinner; Tue, 7 Jul 1998 22:18:10 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id WAA02310 for ; Tue, 7 Jul 1998 22:18:07 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id WAA05983 for fitsbits at majordomo.cv.nrao.edu; Tue, 7 Jul 1998 22:18:02 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id QAA09659 for ; Tue, 30 Jun 1998 16:58:48 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id QAA28358 for ; Tue, 30 Jun 1998 16:58:46 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id QAA04385; Tue, 30 Jun 1998 16:58:45 -0400 To: fitsbits at fits.cv.nrao.edu Date: 30 Jun 98 20:53:59 GMT From: willner at cfa183.harvard.edu (Steve Willner) Message-ID: <35995067.0 at cfanews.harvard.edu> Organization: Smithsonian Astrophysical Observatory, Cambridge, MA, USA Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!gatech!128.10.2.10.MISMATCH!purdue!oitnews.harvard.edu!cfanews.harvard.edu!cfa183!willner References: <6lb0jk$ha$1 at dei.ucolick.org> Subject: Re: re OBJECT keyword Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk In article <6lb0jk$ha$1 at dei.ucolick.org>, sla at ucolick.borg (Steve Allen) writes: > We cannot envision a user interface which can overcome the human > factors involved in the setting of OBJECT values so as to conform > reliably to the IAU Recommendations for Nomenclature (IAU RN). One of us has misunderstood what is being proposed. I don't see any effort to force users to put anything specific in the OBJECT keyword. As I understood it, the proposal was merely to revise the definition to allow more characters to be used if needed. (Isn't OBJECT now limited to some fairly modest length, or have I misunderstood the problem?) Whether one chooses to use those extra characters to put in a proper designation or something else is up to the user. In other words, is there any good reason why OBJECT should not allow the maximum possible number of characters (69?) in a FITS record? -- Steve Willner Phone 617-495-7123 swillner at cfa.harvard.edu Cambridge, MA 02138 USA (Please email your reply if you want to be sure I see it; include a valid Reply-To address to receive an acknowledgement. Commercial email is NOT appreciated.) From owner-fitsbits at kochab.cv.nrao.edu Wed Jul 8 09:56:30 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id JAA25159 for fitsbits-spinner; Wed, 8 Jul 1998 09:56:15 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA25154 for ; Wed, 8 Jul 1998 09:56:11 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id JAA06709 for fitsbits at majordomo.cv.nrao.edu; Wed, 8 Jul 1998 09:56:07 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id GAA24872 for ; Wed, 8 Jul 1998 06:01:17 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id GAA06525 for ; Wed, 8 Jul 1998 06:01:12 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id GAA16545 for ; Wed, 8 Jul 1998 06:01:09 -0400 Received: from jedai.unige.ch(129.194.12.7) by palantir.cv.nrao.edu via smap (V1.3) id sma016534; Wed Jul 8 06:00:46 1998 Received: from obs.unige.ch (isdcul1.unige.ch) by jedai.unige.ch (PMDF V5.1-10 #30042) with ESMTP id <0EVR00EGVT1KIJ at jedai.unige.ch> for fitsbits at fits.cv.nrao.edu; Wed, 8 Jul 1998 11:58:33 +0200 (MET) Date: Wed, 08 Jul 1998 11:58:08 +0200 From: JENNINGS Don Subject: Comments on NOST 100-1.2 To: fitsbits at fits.cv.nrao.edu Cc: "isdc) Jennings Donald G." , pence at tetra.gsfc.nasa.gov Message-id: <35A342B0.DC2A0F4D at obs.unige.ch> Organization: INTEGRAL Science Data Centre MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Hello all, I have briefly reviewed the new draft FITS standard NOST 100-1.2 and have the following three comments. Since I do not subscribe to the FITSBITS exploder or normally read sci.astro.fits, please forgive me if my comments have already been discussed. I ask that the NOST Technical Panel consider my comments for inclusion into the new Standards document. I. Support for 64-bit integers I believe that this is the right time to add the 64-bit integer data type to FITS. Reasons: 1. Other data formats support 64 bit integers. The lack of 64-bit integers in FITS is a significant obstacle when importing non-FITS data into FITS. 2. 64-bit processors are now common. This implies that the use of the "long int" data type in programs will be more frequent. FITS must be able to store these integer values if it is to be a usable format. 3. 64-bit operating systems are now common. This implies that there are quantities generated that cannot be expressed in a 32-bit integer any longer; e.g., memory addresses, file sizes. 4. It is extreamly simple to do. Primary Arrays and IMAGE extensions will accept BITPIX = 64, and BINTABLES will accept TFORM = 'rKa'. 5. 64-bit integer values are at least as useful and worthy of support as the complex data types. I personally have never needed to store complex numbers in a FITS file, nor known anyone with the need, but have needed 64-bit integer support several times (.e.g., onboard spacecraft clock times). 6. The only reasons that I have heard agaist 64-bit integer support essentially condense into "we can live without it". But I claim the time has come where we cannot live without it. I suspect that the programmers that limited the expression of the year to two digits had a similiar "we can live without it" argument in the 60's and 70's. If the NOST Technical Panel decides not to include 64-bit integer support in the new version of the standard, then I ask that they at least provide their reasons for not doing so in the new Standards document. This way history can make them accountable for their decision. II. Unsigned Integer Convention The desire for support of unsigned integers has, I believe, been expressed before. Fortuantely, there is a way to store unsigned integers in the current FITS standard using the BZERO (for primary arrays and IMAGEs) and TZEROn (for BINTABLEs) keywords. See the CFITSIO Users manual for more details. I request that this convention be described in one of the appendicies of the new Standard. It could be extreamly useful for the newer generation of FITS readers and writers to support this convention. Note that: (1) it is already supported by software (CFITSIO), and (2) it is already in use within the community. III. Alternate Substring Array convention B.3 The array substring convention provided in appendix B3, where substrings may be expressed as 'rA:SSTRw/nnn', should also list the alternate convention of 'rAw' where: r = the total length of the ASCII character field w = the width of each substring in the character field Note that this convention: (1) is already suported by software (CFITSIO), (2) is already in use within the community, and (3) is much more likely in general to be used over the 'rA:SSTRw/nnn' convention due to its simplicity. Thank you, Don Jennings -- ------------------------------------------------------------------ If you understand what you're doing then you're not learning anything Don JENNINGS INTEGRAL Science Data Centre E-mail: Don.Jennings at obs.unige.ch 16, Chemin d'Ecogia Phone: +41 22 950-91-23 CH-1290 Versoix Fax: +41 22 950-91-33 ------------------------------------------------------------------ From owner-fitsbits at kochab.cv.nrao.edu Thu Jul 9 15:52:41 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id PAA24593 for fitsbits-spinner; Thu, 9 Jul 1998 15:51:44 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id PAA24588 for ; Thu, 9 Jul 1998 15:51:41 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id PAA09396 for fitsbits at majordomo.cv.nrao.edu; Thu, 9 Jul 1998 15:51:39 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id OAA24490 for ; Thu, 9 Jul 1998 14:58:50 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id OAA09326 for ; Thu, 9 Jul 1998 14:58:47 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id OAA24927 for ; Thu, 9 Jul 1998 14:58:46 -0400 Received: from mraos.ra.phy.cam.ac.uk(131.111.48.8) by palantir.cv.nrao.edu via smap (V1.3) id sma024924; Thu Jul 9 14:58:30 1998 Received: from mraosb.ra.phy.cam.ac.uk by mraos.ra.phy.cam.ac.uk with smtp (Smail3.1.29.0 #2) id m0yuLne-0004HQC; Thu, 9 Jul 98 19:52 BST Date: Thu, 9 Jul 1998 19:52:09 +0100 (BST) From: Sally Hales X-Sender: segh at mraosb To: fitsbits at fits.cv.nrao.edu Subject: sexagesimal TDISPn Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Display of celestial coordinates held internally in degrees in a BINTABLE Normally, in a FITS browser for example, source coordinates are displayed to the user in sexagesimal format, converted from the angle held internally in degrees, since RA,Dec in decimal degrees are not useful for source recognition etc. However, as things stand at present, there is no way for the originator of a BINTABLE to specify what sexagesimal precision he deems appropriate for the display of a celestial coordinate. so the user is left to make his own arbitrary choice, possibly truncating or spuriously extending the meaningful precision of the original data. The obvious place to make provision for specifying the appropriate sexagesimal precision would be the TDISPn field - and the fact that so many BINTABLES contain celestial coordinates which are not recognisable to the user when displayed in any of the existing TDISPn formats emphasises the need for such provision. There are so many respects in which the BINTABLE is superior to compressed ASCII (which now seems to be favoured by some users, perhaps because the lack of a standard for the problem above is a stumbling block for making a really versatile FITS browser which would be adopted throughout the astronomical community) - it seems a pity if it is not fully exploited for want of a solution to this small omission. Sally Hales MRAO Cambridge UK From owner-fitsbits at kochab.cv.nrao.edu Fri Jul 10 10:27:46 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA24655 for fitsbits-spinner; Fri, 10 Jul 1998 10:27:18 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA24649 for ; Fri, 10 Jul 1998 10:27:15 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA10402 for fitsbits at majordomo.cv.nrao.edu; Fri, 10 Jul 1998 10:27:11 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA22762 for ; Fri, 10 Jul 1998 08:09:57 -0400 (EDT) Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id IAA10002 for ; Fri, 10 Jul 1998 08:09:48 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by cv3.cv.nrao.edu (8.8.5/8.8.5/CV-2.7) with ESMTP id EAA02780 for ; Fri, 10 Jul 1998 04:20:44 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id EAA25030 for ; Fri, 10 Jul 1998 04:15:42 -0400 Received: from web3.hq.eso.org(134.171.7.4) by palantir.cv.nrao.edu via smap (V1.3) id sma025027; Fri Jul 10 04:15:25 1998 Received: from dfs1.hq.eso.org by web3.hq.eso.org with ESMTP (8.8.5/ eso-5.3) id KAA10075; Fri, 10 Jul 1998 10:08:42 +0200 (MET DST) Message-Id: <199807100808.KAA26254 at dfs1.hq.eso.org> Received: by dfs1.hq.eso.org (8.8.5/ eso-5.3) id KAA26254; Fri, 10 Jul 1998 10:08:41 +0200 (MET DST) To: fitsbits at fits.cv.nrao.edu Subject: Comments on NOST 100-1.2 of 1998-04-06 Date: Fri, 10 Jul 1998 10:08:41 +0200 From: Preben Grosbol Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Dear FITS exploder, I had unfortunately not time to read the NOST 100-1.2 document of 1998-04-06 carefully before due to other deadlines but here are my first basic set of comments. Due to travels, I would not be able to discuss issues before 1998-07-21. First a few basic comments: 1) In the e-mail announcing the review, it is stated that 'It will be submitted to IAU Commission 5 for formal acceptance ...'. This would not be possible with the current rules under which the IAU FITS Working Group only would consider proposals after they have been recommended by the three regional FITS groups. Thus, it would be natural for the NASA Technical Panel to submit their proposal to the North American FITS group for recommendation. Having said that, I fully support that general comments are solicited through WWW to ensure a thorough review. 2) One of the most basic rules of FITS is that not change should be made which would make current FITS files invalid. As the proposals prohibit usage which is not explicitly illegal now, it is not acceptable in its current form. One should distinguish two cases: a) changes which make old FITS files invalid, and b) modifications which make new FITS files incompatible with old readers. Whereas the former changes must not be allowed, the latter should be avoided since they just add work for re-programming with little advantage. I would like to complement the NASA FITS panel for an important work which will benefit the FITS community greatly. My concerns are related to the details and not the general scope of the document. Below I have listed my explicit comments which are not complete due to time pressure. Best regards, Preben Grosbol ESO. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The explicit comments are given with reference to page (p) and section (s) in the NOST 100-1.2 PostScript version of 1998-04-06: p11,s4.3: 'The primary header may, but need not be, followed ... array.' A header is always followed by a data array. The data array may, however, be of zero size. p13,s4.4.3: '(or random groups records if present)' Formally the random groups records are special records and can therefore NOT be followed by an extension. p15,s5.1.2.1: 'For indexed keywords with a single ...' This phrase tries to distinguish single index (e.g. NAXIS123) and multiple index (e.g. PC012015) keywords but as the latter is not clearly defined none of them are. It must be reworded to make sense. p15,s5.1.2.2: 'that field may be a null field' The concept of 'null field' is not trivial since multiple occurrence of the same keywords is not defined. The problem arises since the type of the keyword is defined by its value. If a 'null field' is given first and the same keywords is later assigned a value the resulting type is unclear. The whole issue surrounding repeated assignment of keyword values should be resolved. p16,s5.2.1: '... followed by a closing single quote ...' The FITS standard specifies that the closing quote first may occur in column 20. Removing this restriction may cause significant problem for old readers without any added functionality. p17,s5.2.3: 'An integer consists of a leading '+' or '-' ...' For positive integers there may be no leading '+'. p17,s5.2.4: 'If only the integer part is present, the decimal point may be omitted' The FITS standard specifies that the 'decimal point' must appear. p17,s5.2.5: 'enclosed in parentheses' The FITS standard does not specify the complex numbers must be enclosed in parentheses. p18,s5.3: 'degrees are the required units for celestial ...' Although I agree in principle the wording is unclear e.g. some observatories are known to use keywords RA and DEC for the celestial coordinates and given them as strings. Should such files be defined invalid by this proposal? p19,s5.4.1.1: 'SIMPLE ... is not permitted in extension headers' This is an additional requirement which may render existing FITS files invalid. p19,s5.4.1.1: 'SIMPLE ... this standard in some significant way' Should be reworded as a FITS either conforms to the standard or not - 'some significant way' is subjective. p19,s5.4.1.1: 'NAXISn ... and for no other values of n' Yes but again it is not specified in the FITS standard. It would be better just to ignore such keywords. p21,s5.4.1.1: 'XTENSION ... must not appear in the primary header' This restriction is not in the FITS standard and may render old FITS files invalid. p29,s7: 'outside this field ... random groups format' Subjective statement which should be omitted. p33,s8.1: 'TABLE ' The string must include 8 characters i.e. 'TABLE ' p33,s8.1.1: 'XTENSION ... 'TABLE '' The string must include 8 characters i.e. 'TABLE ' p36,s8.1.5: 'ANSI FORTRAN-77' The reference to FORTRAN-77 should be consistent - either one should ANSI all places or none. p37,s8.1.5: 'It may be stored, left justified, ... information.' The sentence is either trivial or should be rephrased to give some significant meaning. p37,s8.1.5: 'The value of ...' It seems dangerous to reword the FORTRAN-77 format definition. Although it may be nice for a trivial implementation there may be slight differences in the interpretation if it is not a verbatim reproduction of the real standard. p38,s8.2: 'IMAGE ' The extension name is 'IMAGE ' including three spaces. p38,s8.2.1: 'XTENSION ... IMAGE' The string for the image extension is 'IMAGE '. p39,s8.2.1: 'NAXISn ... for no other values of n' An additional requirement which may render old FITS files invalid. p46,s8.3.3.1: 'Array Descriptor ... of not more than one pair ...' As the field is 8 byte, it is exactly one pair and not zero. p46,s8.3.4: 'Display Format' Again it is dangerous to rephrase the FORTRAN-90 format definition. p46,s8.3.4: 'Integer data are encoded ...' It is not clear what is done with X and B type fields. p47,s8.3.4: 'For data of type integer, logical ...' A reference to X and B type data should be made. p51,sA: 'The following notation ...' It would be simpler if a more standard BNF was used. p69,sE: The points 8, 12, 15, 16, 18a, 19b, 29, 30d, 31b, 31c, 32, 33b, 37 and 38 give cause to significant concern as they may yield incompatibilities with the FITS format. p73,sE: 'applies applies' -> 'applies' p76,sE: 'BIMTABLE' -> 'BINTABLE' From owner-fitsbits at kochab.cv.nrao.edu Fri Jul 10 10:27:46 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA24673 for fitsbits-spinner; Fri, 10 Jul 1998 10:27:33 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA24668 for ; Fri, 10 Jul 1998 10:27:30 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA10407 for fitsbits at majordomo.cv.nrao.edu; Fri, 10 Jul 1998 10:27:28 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA15273 for ; Fri, 10 Jul 1998 09:11:33 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id JAA10266 for ; Fri, 10 Jul 1998 09:11:28 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id JAA15646 for ; Fri, 10 Jul 1998 09:11:26 -0400 Received: from mraos.ra.phy.cam.ac.uk(131.111.48.8) by palantir.cv.nrao.edu via smap (V1.3) id sma015643; Fri Jul 10 09:11:20 1998 Received: from mraosb.ra.phy.cam.ac.uk by mraos.ra.phy.cam.ac.uk with smtp (Smail3.1.29.0 #2) id m0yucrC-0004MIC; Fri, 10 Jul 98 14:04 BST Date: Fri, 10 Jul 1998 14:04:57 +0100 (BST) From: Sally Hales X-Sender: segh at mraosb To: fitsbits at fits.cv.nrao.edu Subject: re NOST: sexagesimal TDISPn Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk RE: NOST 100-1.2 Draft Standard (a repeat of my earlier message where I forgot to mention NOST specifically!) Display of celestial coordinates held internally in degrees in a BINTABLE Normally, in a FITS browser for example, source coordinates are displayed to the user in sexagesimal format, converted from the angle held internally in degrees, since RA,Dec in decimal degrees are not useful for source recognition etc. However, as things stand at present, there is no way for the originator of a BINTABLE to specify what sexagesimal precision he deems appropriate for the display of a celestial coordinate. so the user is left to make his own arbitrary choice, possibly truncating or spuriously extending the meaningful precision of the original data. The obvious place to make provision for specifying the appropriate sexagesimal precision would be the TDISPn field - and the fact that so many BINTABLES contain celestial coordinates which are not recognisable to the user when displayed in any of the existing TDISPn formats emphasises the need for such provision. There are so many respects in which the BINTABLE is superior to compressed ASCII (which now seems to be favoured by some users, perhaps because the lack of a standard for the problem above is a stumbling block for making a really versatile FITS browser which would be adopted throughout the astronomical community) - it seems a pity if it is not fully exploited for want of a solution to this small omission. Sally Hales MRAO Cambridge UK From owner-fitsbits at kochab.cv.nrao.edu Fri Jul 10 13:06:12 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA17203 for fitsbits-spinner; Fri, 10 Jul 1998 13:05:59 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA17197 for ; Fri, 10 Jul 1998 13:05:56 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA10783 for fitsbits at majordomo.cv.nrao.edu; Fri, 10 Jul 1998 13:05:53 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA10381 for ; Fri, 10 Jul 1998 12:22:55 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id MAA10728 for ; Fri, 10 Jul 1998 12:22:52 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id MAA19659 for ; Fri, 10 Jul 1998 12:22:50 -0400 Received: from poseidon.ifctr.mi.cnr.it(155.253.16.87) by palantir.cv.nrao.edu via smap (V1.3) id sma019650; Fri Jul 10 12:22:41 1998 Received: from localhost by poseidon.ifctr.mi.cnr.it; (5.65v3.2/1.1.8.2/05Sep96-0731PM) id AA12296; Fri, 10 Jul 1998 18:19:13 +0200 Organization: Istituto di Fisica Cosmica e Tecnologie Relative Date: Fri, 10 Jul 1998 18:19:13 +0200 (MET DST) From: Lucio Chiappetti To: fitsbits at fits.cv.nrao.edu Subject: Re: Comments on NOST 100-1.2 In-Reply-To: <35A342B0.DC2A0F4D at obs.unige.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk On Wed, 8 Jul 1998, JENNINGS Don wrote: > 2. 64-bit processors are now common. This implies that the > use of the "long int" data type in programs will be more How common ? AFAIK we have DEC Alphas (will they survive Compaq ?) and Sun UltraSparc (but the OS does NOT use 64-bit features, or at least so they told me when I inquired about migration, thinking of having similar problems as the Ultrix-->Digital Unix transition) Is INTEGER*8 in Fortran now standard ? or just supported by a few vendors ? (and by the way, why should one need it ?) > 3. 64-bit operating systems are now common. This implies > that there are quantities generated that cannot be expressed > in a 32-bit integer any longer; e.g., memory addresses, file > sizes. See above for comment on how common they are. The quantity you mention are not relevant talking of the CONTENT of DATA files. And I doubt they are of practical use in common conditions (I see that peoples in banks and similar tend to have large databases, but I ever doubt to need a > 2GB file ... or to have > 2GB physical memory ... and since I do not have that, why should I need 64-bit addresses ? In fact on Alpha I compile EVERYTHING with the -taso option : Truncated Address Space Option, so that addresses fit into 32 bits and I have portable code) > 6. The only reasons that I have heard agaist 64-bit > integer support essentially condense into "we can live > without it". I still believe we can. Unless you want to solve the problem of the inventor of the game of chess (if you put a grain of rice on the first square of the chessboard, two on the second, four on the third ...) why should one need to COUNT such large numbers with ABSOLUTE precision ? REAL*8 should be enough. 40- or 48-bit s/c clocks are the only things which comes to my mind, but s/c clocks are such a pain in the neck anyhow (also because they are unsigned :-( ). And in practice one never has so long elapsed periods or so fast timing that one cannot either round to "Unix time seconds" or MJD, or use full resolution in a limited interval, or convert to REAL*8 elapsed seconds. I'm a supporter of Ockham's razor : "file formats, data structures, data types non sunt multiplicanda praeter necessitatem" > II. Unsigned Integer Convention > Oh Yet Another Data Type ! But fortunately as you say ... > Fortuantely, there is a way to store > unsigned integers in the current FITS standard using the > BZERO (for primary arrays and IMAGEs) and TZEROn (for > BINTABLEs) keywords. Thus I support the specific inclusion in the documentation of the way how to use them. ---------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy) Member of the Ockhamist's Club, together with William of Ockham, Guglielmo da Roveredo, Wilhelm von Eichdorf ---------------------------------------------------------------------------- For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html ---------------------------------------------------------------------------- From owner-fitsbits at kochab.cv.nrao.edu Sat Jul 11 10:01:08 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA28047 for fitsbits-spinner; Sat, 11 Jul 1998 10:00:29 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA28036 for ; Sat, 11 Jul 1998 10:00:26 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA11926 for fitsbits at majordomo.cv.nrao.edu; Sat, 11 Jul 1998 10:00:22 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id GAA28345 for ; Sat, 11 Jul 1998 06:45:11 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id GAA11839 for ; Sat, 11 Jul 1998 06:45:07 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id GAA15006; Sat, 11 Jul 1998 06:45:06 -0400 To: fitsbits at fits.cv.nrao.edu Date: 11 Jul 1998 10:44:58 GMT From: davis at space.mit.edu (John E. Davis) Message-ID: Organization: Center for Space Research Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!eecs-usenet-02.mit.edu!davis References: <6nvtr3$amr$1 at newsfeed.cv.nrao.edu> Subject: Re: Comments on NOST 100-1.2 Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk On 8 Jul 1998 09:56:51 -0400, JENNINGS Don wrote: >The desire for support of unsigned integers has, I believe, >been expressed before. Fortuantely, there is a way to store >unsigned integers in the current FITS standard using the >BZERO (for primary arrays and IMAGEs) and TZEROn (for >BINTABLEs) keywords. See the CFITSIO Users manual for more >details. I think that this hack should be done away with in favor of real support for unsigned values. About the only reason I can see for not adding such support is that older readers may have problems reading the files with unsigned values. But that's life--- software must evolve. --John From owner-fitsbits at kochab.cv.nrao.edu Sat Jul 11 14:31:39 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id OAA14909 for fitsbits-spinner; Sat, 11 Jul 1998 14:31:27 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id OAA14828 for ; Sat, 11 Jul 1998 14:31:22 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id OAA12133 for fitsbits at majordomo.cv.nrao.edu; Sat, 11 Jul 1998 14:31:19 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA19441 for ; Sat, 11 Jul 1998 13:37:30 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id NAA12089 for ; Sat, 11 Jul 1998 13:37:27 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id NAA06767; Sat, 11 Jul 1998 13:37:25 -0400 To: fitsbits at fits.cv.nrao.edu Date: Sat, 11 Jul 1998 13:26:10 -0400 From: akk Message-ID: Organization: ARInternet, Corp. Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!news-peer-east.sprintlink.net!news-peer.sprintlink.net!news-backup-east.sprintlink.net!news.sprintlink.net!198.69.192.1!ari.ari.net!mtolympus.ari.net!anilk Subject: floating illegal operand->error Newsgroups: comp.lang.idl-pvwave,sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Hi all, I've written a C program to resize an Image (i.e. resize a 2-D array). I then use IDL to view the resized image. For starters I just have the program resize the image to the exact same dimensions as the original image (i.e. create an identical image). I am able to view this new image and it appears identical to the original image, however in addition, idl outputs the message "Program caused an arithmetic error: Floating illegal operand" Does anyone know what might be causing this error or what it means? Thanks... NOTE: I'm using the command-> fits_read, 'FILENAME', data, header to read in the image and then use tvscl to view the image. From owner-fitsbits at kochab.cv.nrao.edu Sun Jul 12 10:43:30 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA03966 for fitsbits-spinner; Sun, 12 Jul 1998 10:43:01 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA03961 for ; Sun, 12 Jul 1998 10:42:56 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA13461 for fitsbits at majordomo.cv.nrao.edu; Sun, 12 Jul 1998 10:42:53 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA21721 for ; Sun, 12 Jul 1998 08:48:57 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id IAA13372 for ; Sun, 12 Jul 1998 08:48:48 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id IAA09598; Sun, 12 Jul 1998 08:48:47 -0400 To: fitsbits at fits.cv.nrao.edu Date: 12 Jul 1998 10:41:41 GMT From: davis at space.mit.edu (John E. Davis) Message-ID: Organization: Center for Space Research Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!hub.org!data.pa.vix.com!news.gnac.net!uunet!in4.uu.net!news.research.att.com!eecs-usenet-02.mit.edu!davis References: Subject: Re: Comments on NOST 100-1.2 Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk On 10 Jul 1998 13:06:38 -0400, Lucio Chiappetti wrote: > How common ? AFAIK we have DEC Alphas (will they survive Compaq ?) and > Sun UltraSparc (but the OS does NOT use 64-bit features, or at least so I heard that the `long' integer will be 64 bits in the next release of Solaris. Is this true? > And I doubt they are of practical use in common conditions (I see that > peoples in banks and similar tend to have large databases, but I ever > doubt to need a > 2GB file ... or to have > 2GB physical memory ... and > since I do not have that, why should I need 64-bit addresses ? In fact Less than 20 years ago, Bill Gates thought that no one would ever need 640K of memory. Today, it is not that uncommon to see 100 Megabyte data files. How many people made statements twenty years ago about never needing 100 Megabyte files? If we have learned anything from the computer revolution, then it is that we cannot predict the future. I have no idea whether or not I will be using a keyboard or a microphone in 10 years to communicate with my computer. The FITS file format is nearly 20 years old. About a year ago a new FITS time specification was necessary to handle the year 2000 problem. The fact is that several modern operating systems support 64 bit integers and there are more on the horizon. Let's not make the same mistake and ignore 64 bit data types as well as unsigned types. --John From owner-fitsbits at kochab.cv.nrao.edu Sun Jul 12 10:43:46 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA03990 for fitsbits-spinner; Sun, 12 Jul 1998 10:43:44 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA03984 for ; Sun, 12 Jul 1998 10:43:40 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA13467 for fitsbits at majordomo.cv.nrao.edu; Sun, 12 Jul 1998 10:43:37 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA23382 for ; Sun, 12 Jul 1998 10:01:32 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id KAA13411 for ; Sun, 12 Jul 1998 10:01:29 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id KAA12098 for ; Sun, 12 Jul 1998 10:01:28 -0400 Received: from ujf.ujf-grenoble.fr(193.54.232.33) by palantir.cv.nrao.edu via smap (V1.3) id sma012095; Sun Jul 12 10:01:10 1998 Received: from gagax5.obs.ujf-grenoble.fr (gagax5.obs.ujf-grenoble.fr [195.220.79.15]) by ujf.ujf-grenoble.fr (8.8.5/8.8.5) with ESMTP id PAA03900; Sun, 12 Jul 1998 15:54:48 +0200 (MET DST) Received: (from forveill at localhost) by gagax5.obs.ujf-grenoble.fr (8.7.6/8.6.9) id PAA45326; Sun, 12 Jul 1998 15:54:48 +0200 From: Thierry Forveille MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13736.49192.5219.523617 at gagax5.obs.ujf-grenoble.fr> Date: Sun, 12 Jul 1998 15:54:48 +0200 (DFT) To: davis at space.mit.edu (John E. Davis) Cc: fitsbits at fits.cv.nrao.edu Subject: Re: Comments on NOST 100-1.2 Newsgroups: sci.astro.fits In-Reply-To: References: <6nvtr3$amr$1 at newsfeed.cv.nrao.edu> X-Mailer: VM 6.49 under Emacs 19.34.9 Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk John E. Davis writes: > On 8 Jul 1998 09:56:51 -0400, JENNINGS Don > wrote: > >The desire for support of unsigned integers has, I believe, > >been expressed before. Fortuantely, there is a way to store > >unsigned integers in the current FITS standard using the > >BZERO (for primary arrays and IMAGEs) and TZEROn (for > >BINTABLEs) keywords. See the CFITSIO Users manual for more > >details. > > I think that this hack should be done away with in favor of real > support for unsigned values. About the only reason I can see for not > adding such support is that older readers may have problems reading > the files with unsigned values. But that's life--- software must > evolve. > I must say I have never seen any convincing argument for supporting unsigned values. The present "hack" as you call it offers all the functionalities for no cost, while adding unsigned as an additional supported format would cost significant extra code to everybody for no additional value. To me Occam's razor says it should stay out... 64 bit integers are a whole different story, as they bring real improvements. The question for them is not whether, but when. We will I think have to include them, but the present revision may or may not be timely. From owner-fitsbits at kochab.cv.nrao.edu Sun Jul 12 18:49:22 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id SAA09376 for fitsbits-spinner; Sun, 12 Jul 1998 18:49:10 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA09371 for ; Sun, 12 Jul 1998 18:49:07 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id SAA13718 for fitsbits at majordomo.cv.nrao.edu; Sun, 12 Jul 1998 18:49:04 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id PAA03433 for ; Sun, 12 Jul 1998 15:39:00 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id PAA13618 for ; Sun, 12 Jul 1998 15:38:57 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id PAA15137 for ; Sun, 12 Jul 1998 15:38:56 -0400 Received: from space.mit.edu(18.75.0.10) by palantir.cv.nrao.edu via smap (V1.3) id sma015134; Sun Jul 12 15:38:35 1998 Received: from aluche.mit.edu by space.mit.edu AA29034; Sun, 12 Jul 98 15:36:04 EDT Received: (from davis at localhost) by aluche.mit.edu (8.8.7/8.8.7) id PAA04862; Sun, 12 Jul 1998 15:36:03 -0400 Date: Sun, 12 Jul 1998 15:36:03 -0400 From: "John E. Davis" Message-Id: <199807121936.PAA04862 at aluche.mit.edu> To: Thierry.Forveille at obs.ujf-grenoble.fr Cc: fitsbits at fits.cv.nrao.edu Subject: Re: Comments on NOST 100-1.2 Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk On Sun, 12 Jul 1998 15:54:48 +0200 (DFT), Thierry Forveille said: >I must say I have never seen any convincing argument for supporting >unsigned values. The present "hack" as you call it offers all the >functionalities for no cost, while adding unsigned as an additional >supported format would cost significant extra code to everybody for no >additional value. To me Occam's razor says it should stay out... Please correct me if I am wrong, but my main objection to this convention is inherently non-portable because the BZERO value that must be used is outside the range of the integer data type. For example, to represent an unsigned 32bit integer, BZERO must be set to 2147483648 in the fits file. Now, BZERO is an integer and this value is outside the range of an integer. Why is this a problem? It is a problem because parsing it as a 32 bit integer may result in its truncation. Specifically, CFITSIO uses the strtol function call to parse these values and this function will truncate 2147483648 to 2147483647. To see this, consider: #include #include int main () { long i; char *s; s = "2147483648"; i = strtol (s, NULL, 10); fprintf (stdout, "%s = %ld\n", s, i); s = "2147483647"; i = strtol (s, NULL, 10); fprintf (stdout, "%s = %ld\n", s, i); return 0; } Compiled with gcc on my Linux system, this produces: 2147483648 = 2147483647 2147483647 = 2147483647 The man page for strtol indicates: RETURN VALUE The strtol() function returns the result of the conver- sion, unless the value would underflow or overflow. If an underflow occurs, strtol() returns LONG_MIN. If an over- flow occurs, strtol() returns LONG_MAX. In both cases, errno is set to ERANGE. So, without real support for unsiged types, I maintain that this convention is flawed. Thanks, --John From owner-fitsbits at kochab.cv.nrao.edu Sun Jul 12 18:51:29 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id SAA09445 for fitsbits-spinner; Sun, 12 Jul 1998 18:51:27 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA09440 for ; Sun, 12 Jul 1998 18:51:24 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id SAA13727 for fitsbits at majordomo.cv.nrao.edu; Sun, 12 Jul 1998 18:51:21 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA08930 for ; Sun, 12 Jul 1998 18:17:24 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id SAA13692 for ; Sun, 12 Jul 1998 18:17:22 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id SAA16814; Sun, 12 Jul 1998 18:17:21 -0400 To: fitsbits at fits.cv.nrao.edu Date: 12 Jul 1998 21:10:58 GMT From: davis at space.mit.edu (John E. Davis) Message-ID: Organization: Center for Space Research Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!news.mathworks.com!uunet!in1.uu.net!news.research.att.com!eecs-usenet-02.mit.edu!davis References: <6nvtr3$amr$1 at newsfeed.cv.nrao.edu> <13736.49192.5219.523617 at gagax5.obs.ujf-grenoble.fr> Reply-To: davis at space.mit.edu Subject: Re: Comments on NOST 100-1.2 Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk On 12 Jul 1998 10:43:53 -0400, Thierry Forveille wrote: >I must say I have never seen any convincing argument for supporting >unsigned values. The present "hack" as you call it offers all the >functionalities for no cost, while adding unsigned as an additional >supported format would cost significant extra code to everybody for no >additional value. To me Occam's razor says it should stay out... Please correct me if I am wrong, but my main objection to this convention is that it is inherently non-portable because the BZERO value that must be used is outside the range of the integer data type. For example, to represent an unsigned 32bit integer, BZERO must be set to 2147483648 in the fits file, which is outside the range of a 32 bit signed integer. Why is this a problem? It is a problem because parsing it as a 32 bit integer may result in its truncation. Specifically, CFITSIO uses the strtol function call to parse these values and this function will truncate 2147483648 to 2147483647. To see this, consider: #include #include int main () { long i; char *s; s = "2147483648"; i = strtol (s, NULL, 10); fprintf (stdout, "%s = %ld\n", s, i); s = "2147483647"; i = strtol (s, NULL, 10); fprintf (stdout, "%s = %ld\n", s, i); return 0; } Compiled with gcc on my Linux system, this produces: 2147483648 = 2147483647 2147483647 = 2147483647 The man page for strtol indicates: RETURN VALUE The strtol() function returns the result of the converĄ sion, unless the value would underflow or overflow. If an underflow occurs, strtol() returns LONG_MIN. If an overĄ flow occurs, strtol() returns LONG_MAX. In both cases, errno is set to ERANGE. It is possible avoid strtol with a different function, but one would still need to perform integer multiplications which would result in overflow. About the only portable alternative would be to use double precision arithmetic but even that may not be sufficient if you want to use this convention to represent 64 bit unsigned values. So, without real support for unsigned types, I maintain that this convention is flawed. Thanks, --John From owner-fitsbits at kochab.cv.nrao.edu Mon Jul 13 08:30:00 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA08400 for fitsbits-spinner; Mon, 13 Jul 1998 08:29:09 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA08395 for ; Mon, 13 Jul 1998 08:29:06 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id IAA14266 for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 08:29:03 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id EAA05599 for ; Mon, 13 Jul 1998 04:01:23 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id EAA14063 for ; Mon, 13 Jul 1998 04:01:20 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id EAA10626; Mon, 13 Jul 1998 04:01:14 -0400 To: fitsbits at fits.cv.nrao.edu Date: Mon, 13 Jul 1998 09:00:40 +0100 From: Peter Bunclark Message-ID: <35A9BEA8.61BD at ast.cam.ac.uk> Organization: Royal Greenwich Observatory Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!btnet-peer!btnet!nntp.news.xara.net!xara.net!server5.netnews.ja.net!server3.netnews.ja.net!server1.netnews.ja.net!pegasus.csx.cam.ac.uk!not-for-mail Subject: RA, DEC and UNSIGNED Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk 1. Please let's continue to allow RA and DEC in sexadecimal. One of the most common quotes is ``FITS is good because when you have problems you can just more the header''; the easy readability of the header is seen as a great strength. The RA and DEC are almost the most important keywords for end users, and should be in the format the consumer wants. 2. The lack of unsigned data type was, in my opinion, nearly the biggest cockup in original FITS, right behind the EPOCH and DATE problems. The overheads of the BZERO hack are: a) Compute overhead; either an extra bit of arithmetic, or, more likely, the reader gives up and casts it all to float, causing lots of extra arithmetic and I/O. b) It *is* a hack; I bet that some of the systems that FITS was originally designed for, eg 60-bit machines, need different code from that on base-2 wordlength machines (? or not?). c) It brings FITS into disrepute every time you have the embarrassment of introducing the system to a new astronomer or software engineer. Peter. From owner-fitsbits at kochab.cv.nrao.edu Mon Jul 13 08:30:17 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA08407 for fitsbits-spinner; Mon, 13 Jul 1998 08:29:40 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA08402 for ; Mon, 13 Jul 1998 08:29:37 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id IAA14271 for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 08:29:34 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id FAA08275 for ; Mon, 13 Jul 1998 05:27:44 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id FAA14161 for ; Mon, 13 Jul 1998 05:27:39 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id FAA16893; Mon, 13 Jul 1998 05:27:37 -0400 To: fitsbits at fits.cv.nrao.edu Date: Mon, 13 Jul 1998 09:26:24 GMT From: Skywise Message-ID: <35A9D453.BFAA4FEB at spamless.internetmci.com> Organization: - Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!newsfeed.internetmci.com!208.159.126.161!news.mci2000.com!not-for-mail Subject: what is FITS? Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Sorry if this seems like a silly question, but only being an amateur armchair astronomer of sorts, I just recently added a bunch of astronomy related newsgroups. I've been reading this one for a couple of weeks now and haven't quite figured out what it's all about. Could some kind soul enlighten me to what all this FITS business is about? Or perhaps someplace where I can find out? That way I can understand what everyone is arguing about here. I'm always interested in learning more about astronomy and usually have no problem grasping something just by content but so far this group has eluded me. Thanx so kindly. Skywise From owner-fitsbits at kochab.cv.nrao.edu Mon Jul 13 08:36:38 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA08456 for fitsbits-spinner; Mon, 13 Jul 1998 08:36:36 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA08451 for ; Mon, 13 Jul 1998 08:36:33 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id IAA14303 for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 08:36:30 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA08440 for ; Mon, 13 Jul 1998 08:33:20 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id IAA14284 for ; Mon, 13 Jul 1998 08:33:12 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id IAA14609 for ; Mon, 13 Jul 1998 08:33:10 -0400 Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3) id sma014597; Mon Jul 13 08:33:06 1998 Received: from xebec by head-cfa (SMI-8.6/SMI-SVR4) id IAA01583; Mon, 13 Jul 1998 08:26:16 -0400 Received: by xebec (SMI-8.6/SMI-SVR4) id IAA25477; Mon, 13 Jul 1998 08:26:16 -0400 From: arots at xebec.harvard.edu (Arnold Rots) Message-Id: <199807131226.IAA25477 at xebec> Subject: Re: Comments on NOST 100-1.2 In-Reply-To: from "John E. Davis" at "Jul 11, 98 10:44:58 am" To: davis at space.mit.edu (John E. Davis) Date: Mon, 13 Jul 1998 08:26:16 -0400 (EDT) Cc: fitsbits at fits.cv.nrao.edu X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Hear, hear! It's not so much a question of whether FITS will ever include unsigned integer data types, but when. Having been at the center of the previous major effort to get them accepted, some five years ago, I would estimate that it's going to be another ten years ;-) - Arnold John E. Davis wrote: > On 8 Jul 1998 09:56:51 -0400, JENNINGS Don > wrote: > >The desire for support of unsigned integers has, I believe, > >been expressed before. Fortuantely, there is a way to store > >unsigned integers in the current FITS standard using the > >BZERO (for primary arrays and IMAGEs) and TZEROn (for > >BINTABLEs) keywords. See the CFITSIO Users manual for more > >details. > > I think that this hack should be done away with in favor of real > support for unsigned values. About the only reason I can see for not > adding such support is that older readers may have problems reading > the files with unsigned values. But that's life--- software must > evolve. > > --John > -------------------------------------------------------------------------- Arnold H. Rots AXAF Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 81 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head-cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From owner-fitsbits at kochab.cv.nrao.edu Mon Jul 13 12:47:21 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id MAA09009 for fitsbits-spinner; Mon, 13 Jul 1998 12:46:32 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA09004 for ; Mon, 13 Jul 1998 12:46:29 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id MAA00515 for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 12:46:26 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA08978 for ; Mon, 13 Jul 1998 12:40:28 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id MAA00502 for ; Mon, 13 Jul 1998 12:40:25 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id MAA22735 for ; Mon, 13 Jul 1998 12:40:24 -0400 Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3) id sma022732; Mon Jul 13 12:40:22 1998 Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109]) by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP id MAA25806 for ; Mon, 13 Jul 1998 12:39:45 -0400 (EDT) Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4) id MAA24670; Mon, 13 Jul 1998 12:39:43 -0400 Message-ID: <35AA384F.1BE21420 at tetra.gsfc.nasa.gov> Date: Mon, 13 Jul 1998 12:39:43 -0400 From: William Pence Organization: HEASARC X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: fitsbits at fits.cv.nrao.edu Subject: Unsigned integer support in NOST 100-1.2 References: <199807121936.PAA04862 at aluche.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk In the previous debate a few years about about adding new unsigned integer datatypes to FITS I had argued in favor of the proposal. However, I have since come to appreciate that the current FITS format already fully supports unsigned integers (16 and 32 bit at least), hence I would now oppose any change to the Standard in this regard. FITS is able to store unsigned 16 and 32 bit integers in an efficient format that is easy to read and write. This is all that is required. The transformation between the internal FITS representation and the machine representation on a particular computer of the same unsigned integer value is trivial: flip the value of the most significant bit (bit 32 or 16) and also swap the order of the bytes on little endian machines like IBM PCs. The more important issue for programmers, I believe, is that standard FITS software like the CFITSIO library should provide a transparent interface for reading and writing unsigned integers in FITS files. CFITSIO provides a whole family of routines for reading or writing data of any supported datatype, including unsigned short, unsigned int, and unsigned long (in the C language interface) to FITS images or tables. When using CFITSIO, the programmer does not need to be concerned in any way with how the data values are internally represented in the FITS file. All the business with setting or reading the BZERO keyword value, etc. is all handled internally by the interface routines. Finally, John Davis raised the objection that the BZERO keyword = 2147483648 that is used to represent unsigned 32-bit integers in FITS is not a valid 32-bit signed integer with some particular compilers (it is a valid signed integer value with many other compilers, however). This is not a problem with the FITS format itself, but instead just illustrates that the implementation of FITS readers and writers on any given platform must be able to deal with the limitations of that platform. The similar sorts of issues have to be addressed when reading/writing FITS files in Fortran, which doesn't even support an unsigned integer datatype at all. -Bill Pence From owner-fitsbits at kochab.cv.nrao.edu Mon Jul 13 21:34:11 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id VAA10145 for fitsbits-spinner; Mon, 13 Jul 1998 21:33:47 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA10140 for ; Mon, 13 Jul 1998 21:33:44 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA00961 for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 21:33:41 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id QAA09786 for ; Mon, 13 Jul 1998 16:26:42 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id QAA00773 for ; Mon, 13 Jul 1998 16:26:39 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id QAA00932 for ; Mon, 13 Jul 1998 16:26:36 -0400 Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3) id sma000923; Mon Jul 13 16:26:14 1998 Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109]) by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP id QAA29849 for ; Mon, 13 Jul 1998 16:25:42 -0400 (EDT) Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4) id QAA24946; Mon, 13 Jul 1998 16:25:33 -0400 Message-ID: <35AA6D3D.44297AB4 at tetra.gsfc.nasa.gov> Date: Mon, 13 Jul 1998 16:25:33 -0400 From: William Pence Organization: HEASARC X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: fitsbits at fits.cv.nrao.edu Subject: 64-bit integers in FITS References: <35A342B0.DC2A0F4D at obs.unige.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk I basically have an open mind about the suggestion to support 64-bit integers in FITS files, but just wanted to make a couple comments: - it would be a fairly trivial job to modify the FITS standard to specify the format for 64-bit integer images and binary table columns. Images would have BITPIX = 64, tables would have TFORM = 'K' (or whatever), and the binary data itself would be written as twos-complement signed binary integers containing 8 bytes. Not much more needs to be said. There is no restriction on the value of integer keywords, so they already support 64-bit integers (but most readers/writers only support 32-bit integers). - supporting the reading or writing of FITS files containing 64-bit integer data on 32-bit platforms would likely require a lot of work. If the hardware/compiler doesn't support reading and writing 64-bit integers then interface software like CFITSIO would have to have software emulation routines to do datatype conversion between 32-bit int <-> 64-bit int, 64-bit float <-> 64-bit int, etc. and also trap any overflow conditions. Presumably there already exist routines to do all this, written in C, that could be used in CFITSIO. None the less, adding support for 64-bit integers in CFITSIO, not to mention all the other existing FITS readers and writers, would be a big job, and would make the interface software even more complex than it already is. - There would still remain the problem that it is not possible in principle to fully represent 64-bit integers on a 32-bit machines without possible overflow (when converting to 32-bit integers) or loss of precision (when converting to double precision floating point). Thus one could quite easily write FITS files on 64-bit machines that could not be read on 32-bit machines. This would defeat one of the main purposes of FITS to provide a machine-independent data interchange format. ____________________________________________________________________ Dr. William Pence pence at tetra.gsfc.nasa.gov NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice) Greenbelt MD 20771 +1-301-286-1684 (fax) From owner-fitsbits at kochab.cv.nrao.edu Mon Jul 13 21:35:33 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id VAA10167 for fitsbits-spinner; Mon, 13 Jul 1998 21:35:31 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA10162 for ; Mon, 13 Jul 1998 21:35:28 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA00971 for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 21:35:25 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA09853 for ; Mon, 13 Jul 1998 17:03:38 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id RAA00813 for ; Mon, 13 Jul 1998 17:03:35 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id RAA22820; Mon, 13 Jul 1998 17:03:34 -0400 To: fitsbits at fits.cv.nrao.edu Date: 13 Jul 1998 20:49:42 GMT From: giglio at hades.gsfc.nasa.gov (Louis Giglio) Message-ID: <6odrt6$si7 at post.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!newsfeed.internetmci.com!128.158.254.10!news.msfc.nasa.gov!centauri.hq.nasa.gov!newsfeed.gsfc.nasa.gov!hades.gsfc.nasa.gov!giglio Subject: EXTNAME Keyword in Primary HDU Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk The subject pretty much sums up my question. Is it acceptable to have the EXTNAME keyword -- which is explicitly defined for extension HDU's -- in the primary HDU of a FITS file. Everything I've read seems to allow this without actually explicitly stating that it's legal. Thanks, Louis From owner-fitsbits at kochab.cv.nrao.edu Mon Jul 13 21:39:15 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id VAA10619 for fitsbits-spinner; Mon, 13 Jul 1998 21:39:14 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA10614 for ; Mon, 13 Jul 1998 21:39:10 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA00980 for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 21:39:08 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA09953 for ; Mon, 13 Jul 1998 18:11:08 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id SAA00854 for ; Mon, 13 Jul 1998 18:11:05 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id SAA30153; Mon, 13 Jul 1998 18:11:04 -0400 To: fitsbits at fits.cv.nrao.edu Date: 13 Jul 1998 22:10:43 GMT From: davis at space.mit.edu (John E. Davis) Message-ID: Organization: Center for Space Research Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!eecs-usenet-02.mit.edu!davis References: <199807121936.PAA04862 at aluche.mit.edu> <35AA384F.1BE21420 at tetra.gsfc.nasa.gov> Reply-To: davis at space.mit.edu Subject: Re: Unsigned integer support in NOST 100-1.2 Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk On 13 Jul 1998 12:47:52 -0400, William Pence wrote: >However, I have since come to appreciate that the current FITS format >already fully supports unsigned integers (16 and 32 bit at least), hence >I would now oppose any change to the Standard in this regard. FITS is I understand your point that a fits can store unsigned values using the current convention. As long as that convention is documented, I do not care about what bits need to be flipped. However, I think that there is a deeper issue that keeps nagging me. This leads me to believe that the fits file specification does not define a well-defined file format that is independent of the reader. To see what I mean, consider the BZERO and BSCALE keywords. The NOST document states that these keywords represent floating point values, and if the keywords are absent, then they default to 0.0 and 1.0, respectively. Then the value of a pixel pixel is given by: Physical_Value = BZERO + BSCALE * Array_Value Does this mean that all images are floating point images? If so, are they 64 bit floating point values or 32 bit floating point values? The file specification does not spell this out which means that the interpretation is left to the fits reader. In my opinion, the document should state that the result of Physical_Value = BZERO + BSCALE * Array_Value depends upon the range of the resulting values, and upon the data types specified by the syntax used to specify the BZERO and BSCALE keywords. In this respect, the default values should be the *integers*, 0 and 1, and not floating point values. At this point, I have concluded that a fits file simply stores any numeric value as a 64 bit floating point value in various floating point and signed integer representations, using the BZERO/BSCALE values (or their equivalents) to perform the appropriate conversions. Please try to understand that I am not implying that everything gets written out to the fits files as 8 byte floating point double precision numbers. I feel that the only consistent way to view the current specification is that all data types are implicitly converted to the largest available data type capable of representing them, namely 64 bit floats, and then written out in a user specified representation, e.g., as signed 16 bit integers, with the appropriate values of BZERO and BSCALE. I can live with this interpretation as long as I can store all the numeric data types that I work with with no loss of precision. However, this will present a problem when the file format gets enlarged to handle 64 bit integer quantities. Then, Physical_Value = BZERO + BSCALE * Array_Value will result in a loss of precision for 64 bit integers. Some may find this whole debate pointless, but if you want to define a fits file whose contents have a well defined meaning that is independent of the software that reads it, then these seemingly trivial points matter. --John From owner-fitsbits at kochab.cv.nrao.edu Tue Jul 14 09:50:49 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id JAA25449 for fitsbits-spinner; Tue, 14 Jul 1998 09:50:26 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA25444 for ; Tue, 14 Jul 1998 09:50:23 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id JAA01673 for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 09:50:20 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id DAA21549 for ; Tue, 14 Jul 1998 03:29:38 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id DAA01240 for ; Tue, 14 Jul 1998 03:29:26 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id DAA30214; Tue, 14 Jul 1998 03:29:25 -0400 To: fitsbits at fits.cv.nrao.edu Date: Tue, 14 Jul 1998 08:27:20 +0100 From: Peter Bunclark Message-ID: <35AB0858.24BE at ast.cam.ac.uk> Organization: Royal Greenwich Observatory Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!btnet-peer!btnet!dispose.news.demon.net!demon!delos!server1.netnews.ja.net!pegasus.csx.cam.ac.uk!not-for-mail References: <35A342B0.DC2A0F4D at obs.unige.ch> <35AA6D3D.44297AB4 at tetra.gsfc.nasa.gov> Subject: Re: 64-bit integers in FITS Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Isn't the fundamental point that FITS is a data-interchange medium? Hence, if someone happens to have 64-bit data, they will have a need to move it between machines and would probably prefer to have used FITS. It's certainly not in FITS's remit to declare to instrumentatation groups that they are not allowed to invent 64-bit detectors. Such a hypothetical group would have to invent a cooked-up data format of their own; if it was me I'd put BITPIX=64 in the knowledge that everyone would know exactly what I meant. Why not enshrine it in the standard, perhaps with the advice to use it only when the data genuinely requires such a precision? Peter. William Pence wrote: > > I basically have an open mind about the suggestion to support 64-bit > integers in FITS files, but just wanted to make a couple comments: > > - it would be a fairly trivial job to modify the FITS standard to > specify the format for 64-bit integer images and binary table columns. > Images would have BITPIX = 64, tables would have TFORM = 'K' (or > whatever), and the binary data itself would be written as > twos-complement signed binary integers containing 8 bytes. Not much > more needs to be said. There is no restriction on the value of integer > keywords, so they already support 64-bit integers (but most > readers/writers only support 32-bit integers). > > - supporting the reading or writing of FITS files containing 64-bit > integer data on 32-bit platforms would likely require a lot of work. If > the hardware/compiler doesn't support reading and writing 64-bit > integers then interface software like CFITSIO would have to have > software emulation routines to do datatype conversion between 32-bit int > <-> 64-bit int, 64-bit float <-> 64-bit int, etc. and also trap any > overflow conditions. Presumably there already exist routines to do all > this, written in C, that could be used in CFITSIO. None the less, > adding support for 64-bit integers in CFITSIO, not to mention all the > other existing FITS readers and writers, would be a big job, and would > make the interface software even more complex than it already is. > > - There would still remain the problem that it is not possible in > principle to fully represent 64-bit integers on a 32-bit machines > without possible overflow (when converting to 32-bit integers) or loss > of precision (when converting to double precision floating point). Thus > one could quite easily write FITS files on 64-bit machines that could > not be read on 32-bit machines. This would defeat one of the main > purposes of FITS to provide a machine-independent data interchange > format. > > ____________________________________________________________________ > Dr. William Pence pence at tetra.gsfc.nasa.gov > NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice) > Greenbelt MD 20771 +1-301-286-1684 (fax) From owner-fitsbits at kochab.cv.nrao.edu Tue Jul 14 09:50:49 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id JAA25442 for fitsbits-spinner; Tue, 14 Jul 1998 09:49:53 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA25437 for ; Tue, 14 Jul 1998 09:49:50 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id JAA01668 for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 09:49:46 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id AAA00453 for ; Tue, 14 Jul 1998 00:37:36 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id AAA01098 for ; Tue, 14 Jul 1998 00:37:34 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id AAA17275 for ; Tue, 14 Jul 1998 00:37:32 -0400 Received: from phobos.caltech.edu(131.215.240.1) by palantir.cv.nrao.edu via smap (V1.3) id sma017272; Tue Jul 14 00:37:11 1998 Received: from bottom (bottom.caltech.edu) by phobos (4.1/DEI:4.43) id AA20057; Mon, 13 Jul 98 21:34:31 PDT Received: from localhost by bottom with SMTP (SMI-8.6/DEI:4.43) id VAA18830; Mon, 13 Jul 1998 21:34:30 -0700 Date: Mon, 13 Jul 1998 21:34:30 -0700 (PDT) From: Tim Pearson X-Sender: tjp at bottom Reply-To: Tim Pearson To: fitsbits at fits.cv.nrao.edu Subject: Re: 64-bit integers in FITS In-Reply-To: <35AA6D3D.44297AB4 at tetra.gsfc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Like William Pence, "I basically have an open mind about the suggestion to support 64-bit integers in FITS files." But I would like to remind people that the reason for doing so should not be because 64-bit integers are convenient to use on some computer systems, but because there is a need to interchange data that cannot be represented in any of the current data types (BITPIX=8, 16, 32, -32, or -64). I can't think of any astronomical data that require such precision, but perhaps that just reflects the poverty of my imagination. If we do add BITPIX=64, perhaps we should also consider intermediate types like BITPIX=40, 48, etc. which could also be accommodated in the standard FITS structure and which would save space in the file when full 64-bit precision is not required. I am surprised that many people appear to think that FITS is designed for interchanging computer bit patterns. It is not: it is for interchanging images (and now tabular data), using as few different conventions as possible. This misunderstanding perhaps explains why someone might think that "BSCALE = 2.0" means something different from "BSCALE = 2". BSCALE specifies a mathematical operation to be performed on the data array to construct the image pixel values; how it is done, and with what precision, is up to the reader. There is certainly no implication that 32-bit (say) floating-point arithmetic should be used if that might lose precision. My interpretation of the NOST draft standard (Sec. 5.2.4) is that both "BSCALE = 2" and "BSCALE = 2.0" are allowed, even though BSCALE is specified to have a "floating point" value (5.4.2.5). They should be interpreted identically. Tim Pearson Astronomy Dept, California Institute of Technology From owner-fitsbits at kochab.cv.nrao.edu Tue Jul 14 10:32:46 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA25641 for fitsbits-spinner; Tue, 14 Jul 1998 10:32:39 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA25636 for ; Tue, 14 Jul 1998 10:32:36 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA01747 for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 10:32:33 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA25626 for ; Tue, 14 Jul 1998 10:31:52 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id KAA01736 for ; Tue, 14 Jul 1998 10:31:49 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id KAA11280 for ; Tue, 14 Jul 1998 10:31:48 -0400 Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3) id sma011277; Tue Jul 14 10:31:23 1998 Received: from xebec by head-cfa (SMI-8.6/SMI-SVR4) id KAA19972; Tue, 14 Jul 1998 10:24:34 -0400 Received: by xebec (SMI-8.6/SMI-SVR4) id KAA10763; Tue, 14 Jul 1998 10:24:33 -0400 From: arots at xebec.harvard.edu (Arnold Rots) Message-Id: <199807141424.KAA10763 at xebec> Subject: Re: EXTNAME Keyword in Primary HDU In-Reply-To: <6odrt6$si7 at post.gsfc.nasa.gov> from Louis Giglio at "Jul 13, 98 08:49:42 pm" To: giglio at hades.gsfc.nasa.gov (Louis Giglio) Date: Tue, 14 Jul 1998 10:24:33 -0400 (EDT) Cc: fitsbits at fits.cv.nrao.edu X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Just to be on the safe side, the ASC adopted a convention to use the keyword HDUNAME: identical to EXTNAME in extensions, and playing the same role in primary HDUs. - Arnold Rots Louis Giglio wrote: > The subject pretty much sums up my question. Is it acceptable to have > the EXTNAME keyword -- which is explicitly defined for extension HDU's -- > in the primary HDU of a FITS file. Everything I've read seems to allow > this without actually explicitly stating that it's legal. > > Thanks, > Louis > -------------------------------------------------------------------------- Arnold H. Rots AXAF Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 81 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head-cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From owner-fitsbits at kochab.cv.nrao.edu Tue Jul 14 11:24:05 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id LAA27110 for fitsbits-spinner; Tue, 14 Jul 1998 11:23:23 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA27105 for ; Tue, 14 Jul 1998 11:23:20 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id LAA01803 for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 11:23:18 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA26940 for ; Tue, 14 Jul 1998 11:13:12 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id LAA01784 for ; Tue, 14 Jul 1998 11:13:09 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id LAA23751; Tue, 14 Jul 1998 11:13:09 -0400 To: fitsbits at fits.cv.nrao.edu Date: Tue, 14 Jul 1998 15:12:23 GMT From: jgadeva at jet.uk (Juan Jose Garcia Adeva) Message-ID: <35ab7550.114139353 at internet> Organization: JET Joint Undertaking Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!btnet-peer!btnet!dispose.news.demon.net!demon!newsfeed.nacamar.de!rill.news.pipex.net!pipex!bore.news.pipex.net!pipex!not-for-mail Subject: I am looking for FITS files where BITPIX = 32 and NAXIS = 2 Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Hello, I am using the FITS format in a project, but I only need to support files with BITPIX = 32 and NAXIS = 2. I have written some software to manage this range of files, but I cannot find any example in http://www.cv.nrao.edu/fits/data/samples. So please, if you have some FITS files which match this criteria, send them to me, or send me the address where I can get them. Thanks a lot, Juanjo +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Juan Jose Garcia Adeva | mailto:jgadeva at jet.uk | | Experimental Division II | Personal Home Page: | | JET Joint Undertaking | http://www.wavenet.co.uk/users/jjga | | Abingdon | Company Web Site: | | Oxfordshire OX14 3EA | http://www.jet.uk | | United Kingdom | Phone: +44-1235-464490 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-fitsbits at kochab.cv.nrao.edu Tue Jul 14 12:06:11 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id MAA27489 for fitsbits-spinner; Tue, 14 Jul 1998 12:06:02 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA27484 for ; Tue, 14 Jul 1998 12:05:59 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id MAA01917 for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 12:05:56 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA27474 for ; Tue, 14 Jul 1998 12:05:20 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id MAA01907 for ; Tue, 14 Jul 1998 12:05:16 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id MAA30186; Tue, 14 Jul 1998 12:05:15 -0400 To: fitsbits at fits.cv.nrao.edu Date: 14 Jul 1998 12:05:04 -0400 From: Don Wells Message-ID: Organization: nrao Path: newsfeed.cv.nrao.edu!not-for-mail References: <35ab7550.114139353 at internet> Reply-To: dwells at nrao.edu Subject: Re: I am looking for FITS files where BITPIX = 32 and NAXIS = 2 Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk >>>>> "Juan" == Juan Jose Garcia Adeva writes: Juan> Hello, I am using the FITS format in a project, but I only Juan> need to support files with BITPIX = 32 and NAXIS = 2. .. I Juan> cannot find any example in Juan> http://www.cv.nrao.edu/fits/data/samples. .. Try your code on this 262_KB file: http://www.cv.nrao.edu/fits/data/tests/incunabula/m87-32.fits Examine the two text files m87-32.list and m87-32.vf in the same directory. Note that ORIGIN='KPNO' and DATE='13/09/79': this is the oldest FITS file with BITPIX=32. The 'vf' file is the output of a FITS file verifier when reading this file. It asserts that the '/' in the keyword 'IPPS-B/P' is illegal, however this file is readable by modern software (Cotton's FITSview code displays the file properly). The 'IPPS' refers to KPNO's Interactive Picture Processing System, the predecessor of IRAF and 'B/P' is bits per pixel; the IPPS executed on a CDC 60-bit computer, and floating point pixels were carried in half words, probably with 20-bit mantissas but I can no longer remember that detail. The number system of this FITS test file was specially contrived: BSCALE=1.00000E-06 was used in order to make the significant bits be spread across the second and third bytes to expose byte-flip bugs. Furthermore, the file asserts that BLANK=-2147483648, so this header is sensitive to differences in implementations of number conversion routines, the situation discussed by John Davis and Bill Pence in the unsigned-integer thread in the past few days. -Don -- Donald C. Wells Associate Scientist dwells at nrao.edu http://www.cv.nrao.edu/~dwells National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road, Charlottesville, Virginia 22903-2475 USA From owner-fitsbits at kochab.cv.nrao.edu Tue Jul 14 13:28:51 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA28346 for fitsbits-spinner; Tue, 14 Jul 1998 13:28:30 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA28341 for ; Tue, 14 Jul 1998 13:28:27 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA02019 for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 13:28:25 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA28235 for ; Tue, 14 Jul 1998 13:27:22 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id NAA02009 for ; Tue, 14 Jul 1998 13:27:19 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id NAA28560 for ; Tue, 14 Jul 1998 13:27:18 -0400 Received: from silk.gsfc.nasa.gov(128.183.127.210) by palantir.cv.nrao.edu via smap (V1.3) id sma028548; Tue Jul 14 13:26:59 1998 Received: by silk.gsfc.nasa.gov id AA02230; Tue, 14 Jul 1998 13:27:23 -0400 Message-Id: <35AB94A8.190BF9E7 at silk.gsfc.nasa.gov> Date: Tue, 14 Jul 1998 13:26:00 -0400 From: Tom McGlynn Organization: NASA/GSFC X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: fitsbits at fits.cv.nrao.edu Cc: Tim Pearson Subject: Re: 64-bit integers in FITS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk When I wrote a Java FITS reader last year I was considering whether I should support 64 bit integers and I asked whether there was any need for it. The response was underwhelming, but I went ahead and did it anyway. (See http://members.home.net/mcglynn/java/nom/tam/fits). A few points: It's very clear how the standard should support this data type, e.g., BITPIX=64 for image data, and TFORM='K' for binary tables. (16 byte integers will be a little harder since 'L' is already taken) This makes adopting it a lot easier. I have thought of a few things that people might want to store in 8 byte integers today or soon. Presumably this number will increase with time. For some double precision numbers are not an acceptable alternative. Note that while we do have ways to indicate that real data is being encoded as integers (BZERO/BSCALE, ...) we do not have the inverse: that value encoded in a double is really an integer. That's an important thing to know about an item. Some things that might need 8 byte integers: - As mentioned previously clock times frequently require more than 32 bits. - File sizes - Verification/encryption keys, e.g., an 8 byte checksum. Possible rouding errors mean that these cannot be stored as doubles. - Catalog IDs (e.g., the Monet catalog already has 270 million entries). Its very useful to integer ID's for catalogs but some of the next generations of catalogs will have more than 4 billion entries. - System data (e.g., the one suggestion I had last year was that databases often use 8 byte quantities). With regard to Tim Pearson's question of whether we should implement intermediate sizes, the historical precedent seems to be no: FITS does not support 24 bit ints. I think there are some other problems: What granularity to support? What's the format code in binary tables? More importantly FITS seems to have evolved such that its internal formats are compatible with those found on typical hardware. It would be a lot more painful to support these intermediate types (e.g., to hande the sign extension, packing and overflow issues). There is the question of how to support i*8's on machines which don't have that. It should be very straightfoward to convert from i*8 to r*8 (not too much worse than the signed to unsigned conversions) but that won't always be good enough. This is the one issue that I'd like to understand better before going ahead and recommending adopting i*8. What fraction of the community cannot read i*8's? E.g., do gcc and g77 support it? Tom McGlynn From owner-fitsbits at kochab.cv.nrao.edu Tue Jul 14 21:30:10 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id VAA00832 for fitsbits-spinner; Tue, 14 Jul 1998 21:30:00 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA00827 for ; Tue, 14 Jul 1998 21:29:57 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA02421 for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 21:29:55 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA00194 for ; Tue, 14 Jul 1998 17:30:15 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id RAA02283 for ; Tue, 14 Jul 1998 17:30:12 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id RAA17785; Tue, 14 Jul 1998 17:30:11 -0400 To: fitsbits at fits.cv.nrao.edu Date: 14 Jul 1998 11:00:06 -0700 From: sla at ucolick.borg (Steve Allen) Message-ID: <6og6b6$oaj$1 at dei.ucolick.org> Organization: UCO/Lick Observatory Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!logbridge.uoregon.edu!agate!news.ucsc.edu!not-for-mail References: <35A342B0.DC2A0F4D at obs.unige.ch> <35AA6D3D.44297AB4 at tetra.gsfc.nasa.gov> Subject: Re: 64-bit integers in FITS Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk The performance increase for, e.g., database applications experienced with Dec Alpha processors is rapidly driving Sun, Intel, HP, and others to produce hardware and software with 64-bit capabilities. In article <35AA6D3D.44297AB4 at tetra.gsfc.nasa.gov>, William Pence wrote: >- it would be a fairly trivial job to modify the FITS standard to >specify the format for 64-bit integer images and binary table columns. It should be noted that introduction of 64-bit integers will probably create demand for enhancement of the TFORMn = 'P' (Array Descriptor) data type. The Appendix for BINTABLE currently suggests this for a length and offset into a heap following a table. It's easy to imagine heaps of more than 2**32 bytes. Perhaps something as simple as a new TFORMn = 'Q' (64-bit Array Descriptor) which consists of two 64-bit integers would do the job. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla at ucolick.borg Voice: +1 831 459 3046 FAX (don't): +1 831 459 5244 WWW: http://www.ucolick.borg/~sla PGP public keys: see WWW Junk mail is irrelevant -- my return address has been assimilated. From owner-fitsbits at kochab.cv.nrao.edu Tue Jul 14 21:35:57 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id VAA00858 for fitsbits-spinner; Tue, 14 Jul 1998 21:35:44 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA00853 for ; Tue, 14 Jul 1998 21:35:41 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA02430 for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 21:35:38 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA00411 for ; Tue, 14 Jul 1998 18:14:16 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id SAA02312 for ; Tue, 14 Jul 1998 18:14:14 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id SAA19841; Tue, 14 Jul 1998 18:14:13 -0400 To: fitsbits at fits.cv.nrao.edu Date: 14 Jul 1998 22:10:06 GMT From: seaman at noao.edu (Rob Seaman) Message-ID: <6ogkvu$bqj$1 at noao.tuc.noao.edu> Organization: National Optical Astronomy Observatories Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!newsfeed.internetmci.com!192.52.106.6!ncar!noao!noao.edu!seaman References: <35AB94A8.190BF9E7 at silk.gsfc.nasa.gov> Subject: Re: 64-bit integers in FITS Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Tom McGlynn writes: > Note that while we do have ways to indicate that real data is being > encoded as integers (BZERO/BSCALE, ...) we do not have the inverse: that > value encoded in a double is really an integer. That's an important thing > to know about an item. Well, BSCALE and BZERO were originally designed for packing reals into integer pixels before the floating point convention, but they now can also mean that 16 bit integers are unsigned, so FITS has no reliable way to indicate that the original datatype was different than the FITS datatype in either direction. This seems like a pretty esoteric thing to rely on knowing in any event. > Some things that might need 8 byte integers: > - As mentioned previously clock times [...] > - File sizes > - Verification/encryption keys, e.g., an 8 byte checksum. [...] > - Catalog IDs [...] > - System data [...] However, can anybody suggest a current need for images with 64 bit pixels? ...and do tables and images have to support the same set of datatypes? "Exotic" image data arrays are likely to be written as binary tables anyway. On the other hand, 64 bits may not be enough for some of the applications listed above. Encryption keys and digital signatures, for instance, can require hundreds or thousands of bits (and a proportionately large number of ASCII digits or characters). A character string may be the only thing that suffices for table fields (or header keywords) that require extended precision. > With regard to Tim Pearson's question of whether we should implement > intermediate sizes, the historical precedent seems to be no: FITS does > not support 24 bit ints. Note that the hubbub about unsigned integers is also something of a historical artifact. If a signed integer datatype is large enough to contain the entire range of the unsigned integers being generated (e.g., packing 15 bit unsigned data into 16 bit signed pixels), then there is no problem - other than some slight overhead that may perhaps be involved in this easy type conversion. And if the signed datatype is not large enough (trying to fit 18 bits into a short integer), then some higher precision datatype is needed entirely. The main reason for worrying about unsigned integers is that the affordable state of the art for A/D converters is 16 bits and we don't want to waste the high order bit. Folks building instruments with 18 bit A/D's won't be concerned with packing them into short integers using BZERO. Perhaps rather than worrying about unsigned integers (or 24 bit ints or whatever), we should get back to devising a speedy FITS compression scheme that would allow using 32 (or even 64) bit integer pixels for intermediate precision data in a space-efficient manner. Rob Seaman -- seaman at noao.edu, http://iraf.noao.edu/~seaman NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248 PGP: 98 8D 8B 49 74 9A 41 88 3A 43 87 54 51 BF 30 4B From owner-fitsbits at kochab.cv.nrao.edu Wed Jul 15 12:23:42 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id MAA18258 for fitsbits-spinner; Wed, 15 Jul 1998 12:23:11 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA18253 for ; Wed, 15 Jul 1998 12:23:06 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id MAA03276 for fitsbits at majordomo.cv.nrao.edu; Wed, 15 Jul 1998 12:23:03 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA18232 for ; Wed, 15 Jul 1998 12:21:43 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id MAA03266 for ; Wed, 15 Jul 1998 12:21:40 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id MAA12338; Wed, 15 Jul 1998 12:21:39 -0400 To: fitsbits at fits.cv.nrao.edu Date: 15 Jul 1998 16:01:58 GMT From: hodge at bowline.stsci.edu (Phil Hodge) Message-ID: <6oijpm$4um$1 at tnm.stsci.edu> Organization: Space Telescope Science Institute Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!howland.erols.net!cs.utexas.edu!ennfs.eas.asu.edu!noao!stsci.edu!not-for-mail References: <199807121936.PAA04862 at aluche.mit.edu> <35AA384F.1BE21420 at tetra.gsfc.nasa.gov> Subject: Re: Unsigned integer support in NOST 100-1.2 Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Bill Pence wrote: > In the previous debate a few years about about adding new unsigned > integer datatypes to FITS I had argued in favor of the proposal. > However, I have since come to appreciate that the current FITS format > already fully supports unsigned integers (16 and 32 bit at least), hence > I would now oppose any change to the Standard in this regard. FITS is > able to store unsigned 16 and 32 bit integers in an efficient format > that is easy to read and write. This is all that is required. The > transformation between the internal FITS representation and the machine > representation on a particular computer of the same unsigned integer > value is trivial: flip the value of the most significant bit (bit 32 or > 16) and also swap the order of the bytes on little endian machines like > IBM PCs. This is trivial to implement, yes, but it's not transparent to many people who would read the header. It's rather esoteric, in fact. I think that FITS should support unsigned 16-bit and 32-bit integers using notation (e.g. a DATATYPE keyword) that would be clear to an intelligent person who is not necessarily an expert on FITS. Rob Seaman wrote: > Perhaps rather than worrying about unsigned integers (or 24 bit ints or > whatever), we should get back to devising a speedy FITS compression scheme > that would allow using 32 (or even 64) bit integer pixels for intermediate > precision data in a space-efficient manner. Would that be 32-bit unsigned pixels? Phil From owner-fitsbits at kochab.cv.nrao.edu Wed Jul 15 13:43:29 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA18801 for fitsbits-spinner; Wed, 15 Jul 1998 13:42:59 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA18795 for ; Wed, 15 Jul 1998 13:42:56 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA03380 for fitsbits at majordomo.cv.nrao.edu; Wed, 15 Jul 1998 13:42:51 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA18720 for ; Wed, 15 Jul 1998 13:39:59 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id NAA03368 for ; Wed, 15 Jul 1998 13:39:56 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id NAA18830; Wed, 15 Jul 1998 13:39:55 -0400 To: fitsbits at fits.cv.nrao.edu Date: 15 Jul 1998 17:39:40 GMT From: davis at space.mit.edu (John E. Davis) Message-ID: Organization: Center for Space Research Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!eecs-usenet-02.mit.edu!davis References: Subject: Re: 64-bit integers in FITS Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk On 14 Jul 1998 09:51:10 -0400, Tim Pearson wrote: >I am surprised that many people appear to think that FITS is designed >for interchanging computer bit patterns. It is not: it is for >interchanging images (and now tabular data), using as few different >conventions as possible. My main concern is that FITS is not being used to simply exchange images between systems (which it does well), but is used as a general purpose data archive format. I have no problems with this concept as long as the file format is well defined in the absence of a reader. I remain unconvinced that this requirement is fulfilled. If FITS should not be used as a general purpose archive format, then it would be nice if the scope of the file format was spelled out in the NOST document. Some people believe that all programs used for processing astrophysical data should read and write FITS files and communicate with each other using such files. I believe that this practice goes beyond the original scope of the FITS file format. --John From owner-fitsbits at kochab.cv.nrao.edu Wed Jul 15 17:17:29 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id RAA03981 for fitsbits-spinner; Wed, 15 Jul 1998 17:17:14 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA03976 for ; Wed, 15 Jul 1998 17:17:11 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id RAA03791 for fitsbits at majordomo.cv.nrao.edu; Wed, 15 Jul 1998 17:17:08 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id QAA03904 for ; Wed, 15 Jul 1998 16:52:21 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id QAA03760 for ; Wed, 15 Jul 1998 16:52:18 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id QAA04453 for ; Wed, 15 Jul 1998 16:52:16 -0400 Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3) id sma004444; Wed Jul 15 16:52:03 1998 Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109]) by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP id QAA26229 for ; Wed, 15 Jul 1998 16:51:33 -0400 (EDT) Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4) id QAA27106; Wed, 15 Jul 1998 16:51:31 -0400 Message-ID: <35AD1651.945E6380 at tetra.gsfc.nasa.gov> Date: Wed, 15 Jul 1998 16:51:29 -0400 From: William Pence Organization: HEASARC X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: fitsbits at fits.cv.nrao.edu Subject: Re: 64-bit integers in FITS References: <35AB94A8.190BF9E7 at silk.gsfc.nasa.gov> <6ogkvu$bqj$1 at noao.tuc.noao.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Rob Seaman wrote: > However, can anybody suggest a current need for images with 64 bit > pixels? ...and do tables and images have to support the same set of > datatypes? "Exotic" image data arrays are likely to be written as > binary tables anyway. >From the implementation point of view, a FITS image is just a special case of a table with 1 row and 1 vector column. So if one is going to support 64-bit integer table columns, then very little else needs to be added to support 64-bit images. ____________________________________________________________________ Dr. William Pence pence at tetra.gsfc.nasa.gov NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice) Greenbelt MD 20771 +1-301-286-1684 (fax) From owner-fitsbits at kochab.cv.nrao.edu Wed Jul 15 17:18:04 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id RAA03997 for fitsbits-spinner; Wed, 15 Jul 1998 17:18:02 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA03992 for ; Wed, 15 Jul 1998 17:17:59 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id RAA03796 for fitsbits at majordomo.cv.nrao.edu; Wed, 15 Jul 1998 17:17:56 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA03941 for ; Wed, 15 Jul 1998 17:06:54 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id RAA03778 for ; Wed, 15 Jul 1998 17:06:52 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id RAA04591 for ; Wed, 15 Jul 1998 17:06:50 -0400 Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3) id sma004588; Wed Jul 15 17:06:37 1998 Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109]) by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP id RAA26473 for ; Wed, 15 Jul 1998 17:06:06 -0400 (EDT) Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4) id RAA27121; Wed, 15 Jul 1998 17:06:05 -0400 Message-ID: <35AD19BD.6CDD6A9C at tetra.gsfc.nasa.gov> Date: Wed, 15 Jul 1998 17:06:05 -0400 From: William Pence Organization: HEASARC X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: fitsbits at fits.cv.nrao.edu Subject: Re: Unsigned integer support in NOST 100-1.2 References: <199807121936.PAA04862 at aluche.mit.edu> <35AA384F.1BE21420 at tetra.gsfc.nasa.gov> <6oijpm$4um$1 at tnm.stsci.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk Phil Hodge wrote: > This is trivial to implement, yes, but it's not transparent to many > people who would read the header. It's rather esoteric, in fact. > I think that FITS should support unsigned 16-bit and 32-bit integers > using notation (e.g. a DATATYPE keyword) that would be clear to an > intelligent person who is not necessarily an expert on FITS. The FITS standard allows optional characters following the datatype character in the TFORMn keyword, so one could adopt a convention something like: TFORM1 = '1IU' / datatype is unsigned 16-bit integer TZERO1 = 32768 or TFORM1 = '1I(unsigned)' / datatype is unsigned 16-bit integer TZERO1 = 32768 This doesn't require any change to the FITS standard, and the TZEROn keyword is still required, but at least it would be clearer to people reading the header that this is an unsigned integer column. ____________________________________________________________________ Dr. William Pence pence at tetra.gsfc.nasa.gov NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice) Greenbelt MD 20771 +1-301-286-1684 (fax) From owner-fitsbits at kochab.cv.nrao.edu Thu Jul 16 10:15:58 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA29260 for fitsbits-spinner; Thu, 16 Jul 1998 10:14:07 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA29255 for ; Thu, 16 Jul 1998 10:14:03 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA04851 for fitsbits at majordomo.cv.nrao.edu; Thu, 16 Jul 1998 10:14:00 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id EAA23103 for ; Thu, 16 Jul 1998 04:02:52 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id EAA04356 for ; Thu, 16 Jul 1998 04:02:48 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id EAA14378 for ; Thu, 16 Jul 1998 04:02:44 -0400 Received: from ujf.ujf-grenoble.fr(193.54.232.33) by palantir.cv.nrao.edu via smap (V1.3) id sma014372; Thu Jul 16 04:02:29 1998 Received: from gagax5.obs.ujf-grenoble.fr (gagax5.obs.ujf-grenoble.fr [195.220.79.15]) by ujf.ujf-grenoble.fr (8.8.5/8.8.5) with ESMTP id JAA05863; Thu, 16 Jul 1998 09:56:08 +0200 (MET DST) Received: (from forveill at localhost) by gagax5.obs.ujf-grenoble.fr (8.7.6/8.6.9) id JAA78136; Thu, 16 Jul 1998 09:56:08 +0200 From: Thierry Forveille MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13741.45592.173971.583641 at gagax5.obs.ujf-grenoble.fr> Date: Thu, 16 Jul 1998 09:56:08 +0200 (DFT) To: William Pence Cc: fitsbits at fits.cv.nrao.edu Subject: Re: Unsigned integer support in NOST 100-1.2 In-Reply-To: <35AD19BD.6CDD6A9C at tetra.gsfc.nasa.gov> References: <199807121936.PAA04862 at aluche.mit.edu> <35AA384F.1BE21420 at tetra.gsfc.nasa.gov> <6oijpm$4um$1 at tnm.stsci.edu> <35AD19BD.6CDD6A9C at tetra.gsfc.nasa.gov> X-Mailer: VM 6.49 under Emacs 19.34.9 Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk William Pence writes: > The FITS standard allows optional characters following the datatype > character in the TFORMn keyword, so one could adopt a convention > something like: > > TFORM1 = '1IU' / datatype is unsigned 16-bit integer > TZERO1 = 32768 > > or > > TFORM1 = '1I(unsigned)' / datatype is unsigned 16-bit integer > TZERO1 = 32768 > > This doesn't require any change to the FITS standard, and the TZEROn > keyword is still required, but at least it would be clearer to people > reading the header that this is an unsigned integer column. > Really I don't see the point of keeping track of the unsigned origin of a datum. As mentioned earlier in this discussion, the purpose of FITS is to transfer numerical information, not bit patterns. Whether a column originates from unsigned IEEE 16 bits integers or 30 bits one from a CDC mainframe is irrelevant for the receiving program, as long as it fits in its specified format. Most modern image processing systems will convert it to 32 bits integers anyway (if not to floats) for the sake of efficiency. Actually, all people I have heard arguing for an unsigned 16 bit format (nobody seems to demand 32 bits unsigneds) really want to use it to store floating point data affected by quantisation noise ;) From owner-fitsbits at kochab.cv.nrao.edu Thu Jul 16 10:15:58 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA29267 for fitsbits-spinner; Thu, 16 Jul 1998 10:14:39 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA29262 for ; Thu, 16 Jul 1998 10:14:36 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA04856 for fitsbits at majordomo.cv.nrao.edu; Thu, 16 Jul 1998 10:14:34 -0400 (EDT) Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id HAA28899 for ; Thu, 16 Jul 1998 07:24:27 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by cv3.cv.nrao.edu (8.8.5/8.8.5/CV-2.7) with ESMTP id HAA26055 for ; Thu, 16 Jul 1998 07:24:24 -0400 (EDT) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id HAA16775 for ; Thu, 16 Jul 1998 07:24:23 -0400 Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3) id sma016772; Thu Jul 16 07:24:21 1998 Received: from bynars by head-cfa (SMI-8.6/SMI-SVR4) id HAA15299; Thu, 16 Jul 1998 07:20:57 -0400 Message-Id: <199807161120.HAA15299 at head-cfa> To: fitsbits at nrao.edu Subject: release of saord 1.8 cc: eric at head-cfa.harvard.edu Date: Thu, 16 Jul 1998 07:20:57 -0400 From: Eric Mandel Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk ******************************************************************************* The SAO R&D Software Suite Public Release 1.8 16 July 1998 containing: SAOimage: The Next Generation (SAOtng) The X Public Access mechanism (XPA) as well as: The ASSIST Graphical User Interface The XDir directory browser The IRAF ncl with tcsh line editing Contributors to this software include: Eric Mandel Smithsonian Astrophysical Observatory William Joye Smithsonian Astrophysical Observatory Saleem Mukhtar Jet Propulsion Laboratory Doug Tody National Optical Astronomy Observatories with important assistance from: Alberto Accomazzi Smithsonian Astrophysical Observatory Mark S. Ackerman University of California, Irvine Doug Mink Smithsonian Astrophysical Observatory John Roll Smithsonian Astrophysical Observatory Dennis Schmidt Smithsonian Astrophysical Observatory Ralph Swick The Web Consortium What's New and Significant in this release? ------------------------------------------- This release of the SAO R&D package contains support for new types of FITS data. SAOtng 1.8 can display FITS image extensions, FITS binary tables, n-D FITS images, compressed FITS data, and FITS files that are found on the Web. In addition, SAOtng can display raw event lists (i.e., binary files containing events with a known record structure) -- useful for X-ray lab data. For X-ray astronomers, the ability to image FITS binary tables is particularly significant. Our new support for FITS binary tables includes a technique for filtering photon events in FITS tables. This filtering scheme is several times faster than previous schemes (such as IRAF QPOE filtering) and also supports full C-syntax in the filter specification. In addition to standard filtering using QPOE-style range lists, you now can filter one attribute against another (e.g., "pi==pha+1") or use arithmetic functions (e.g., "pha%2==1" to get odd pha values). Full boolean algebra is supported, as is spatial region filtering (e.g., "circle(400,450,50) && pie(400,450,90)"). New support for manipulating region marker attributes has been added. It now is possible to fix attributes such as position, size, etc. on one or more markers to prevent accidental resize or movement. This is especially useful when performing catalog marking. Finally, a number of bug fixes and other relatively minor improvements have been made, most notably to the internal memory management scheme. Introduction ------------ We are pleased to announce the availability of a new public release (version 1.8) of the SAO R&D software tree containing, among other things, a new and improved version of SAOtng. We invite you to retrieve the software and use it for your astronomical analysis (and other?) needs. [Historic Note: this is "the release formerly known as 1.7.2", which was available from 4 June 1998 to 5 June 1998. Oops! We had to withdraw this release because of a bug that was unacceptable to our quality control.] SAOimage: The Next Generation (SAOtng) -------------------------------------- SAOtng is a new version of the popular SAOimage display program. It is a superset of the ximtool program developed at NOAO for IRAF and as such, utilizes the NOAO widget server (included in this package). It also incorporates the X Public Access mechanism to allow external processes to access and control its data, GUI functions, and algorithms. SAOtng supports direct display of IRAF images and FITS images (and easily can support other file formats), multiple frame buffers, region/cursor manipulation, several scale algorithms, many colormaps, and easy communication with external analysis tasks. It is highly configurable and extensible to meet the evolving needs of the astronomical community. The X Public Access Mechanism ---------------------------- To add 'open software' functionality to programs such as SAOtng, we have developed the 'X Public Access' mechanism (XPA). Built on top of the existing Xt selection interface, XPA allows an Xt program to define points of public access through which data and commands can be exchanged with external programs. Its simple programming and command-line interface is designed so that arbitrarily large amounts of data can be transferred to and from Xt programs using XPA. Also, the data associated with a given access point can be read and written simultaneously. XPA is the precursor to a more generalized message bus system that will be built as collaboration between SAO and NOAO. Platforms --------- The SAO R&D software has been built on the following platforms: Sun Sparc Solaris 2.5, 2.6 OpenWindows 3.x Sun Sparc SunOs 4.1.3, 4.1.4 X11R5/R6.3 HP9000/735 HP/UX A.09.01 X11R5 SGI IRIX 5.2, 5.3, 6.2 X11R5/R6 DEC Alpha OSF1 4.0 X11R6 Gateway P5-90 Slackware 2.2.5 X11R6 RedHat 5.0 X11R6 We develop and run the software mainly on Suns, but time has been spent with the other (borrowed) platforms, especially 64-bit Alphas. Ports to other systems should be relatively easy at this stage. If you do a port (or try to and have problems), please let us know. Information and Availability --------------------------- Please visit the SAO R&D Group Home Page for news, updates, and downloads: http://hea-www.harvard.edu/RD/ Our home page will help you to download the source code distribution and/or binary distributions for various platforms. Alternatively, the SAO R&D software suite can be retrieved directly via anonymous ftp from sao-ftp.harvard.edu in the pub/rd directory. The source tree is contained in a compressed tar file called saord.tar.Z. The binary distributions also are available at this site. We recommend using the binary distributions where possible. The unpacked tar file requires approximately 20 Mb of disk space. The build will require approximately double that amount, depending on the platform. SAOtng Mailing List ------------------- An saord mailing list (saord-announce) have been set up using Brent Chapman's "Majordomo" mailing list manager. Subscribers to this list will receive periodic status reports, release notices, and other useful information concerning SAORD software. If you wish to become a subscriber, please send an e-mail message to: majordomo at head-cfa.harvard.edu The mail should contain the following command in the body of the message: subscribe saord-announce If either you or your mailer add a signature to your mail message, please add the following command after the "subscribe" command(s): end (Note that we have combined the old saotng-announce and assist-announce lists into this saord-announce list, so it is not necessary to join the new list if you subscribed to one of the old lists.) Acknowledgments ---------------- Much of this software was developed at SAO by the HEAD Software R&D group with the significant help of collaborators across the country. The work at SAO was performed in large part under a grant from NASA's Applied Information System Research Program (NAG5-3996), with support from the AXAF Science Center (NAS8-39073). SAOtng, ASSIST, and XPA are embodiments of an evolving software cooperation philosophy and practice we hope to bring to astronomy and other disciplines. They reflect our efforts to understand how software systems (and people) can act in concert without sacrificing their independence. For more information (or to complain or encourage!) --------------------------------------------------- Please send mail to: saord at cfa.harvard.edu. We respond to questions, bug reports, suggestions, gripes ... Eric Mandel eric at cfa.harvard.edu From owner-fitsbits at kochab.cv.nrao.edu Thu Jul 16 11:51:11 1998 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id LAA00822 for fitsbits-spinner; Thu, 16 Jul 1998 11:50:47 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA00817 for ; Thu, 16 Jul 1998 11:50:44 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id LAA05029 for fitsbits at majordomo.cv.nrao.edu; Thu, 16 Jul 1998 11:50:41 -0400 (EDT) Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA00804 for ; Thu, 16 Jul 1998 11:49:15 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id LAA05013 for ; Thu, 16 Jul 1998 11:49:12 -0400 (EDT) Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id LAA08949; Thu, 16 Jul 1998 11:49:11 -0400 To: fitsbits at fits.cv.nrao.edu Date: Thu, 16 Jul 1998 11:39:11 -0400 From: "William F. Wyatt" Message-ID: <35AE1E9F.6021 at cfa.harvard.edu> Organization: Harvard-Smithsonian Center for Astrophysics Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!gatech!128.10.2.10.MISMATCH!purdue!oitnews.harvard.edu!cfanews.harvard.edu!131.142.10.146 References: Subject: Re: Comments on NOST 100-1.2 Newsgroups: sci.astro.fits Sender: owner-fitsbits at majordomo.cv.nrao.edu Precedence: bulk On 10 Jul 1998 13:06:38 -0400, Lucio Chiappetti