|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
On Sat 2007-08-18T16:30:24 -0400, Craig Markwardt hath writ:
Another proposed change, the case of the EXTEND keyword being made optional, will also impose a software-change burden. Software which previously relied on that keyword will now be required to check for the presence of extensions in a different way. Isn't this horse already pretty far out of sight of the barn, too? -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m |
#22
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
Steve Allen writes: On Sat 2007-08-18T16:30:24 -0400, Craig Markwardt hath writ: Another proposed change, the case of the EXTEND keyword being made optional, will also impose a software-change burden. Software which previously relied on that keyword will now be required to check for the presence of extensions in a different way. Isn't this horse already pretty far out of sight of the barn, too? I'm not sure which is the horse and which is the barn. Has EXTEND ever been optional for files with extensions? Craig |
#23
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
On Mon 2007-08-20T01:00:32 -0400, Craig Markwardt hath writ:
Has EXTEND ever been optional for files with extensions? Has EXTEND ever been relevant for FITS files at all? I would like to know of any applications which actually use it. If I am not mistaken the CFITSIO toolkit always sets EXTEND to true. In my experience there are two types of reading applications: Apps which don't know what they would do with an extension, don't even look for them, and don't care whether EXTEND is set or not. Apps which know that they are expecting extension(s), don't care whether EXTEND is set or not, and may fail with an unhelpful message if they do not find the particular extension(s) they seek. So what applications are there, other than fv, which do not a priori know what they are expecting when they read a FITS file? In particular, are there any which, when they find extensions, actually take different actions based on what they discover? These are the sorts of questions which prompted the FITS MIME effort, and the sorts of questions which we realized we could not address there. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m |
#24
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
Steve Allen wrote:
So what applications are there, other than fv, which do not a priori know what they are expecting when they read a FITS file? In particular, are there any which, when they find extensions, actually take different actions based on what they discover? The catfits task in the STSDAS package under IRAF prints a "table of contents" for a FITS file. If the EXTEND keyword is absent, catfits does not look for extensions. I won't defend the EXTEND keyword; I'm just answering your question by giving an example. If an application expects data in one or more extensions, there isn't much point in the application first checking the EXTEND keyword. Phil |
#25
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
The SECCHI instrument on the STEREO mission produces some files with table
extensions, and other files which don't. The value of the EXTEND keyword is set to either T or F to account for this. Steve Allen wrote: On Mon 2007-08-20T01:00:32 -0400, Craig Markwardt hath writ: Has EXTEND ever been optional for files with extensions? Has EXTEND ever been relevant for FITS files at all? I would like to know of any applications which actually use it. If I am not mistaken the CFITSIO toolkit always sets EXTEND to true. In my experience there are two types of reading applications: Apps which don't know what they would do with an extension, don't even look for them, and don't care whether EXTEND is set or not. Apps which know that they are expecting extension(s), don't care whether EXTEND is set or not, and may fail with an unhelpful message if they do not find the particular extension(s) they seek. So what applications are there, other than fv, which do not a priori know what they are expecting when they read a FITS file? In particular, are there any which, when they find extensions, actually take different actions based on what they discover? These are the sorts of questions which prompted the FITS MIME effort, and the sorts of questions which we realized we could not address there. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m _______________________________________________ fitsbits mailing list http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits -- William Thompson NASA Goddard Space Flight Center Code 671 Greenbelt, MD 20771 USA 301-286-2040 |
#26
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
On Monday 20 August 2007 07:00, Craig Markwardt wrote:
Has EXTEND ever been optional for files with extensions? At the time when extensions were introduced, most readers would not even think of looking for them. Thus, it was important that users could look on their primary header and see (and then complain) that there were extension data available in the file which were not detected by the local reader. Now that extensions are common and most readers would check, I see little problem in making EXTEND optional. The ESO readers, I know of, all would scan the full file no matter what. Preben |
#27
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
Hate to say this, but we're starting to have a generation
problem. I got into FITS at the time of binary arrays, not at the start (so I'm in the 'middle; generation). But at this time we have people asking about how a FITS file is different from an image and people asking about FITS files with and without extensionsi - do we still have FITS files without extensions? It being "once FITS always FITS" I object to making the EXTEND keyword optional. Aloha, Maren On Tue, 21 Aug 2007, Preben Grosbol wrote: On Monday 20 August 2007 07:00, Craig Markwardt wrote: Has EXTEND ever been optional for files with extensions? At the time when extensions were introduced, most readers would not even think of looking for them. Thus, it was important that users could look on their primary header and see (and then complain) that there were extension data available in the file which were not detected by the local reader. Now that extensions are common and most readers would check, I see little problem in making EXTEND optional. The ESO readers, I know of, all would scan the full file no matter what. Preben _______________________________________________ fitsbits mailing list http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits |
#28
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
On Fri, 17 Aug 2007, Steve Allen wrote:
I would like to see the IAUFWG establish a registry (in the sense of the IANA) wherein all the documented FITS conventions have unique names, and I would like to see a series of keywords which can be placed in the PHDU to assert that "this FITS file employs these named conventions". I sort of endorse this statement (not really familiar with the requirements of a IANA registry, and we should consider feasibility w.r.t. current IAUFWG convention registry) ... but yes, there should be some univocal recipe (based on one or more keywords, sort of glorified "magic" file ... something like this was discussed when talking about the establishment of the current registry) to assert that a given FITS extension employs these named conventions (I do not see why this shall be in the PHDU and apply to the entire FITS file, as some conventions may apply only to some extensions). Lucio Chiappetti -- ---------------------------------------------------------------------- is a newsreading account used by more persons to avoid unwanted spam. Any mail returning to this address will be rejected. Users can disclose their e-mail address in the article if they wish so. |
#29
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
On Tue, 21 Aug 2007, Maren Purves wrote:
Hate to say this, but we're starting to have a generation problem. I got into FITS at the time of binary arrays, not at the start (so I'm in the 'middle; generation). Hmm ... if nearly contemporary to FITS (I graduated 1 month before FITS's birthday :-)) but of course wasn't in the Deciding Bodies that early (or as early as generalized extensions were introduced). do we still have FITS files without extensions? I guess there will be plenty, those which the programmer-type people will ask "how different with JPEG". Seriously, there is no need to use an extension for a plain image or even a datacube. It being "once FITS always FITS" I object to making the EXTEND keyword optional. The "fault" about EXTEND was in its original definition. The keyword EXTEND=T was present "if the FITS file MAY contain extensions" and it being equal to T did "not imply extensions be present". As such it resembles a bit the present versioning/no-versioning discussion. But it was/is pretty useless to tell whether the file really contains extensions. So the safest way taken by FITS readers was to scan anyhow after the PHDU for named XTENSION kwds. I doubt there are many readers around which won't do that is EXTEND is absent. -- ---------------------------------------------------------------------- is a newsreading account used by more persons to avoid unwanted spam. Any mail returning to this address will be rejected. Users can disclose their e-mail address in the article if they wish so. |
#30
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
Maren Purves a écrit :
- do we still have FITS files without extensions? Yes we do :-) For instruments that naturally generate measurements on a regular 2D grid (such as simple optical/IR imagers with a single CCD/IR sensor) the pre-extensions standard works perfectly and they typicall use it. Several (mostly older) CFHT instruments do that, and I expect most optical observatories to be in a similar situation. If extensions ever were made compulsory those instruments could of course put their data in an IMAGE extension, but there is little point in doing that. It being "once FITS always FITS" I object to making the EXTEND keyword optional. I don't particularly object to the EXTEND change (which doesn't invalidate any old FITS file, just gives a (very) small added flexibility to new ones, so doesn't break the "once FITS always FITS rule"), but don't see its point either. Of course it saves 80 bytes in every FITS file, but I suppose there must be some stronger reason :-) |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[fitsbits] Proposed Changes to the FITS Standard | Mark Calabretta | FITS | 0 | August 2nd 07 09:39 AM |
[fitsbits] Proposed Changes to the FITS Standard | Steve Allen | FITS | 0 | August 1st 07 06:08 PM |
[fitsbits] Proposed Changes to the FITS Standard | Thierry Forveille | FITS | 0 | August 1st 07 04:51 PM |
[fitsbits] Proposed Changes to the FITS Standard | William Pence | FITS | 0 | July 27th 07 07:38 PM |
[fitsbits] Proposed Changes to the FITS Standard | Rob Seaman | FITS | 0 | July 24th 07 07:21 PM |