[GRASSLIST:2270] Poor quality PNG file driver output

GRASS GRASS user
1

Hi all,

I'm having trouble outputting images from the PNG file driver - the quality of the resulting .png images is very poor. I put together the maps that I want to output using:

d.mon start=PNG
d.mon select=PNG
d.rast dem.relshade
d.mon stop=PNG

This does NOT give me what I'd see in the grass monitor if I'd used d.mon start=x0 instead of the PNG driver. The colors in the image are interpolated, not enough shades of grey, for instance, as if the color palette was very small. Lots of blotchy colors, and no smooth transitions and gradients.

Markus, in your book you make the following reference on p. 187 in the section 8.1.3 on "Monitor output to PNG and HTML files"

"If the Gd2.x library is installed the driver supports true color output"

Because my images look like they don't have enough colors, I assumed this was the problem. So, I installed the gd 2.0.9 library and tested it to make sure it was working. I get the same poor quality images. I AM setting the GRASS_TRUECOLOR=TRUE environment variable.

What's going on here? Why is the output from PNG file driver so different from the output from the GRASS monitor?

Thanks in advance for any help.

Jason

Jason Horn
Boston University Department of Biology
5 Cumington Street Boston, MA 02891

jhorn@bu.edu
617 353 6975

2

I'm having trouble outputting images from the PNG file driver - the
quality of the resulting .png images is very poor. I put together the
maps that I want to output using:

d.mon start=PNG
d.mon select=PNG
d.rast dem.relshade
d.mon stop=PNG

This does NOT give me what I'd see in the grass monitor if I'd used
d.mon start=x0 instead of the PNG driver. The colors in the image are
interpolated, not enough shades of grey, for instance, as if the color
palette was very small. Lots of blotchy colors, and no smooth
transitions and gradients.

Markus, in your book you make the following reference on p. 187 in the
section 8.1.3 on "Monitor output to PNG and HTML files"

"If the Gd2.x library is installed the driver supports true color
output"

Because my images look like they don't have enough colors, I assumed
this was the problem. So, I installed the gd 2.0.9 library and tested
it to make sure it was working. I get the same poor quality images. I
AM setting the GRASS_TRUECOLOR=TRUE environment variable.

What's going on here? Why is the output from PNG file driver so
different from the output from the GRASS monitor?

Did you recompile GRASS after installing GD 2.0?

maybe one of the following two scripts will be helpful.

Hamish

(attachments)

d.out.png.xwdump (603 Bytes)
d.out.png.driver (1.12 KB)

3

Hamish,

Thanks so much for your response. I found your scripts elsewhere on the web and have already had a go at using them. The PNG script uses the same commands that I was referring to, so the output is the same. The xwd script works better, but the output is still NOT a match to what I see on the screen in the GRASS monitor. The xwd output tends to dither areas of flat color, so that's not acceptable either.

As for re-compiling grass, I'm not sure if I could do it. I am using 5.0.2 off of the OpenOSX CD because I'm not an expert with UNIX. It was a two-day ordeal for me to get the gd library compiled and running on my system. However, I would try to compile it (and all the other libraries that go with it) if I thought it would help. So, for Hamish, or anyone else who can help...

1) Why do you think re-compiling would help? I wouldn't want to waste days on that endeavor if it wouldn't work.

2) If I do, which version should I compile?

3) Why do you think I'm getting the kind of poor quality from the PNG driver? Am I correct in assuming that it's because I don't have the TRUECOLOR support from the gd library (even though it's now installed)?

Anyone's help would be appreciated. I'm really stuck.

Thanks,

Jason

Jason Horn
Boston University Department of Biology
5 Cumington Street Boston, MA 02891

jhorn@bu.edu
617 353 6975

On Jan 18, 2004, at 5:49 PM, Hamish wrote:

I'm having trouble outputting images from the PNG file driver - the
quality of the resulting .png images is very poor. I put together the
maps that I want to output using:

d.mon start=PNG
d.mon select=PNG
d.rast dem.relshade
d.mon stop=PNG

This does NOT give me what I'd see in the grass monitor if I'd used
d.mon start=x0 instead of the PNG driver. The colors in the image are
interpolated, not enough shades of grey, for instance, as if the color
palette was very small. Lots of blotchy colors, and no smooth
transitions and gradients.

