[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

[Glynn Clements]

GRASS GIS wrote:

>  Final test which seems to show that there is something wrong: r.in.gdal
>  in=test.tif out=test: import takes a very long time and creates a huge
>  colr table file:
> 
>  % 0 65535
>  0:0
>  1:0
>  2:0
>  3:0
>  4:0
>  5:0
>  6:0
>  7:0
>  8:0
>  9:0
>  10:0
>  11:0
>  [...]
>  65535:0 65535:0
> 
>  Whereas the original colr file only contains this:
>  % 334 460
>  334:0:191:191 359.2:0:255:0
>  359.2:0:255:0 384.4:255:255:0
>  384.4:255:255:0 409.6:255:127:0
>  409.6:255:127:0 434.8:191:127:63
>  434.8:191:127:63 460:20
> 
>  The display of test also takes a long time, I suppose because of this long
>  colr table.

r.out.gdal stores the colour table in a sequence of metadata items
named COLOR_TABLE_RULES_COUNT and COLOR_TABLE_RULE_RGB_<num>.

However, r.in.gdal ignores these settings. It just creates a colour
table which matches the palette of the imported file.

Although that's arguably the right thing to do]1], a 64K-entry table
is less than ideal. For a start, creating a colour table is O(n^2), as
each new entry is checked for overlap against all existing entries.

[1] If the data has been modified, the metadata items may have been
passed through untouched, so will no longer be correct.

One option is to provide an option to create the colour table from the
metadata items rather than from the palette. Another is to
"reverse-engineer" the colour table from the palette, replacing
sequences of palette entries with a single rule.

The latter is preferable, but it's non-trivial, particularly if you
consider that the original rules may have used non-integer endpoints.

-- 
Glynn Clements <glynn at gclements.plus.com>