[fitsbits] Maximum number of extensions

[Clive Page]

>Richard West wrote:
>> 
>> Perhaps a daft question, but not one I've found an answer too in any of the
>> FITS documentation I've looked in. Is there a formal limit to the number of
>> extensions (HDUs) in a FITS file?

In article <mailman.1053378241.14039.fitsbits at listmgr.cv.nrao.edu>,
William Pence  <pence at tetra.gsfc.nasa.gov> wrote:

>There is nothing in the FITS Standard definition document that limits the
>number of extensions in a FITS file.  CFITSIO used to only support up to
>1000 HDUs in a FITS file, which is why some of the ftools tasks have this
>limit.  In July 2002 CFITSIO was modified to support an unlimited number of
>HDUs in a FITS file.

That flexibility is good, I guess, but perhaps it would be better if you
didn't tell everyone. :-)  I really think the use of huge numbers of HDUs
ought to be discouraged.  There is no index to them, so the only way a
reading program has of finding a specific HDU is to scan the header lines
of every preceding HDU.  Similarly the only way of finding the total
number of HDUs in a FITS file is to move to the "next" HDU and find that,
after a few thousand or whatever, it doesn't exist. You could, I suppose
design and insert your own index near the front, but of course if that's a
table it can't be in the primary HDU.  Wouldn't it be better to just have
lots of files, each with one or two HDUs?   Modern file systems cope so
much better with data access, don't they?


-- 
Clive Page   cgp <at sign> le.ac.uk