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

[Glynn Clements]

Michael Barton wrote:

> >> I just have been having problems with r.colors on the Mac. This is from cvs
> >> source code I downloaded and compiled today.
> >> 
> >> r.colors will crash the GUI when I run it with either grey.eq or grey.log as
> >> the color map. It seems to calculate the equalization stretch OK with
> >> grey.eq, though, in spite of crashing.
> > 
> > My guess is the gronsole code. Running r.colors from the command line
> > with GRASS_MESSAGE_FORMAT=gui doesn't show anything unusual.
> > 
> > As I've mentioned before, the use of "read" with non-blocking I/O is
> > likely to be problematic if the program generates output quickly. If
> > there's a problem here, r.colors is a good candidate to trigger it as
> > it will generate percentage output relatively fast.
> 
> This hasn't happened before for me with r.colors. Other things that run
> faster haven't given me problems before, though this has happened with
> v.to.rast. Your explanation may well be the correct one. But I wonder why it
> is a problem now and not previously (i.e., a month ago).
> 
> If read is a problem, what is an alternative?

gets.

Gronsole::output_to_gronsole is written on the assumption that it will
get complete lines. Gronsole::readout tries to do this, but fails to
allow for the fact that "read" may return arbitrary chunks of data
(i.e. partial lines).

If the stream is in non-blocking mode, gets will return an empty
string if a complete line isn't available. The fblocked function can
be used to distinguish this from the case where the process wrote a
blank line. Also, after this case occurs, another readable event won't
be generated for the stream until a complete line is available.

> I don't understand the
> gronsole code very well (didn't write it), but I might be able to fix a
> specific issue like this.

Gronsole::readout is the relevant function.

> >> 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.

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.

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.

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