[GRASS5] color in GRASS - solved for PNG but I don't know why

[Glynn Clements]

Michael Barton wrote:

> I've solved the problem but don't know why it is a problem. I've been 
> messing with this all day with various suggestions. I'm copying this to 
> the list in case it indicates an obscure bug that needs fixing.
> 
> Here is the situation:
> 
> I have a
> 
>      GRASS_TRUECOLOR: TRUE
> 
> statement in my .grassrc5 file (exactly this format, following the 
> format for other statements in the file)
> 
> When I ran a g.gisenv, it said that
> 
>     GRASS_TRUECOLOR=TRUE
> 
> (exactly this format).

Neither of these are relevant. The PNG driver looks for an
envioronment variable named GRASS_TRUECOLOR, not a GRASS variable. 
~/.grassrc5 and g.gisenv deal with GRASS variables, not environment
variables.

> When I typed d.mon start=PNG it responded
> 
>     PNG: GRASS_TRUECOLOR status: FALSE
> 
> (exactly this format). So, I have the right version of PNG and the 
> correct statement in .grassrc5, but PNG didn't know to use truecolor.
> 
> So, I tried to set this variable at the shell level using
> 
> setenv GRASS_TRUECOLOR TRUE
> 
> (quitting GRASS first, then restarting)

OK; although you can also set that variable within GRASS, so long as
it's set before starting the PNG driver.

> Now GRASS creates a 332 Kb PNG file that DOES look like the screen. 
> Clearly it IS now producing a 24 bit graphic image. Apparently, the 
> truecolor statement in the .grassrc5 file is not parsing correctly on 
> my system.

~/.grassrc5 isn't relevent here.

> Do I need to change the format to
> 
> GRASS_TRUECOLOR=TRUE

No.

> --using an equals sign instead of a colon? Is this some other kind of 
> error. It SEEMS that my other settings in .grassrc5 are being read 
> correctly (but now I'm unsure).

Some settings are controlled by GRASS variables, others by environment
variables. The PNG driver's true-colour setting is controlled by an
environment variable.

In some cases, there is a clear reason for preferring one over the
other; in other cases, either could be used. Some specific factors
are:

1. If the variable needs to be changed by a program, it has to be a
GRASS variable, as a process cannot change the environment of an
existing process. A concrete example is the MONITOR variable, which is
changed by "d.mon select=...".

2. If the variable is used by a non-GRASS program it has to be an
environment variable. E.g. GRASS uses some external programs which use
the PAGER environment variable (e.g. "man", which is used by
g.manual).

3. If it might be desirable for a given variable different to have
different values for different invocations of a program, it needs to
be an environment variable, as there is only one ~/.grassrc5 file but
each process has its own set of environment variables. E.g. the
GRASS_WIDTH and GRASS_HEIGHT variables which control the initial size
of a monitor are environment variables, so that you can do e.g.:

	GRASS_WIDTH=640 GRASS_HEIGHT=480 d.mon start=x0
	GRASS_WIDTH=256 GRASS_HEIGHT=256 d.mon start=x1

> I tried tiff output using my script to send the display to the 
> cell_driver and then to r.out.tiff. However, it still looks 8bit. 
> Apparently, it is not convinced by the truecolor environment variable 
> yet.

The CELL driver is limited to 8 bits; I'm not aware of any plans to
change this. I'm not sure if the CELL driver is really useful any
more. FWIW, you can always use the PNG driver plus r.in.png.

-- 
Glynn Clements <glynn.clements at virgin.net>