[GRASS5] color in GRASS

GRASS GRASS developer
1

As part of my menu updating, I've added some ways to more easily get GRASS output into other programs. This involves using the cell driver, coupled with r.out.tiff, and the PNG driver. These work well, but the output leaves something to be desired. It seems primarily due to a very minimal color-depth supported by both of these routines. I've seen a bit of discussion on this recently, but nothing definitive.

How difficult is it to at least get 24bit color (or perhaps even get wild with 32bit) to these output routines? It would be nice to include GRASS output that looks as nice as the displays do. Currently, my only option for doing this is via xwd.

Michael Barton
______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671

2

Michael Barton wrote:

As part of my menu updating, I've added some ways to more easily get GRASS output into other programs. This involves using the cell driver, coupled with r.out.tiff, and the PNG driver. These work well, but the output leaves something to be desired. It seems primarily due to a very minimal color-depth supported by both of these routines. I've seen a bit of discussion on this recently, but nothing definitive.

How difficult is it to at least get 24bit color (or perhaps even get wild with 32bit) to these output routines? It would be nice to include GRASS output that looks as nice as the displays do. Currently, my only option for doing this is via xwd.

Michael Barton

I think both r.out.tiff, and the PNG driver support 24 bit color output. Glynn recently pointed out that the PNG driver in 5.0 must be compiled with GD 2.x in order to support 24 bit color. I am not familiar with the cell driver you refer to.

--
Richard Greenwood
www.greenwoodmap.com

3

As part of my menu updating, I've added some ways to more easily get
GRASS output into other programs.
This involves using the cell driver, coupled with r.out.tiff, and the
PNG driver. These work well, but the output leaves something to be
desired. It seems primarily due to a very minimal color-depth
supported by both of these routines. I've seen a bit of discussion on
this recently, but nothing definitive.

How difficult is it to at least get 24bit color (or perhaps even get
wild with 32bit) to these output routines? It would be nice to include
GRASS output that looks as nice as the displays do. Currently, my only
option for doing this is via xwd.

for the PNG driver, when you do "d.mon start=PNG", does it say:
"PNG: GRASS_TRUECOLOR status: TRUE"

?

to turn it on, you need to do:
export GRASS_TRUECOLOR=TRUE

These both currently fail by the way -- they probably shouldn't:
GRASS_TRUECOLOR=1
GRASS_TRUECOLOR=true

Now we don't have GD to worry about, should GRASS_TRUECOLOR be set to
TRUE by default?

Hamish

4

As part of my menu updating, I've added some ways to more easily get
GRASS output into other programs.

FYI, I've also just finished a preliminary r.out.mat for exporting maps
to Matlab for plotting/analysis/whatever. It's in 5.3's CVS now..
Specifically I'd be interested in how it works for anyone not on linux &
i386 (64bit / big endian anyone?). If Matlab is out of your price range,
"Octave" which is a Free GPL clone can load these files too, but still
has a couple rough edges. I expect r.out.mat will be upgraded and
r.in.mat will arrive at some point; it's a trickier beast to get right
for all cases.

some notes:

* MAT-File v4 for now, probably v5 later (with variables nicely placed
  in a nested structure)
* Everything should be endian safe, currently untested
* In Matlab, plot with either 'image(map_data)' or something like:
    contourf(map_data), axis ij, axis equal, axis tight, colorbar
* As there is no IEEE value for NaN (AFAIK) for integer maps, GRASS's
  null value is used to represent it for these maps. You'll have to do
  something like this to clean them once they are in Matlab:
    map_data(find(map_data < -1e9)) = NaN;
  Floats and Doubles should work as expected.
* It has to load the entire map into memory before writing, therefore
  it might have problems with *huge* maps. Generally cells*sizeof(type).
  (a 3000x4000 DCELL map uses ~100mb RAM)
* It works.

I hope it is of some use to someone..

regards,
Hamish

5

Michael Barton wrote:

How difficult is it to at least get 24bit color (or perhaps even get
wild with 32bit) to these output routines?

For 24-bit colour, you need either the recent (GD-less) 5.3 PNG
driver, or an older PNG driver which was built with GD 2.x. In either
case, you need to use:

  export GRASS_TRUECOLOR=TRUE

before starting the PNG driver. You will then get 32-bit PNG files: 8
bits of each of red, green, blue and alpha. The alpha channel will be
completely opaque, unless you also use:

  export GRASS_TRANSPARENT=TRUE

