[gdal-dev] FITS driver update?

[Chiara Marmo]

Hi Simon,

> It's been well over a decade since I last looked at this code, and I
> originally wrote it for a non-astronomy use-case (we just needed a format
> that could handle multi-spectral imagery), so it's entirely possible it
> doesn't quite align with normal astronomy conventions... My main concern
> though is that making these changes would likely break existing code that
> uses this library. Maybe you could add a param to enable a "flip" mode that
> flips the y-axis while keeping the current default behavior?

I did a (quick, maybe incomplete) research on which software uses gdal to read FITS and the only one I have found, beeing largely used , is QGIS. I do not know a lot of peaple (excepting me :) ) using QGIS to display FITS... that's why I'm working on that. 

> - I tend to think of image origin as a display issue. It's not clear to me
> that GDAL implies any particular origin for its coordinate system, so it
> seems simpler to me to have the first row of data in the FITS file
> correspond to the first row of data from GDAL's POV as well. For that
> matter, it's not clear to me that FITS implies a specific origin -
> displaying the first pixel in the lower left is more of a convention? It's
> true that converting to a TIFF and then displaying the TIFF in the usual way
> flips the image, but I'd probably tackle that by simply flipping the TIFF
> image vertically after conversion rather than messing around with the data
> ordering. Just my 2c.

Indeed, the standard description of FITS says that for raster the origin is bottom left pixel, and its center is 1,1: those two definitions are important when georeferencing a raster.
I'm working at the inteface between planetary mappers , using GIS software and GDAL, and astronomers ,using traditional FITS visualization software (like Aladin or ds9): FITS images are sometimes raw data, without geographical information, the results is that GDAL based tools display flipped FITS with respect to astronomical software. Each time I have to explain that there is a different convention in FITS and generic raster description in computer sciences and direction doesn't matter... but users do forget fast...

I need homogeneity in visualization for the two communities could talk together... :)   

> - Implementing the BSCALE and BZERO via GetOffset() and GetScale() sounds
> like a good idea, in which case, it's fine to exclude those keywords from
> the metadata.

Yep, thanks Even for suggestion.

Chiara

-- 
Chiara Marmo
Ingénieur de Recherche GEOPS - Paris Sud-11
Bât 509
Tel: +33 (0)1 69 15 49 03