[fitsbits] Maximum number of extensions

[Peter Teuben]

> 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?

what's there from preventing making your own keyword in the pHDU
and call it NUMHDU.   cfitsio can do this in-place, since the size
of the pHDU won't change. I suspect it doesn't have to recopy the whole
thing, since it only has to update a fixed location, like direct access.
Probably should work well. The miriad software does a similar trick
with visibility data, every now and then it writes the current length
to another header item, so that dataloss in minimized in case of
a crash or so.

I'm not sure if I was one of the pressure points on Bill to get rid of the
1000, but we quickly ran into that problem with one of our digital
spectrometers, being afraid to loose data, we wrote out each scan as a
separate HDU/bintable, so over the course of an observing session we  rapidly
were banging against 1000, and we had to make a private modification
to cfitsio to handle 10000, which was enough for us (for now). 

peter