in which case any pixels which aren't drawn will be transparent.

I'm not sure what you mean by 32-bit colour. The term is sometimes
used to refer to formats which have an alpha channel, but it can also
refer to 24-bit data with 8 bits of padding so that pixels are aligned
to word boundaries (for performance reasons).

When referring to display depth (e.g. in the Display properties dialog
on Windows), 32-bit corresponds to the latter, i.e. the extra 8 bits
are just padding.

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

6

Hamish wrote:

> As part of my menu updating, I've added some ways to more easily get
> GRASS output into other programs.
> This involves using the cell driver, coupled with r.out.tiff, and the
> PNG driver. These work well, but the output leaves something to be
> desired. It seems primarily due to a very minimal color-depth
> supported by both of these routines. I've seen a bit of discussion on
> this recently, but nothing definitive.
>
> How difficult is it to at least get 24bit color (or perhaps even get
> wild with 32bit) to these output routines? It would be nice to include
> GRASS output that looks as nice as the displays do. Currently, my only
> option for doing this is via xwd.

for the PNG driver, when you do "d.mon start=PNG", does it say:
"PNG: GRASS_TRUECOLOR status: TRUE"

?

to turn it on, you need to do:
export GRASS_TRUECOLOR=TRUE

These both currently fail by the way -- they probably shouldn't:
GRASS_TRUECOLOR=1
GRASS_TRUECOLOR=true

Now we don't have GD to worry about, should GRASS_TRUECOLOR be set to
TRUE by default?

The reason why I originally made it default to off was for backwards
compatibility. All previous versions of the PNG driver created 8-bit
paletted images (either PNG or GIF), and I didn't want the changes to
bite anyone who was relying upon existing behaviour.

Even if 24-bit support is always available, there are valid reasons
for creating a paletted image. One reason is that they will tend to be
smaller, which can be important for images which are to be used on web
sites.

FWIW, it would be nice to have a cleaner mechanism than an environment
variable for selecting 8/24 bit images. A command-line option is one
possibility, but that's potentially messy given the d.mon -> mon.start
-> driver chain. Another option would be creating separate PNG8/PNG24
drivers.

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

7

Well, I THOUGHT this might be the magic solution.

I had GRASS_TRUECOLOR=true in lowercase. With great excitement, I just tried it with GRASS_TRUECOLOR=TRUE (restarting GRASS, of course) and sadly had the same result.

Michael

On Tuesday, March 23, 2004, at 12:24 AM, Hamish wrote:

to turn it on, you need to do:
export GRASS_TRUECOLOR=TRUE

These both currently fail by the way -- they probably shouldn't:
GRASS_TRUECOLOR=1
GRASS_TRUECOLOR=true

______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671

8

Somehow this is just not doing the trick--unless my eyes are deceiving me.

The PNG driver is creating a 44Kb image of the display while xwd is creating a 1.2 Mb image of the same display. The differences in color are clearly apparent. As a test, I am just looking at a greyscale shaded relief map. Will this look paletted as a 24bit PNG? The image created by xwd does not look paletted and closely matches the display monitor image.

Michael

On Tuesday, March 23, 2004, at 04:43 AM, Glynn Clements wrote:

Michael Barton wrote:

How difficult is it to at least get 24bit color (or perhaps even get
wild with 32bit) to these output routines?

For 24-bit colour, you need either the recent (GD-less) 5.3 PNG
driver, or an older PNG driver which was built with GD 2.x. In either
case, you need to use:

  export GRASS_TRUECOLOR=TRUE

before starting the PNG driver. You will then get 32-bit PNG files: 8
bits of each of red, green, blue and alpha. The alpha channel will be
completely opaque, unless you also use:

  export GRASS_TRANSPARENT=TRUE

in which case any pixels which aren't drawn will be transparent.

I'm not sure what you mean by 32-bit colour. The term is sometimes
used to refer to formats which have an alpha channel, but it can also
refer to 24-bit data with 8 bits of padding so that pixels are aligned
to word boundaries (for performance reasons).

When referring to display depth (e.g. in the Display properties dialog
on Windows), 32-bit corresponds to the latter, i.e. the extra 8 bits
are just padding.

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

______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671

9

Michael Barton wrote:

Well, I THOUGHT this might be the magic solution.

I had GRASS_TRUECOLOR=true in lowercase. With great excitement, I just
tried it with GRASS_TRUECOLOR=TRUE (restarting GRASS, of course) and
sadly had the same result.

