A Space & astronomy forum. SpaceBanter.com

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » SpaceBanter.com forum » Astronomy and Astrophysics » FITS
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

FITS long integer support (was [fitsbits] ADASS FITS BoF onSunday)

Thread Tools Display Modes
Old October 20th 04, 03:18 PM
Thomas McGlynn
external usenet poster
Posts: n/a
Default FITS long integer support (was [fitsbits] ADASS FITS BoF onSunday)

Clive Page wrote:

On Tue, 19 Oct 2004, William Pence wrote:

Please let me know if you have ideas for other topics (regardless of
whether you plan to attend the meeting).

I shall not be at ADASS, unfortunately, but one topic raised on this list
recently is of interest to me: whether we can overcome the limits implied
by 32-bit integers.

With the help of Bill and his colleagues at GSFC I was able to build a
version of cFITSIO which handled files of over 2 GB, but I think a 2
gigarow limit in tables may be enforced by the presence of implicitly
32-bit signed integers for NAXIS2 (etc.) in the headers. It would be
interesting to know whether any other people have an interest in extending
FITS beyond the 32-bit limit, and whether they have ideas to help solve


Hi Clive,

There are two questions here that can get confused. I'm not
sure which you are interested in.

I don't think there is any implication that header keywords are limited
to what is permitted in 4 byte integers, i.e.,

NAXIS1 = 10000000000
NAXIS2 = 2

is perfectly legal for describing a 20 GB file. There isn't a problem
in the FITS standard with this, but some (many?) FITS readers will
have trouble doing anything with this data. This doesn't have anything
to do with longwords directly but typically with internal limits
in compilers and operating systems.

There are also three changes to the FITS standard that would be needed
to accommodate long integers.


would indicate arrays of 8 byte integers in images.

TFORMxx = 'K'

would indicate arrays of 8 byte integers in tables.

TFORMxx = 'Q'

would indicate use of longwords in pointers in variable length columns.

The first two are already supported in a number of FITS readers (CFITSIO I think plus
at least one IDL and one Java implementation at least). I don't know that any implementation
support longs in variable length arrays. Currently the only legal way to write 8 byte
integers is in ASCII tables where integers of arbitrary size can be written -- though
I doubt many readers can read these without losing precision.

So is the question that we want to improve the quality of FITS readers (and writers)
so that they can read and write files that are already legal, or do we wish
to extend the standard to accommodate a new type?


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[fitsbits] Start of the FITS MIME type Public Comment Period William Pence FITS 8 June 17th 04 06:08 AM
[fitsbits] problems with fits readers Eric Greisen FITS 0 June 4th 04 08:15 PM
[fitsbits] Happy Birthday, FITS! Don Wells FITS 0 March 28th 04 01:58 PM
Reading floating point FITS files John Green FITS 34 November 29th 03 12:31 AM
[fitsbits] BLANK keyword misinterpretation Steve Allen FITS 4 November 21st 03 04:42 PM

All times are GMT +1. The time now is 05:12 AM.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright 2004-2020 SpaceBanter.com.
The comments are property of their posters.