Forwarded on behalf of Simon ---------- Message transmis ----------
Sujet : Re: [gdal-dev] FITS driver update? Date : vendredi 25 mars 2016, 17:29:27 De : Simon Perkins <s...@perkmail.net> À : Even Rouault <even.roua...@spatialys.com>, gdal-dev@lists.osgeo.org CC : Chiara Marmo <chiara.ma...@u-psud.fr> 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? Some random comments: - 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. - 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. - Other changes seem fine since they just add functionality. Sy On Fri, Mar 25, 2016 at 3:09 AM Even Rouault <even.roua...@spatialys.com> wrote: > Bonjour Chiara, > > Not being a specialist of the format, I've no in-depth opinion on the > changes. > I'm mostly surprised that the issue with the raster origin didn't surface > before. Are there references for that ? I've CC'ed Simon Perkins (hoping > his > email is still OK) who is the original author, in case he can comment. > > Regarding scaling (hoping that we talk about the same concepts), there are > 2 > choices: either you apply the offset/scale automatically in IReadBlock() / > IRasterIO() (or the underlying lib does it automatically), or you return > the > raw values and implement the GetOffset() and GetScale() method of > GDALRasterBand (in which case, applying the scale is typically done > afterwards > with gdal_translate -unscale ) > > Best regards, > > Even > > > Hi gdal-list, > > > > I work in a planetary/geology/astronomy lab, and I'm interested in having > > standard and full implementation of FITS format in GDAL. Geographical > > metadata are not yet well defined in FITS, then in the first time I'm > just > > verifying that GDAL works as expected (by astronomers :) ) with FITS > > format. > > > > I have forked the OsGeo project in https://github.com/epn-vespa/gdal/ > and > > addressed three points: 1) FITS origin is defined on the left bottom > > corner of a raster, this is the expected behaviour of FITS processing > > software: I have modified the read and write block direction. 2) Unsigned > > INT 16 and 32 bit are supported by FITS via specific BZERO value > > (https://heasarc.gsfc.nasa.gov/docs/software/fitsio/c/c_user/node23.html > ): > > I have added USHORT and ULONG support. 3) BZERO BSCALE are 'reserved > > keywords' and copying them in the metadata produce inconsistency in > > reverse conversion: a FITS containing BZERO BSCALE is converted to tiff, > > tiff reconverted to FITS, BZERO BSCALE become strings and FITS > > visualization ended up in a 0 raster. I have excluded BZERO and BSCALE > > from metadata keywords. > > > > I haven't figured out yet how to manage scaled values... this will take > > some more time, as geographical conversion. > > > > I'm wondering if those small changes could be tested by the community and > > maybe integrated in the code at some time. > > > > All comments are welcome! > > Thanks for listening, > > Chiara > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > ------------------------------------------------------- -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