1. Which versions of GRASS/PNGdriver/GD are you using? The PNG driver
in 5.0.x and 5.3 snapshots prior to 2003-10-31 only support 24-bit
images if built using GD 2.x. 5.3 from 2003-10-31 onwards doesn't use
GD, and always supports 24-bit images.

2. If you're using a suitable PNG driver, did you export the variable
setting?

For bash, you need to use either:

  GRASS_TRUECOLOR=TRUE
  export GRASS_TRUECOLOR
or:
  export GRASS_TRUECOLOR=TRUE

[The latter is a bash extension; the former should work with all
Bourne-style shells.]

For C shells (csh, tcsh), the syntax is:

  setenv GRASS_TRUECOLOR TRUE

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

10

Michael Barton wrote:

Somehow this is just not doing the trick--unless my eyes are deceiving
me.

Are you sure that your version of the PNG driver supports 24-bit
images? I.e. it either uses GD 2.x or is the GD-less version (i.e. 5.3
later than 2003-10-31)?

The PNG driver is creating a 44Kb image of the display while xwd is
creating a 1.2 Mb image of the same display.

The PNG format compresses the image data using zlib; xwd doesn't use
compression.

The differences in color are clearly apparent.

It's probably an 8-bit PNG, then.

As a test, I am just looking at a greyscale
shaded relief map. Will this look paletted as a 24bit PNG?

No.

There isn't actually any need for it to look paletted as an 8-bit PNG
either. 8 bits gives 256 colours; 24 bits gives 256 levels per
component. For a grey-scale image, both are limited to 256 shades of
grey.

However, the display library (libdisplay) which d.rast uses is
somewhat less than optimal in the way in which it configures the
driver's colour table. In many cases, it simply allocates a colour
cube (up to 32x32x32 levels, although with a 256 colour driver, it's
limited to 6x6x6 = 216 colours). OTOH, it uses a special case when it
knows that the image is grey-scale.

The image
created by xwd does not look paletted and closely matches the display
monitor image.

It very much appears that your PNG driver is only creating 8-bit
images.

When the driver is started with "d.mon start=PNG", does it print
either of:

  PNG: GRASS_TRUECOLOR status: TRUE
or:
  PNG: GRASS_TRUECOLOR status: FALSE

If it doesn't print either, it's the old GD-based driver, and it was
built with GD 1.x, which only supports 8-bit images.

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

11

OK,

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

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.

Do I need to change the format to

GRASS_TRUECOLOR=TRUE

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

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.

Michael

On Tuesday, March 23, 2004, at 02:28 PM, Glynn Clements wrote:

Michael Barton wrote:

Well, I THOUGHT this might be the magic solution.

I had GRASS_TRUECOLOR=true in lowercase. With great excitement, I just
tried it with GRASS_TRUECOLOR=TRUE (restarting GRASS, of course) and
sadly had the same result.

1. Which versions of GRASS/PNGdriver/GD are you using? The PNG driver
in 5.0.x and 5.3 snapshots prior to 2003-10-31 only support 24-bit
images if built using GD 2.x. 5.3 from 2003-10-31 onwards doesn't use
GD, and always supports 24-bit images.

2. If you're using a suitable PNG driver, did you export the variable
setting?

For bash, you need to use either:

  GRASS_TRUECOLOR=TRUE
  export GRASS_TRUECOLOR
or:
  export GRASS_TRUECOLOR=TRUE

[The latter is a bash extension; the former should work with all
Bourne-style shells.]

For C shells (csh, tcsh), the syntax is:

  setenv GRASS_TRUECOLOR TRUE

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

______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671

12

Michael Barton wrote:

OK,

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

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.

This seems exactly as a problem I had with debug in grass57. The problem being that this must be declared as a shell (like bash) variable and has nothing to do with .grassrc (GRASS variable). It's also inclined in the fact you have to use 'export GRASS_TRUECOLOR', 'export' being the key word here.
Markus then informed me that he working on a list. So you could add it to your bash of whatever shell (in .bashrc) or issue the command before starting GRASS. (Not sure if I'm completely right here, but that's how I understand it)

Do I need to change the format to

GRASS_TRUECOLOR=TRUE

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

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.

Michael

On Tuesday, March 23, 2004, at 02:28 PM, Glynn Clements wrote:

Michael Barton wrote:

Well, I THOUGHT this might be the magic solution.

