Glynn,
should this go into GRASS 6? Looks like a potential speedup for large
color tables, say, to avoid them.
?
Markus
On Tue, May 18, 2010 at 1:28 AM, <svn_grass@osgeo.org> wrote:
Author: glynn
Date: 2010-05-17 19:28:45 -0400 (Mon, 17 May 2010)
New Revision: 42277
Modified:
grass/trunk/lib/raster/color_xform.c
Log:
Compact colour table: only add another rule when the colour changes
Modified: grass/trunk/lib/raster/color_xform.c
--- grass/trunk/lib/raster/color_xform.c 2010-05-17 22:19:43 UTC (rev 42276)
+++ grass/trunk/lib/raster/color_xform.c 2010-05-17 23:28:45 UTC (rev 42277)
...
Markus Neteler wrote:
should this go into GRASS 6? Looks like a potential speedup for large
color tables, say, to avoid them.
Maybe.
It does change the behaviour slightly, but situations where the
difference would be visible are unlikely to occur in practice.
Specifically, if previously you had:
value 10 11 12 13 14
colour 0 5 5 5 10
now it would elminate some values to give:
value 10 11 14
colour 0 5 10
effectively stretching the transition.
This can occur either if the source colour table has discontinuities
(which seems an odd choice for use with equalisation), or the the
histogram is extremely spikey i.e. specific category values constitute
a significant proportion of the data, with adjacent values having
negligible counts.
Making it preserve the colour table exactly would take some more work.
It would need to consider three values at a time, eliminating the
middle value whenever its colour is identical to the first and last
values.
--
Glynn Clements <glynn@gclements.plus.com>
Markus wrote:
should this go into GRASS 6? Looks like a potential speedup
for large color tables, say, to avoid them.
?
I am really quite concerned about the effects of this change.
Please don't backport it to gr6 as the default action.
Hamish
(more later, badly lacking time right now)