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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