I had GRASS_TRUECOLOR=true in lowercase. With great excitement, I just
tried it with GRASS_TRUECOLOR=TRUE (restarting GRASS, of course) and
sadly had the same result.

1. Which versions of GRASS/PNGdriver/GD are you using? The PNG driver
in 5.0.x and 5.3 snapshots prior to 2003-10-31 only support 24-bit
images if built using GD 2.x. 5.3 from 2003-10-31 onwards doesn't use
GD, and always supports 24-bit images.

2. If you're using a suitable PNG driver, did you export the variable
setting?

For bash, you need to use either:

    GRASS_TRUECOLOR=TRUE
    export GRASS_TRUECOLOR
or:
    export GRASS_TRUECOLOR=TRUE

[The latter is a bash extension; the former should work with all
Bourne-style shells.]

For C shells (csh, tcsh), the syntax is:

    setenv GRASS_TRUECOLOR TRUE

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

______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

13

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

This seems exactly as a problem I had with debug in grass57. The
problem being that this must be declared as a shell (like bash)
variable and has nothing to do with .grassrc (GRASS variable). It's
also inclined in the fact you have to use 'export GRASS_TRUECOLOR',
'export' being the key word here.
Markus then informed me that he working on a list. So you could add it

to your bash of whatever shell (in .bashrc) or issue the command
before starting GRASS. (Not sure if I'm completely right here, but
that's how I understand it)

Ok, a couple of things are getting confused here,

There are two kinds of variables:

a) GRASS variables, set in .grassrc and (re)set with g.gisenv. These are
MAPSET, LOCATION_NAME, MONITOR, etc. These don't exist in the shell
unless you specifically create shell variables from them with the command
"eval `g.gisenv`". e.g. "echo $MAPSET" doesn't work (in modern versions
of GRASS), you need to do "g.gisenv get=MAPSET" to see the value.

b) UNIX 'environmental' shell variables, which exist & persist in all
'children' processes if you use the "export" keyword. If you don't use
"export", they only exist in the current version of the shell. You can
set any GRASS specific environmental variables in a '.grass.bashrc' file.

see
http://grass.ibiblio.org/gdp/html_grass5/env_vars.html

Mac OSX 10.2 will generally use csh and "setenv GRASS_TRUECOLOR TRUE"
Mac OSX 10.3 will generally use bash and "export GRASS_TRUECOLOR=TRUE"

I'm not sure if the GRASS start up script checks .grass.bashrc if you
aren't actually running bash. I'd guess it would?

Hamish

14

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@virgin.net>

15

On Wednesday, March 24, 2004, at 06:34 AM, Glynn Clements wrote:

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

This is working for normal PNG output, but doesn't seem to be working for d.dm. I don't see anything in the d.dm script that resets the GRASS_TRUECOLOR variable. However, it shows as being set to TRUE in my environment (run setenv from the shell for csh), but shows as FALSE when d.dm creates PNG output. This is the case even if I set it before starting GRASS.

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.

OK. So what's the point of the GRASS_TRUECOLOR variable in the .grassrc5 file?

The CELL driver is limited to 8 bits; I'm not aware of any plans to
change this.

After a lot of playing around, I finally discovered this (very last line of the man page).

'm not sure if the CELL driver is really useful any
more. FWIW, you can always use the PNG driver plus r.in.png.

Is there some way to redirect output from the PNG driver to r.in.png? It seems to be doing it's thing in the background. If there is, I could perhaps come up with a way to get 24bit tiff output of a display.

______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671

16

Michael Barton wrote:

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

OK. So what's the point of the GRASS_TRUECOLOR variable in the
.grassrc5 file?

There isn't any point to having a GRASS_TRUECOLOR setting in the
~/.grassrc5 file. That doesn't mean that you can't set it; g.gisenv
will let you set whichever variables you wish, regardless of whether
they do anything.

> 'm not sure if the CELL driver is really useful any
> more. FWIW, you can always use the PNG driver plus r.in.png.

Is there some way to redirect output from the PNG driver to r.in.png?

  d.mon start=PNG
  <draw stuff>
  d.mon stop=PNG
  r.in.png input=map.png output=the_map

It seems to be doing it's thing in the background.

Note that the map.png file is only created when you stop the driver.

If there is, I could perhaps come up with a way to get 24bit tiff
output of a display.

Convert map.png to a TIFF file with your preferred graphics package
(Photoshop, GIMP, pngtopnm+pnmtotiff etc).

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