Markus, in your book you make the following reference on p. 187 in the
section 8.1.3 on "Monitor output to PNG and HTML files"

"If the Gd2.x library is installed the driver supports true color
output"

Because my images look like they don't have enough colors, I assumed
this was the problem. So, I installed the gd 2.0.9 library and tested
it to make sure it was working. I get the same poor quality images. I
AM setting the GRASS_TRUECOLOR=TRUE environment variable.

What's going on here? Why is the output from PNG file driver so
different from the output from the GRASS monitor?

Did you recompile GRASS after installing GD 2.0?

maybe one of the following two scripts will be helpful.

Hamish

<d.out.png.xwdump><d.out.png.driver>

4

Hamish,

Thanks again for the assistance. To answer your questions...

On Jan 18, 2004, at 9:49 PM, Hamish wrote:

The xwd script works better, but the output is still NOT a match to
what I see on the screen in the GRASS monitor. The xwd output tends
to dither areas of flat color, so that's not acceptable either.

That is odd, it should be just a straight screen capture.

Can you Aquire->Screenshot from Gimp or another graphics program?

(install the gimp with 'Fink' [http://fink.sourceforge.net])
* I assume you are running MacOSX ?

See the attached files.
1) GRASS_monitor screen capture of the GRASS monitor
2) png_driver.png produced by the PNG file driver
3) xwdtopnm.pnm produced by the first step in your xwd script. This image is perfect and matches the original GRASS monitor contents. So far so good.
4) pnmtopng.png produced by the second step in the xwd script. This is the output of pnmtopng with no options specified. I mentioned before that I saw dithering, but I realized that it was the viewer that I was using (Preview), not the file itself. Oddly enough, this image looks fine when viewed in apps like Photoshop or GaphicConverter. It looks poor in Preview and in Mail. Either there must be something up with PNG files and OS X's quartz layer, or there's something strange with the image. Either way, this image looks like the GRASS Monitor, so this is the method I'll use.

As for re-compiling grass, I'm not sure if I could do it. I am using
5.0.2 off of the OpenOSX CD because I'm not an expert with UNIX.

see attached for instructions on building in OSX 10.3. If you are using
10.2, well that's a bit different. It's not too rough if everything
works properly and you may learn something along the way..

It was a two-day ordeal for me to get the gd library compiled and
running on my system.

I take it you didn't install gd via fink?
http://fink.sourceforge.net/pdb/package.php/gd2

'apt-get install gd2' would have done it....

I tried this, but there were problems with 10.3 and fink. Fink still tries to install xfree86, even though you have Apple's X11 installed. So you have to trick it by installing the Apple X11 sdk and change a few other things, bla, bla bla. Plus there are other errors generated during building. I couldn't verify that I was getting a good install. I found these instructions on the web for building the gd libraries and used them. http://www.paginar.net/matias/articles/gd_x_howto.html At least I knew what was happening and where it was going.

However, I would try to compile it (and all the other
libraries that go with it) if I thought it would help.

... definite maybe.

1) Why do you think re-compiling would help?

Installing GD-2.0 by itself doesn't let GRASS know it is installed and
GRASS should use it. This is figured out at the configure stage before
compiling GRASS. There are just way too many places it could be for
GRASS to look for it each time.

I'll give it a shot.

2) If I do, which version should I compile?

Depends on what you want/need.
5.0.3 most stable version
5.3 datum support, some new features; things may change without warning
5.7 vastly improved vector support; things may change without warning

I'll try 5.0.3 for now.

3) Why do you think I'm getting the kind of poor quality from the PNG
driver? Am I correct in assuming that it's because I don't have the
TRUECOLOR support from the gd library (even though it's now
installed)?

I think so... but that's just a guess.

good luck,
Hamish

(install fink!)
<compile_53_osx_panther.txt>

Thanks again! I'll let you know what happens.

(attachments)

GRASS_monitor.png
png_driver.png
pnmtopng.png
xwdtopnm.pnm (900 KB)

5

just to note

1) GRASS_monitor screen capture of the GRASS monitor

24-bit TrueColor image

2) png_driver.png produced by the PNG file driver

