[GRASSLIST:4589] Re: different CELL integer types?

[Glynn Clements]

William K wrote:

> A little more info:
> 
> > I've been importing a bunch of SRTM data recently and noticed that 
> > there seems to be (at least) 2 different integer cell types - 16 bit 
> > and 32 bit.  As imported, one tile takes up a maximum of 2.7MB in the 
> > CELL file, same as the source SRTM data file, and in the GRASS header 
> > file it's type is 1.
> 
> I mean, the 'format:' line in the header file.
> 
> > After I run it thru fillnulls, I round that back to integers with 
> > r.mapcalc, and the CELL file sizes double, and the GRASS header has a 
> > type of 3.
> >
> At least many end up like this.  I looked closer at a few, and it seems 
> that all the tiles with some negative values switch to the larger 
> integer size.  If the whole tile is positive, it stays as 16 bit.  Are 
> grass 16 bit ints not signed, so grass has to use 32 bit ints?  I can 
> mapcalc them to be all positive and they do switch back to 16 bit (or 8 
> bit for those low, flat tiles).

Compressed integer rasters use 1, 2, 3 or 4 bytes, depending upon how
many are needed. However, as you note, negative values always require
4 bytes.

Essentially, the stream of ints is first converted to the external
representation, which is 4 bytes, big-endian, with the topmost bit of
the first byte being a sign bit.

If the raster is uncompressed, the stream of bytes is then written out
to the file.

OTOH, if the raster is compressed, the next step is to determine the
number of bytes required. If the first 1, 2 or 3 bytes of every cell
in a given row are always zero, those bytes will be discarded. As
negative values always have the topmost bit of the first byte set,
they will always require 4 bytes. Consequently, any rows which include
at least one negative value will be written out using 4 bytes per cell
(although the actual data will still be subject to RLE compression).

Unfortunately, this can't be changed without breaking existing raster
maps.

-- 
Glynn Clements <glynn.clements at virgin.net>