From fitsbits-request Fri Nov 3 11:29:29 1995 X-VM-Message-Order: (1 2 5 6 7 8 10 3 9 15 16 17 11 12 13 4 18 14) X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n" X-VM-Labels: nil X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil X-VM-Bookmark: 18 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2730" "" "3" "November" "1995" "11:30:55" "GMT" "Mark Robinson" "mark-r at mercury.ee.man.ac.uk" nil "76" "New Windows FITS viewer available for download" "^From:" nil nil "11" nil nil (number " " mark " Mark Robinson Nov 3 76/2730 " thread-indent "\"New Windows FITS viewer available for download\"\n") nil] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA26822; Fri, 3 Nov 1995 11:29:29 -0500 Return-Path: Message-Id: <47cuhf$l31 at yama.mcc.ac.uk> Organization: Manchester Scientific Instruments Ltd. Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!spool.mu.edu!usenet.eel.ufl.edu!tank.news.pipex.net!pipex!sunsite.doc.ic.ac.uk!yama.mcc.ac.uk!mercury.ee.man.ac.uk!mark-r Newsgroups: sci.astro.fits,sci.astro,sci.image.processing content-length: 2728 From: mark-r at mercury.ee.man.ac.uk (Dr. Mark Robinson (FHR Associates)) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: New Windows FITS viewer available for download Date: 3 Nov 1995 11:30:55 GMT Hi. I have put a beta version of a new FITS viewer for MS Windows on our ftp site at ftp://mercury.ee.man.ac.uk/pub/fits/fitswin.zip The README file is included below... Mark. [followups to sci.astro.fits] ------ 8< ---------- README.TXT FITS for Windows V0.1 --------------------- FITS for Windows is a viewer for images in the Flexible Image Transport System (FITS) format. It runs under Windows 3.x, 95 and NT (as a 16 bit application). Native 32 bit Windows and Linux versions are planned. Currently only 8,16 and 32 bit integer and 32 bit floating point primary data is supported (64 bit FP is not implemented mainly because I couldn't find any example images on the net). Random Groups and extensions are not currently supported. The program includes a histogram viewer and a 'blink' or 'movie' viewer. More information is given in the help file. License. -------- This version of FITS for Windows is public domain and contains no 'nag' screens or time limits. However, some features (printing, file export and clipboard functions) are disabled. A registered version is available which includes these functions, and a Professional edition containing Image Processing functions will be released soon. Prices are given in the help file. Even if you don't intend to purchase one of the registered versions, we would appreciate it if you would register your use of the free version, so that (if you wish) we can keep you informed of updates and so that we can get some idea of its use. Mail msi at mercury.ee.man.ac.uk. Known Bugs. ----------- Only the ARC, TAN, SIN, GLS and MER projection systems are supported. The contast and brightness controls don't work on 16 bit displays. The program has not been tested at all on 24 bit displays. Images without primary data (or with random groups) display the 'invalid FITS Image' message. No 64 bit Floating point support (and possibly unpredictable results if you load one). This is a beta release of the software and we appreciate bug reports (send to msi at mercury.ee.man.ac.uk). Bugs will, where possible, be dealt with promptly. If the bugs are image-dependent, we will arrange for you to FTP the images to our site. Please do not email images. Suggestions. ------------ If you would like to see some function implemented in FITS for Windows please let us know. We are specialists in Image Processing and Machine Vision and can implement or have implemented many algorithms. ------ 8< ---------- README.TXT -- Manchester Scientific Instruments Ltd. | There's lies, damned lies Campus Ventures Centre. Uni of M/CR. | and Amplifier power ratings. Oxford Rd. Manchester. M13 9PL, UK | -- Bluffers Guide to Hi-Fi. http://mercury.ee.man.ac.uk/mjr.htm | From fitsbits-request Mon Nov 6 19:11:40 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["464" "" "3" "November" "1995" "23:51:18" "GMT" "Immanuel Freedman" "immanuel at mother.com" nil "20" "Data Compression" "^From:" nil nil "11" nil nil (number " " mark " Immanuel Freedman Nov 3 20/464 " thread-indent "\"Data Compression\"\n") nil] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA03804; Mon, 6 Nov 1995 19:11:40 -0500 Return-Path: Message-Id: <47e9tm$rre at pa.mother.com> Organization: Mother.COM Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!news.duke.edu!news.mathworks.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!agis!news.PBI.net!pa.mother.com!news Newsgroups: sci.astro.fits content-length: 462 From: "Dr. Immanuel Freedman" Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Data Compression Date: 3 Nov 1995 23:51:18 GMT Colleagues This is a posting to open discussion about Data Compression within the FITS Standard. It is a continuation of the topic presented at the ADASS V FITS BoF session. What do the readers of this group feel about the need for data compression, now that several major projects have already adopted such techniques both onboard (Galileo, Mars Observer...) and for browse/archival (Space Telescope...) ? Dr. Immanuel Freedman immanuel at mother.com From fitsbits-request Sun Nov 12 15:11:57 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["746" "" "7" "November" "1995" "13:17:17" "GMT" "Gerard Farrell" "gerard at mercury.ee.man.ac.uk" nil "22" "Re: New Windows FITS viewer available for download" "^From:" nil nil "11" nil nil (number " " mark " Gerard Farrell Nov 7 22/746 " thread-indent "\"Re: New Windows FITS viewer available for download\"\n") nil] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA14668; Sun, 12 Nov 1995 15:11:57 -0500 Return-Path: Message-Id: <47nm8t$gof at yama.mcc.ac.uk> Organization: Manchester Scientific Instruments Ltd Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!portal.gmu.edu!solaris.cc.vt.edu!newsrelay.netins.net!news-feed-1.peachnet.edu!usenet.eel.ufl.edu!tank.news.pipex.net!pipex!news.mathworks.com!newsfeed.internetmci.com!EU.net!uknet!yama.mcc.ac.uk!usenet References: <47cuhf$l31 at yama.mcc.ac.uk> <47ju9b$ouc at redstone.interpath.net> Newsgroups: sci.astro.fits content-length: 744 From: gerard at mercury.ee.man.ac.uk (Gerard Farrell) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Re: New Windows FITS viewer available for download Date: 7 Nov 1995 13:17:17 GMT In article <47ju9b$ouc at redstone.interpath.net>, heafnerj at mercury.interpath.net says... > >Is there any way I could bribe you to do an OS/2 port of this software? >I've given up on Windows/DOS stuff and there's no native OS/2 FITS >software available anywhere. > > Joe > I asked Mark about this possibility but he just laughed at me, so I guess that means the OS/2 version will come sometime after our FITS for ZX81 version. But seriously, if the demand is there we know an OS/2 programmer who might be coerced into lending a hand, but we couldn't do it for a one off. Can't you just run Windows under OS/2 - I thought it was supposed to better than Windows under DOS! Regards, Gerard Farrell (Mark's boss :) ) From fitsbits-request Tue Nov 14 00:48:03 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3056" "Sat" "11" "November" "1995" "22:20:03" "-0700" "Jeff Bloch" "jbloch at alexis" "" "57" "Thoughts regarding CSC, QSC, and TSC Projections in WCS Document" "^From:" nil nil "11" "1995111205:20:03" "Thoughts regarding CSC, QSC, and TSC Projections in WCS Document" (number " " mark " Jeff Bloch Nov 11 57/3056 " thread-indent "\"Thoughts regarding CSC, QSC, and TSC Projections in WCS Document\"\n") nil] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA29323; Tue, 14 Nov 1995 00:48:03 -0500 Return-Path: Message-Id: Organization: Los Alamos National Laboratory Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!in1.uu.net!newshost.nmt.edu!baervan.nmt.edu!tesuque.cs.sandia.gov!ferrari.mst6.lanl.gov!newshost.lanl.gov!alexis!jbloch Newsgroups: sci.astro.fits content-length: 3054 From: Jeff Bloch Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Thoughts regarding CSC, QSC, and TSC Projections in WCS Document Date: Sat, 11 Nov 1995 22:20:03 -0700 From the comments I heard at the recent ADASS meeting, it seems that the WCS document may soon be ratified as a standard for representing most types of coordinate projections for FITS data. I have a question about the software philosophical approach (I know that FITS is NOT defined by software) in thinking about how the CSC, QSC, and TSC projections fit into the overall scheme. For all of the other all-sky systems in which the whole sky can be represented on a single flat plane, the pixel coordinate in the single flat plane will yield the unique sky coordinate (singularities and boundaries aside). CSC, QSC, and TSC projections display the whole sky on six square "panes" arranged in a sideways "T" for display purposes. But they are stored in the FITS file as a cube of NxNx6 pixel array elements, according to the description, and requires an extra "CUBEFACE" axis description keyword. For all other all sky projections, a single image plane can be extracted from the FITS file, and then the header keywords are used as per the WCS definitions to convert pixel locations to coordinates and vice versa. For these CSC, QSC, and TSC projections, the display software has to do something very different: first pull out the six panes, display them as a sideways "T", and then keep track of a new image coordinate system in this image in which the display software has to determine which "pane" is being considered before the WCS FITS header info can be used to do conversions. I think the issue that I am trying to get clarification on is that the document describes how the QSC, CSC, and TSC all sky image projections should be arranged on the page, but this arrangement does not correspond to the storage convention of a stack of faces or an image cube, unlike all the other projections. A situation which illustrates the need for clarification is if an all sky map in these systems were stored in a FITS file on one flat plane like they are displayed in the document. Does the current WCS definition allow this alternative? I agree that four panes would be wasted but that is how the image would be displayed on a flat screen or page, and in some circumstances may make map manipulation and display more manageable. Any generic software that can deal with FITS file maps in any WCS standard coordinate system will have to face this issue. I think that these projections are valuable for medium resolution sky surveys and allow for simple operations on square arrays for things like point source searches, which for projections like Hammer-Aitoff, are problematic near the map edges due to distortions. -------------------------------------------------------------------------- Jeffrey Bloch Office: (505) 665-2568 Astrophysics and Radiation Measurements Group ALEXIS SOC:(505) 665-5975 Los Alamos National Laboratory FAX: (505) 665-4414 Group NIS-2, Mail Stop D436 e-mail: jbloch at lanl.gov Los Alamos, NM 87545 pager: 104-8005 -------------------------------------------------------------------------- From fitsbits-request Wed Nov 15 01:21:38 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["563" "" "13" "November" "1995" "17:14:31" "GMT" "Immanuel Freedman" "immanuel at mother.com" "<487udn$ooa at pa.mother.com>" "18" "Re: Thoughts regarding CSC, QSC, and TSC Projections in WCS Document" "^From:" nil nil "11" "1995111317:14:31" "Thoughts regarding CSC, QSC, and TSC Projections in WCS Document" (number " " mark " Immanuel Freedman Nov 13 18/563 " thread-indent "\"Re: Thoughts regarding CSC, QSC, and TSC Projections in WCS Document\"\n") ""] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA11429; Wed, 15 Nov 1995 01:21:38 -0500 Return-Path: Message-Id: <487udn$ooa at pa.mother.com> Organization: Mother.COM Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!news.duke.edu!news.mathworks.com!newsfeed.internetmci.com!news.sprintlink.net!news.us.world.net!ns2.mainstreet.net!news.PBI.net!pa.mother.com!news References: Newsgroups: sci.astro.fits content-length: 561 From: "Dr. Immanuel Freedman" Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Re: Thoughts regarding CSC, QSC, and TSC Projections in WCS Document Date: 13 Nov 1995 17:14:31 GMT Jeffrey Historically, COBE used the stack of 6 N*N cubefaces throughout the processing, but a single FITS pane was often constructed for display or preliminary analysis. The only data now extant in this format - to the best of my knowledge - are COBE & EUVE. I would be happy if the data could be stored as a COMPRESSED single pane, so that the ease of point-based processing is maintained and their is no storage penalty. The beauty of the QSC, CSC & TSC systems is that the Jacobian is constant almost everywhere. Dr. Immanuel Freedmn (916) 759 8673 From fitsbits-request Wed Nov 15 10:13:36 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1681" "Mon" "13" "November" "1995" "17:09:55" "-0700" "Jeff Bloch" "jbloch at alexis" "" "42" "Re: Thoughts regarding CSC, QSC, and TSC Projections in WCS Document" "^From:" nil nil "11" "1995111400:09:55" "Thoughts regarding CSC, QSC, and TSC Projections in WCS Document" (number " " mark " Jeff Bloch Nov 13 42/1681 " thread-indent "\"Re: Thoughts regarding CSC, QSC, and TSC Projections in WCS Document\"\n") "<487udn$ooa at pa.mother.com>"] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA15376; Wed, 15 Nov 1995 10:13:36 -0500 Return-Path: Message-Id: Organization: Los Alamos National Laboratory Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!news.duke.edu!news.mathworks.com!newsfeed.internetmci.com!news.sprintlink.net!chaos.aoc.nrao.edu!newshost.nmt.edu!baervan.nmt.edu!tesuque.cs.sandia.gov!ferrari.mst6.lanl.gov!newshost.lanl.gov!alexis!jbloch References: <487udn$ooa at pa.mother.com> Newsgroups: sci.astro.fits content-length: 1679 From: Jeff Bloch Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Re: Thoughts regarding CSC, QSC, and TSC Projections in WCS Document Date: Mon, 13 Nov 1995 17:09:55 -0700 Per Dr. Freedman's comments and some more thinking on the subject, I wonder if a seventh "CUBEFACE" number can be defined in the WCS document which indicates that the FITS image contains the QSC, CSC & TSC projections on a single flat plane in the sideways "T" configuration? I think that there is enough info in the rest of the header to still uniquely transform pixel locations to positions in that case. The interpreting software will have to be a little more clever in determining which face a particular pixel resides on before applying the WCS algorithms, but I think this is very managable. -------------------------------------------------------------------------- Jeffrey Bloch Office: (505) 665-2568 Astrophysics and Radiation Measurements Group ALEXIS SOC:(505) 665-5975 Los Alamos National Laboratory FAX: (505) 665-4414 Group NIS-2, Mail Stop D436 e-mail: jbloch at lanl.gov Los Alamos, NM 87545 pager: 104-8005 -------------------------------------------------------------------------- On 13 Nov 1995, Dr. Immanuel Freedman wrote: > Jeffrey > > Historically, COBE used the stack of 6 N*N cubefaces throughout the processing, but > a single FITS pane was often constructed for display or preliminary analysis. The > only data now extant in this format - to the best of my knowledge - are COBE & EUVE. > > I would be happy if the data could be stored as a COMPRESSED single pane, so that > the ease of point-based processing is maintained and their is no storage penalty. > > The beauty of the QSC, CSC & TSC systems is that the Jacobian is constant almost > everywhere. > > > Dr. Immanuel Freedmn > (916) 759 8673 > > > From fitsbits-request Wed Nov 15 12:42:51 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["5838" "Wed" "15" "November" "1995" "12:42:33" "-0500" "Arnold Rots" "arots at xebec.gsfc.nasa.gov" "<199511151742.MAA01006 at xebec.gsfc.nasa.gov>" "128" "Re: WCS Proposal" "^From:" nil nil "11" "1995111517:42:33" "WCS Proposal" (number " " mark " Arnold Rots Nov 15 128/5838 " thread-indent "\"Re: WCS Proposal\"\n") "<9510260727.AA04917 at grus.rp.CSIRO.AU>"] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA16893; Wed, 15 Nov 1995 12:42:51 -0500 Return-Path: Message-Id: <199511151742.MAA01006 at xebec.gsfc.nasa.gov> In-Reply-To: <9510260727.AA04917 at grus.rp.CSIRO.AU> from "Mark Calabretta" at Oct 26, 95 05:27:58 pm X-Mailer: ELM [version 2.4 PL24beta] Content-Type: text content-length: 5836 From: Arnold Rots Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at nrao.edu, mcalabre at atnf.CSIRO.AU Cc: arots at xebec.gsfc.nasa.gov (Arnold Rots) Subject: Re: WCS Proposal Date: Wed, 15 Nov 1995 12:42:33 -0500 (EST) The G&C WCS proposal pulls together many loose ends in FITS convention land. In the process it formalizes things that everybody has used; unfortunately, the proposed conventions do not always coincide with the various practices in different sectors of the astronomical community. I am not talking about the coordinate systems themselves, but about the auxiliary conventions - in particular the ones dealing with time. I am sure not everybody is fully aware of these implications. Since the WCS proposal offers us a chance to set a number of things straight, we should look very carefully at the conventions proposed by G&C: make sure they follow common practice and, if there are differing practices, define a way to specify these differences. I recognize that G&C really address celestial coordinates and that time only comes in because of the time variable aspects of this, such as precesssion, nutation, etc. However, whether we intend this or not, sooner or later images that have a time stamp will be used by somebody who is interested in time variable phenomena, such as supernovae or proper motions. That being the case, we should make a reasonable effort to make it clear what we are talking about. The problem is that in this area there have been conflicting practices. I feel that we, therefore, should deal with these issues in a general way, trying to conform as much as possible to existing practices. Steve Allen has voiced similar concerns on fitsbits. Another way to put this is that time obviously is being dealt with more systematically in conventions used for specific time series data files. At the very least, we should make sure that the conventions are consistent. As it stands, this is not the case. Against this background, I would like to make two specific proposals. 1. As implied by G&C, the old DATE-OBS keyword does not allow enough flexibility or precision. We should be cognizant, though, that certain sectors of the community have solved this by adding the keywords TIME-OBS, DATE-END, and TIME-END, specifying that DATE-OBS and TIME-OBS refer to the start of the observation(s). 1a. I think it would be good to recognize this practice as a valid way of specifying the precise epoch. 1b. I also think that providing an MJD-based alternative is a good idea, but in order to avoid any confusing as to whether the -OBS appendix refers to the start, middle, or end of an observation, I would propose to use the specific keywords MJD-BEG, MJD-AVG, and/or MJD-END. 2. Mark wrote: > G&C doesn't assume TAI, it prescribes it. That's worse. There are a lot of FITS files out in the community that would otherwise be conforming with the WCS proposal, but on this issue would be invalidated. Besides, I would argue that, FITS being an IAU-accepted standard, it should stick to the official IAU time system: TT (:-). And, as argued by Steve Allen, it would be unwise to force TAI on older archival data. There is also the issue of whether any pathlength correction have been applied; i.e., the time reference frame. I propose that we add the following two keywords: 2a. TIMESYS valid values: TT, TAI, UTC, UT1, ... default: UTC (this is a recommendation based on the suspicion that UTC is the most ubiquitous system in existing files that carry time with sufficient precision to care about this) 2b. TIMEREF valid values: LOCAL, GEOCENTRIC, BARYCENTRIC default: LOCAL (this is partly to make it very clear that there is an important issue here; LOCAL means: at the observatory, whether it is on the earth's surface or meandering through other parts of the solar system) One might argue whether the TASSIGN keyword should be included in this. For the uninitiated: this defines where the time tag is added to the data. It would, for instance, be significant for interplanetary probes: was the time stamp attached by the spacecraft or at the time the telemetry was received on the ground? However, the exceptions to the usual case (time stamps are attached at the observatory) are sufficiently rare that we should not (have to) worry about this. - Arnold Rots Mark Calabretta wrote: > > > On Wed 1995/10/18 10:40:17 -0400, Arnold Rots wrote > in a message to: fitsbits at fits.cv.nrao.edu > > >b. What does "time of observation" mean? The start, the middle, the > >end, a weighted mean? > > As stated in section 3, it's an average. > > In the context of section 3, MJD-OBJ is provided as a timestamp for the > observation as a whole, in particular for the calculation of proper motion in > maps taken at two epochs. Depending on the timescale of the observation, it > could also be relevant to such effects as parallax, precession, nutation, > aberration, and gravitational deflection. As such the precision of MJD-OBS > depends on the duration of the observation - if the observation lasted 1 sec > then MJD-OBJ would have comparable precision. > > Putting it another way, effects which vary significantly during the course > of an observation (for example, a long exposure on a planet) should be > accounted for in the observing process (sharp planet + smeared stars), or > otherwise will result in some sort of blurring in the image (smeared planet + > sharp stars). > > I'm not arguing that start/stop times may not be needed (in the general case > you could have multiple starts/stops), only that definition of the required > keywords is outside the scope of the paper - that being the representation of > celestial coordinates. > > >c. It is unwise to implicitly assume a particular time system. G&C > >assume TAI; I am sure many would interpret it as UTC. The point is > > G&C doesn't assume TAI, it prescribes it. > From fitsbits-request Thu Nov 16 05:43:15 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1224" "Thu" "16" "November" "1995" "09:33:00" "+0100" "Lucio Chiappetti" "lucio at ifctr.mi.cnr.it" "" "26" "Re: Data Compression" "^From:" nil nil "11" "1995111608:33:00" "Data Compression" (number " " mark " Lucio Chiappetti Nov 16 26/1224 " thread-indent "\"Re: Data Compression\"\n") "<47e9tm$rre at pa.mother.com>"] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA25122; Thu, 16 Nov 1995 05:43:15 -0500 Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative In-Reply-To: <47e9tm$rre at pa.mother.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII content-length: 1222 From: Lucio Chiappetti Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Re: Data Compression Date: Thu, 16 Nov 1995 09:33:00 +0100 (MET) On 3 Nov 1995, Dr. Immanuel Freedman wrote: > This is a posting to open discussion about Data Compression within the > FITS Standard. [...] > What do the readers of this group feel about the need for data compression, Personally as an user, it is something I'd never like to see as an "extra feature" in data I'd receive, I'd have to handle or I'd produce, and which shall force usage of "additional software". (I'm quite happy with "standard Unix compress" of "plain FITS files", inefficient it may be for some astronomical applications). This does not mean large projects shall not use it in their archiving, but this shall be made transparent to the user (e.g. include uncompressing ready-to-use "viewer" at the browser end) ---------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR | Ma te' vugl' da' quost avis a ti' Orsign via Bassini 15 - I-20133 Milano | Buttet rabios intant te se' pisnign Internet: LUCIO at IFCTR.MI.CNR.IT | Decnet: IFCTR::LUCIO | (Rabisch, II 46, 119-120) ---------------------------------------------------------------------------- From fitsbits-request Thu Nov 16 23:42:12 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1747" "" "14" "November" "1995" "22:07:13" "GMT" "Immanuel Freedman" "immanuel at mother.com" "<48b3uh$a9j at pa.mother.com>" "47" "FITS Data Compression" "^From:" nil nil "11" "1995111422:07:13" "FITS Data Compression" (number " " mark " Immanuel Freedman Nov 14 47/1747 " thread-indent "\"FITS Data Compression\"\n") nil] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA03968; Thu, 16 Nov 1995 23:42:12 -0500 Return-Path: Message-Id: <48b3uh$a9j at pa.mother.com> Organization: Mother.COM Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!in1.uu.net!jaxnet.jaxnet.com!ns2.mainstreet.net!news.PBI.net!pa.mother.com!news Newsgroups: sci.astro.fits content-length: 1745 From: "Dr. Immanuel Freedman" Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: FITS Data Compression Date: 14 Nov 1995 22:07:13 GMT Colleagues Addressing the issues of FITS data compression: 1) I see data compression & data structures as within the accepted framework of approximation theory, 2) I prefer to think in terms of alternative representations - abstract data types with efficiently-supported operations, 3) Separating the data into an approximated component + compressed residual preserves the original data exactly for future use (per Bill Press & Jim Tilton), 4) Several major NASA projects have already adopted compression methods: Cassini - on-board data analysis & JPEG-ish image compression Galileo - multiple dictionary textual substitution (non-image) Integer Cosine Transform approximation (image) HST - archival browse imaging via HCOMPRESS IHW - archival Previous Pixel compression COBE - packing, spherical harmonic analysis - Vector Quantization of star catalog (Pixel # for direction) - experimental packing, Modified Huffman Codes, Rice codes STS - Block Adaptive Quantization. At least one project is already using k-d trees for range query & set operations within the astronomical data base and last year more than 13 papers referred to some kind of compression (linear quadtree, k-d tree, pyramidal & wavelet transforms...), 5) Major standards (JPEG, MPEG, DICOM, NITFS, SDTS...) are NOT defined by software. An algorithmic definition of a minimal decoder is specified together with accuracy constraints. Any implementation that is decodeable by the standard algorithm to the prescribe accuracy or higher is conformant. Please feel free to email or post questions to this thread, Dr. Immanuel Freedman (916) 759-8673 From fitsbits-request Fri Nov 17 03:42:01 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3690" "Fri" "17" "November" "1995" "19:41:44" "+1100" "Mark Calabretta" "mcalabre at atnf.csiro.au" "<9511170841.AA25324 at grus.rp.CSIRO.AU>" "82" "WCSLIB 2.1" "^From:" nil nil "11" "1995111708:41:44" "WCSLIB 2.1" (number " " mark " Mark Calabretta Nov 17 82/3690 " thread-indent "\"WCSLIB 2.1\"\n") nil] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA05656; Fri, 17 Nov 1995 03:42:01 -0500 Return-Path: Message-Id: <9511170841.AA25324 at grus.rp.CSIRO.AU> content-length: 3688 From: Mark Calabretta Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at nrao.edu Subject: WCSLIB 2.1 Date: Fri, 17 Nov 1995 19:41:44 +1100 Version 2.1 of WCSLIB is now available for collection from either of the following sites ftp.atnf.csiro.au:/pub/software/wcslib/wcslib-2.1.tar.gz fits.cv.nrao.edu:/fits/src/wcs/wcslib-2.1.tar.gz The change log file is appended below. WCSLIB consists of independent C and FORTRAN implementations of the algorithms described in the draft paper "Representations of Celestial Coordinates in FITS" by Eric Greisen and Mark Calabretta. The latest version of this paper, dated 1995/10/30, may be obtained from fits.cv.nrao.edu:/fits/documents/wcs/wcs.all.ps.Z Mark Calabretta ATNF >>> WCSLIB version 2.1 ------------------ The main change of interest to programmers is that of changed call sequences for WCSFWD and WCSREV as described below. * The WCS linear transformations are now implemented in WCSLIB, complete with matrix inverter. The new files are lin.f and test program tlin.f. * Given either the celestial longitude or latitude plus an element of the pixel coordinate a new routine, WCSMIX, solves for the remaining elements by iterating on the unknown celestial coordinate element using WCSFWD. * The high level driver routines WCSFWD, WCSREV, and WCSMIX now apply the full WCS algorithm chain (except for pixel regularization table), including parsing the CTYPEn header cards and computing non-celestial elements of the world coordinate. This required a change to their call sequences which now more closely reflect the sequence of algorithms applied. A new routine, WCSSET, parses the CTYPEn. * The high level driver routines of WCSLIB 1.0 are available as intermediate level drivers CELSET, CELFWD, and CELREV, but note that their call sequences have been extended to return native coordinates. The related parameter array is now called CEL instead of WCS. * The reference point for conic projections is now at the midpoint of the standard parallels. The FITS header cards PROJP1 and PROJP2 now give the half-sum (midpoint) and half-difference of the latitudes of the standard parallels; previously they gave the latitudes of the standard parallels themselves. The change is reflected in this release of WCSLIB. * A bug in CELSET (formerly WCSSET) which misapplied WCS draft equations 7 has been fixed (thanks to Rick Ebert IPAC/JPL and Lindsey Davis, NOAO for reporting this). This affected the computation of Euler angles for the celestial coordinate transformation for those projections which have their reference point away from the native pole. In investigating this a deficiency with the formalism was discovered which led to the introduction of a LATPOLE FITS header card which may be used to disambiguate where CRVAL1, CRVAL2, and LONGPOLE do not uniquely determine the latitude of the native pole. The CEL parameter array (formerly WCS) has been extended to accomodate LATPOLE as CEL(4), and the flag variable is now CEL(5) (formerly WCS(4)). * Default values of LONGPOLE and LATPOLE are now supported and their use is recommended where appropriate. * Numerical precision was being lost near the native poles in the SIN, AIR, and QSC projections and this has been recovered (reported by Lindsey Davis, NOAO). Floating underflows in CSC are now avoided. * Numerical precision was also lost in certain circumstances in the spherical coordinate transformation routines and this has been fixed. * The test programs have been enhanced in various ways and the library has been validated on an SGI machine using both 32-bit and 64-bit compilers. ------------------------------------------------------------------------------ $Id: CHANGES,v 2.3 1995/11/16 07:07:05 mcalabre Exp $ From fitsbits-request Sat Nov 18 09:55:45 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6367" "" "17" "November" "1995" "10:16" "EDT" "Barry M. Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov" "<17NOV199510164533 at nssdca.gsfc.nasa.gov>" "179" "Sources of FITS Information" "^From:" nil nil "11" "1995111714:16:00" "Sources of FITS Information" (number " " mark " Barry M. Schlesin Nov 17 179/6367 " thread-indent "\"Sources of FITS Information\"\n") nil] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA20678; Sat, 18 Nov 1995 09:55:45 -0500 Return-Path: Message-Id: <17NOV199510164533 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!reeve.research.aa.wl.com!decwrl!lll-winken.llnl.gov!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Reply-To: fits at nssdca.gsfc.nasa.gov Newsgroups: sci.astro.fits,news.answers,sci.answers content-length: 6365 From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Sources of FITS Information Date: 17 Nov 1995 10:16 EDT Archive-name: astronomy/fits/info-sources Last modified: 1995/11/17 In addition to the substantive change listed below, there have been a number of editorial revisions. Substantive change this month: o Availability of "Definition of FITS" in *compressed* Postscript -------- Sources of FITS Information Preface This material on sources of Flexible Image Transport System (FITS) information is posted and updated periodically by the FITS Support Office at the NASA Goddard Space Flight Center (GSFC). It discusses where general FITS information, including some answers to frequently asked questions, can be found, and provides sources for detailed information on FITS software and documentation. ------- FITS Support Office The FITS Support Office maintains a library of FITS information accessible from http://www.gsfc.nasa.gov/astro.fits/fits_home.html or ftp://nssdc.gsfc.nasa.gov/pub/fits/. The material available includes o "Definition of FITS," a codification of FITS for the NASA/Science Office of Standards and Technology (NOST), available in LaTeX, uncompressed PostScript, compressed PostScript and (usually) ASCII text (The ASCII text version may not be available for a short while after the announcement of a new version.) o "A User's Guide to FITS", published by the FITS Support Office, in LaTex, and compressed and uncompressed PostScript o Revisions to version 1.0 of the "Definition of FITS" covering the specification of units, that were incorporated into version 1.1 (text) o A current list of the extension type (structure) names registered with the International Astronomical Union FITS Working Group (IAUFWG) (text) o Rules for physical blocking on various media adopted by the IAUFWG (text) In the same directory, but accessible directly via http://www.gsfc.nasa.gov/astro/fits/basics_info.html is the FITS Basics and Information that used to be regularly posted to sci.astro.fits and sci.data.formats under the heading of FITS Basics and Information. It continues to be revised to reflect current FITS developments. It contains the following material: o An overview of FITS o A list of FITS documents o A list of software packages that support FITS, including FITS-image converters for various platforms o A list of on-line FITS resources o A description of the FITS Support Office The hypertext version provides links to many of the documents, software, and network locations listed. The text version provides information on how to obtain much of this material. There is also a hypertext version of the List of Registered Extensions. Links from the Web page and subdirectories of the ftp directory contain o Software developed by the FITS Support Office. o Error test files, primary HDUs useful for testing the ability of software designed to read FITS files to cope with files that have errors or are non-standard. These files should be downloaded in binary form. Printed copies of the material in the FITS directory can be obtained from the Coordinated Request and User Support Office (CRUSO): (Postal) Coordinated Request and User Support Office Code 633 National Space Science Data Center NASA Goddard Space Flight Center Greenbelt MD 20771 USA (Electronic mail) request at nssdca.gsfc.nasa.gov (Telephone) +1-301-286-6695 8:00 A. M. - 4:30 P.M. U. S. Eastern Time (-0500 from the last Sunday in October through the first Saturday in April; -0400 the remainder of the year) When no one is available, messages can be left on voice mail. (FAX) +1-301-286-1635 ------- National Radio Astronomy Observatory (NRAO) A FITS Archive can be found at URL http://fits.cv.nrao.edu/ or at ftp://fits.cv.nrao.edu/fits, located at NRAO. This machine supports a WAIS server named nrao-fits which has an index of all of the FITS-related text files in the archive; the file nrao-fits.src is available at think.com and at ftp://fits.cv.nrao.edu/fits/wais-sources/nrao-fits.src. Some of the more noteworthy materials in this archive are o Drafts of proposed additions to the FITS standard and other drafts that may in the future be formally proposed o Text of any detailed proposals currently being discussed by the FITS committees o A collection of documents on World Coordinate Systems, including the current draft proposal o Conventions specific to particular projects or disciplines o Some code for various environments and Usenet postings about code o Sample data and special test files designed to measure the ability of a FITS reader to handle a wide variety of FITS files o Archives of traffic on FITS-related newsgroups and exploders ------- HEASARC The NASA/Goddard High Energy Astrophysics Science Archive Research Center (HEASARC) Web server at http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html and the anonymous ftp access through ftp://heasarc.gsfc.nasa.gov/fits_info/ provide FITS material. HEASARC has developed a the FITSIO package of software routines for easily reading and writing FITS files, in FORTRAN with a C interface available, portable to a wide variety of machines. There is also the FTOOLS collection of software tools and the VERIFITS FITS conformance verifier. HEASARC software is available directly through http://heasarc.gsfc.nasa.gov/docs/heasarc/tech_res_software.html or ftp://heasarc.gsfc.nasa.gov/fits_info/software/ . The HEASARC server also provides information from the OGIP/HEASARC FITS Working Group, (HFWG) the internal legislative body on FITS-related matters within the Office of Guest Investigator Programs (OGIP) at NASA/GSFC, at http://heasarc.gsfc.nasa.gov/heasarc/ofwg/ofwg_intro.html or ftp://heasarc.gsfc.nasa.gov/fits_info/ . The HFWG has developed a number of FITS conventions that are more specific than the requirements of the FITS standards. Proposed conventions are publicized to the FITS community as a whole, with the goal of collaborative development of a set of conventions that will be accepted throughout the community as well as within OGIP/HEASARC. ------- Direct questions about this posting to Barry M. Schlesinger Coordinator, FITS Support Office Electronic mail: fits at nssdca.gsfc.nasa.gov Telephone: +1-301-441-4205 The FITS Support Office is operated under the guidance of the NASA/GSFC Astrophysics Data Facility. From fitsbits-request Sat Nov 18 19:00:32 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["370" "" "17" "November" "1995" "19:37:59" "GMT" "Xinjian Lu" "xlu at solitaire.cv.nrao.edu" "<48ioan$5qd at vixen.cso.uiuc.edu>" "16" "FITS Browser test page" "^From:" nil nil "11" "1995111719:37:59" "FITS Browser test page" (number " " mark " Xinjian Lu Nov 17 16/370 " thread-indent "\"FITS Browser test page\"\n") nil] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA24506; Sat, 18 Nov 1995 19:00:32 -0500 Return-Path: Message-Id: <48ioan$5qd at vixen.cso.uiuc.edu> Organization: University of Illinois at Urbana Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!sol.ctr.columbia.edu!hamblin.math.byu.edu!acs2.byu.edu!news.cuny.edu!news.sprintlink.net!siemens!news.ecn.bgu.edu!vixen.cso.uiuc.edu!usenet Newsgroups: sci.astro.fits content-length: 368 From: Xinjian Lu Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: FITS Browser test page Date: 17 Nov 1995 19:37:59 GMT Hi, there The FITS Browser test page has been set up at: http://hdf.ncsa.uiuc.edu:4321/fits You can . Retrieve the Images within the FITS file . Convert it to HDF file and use our HDF browser to see more details . See the principal information from the FITS header . .... Feel free please take a look at it and send your comments to me. -xinjian From fitsbits-request Sun Nov 19 16:52:28 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1648" "" "16" "November" "1995" "21:37:43" "GMT" "William Thompson" "thompson at orpheus.nascom.nasa.gov" "<48gav7$33t at post.gsfc.nasa.gov>" "54" "Re: WCS Proposal" "^From:" nil nil "11" "1995111621:37:43" "WCS Proposal" (number " " mark " William Thompson Nov 16 54/1648 " thread-indent "\"Re: WCS Proposal\"\n") "<199511151742.MAA01006 at xebec.gsfc.nasa.gov>"] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA07152; Sun, 19 Nov 1995 16:52:28 -0500 Return-Path: Message-Id: <48gav7$33t at post.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!portal.gmu.edu!europa.chnt.gtegsc.com!news.kreonet.re.kr!usenet.kornet.nm.kr!ames!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson References: <199511151742.MAA01006 at xebec.gsfc.nasa.gov> Newsgroups: sci.astro.fits content-length: 1646 From: thompson at orpheus.nascom.nasa.gov (William Thompson) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Re: WCS Proposal Date: 16 Nov 1995 21:37:43 GMT This is the way that the SOHO project uses time: Calendar dates (segmented time): 1. Are always expressed in UTC 2. Uses the ISO 8601 format as endorsed by the Consultative Committee for Space Data Systems. For example, the current date/time would be expressed as DATE_OBS = 1995-11-16T21:21:15.721Z 3. An underscore is used in the name DATE_OBS to distinguish it from the standard DATE-OBS keyword. 4. Even when not using the CCSDS format, years are always given with four digits to avoid confusion when the year 2000 rolls around. Date formats with different interpretations in Europe and America, such as 11/12/95, are avoided. MJD numbers: 1. Are only used internally to the software. They're never written into the FITS header. 2. Are combined with a second number which is the number of milliseconds into the day. Thus, this is also a segmented time, and is expressed in UTC. This second time-of-day number has a larger maximum value on days containing a leap second. TAI time: 1. Is always unsegmented, i.e. a single number which is the number of seconds since 1 Jan 1958 0h. The above calendar time can be expressed in TAI as OBT_TIME = 1195248104.721 2. Is the only unsegmented time used by us. For either UTC or TAI time, we give both the start and end times of the observation. This is explained in more detail in http://orpheus.nascom.nasa.gov/cds/swnote/time_conversion.ps (or .tex for the original LaTeX file). The software refered to can be found in ftp://sohoftp.nascom.nasa.gov/pub/softops/cds/util/time/ William Thompson From fitsbits-request Sun Nov 19 18:40:50 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1352" "" "18" "November" "1995" "09:06:16" "GMT" "Steve Allen" "sla at umbra.ucolick.org" "<48k7m8$2vi at darkstar.UCSC.EDU>" "31" "Re: WCS Proposal" "^From:" nil nil "11" "1995111809:06:16" "WCS Proposal" (number " " mark " Steve Allen Nov 18 31/1352 " thread-indent "\"Re: WCS Proposal\"\n") "<48gav7$33t at post.gsfc.nasa.gov>"] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA08033; Sun, 19 Nov 1995 18:40:50 -0500 Return-Path: Message-Id: <48k7m8$2vi at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory, Santa Cruz Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!newsxfer.itd.umich.edu!news.uoregon.edu!cuhknntp!hpg30a.csc.cuhk.hk!agate!darkstar.UCSC.EDU!umbra.ucolick.org!sla References: <199511151742.MAA01006 at xebec.gsfc.nasa.gov> <48gav7$33t at post.gsfc.nasa.gov> Newsgroups: sci.astro.fits content-length: 1350 From: sla at umbra.ucolick.org (Steve Allen) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Re: WCS Proposal Date: 18 Nov 1995 09:06:16 GMT In article <48gav7$33t at post.gsfc.nasa.gov>, William Thompson wrote: >This is the way that the SOHO project uses time: >Calendar dates (segmented time): > 1. Are always expressed in UTC This is not useful for data obtained prior to 1972 when UTC was first deployed. >TAI time: > 1. Is always unsegmented, i.e. a single number which is the number of > seconds since 1 Jan 1958 0h. The above calendar time can be > expressed in TAI as It remains to be seen whether the enormous amount of archival astronomical data stored in emulsion on glass plates will be deemed of sufficient value to convert to digital form. But for much of that data the specification of either UTC or TAI as the time system is inappropriate. Early in this century the San Jose railroad station set its clocks by using signals telegraphed down from the Lick Observatory clock on Mt. Hamilton. For all plates taken during that era the observatory was its own source of standard time. Attempts to convert the times of these plates to UTC or TAI for storage in FITS would not be reasonable. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla at ucolick.org Voice: +1 408 459 3046 FAX: +1 408 454 9863 WWW: http://www.ucolick.org/~sla PGP public keys: see WWW From fitsbits-request Mon Nov 20 12:42:57 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["865" "" "18" "November" "1995" "16:22:57" "-0800" "Stephen Walton" "swalton at galileo.csun.edu" "<48ltd1$4qd at galileo.csun.edu>" "23" "Archival times (was: Re: WCS Proposal)" "^From:" nil nil "11" "1995111900:22:57" "Archival times (was: Re: WCS Proposal)" (number " " mark " Stephen Walton Nov 18 23/865 " thread-indent "\"Archival times (was: Re: WCS Proposal)\"\n") "<48k7m8$2vi at darkstar.UCSC.EDU>"] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA16788; Mon, 20 Nov 1995 12:42:57 -0500 Return-Path: Message-Id: <48ltd1$4qd at galileo.csun.edu> Organization: Cal State Northridge Dept. of Physics & Astronomy Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.kei.com!newsstand.cit.cornell.edu!newsfeed.cit.cornell.edu!news.tc.cornell.edu!newsserver.sdsc.edu!nic-nac.CSU.net!csun.edu!galileo.csun.edu!not-for-mail References: <199511151742.MAA01006 at xebec.gsfc.nasa.gov> <48gav7$33t at post.gsfc.nasa.gov> <48k7m8$2vi at darkstar.UCSC.EDU> Newsgroups: sci.astro.fits content-length: 863 From: swalton at galileo.csun.edu (Stephen Walton) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Archival times (was: Re: WCS Proposal) Date: 18 Nov 1995 16:22:57 -0800 In article <48k7m8$2vi at darkstar.UCSC.EDU>, Steve Allen wrote: >It remains to be seen whether the enormous amount of archival astronomical >data stored in emulsion on glass plates will be deemed of sufficient value >to convert to digital form. Peter Foukal just completed a project in which he digitized all the Mount Wilson K-line spectroheliograms, more than 80 years' worth of near-daily images. >But for much of that data the specification >of either UTC or TAI as the time system is inappropriate. Is this really that much of an issue? The difference between UTC and GMT is never more than a few seconds, surely trivial when we're talking about photographic plates with hour or more long exposures. -- Stephen Walton, California State University, Northridge "Be careful what you wish for; you might get it." swalton at csun.edu From fitsbits-request Mon Nov 20 15:12:10 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["781" "" "16" "November" "1995" "20:18:00" "GMT" "Immanuel Freedman" "immanuel at mother.com" "<48g69o$plk at pa.mother.com>" "23" "Re: Data Compression" "^From:" nil nil "11" "1995111620:18:00" "Data Compression" (number " " mark " Immanuel Freedman Nov 16 23/781 " thread-indent "\"Re: Data Compression\"\n") ""] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA18064; Mon, 20 Nov 1995 15:12:10 -0500 Return-Path: Message-Id: <48g69o$plk at pa.mother.com> Organization: Mother.COM Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!portal.gmu.edu!solaris.cc.vt.edu!homer.alpha.net!uwm.edu!cs.utexas.edu!swrinde!newsfeed.internetmci.com!in2.uu.net!jaxnet.jaxnet.com!ns2.mainstreet.net!news.PBI.net!pa.mother.com!news References: Newsgroups: sci.astro.fits content-length: 779 From: "Dr. Immanuel Freedman" Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Re: Data Compression Date: 16 Nov 1995 20:18:00 GMT Colleagues Indeed, this transparency is EXACTLY what I'm proposing and has been implemented as an experiment in the COBE project & NITFS. We should be able to read/write & manipulate data in compressed/structured form without additional overhead. However, we spend YEARS defining our data structures for processing & analysis for many large-scale or archival projects and the overhead of assigning compression methods is very small by comparison. I propose a compressive class library, implemented "underneath" the data base so that we may declare data to be of compressed/structured class or type and the compression/decompression/manipulation takes place through the implemented member functions of the class, Thanks for your input, Dr. Immanuel Freedman (916) 759 8673 From fitsbits-request Wed Nov 22 15:34:32 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["301" "Tue" "21" "November" "1995" "13:20:00" "gmt" "Catherine Lemoine" "clemoin at worldnet.net" "<48sgfu$hqb at aldebaran.sct.fr>" "16" "astronomy thesaurus" "^From:" nil nil "11" "1995112113:20:00" "astronomy thesaurus" (number " " mark " Catherine Lemoine Nov 21 16/301 " thread-indent "\"astronomy thesaurus\"\n") nil] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA12041; Wed, 22 Nov 1995 15:34:32 -0500 Return-Path: Message-Id: <48sgfu$hqb at aldebaran.sct.fr> Organization: Your Organization Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!uwm.edu!lll-winken.llnl.gov!simtel!news.kei.com!newsfeed.internetmci.com!EU.net!Austria.EU.net!newsfeed.ACO.net!swidir.switch.ch!in2p3.fr!univ-lyon1.fr!jussieu.fr!rain.fr!world-net!usenet Newsgroups: sci.astro.fits content-length: 299 From: clemoin at worldnet.net (Catherine Lemoine) Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: astronomy thesaurus Date: Tue, 21 Nov 95 13:20:00 gmt Hi all, I'm developping an MS Access Astronomy Database, and I'm looking for a thesaurus I could implement in it. The Nasa thesaurus is not enought specific, and isn't a hierarchic one. If anyone has an online reference about it, please send an e-mail : clemoin at worldnet.net thanks, sylvain. From fitsbits-request Sat Nov 25 14:45:30 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1774" "" "21" "November" "1995" "02:27:26" "GMT" "Tim Pearson" "tjp at solitaire.cv.nrao.edu" "<48rdee$j4p at gap.cco.caltech.edu>" "37" "Re: WCS Proposal" "^From:" nil nil "11" "1995112102:27:26" "WCS Proposal" (number " " mark " Tim Pearson Nov 21 37/1774 " thread-indent "\"Re: WCS Proposal\"\n") "<199511151742.MAA01006 at xebec.gsfc.nasa.gov>"] nil) Received: by fits.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA14759; Sat, 25 Nov 1995 14:45:30 -0500 Return-Path: Message-Id: <48rdee$j4p at gap.cco.caltech.edu> Organization: California Institute of Technology, Pasadena Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!portal.gmu.edu!solaris.cc.vt.edu!news.mathworks.com!news.kei.com!simtel!lll-winken.llnl.gov!fnnews.fnal.gov!nntp-server.caltech.edu!news References: <199511151742.MAA01006 at xebec.gsfc.nasa.gov> Newsgroups: sci.astro.fits content-length: 1772 From: Tim Pearson Sender: fitsbits-request at fits.cv.nrao.edu To: fitsbits at fits.cv.nrao.edu Subject: Re: WCS Proposal Date: 21 Nov 1995 02:27:26 GMT I have two comments on this thread: (1) I agree that it is unreasonable to insist that all epochs (times) in FITS files be referenced to a single system, e.g., UTC or TAI. In some cases the conversion from the recorded time to the standard system may be unknown (to be determineed from the data, for example). Thus we need a new keyword, like TIMESYS, to specify the time system in cases where it matters. 'UTC' is a reasonable default. (2) I like the use of Modified Julian Date for recording epoch. Unfortunately, though, a large segment of the IAU does not. Here is an excerpt from Resolution No. C3 of Commission 26, 27, 30, and 42 (IAU Information Bulletin No.74, january 1995): "Commissions 26, 27, 30, & 42 of the IAU ... do deplore the introduction of the Modified Julian Day system ; ... recommend the rescinding of resolution No.4 of the XVth general assembly of the IAU that established the Modified Julian Day system,and recommend the continuing use of Julian Day Numbers...." I do not know the background to this; but the argument against MJD seems to be that the odd half-day difference between MJD and JD is "very confusing to the users". This may be true, but it ignores the widespread use of MJD in computer systems. I think that this resolution does not have the status of a resolution of the General Assembly; but it may be brought up in the next General Assembly. (Please, let's not discuss the merits of counting time from Greenwich noon or from Greenwich midnight here!) Tim Pearson, Astronomy Dept 105-24, Caltech, Pasadena, California 91125, USA Internet: tjp at astro.caltech.edu, Pearson_T at caltech.edu NSI-Decnet (SPAN): Deimos::TJP or 15237::TJP Telephone: +1 818 395-4980 FAX: +1 818 568-9352