256 colour indexed image

3) xwdtopnm.pnm produced by the first step in your xwd script.
This image is perfect and matches the original GRASS monitor contents.

So far so good.

24-bit TrueColor image

[sending 1mb files to everyone on the mailing list isn't the best idea, btw]

4) pnmtopng.png produced by the second step in the xwd script.
This is the output of pnmtopng with no options specified. I mentioned

before that I saw dithering, but I realized that it was the viewer
that I was using (Preview), not the file itself. Oddly enough, this
image looks fine when viewed in apps like Photoshop or
GaphicConverter. It looks poor in Preview and in Mail. Either there
must be something up with PNG files and OS X's quartz layer, or
there's something strange with the image. Either way, this image
looks like the GRASS Monitor, so this is the method I'll use.

24-bit Grayscale image

maybe the pnmtopng program is being smart & sees that the image has no
colour and thus creates a smaller grayscale PNG image.

If the 24bit TrueColor .pnm file looks good in "Preview", and the 24bit
GrayScale .png doesn't, I'd say it was a "Preview" issue..

tip:
try setting GRASS_WIDTH= and GRASS_HEIGHT= on the command line to get
rid of those black bands on the side.

>> It was a two-day ordeal for me to get the gd library compiled and
>> running on my system.
>
> I take it you didn't install gd via fink?
> http://fink.sourceforge.net/pdb/package.php/gd2
> 'apt-get install gd2' would have done it....

I tried this, but there were problems with 10.3 and fink. Fink still
tries to install xfree86, even though you have Apple's X11 installed.

So you have to trick it by installing the Apple X11 sdk and change a
few other things, bla, bla bla. Plus there are other errors generated
during building. I couldn't verify that I was getting a good install.

I don't know if I'd call that tricking it, but ok. I installed Apple's
X11, X11 SDK, & Developer's Tools before I tried Fink on OSX 10.3.
And then Fink worked the first time.. shrug

> good luck,
> Hamish

6

Jason Horn wrote:

As for re-compiling grass, I'm not sure if I could do it. I am using
5.0.2 off of the OpenOSX CD because I'm not an expert with UNIX. It
was a two-day ordeal for me to get the gd library compiled and running
on my system. However, I would try to compile it (and all the other
libraries that go with it) if I thought it would help. So, for Hamish,
or anyone else who can help...

1) Why do you think re-compiling would help? I wouldn't want to waste
days on that endeavor if it wouldn't work.

If the PNG driver was built using GD 1.x, it will use GD 1.x at
run-time (or fail to run if GD 1.x can't be found). There isn't any
way to make it use GD 2.x without re-compiling it.

The quote from Markus' book:

  "If the Gd2.x library is installed the driver supports true
  color output"

isn't entirely accurate. The determining factor is whether the driver
was built with GD 2.x, not whether GD 2.x happens to be present on the
system.

The official recommendation was to use GD 1.x, because more systems
have it installed, and GD 2.x was considered "beta" until recently.

2) If I do, which version should I compile?

Hard to say. 5.0.3 has some fixes; however, OpenOSX made some
Mac-specific changes to improve integration (e.g. allowing tcltkgrass
to use the Aqua version of Tcl/Tk) which aren't in the stock source
releases.

If you build 5.0.2 from the OpenOSX source code, you could just
replace the PNG driver ($GISBASE/driver/PNG) and continue using the
other OpenOSX binaries. That way, it wouldn't matter if you had
problems building any of the other components, so long as you could
build the PNG driver successfully.

FWIW, the current CVS version (5.3) no longer uses the GD library, and
will always support 24-bpp images.

