[gdal-dev] Reading signed 8-bit Erdas Imagine .img (HFA driver)

[Jason Roberts]

I am testing GDAL's ability to read various data formats commonly
encountered by ArcGIS users, with the goal of replacing some of my
ArcGIS-based infrastructure with GDAL. At the moment I am working through
Erdas Imagine .img format.

 

The GDAL HFA driver page http://www.gdal.org/frmt_hfa.html says "It supports
the erdas band types u8, s8, u16, s16, u32, s32, f32, f64, c64 and c128". I
am trying to figure out how to successfully read s8. I have a .img generated
by ArcGIS from this ArcInfo ASCII grid:

 

ncols 3               

nrows 3

xllcorner 0.0

yllcorner 0.0

cellsize 1.0

-127 63 126

-127 63 126

-127 63 126

 

But I am getting this with the Python bindings and 1.6.0:

 

>>> dataset = gdal.Open(r'C:\Temp\NoDataTest\IMG\WithoutNoData\int8a.img')

>>> band = dataset.GetRasterBand(1)

>>> band.ReadAsArray()

array([[129,  63, 126],

       [129,  63, 126],

       [129,  63, 126]], dtype=uint8)

 

I expected an array with dtype int8 and the first column to have values
-127. 

 

I suspect this problem is here in hfadataset.cpp:

 

    switch( nHFADataType )

    {

      case EPT_u1:

      case EPT_u2:

      case EPT_u4:

      case EPT_u8:

      case EPT_s8:

        eDataType = GDT_Byte;

        break;

 

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.

 

Thanks for your help,

 

Jason

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090831/9905a091/attachment.html