Memory size reporting is wrong for <3 dimensions

[MatthewWhiting]

If I try and read a 4096-channel 1D spectrum, this is what gets reported:

Thu Jun 14-09:57-FITStesting>../Duchamp-working/Duchamp-1.1.14 -f orion-freq-1.fits 
Opening image: orion-freq-1.fits
Dimensions of FITS file: 4096
WARNING <Cube Reader> : No rest frequency defined. Using frequency units in spectral axis.
Reading data ... 
 About to allocate 2.62815GB of which 1.82031GB is for the image
Segmentation fault

and here is the offending code:

  void Cube::reportMemorySize(std::ostream &theStream, bool allocateArrays)
  {
    std::string unitlist[4]={"kB","MB","GB","TB"};
    size_t size=axisDim[0]*axisDim[1]*axisDim[2];
    size_t imsize=axisDim[0]*axisDim[1];

Clearly this needs to be more adaptive to the number of dimensions.

[MatthewWhiting]

The problem here seems to stem from the fact we never set the number of axes in the FitsHeader? class - this is always assumed to be 3, so we end up getting junk dimensions incorporated. If we set this in dataIO and getMetadata, the initialisation progresses fine (in [944]). We do, however, end up with bad memory errors that need tracking down.

[MatthewWhiting]

The errors that crop up are related to the issues identified in #148, where 1D searches are not being processed properly.

The immediate problem with this issue, the memory reporting, has been fixed, so I'll close this and defer discussion of 1D searches to #148.