3) Why do you think I'm getting the kind of poor quality from the PNG
driver? Am I correct in assuming that it's because I don't have the
TRUECOLOR support from the gd library (even though it's now installed)?

Yes. GD 1.x only supports 256-colour images, and you can't make the
PNG driver use GD 2.x without re-compiling it.

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

7

Jason Horn wrote:

Thanks so much for your response. I found your scripts elsewhere on
the web and have already had a go at using them. The PNG script uses
the same commands that I was referring to, so the output is the same.
The xwd script works better, but the output is still NOT a match to
what I see on the screen in the GRASS monitor. The xwd output tends to
dither areas of flat color, so that's not acceptable either.

I have found xwd to be unreliable on true-colour displays. If you have
either ImageMagick or GIMP, both of those have a screen-grabbing
feature which can be used instead of xwd.

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

8

Glynn, Hamish

Thanks for all the information - it helps tremendously to have the benefit of your familiarity and experience with GRASS. I never would have known, for example that 5.3 doesn't need the gd library anymore unless you'd told me.

Glynn, I can't use manual screen capture because I'm writing a script to automate the building and output of hundreds of images that will be used in an animation sequence (each is a NEXRAD RADAR image overlaid on a shaded landscape and that has labels identifying point features) Looks like the xwd will work fine until I re-compile 5.3.

To Everyone,
Sorry for the attachments. I'm new to the list - won't make that mistake again. :slight_smile:

Cheers,

Jason

Jason Horn
Boston University Department of Biology
5 Cumington Street Boston, MA 02891

jhorn@bu.edu
617 353 6975

On Jan 19, 2004, at 2:12 AM, Glynn Clements wrote:

Jason Horn wrote:

As for re-compiling grass, I'm not sure if I could do it. I am using
5.0.2 off of the OpenOSX CD because I'm not an expert with UNIX. It
was a two-day ordeal for me to get the gd library compiled and running
on my system. However, I would try to compile it (and all the other
libraries that go with it) if I thought it would help. So, for Hamish,
or anyone else who can help...

1) Why do you think re-compiling would help? I wouldn't want to waste
days on that endeavor if it wouldn't work.

If the PNG driver was built using GD 1.x, it will use GD 1.x at
run-time (or fail to run if GD 1.x can't be found). There isn't any
way to make it use GD 2.x without re-compiling it.

The quote from Markus' book:

  "If the Gd2.x library is installed the driver supports true
  color output"

isn't entirely accurate. The determining factor is whether the driver
was built with GD 2.x, not whether GD 2.x happens to be present on the
system.

The official recommendation was to use GD 1.x, because more systems
have it installed, and GD 2.x was considered "beta" until recently.

2) If I do, which version should I compile?

Hard to say. 5.0.3 has some fixes; however, OpenOSX made some
Mac-specific changes to improve integration (e.g. allowing tcltkgrass
to use the Aqua version of Tcl/Tk) which aren't in the stock source
releases.

If you build 5.0.2 from the OpenOSX source code, you could just
replace the PNG driver ($GISBASE/driver/PNG) and continue using the
other OpenOSX binaries. That way, it wouldn't matter if you had
problems building any of the other components, so long as you could
build the PNG driver successfully.

FWIW, the current CVS version (5.3) no longer uses the GD library, and
will always support 24-bpp images.

3) Why do you think I'm getting the kind of poor quality from the PNG
driver? Am I correct in assuming that it's because I don't have the
TRUECOLOR support from the gd library (even though it's now installed)?

Yes. GD 1.x only supports 256-colour images, and you can't make the
PNG driver use GD 2.x without re-compiling it.

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

9

On Mon, Jan 19, 2004 at 07:12:16AM +0000, Glynn Clements wrote:

Jason Horn wrote:

> As for re-compiling grass, I'm not sure if I could do it. I am using
> 5.0.2 off of the OpenOSX CD because I'm not an expert with UNIX. It
> was a two-day ordeal for me to get the gd library compiled and running
> on my system. However, I would try to compile it (and all the other
> libraries that go with it) if I thought it would help. So, for Hamish,
> or anyone else who can help...
>
> 1) Why do you think re-compiling would help? I wouldn't want to waste
> days on that endeavor if it wouldn't work.

If the PNG driver was built using GD 1.x, it will use GD 1.x at
run-time (or fail to run if GD 1.x can't be found). There isn't any
way to make it use GD 2.x without re-compiling it.

The quote from Markus' book:

  "If the Gd2.x library is installed the driver supports true
  color output"

isn't entirely accurate. The determining factor is whether the driver
was built with GD 2.x, not whether GD 2.x happens to be present on the
system.

The next edition of the book will not have this sentence any more
as it is related to GRASS 5.3 (which contains a PNG driver without
the need of GD, thanks to Glynn Clements).

Markus Neteler

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy