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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
