[GRASS-dev] problem with r.colors on Mac

[Markus Neteler]

On Wed, Apr 11, 2007 at 11:42:57AM +0100, Glynn Clements wrote:
> Michael Barton wrote:
> > >> r.colors gives me a blank (i.e. white) image if I use grey.log. I list the
> > >> color table below. As you can see, it?s just white.
> > >> 
> > >> color table from grey.log
> > >> 
> > >> % 43844 43964
> > >> nv:255
> > >> 43844:254 43963:254
> > >> 43964:255 43964:255
> > > 
> > > This is expected behaviour; grey.log maps a value of x to
> > > 255*log(x)/log(max); the minimum value is ignored. IOW, it *doesn't*
> > > map the minimum value to black, it maps 1 to black (log(1) == 0).
> > > 
> > > I don't know whether this is a good idea, but it is how grey.log has
> > > always behaved.
> > 
> > I had thought that grey.log was a histogram stretch like grey.eq. In the
> > docs, it is called "histogram logarithmic transformed grey scale". In that
> > sense, it seems like it should set the minimum value to black rather than 1.
> > Thanks for the explanation. Would it be difficult to change this to stretch
> > the image histogram rather than values of 1 to n?
> 
> It wouldn't be hard to change it to map log(min) to black. I'm not so
> sure about the histogram equalisation part.
> 
> The main issue is whether someone might be relying upon the existing
> behaviour.

Maybe not too much since it is "only" a color table.
 
> Beyond that, it would be nice to be able to apply histogram
> equalisation and/or logarithmic scaling to any colour table, rather
> than just grey.

Absolutely. A long standing wish...

> The existence of grey.log and grey.eq is the main reason that r.colors
> still has separate color= and rules= options, as those two cannot be
> implemented using rules files.

A simplification would be appreciated, but moreover support for FP map
histogram equalisation etc.

Markus