[gdal-dev] Fwd: Re: FITS driver update?

[Even Rouault]

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 <sy at perkmail.net>
À : Even Rouault <even.rouault at spatialys.com>, gdal-dev at lists.osgeo.org
CC : Chiara Marmo <chiara.marmo at 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.rouault at 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