Jason Roberts wrote:
GDAL only supports unsigned 8-bit integers (GDT_Byte). That is the
ultimate difficulty but it has been worked around before in other
drivers. Is there any possibility that the HFA driver could be changed
to work like the AIG driver, so that S8 data is returned as GDT_Int16
instead of GDT_Byte?
If not, how exactly does this driver support S8 .img files? If I had
some way of detecting that it was S8, I guess I could fix it up by
casting the array to int16 and subtracting 256 from all cells with
values > 127. But I know of no way to detect that it is S8 except by
calling an ArcGIS API or trying to parse .img format myself. Neither of
those are a good solution.
Jason,
GDAL does not treat signed bytes as a proper data type (with a GDT_* code)
but it does support setting the PIXELTYPE metadata item in the IMAGE_STRUCTURE
domain to SIGNEDBYTE per RFC 14:
http://trac.osgeo.org/gdal/wiki/rfc14_imagestructure
This gives application code an opportunity to do something special with the
data - such as casting to a signed byte type. Some CreateCopy()
implementations for formats with signed byte support also look for this
metadata and translate the data as signed bytes.
We could in theory upgrade such bands to GDT_Int16 but it would require
quite a bit of messy code and it would not be in line with the approach
in other drivers.
Note, the HFA driver already returns the PIXELTYPE SIGNEDBYTE metadata
as do a few other drivers where appropriate.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [email protected]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev