stripes in eps output

[Eric Salathé]

My experience has also been that EPS files generated from grads using
gxps look just fine when printed in journals -- most of my paper have
GrADs images and I would not be using Grads if the images looked bad
in print. I usually tweak and reformat graphics in Illustrator, which
deals with the the lines just fine and makes very nice raster files
if needed.

The problem comes with looking at the EPS file (eg in ghostview or
Preview) or when converting to a raster image. Since most images end
up on the web as PNG, and not in print, this is important. Grad's
printim does a decent job and is quick, but without a lot of control
over image size and format. The solution is to turn of anti aliasing.
Using +antialias in ImageMagick convert as Jeffery Gall suggests
works reasonably well (convert actually calls gs), but then lines are
rendered too thick and pixelated. If you specify a fine dpi, then
scale down, you can get better line art while eliminating the
striping. Compare these results on an eps generated with gxps (note
I've added -trim to remove blank margins):

convert -trim +antialias -density 150 test.eps test.png
convert -trim +antialias -scale 25% -density 600 test.eps test_scale.png

<http://www.atmos.washington.edu/~salathe/Public/test.png>
<http://www.atmos.washington.edu/~salathe/Public/test_scale.png>

To do this, I use a grads script that calls a csh script that can
handle any output format:

Grads script saveimg in $GASCRP:

function saveimg(file)

* print screen to eps file specified as argument


* first print to gx file

'enable print tmp.gx'
'print'
'disable print'

* now translate to image format

'! gxconvert tmp.gx ' file
'! \rm -f tmp.gx'

csh script in $PATH:

#!/bin/csh

if (! $#argv == 1) then
echo "usage: gxconvert file.gx file.ext where ext indicates output
format"
exit
endif

gxps -c -i $1 -o tmp.ps > /dev/null

if ($2:e == 'ps') then
mv tmp.ps $2
else if  ($2:e == 'eps') then
ps2epsi tmp.ps $2
\rm -f tmp.ps
else
convert +antialias -trim -scale 50% -density 300 tmp.ps $2
\rm -f  tmp.ps
endif

exit


-Eric

--
Eric Salathé
CSES Climate Impacts Group
<salathe at washington.edu>
University of Washington          <http://www.atmos.washington.edu/
~salathe>
206-616-5351

On Feb 8, 2007, at 12:27 PM, Matthias Munnich wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The trouble is that one of the most common PostScript renderers,
> Ghostscript (gs), is nowadays doing antialiasing by default to soften
> ragged lines and corners.  It blends neighboring bit even for purely
> horizontal lines.  This leads to the pixel-width horizontal lines due
> to the way Grads is filling contours.   Antialiasing can be turned of
> with "-dGraphicsAlphaBits=1" in gs or "-noantialias" in ghostview
>
>  I still don't  believe that hardcopy publications are likely to show
> lines.  These lines would be close to invisible anyway  on a 1200dpi
> printer .   I  suspect people are rendering  their graphics themselves
> with tools like ImageMagick.  Almost any free software is  using
> Ghostscript as the rendering engine.  These tools usually use default
> Ghostscript settings and you get the lines.
>
> Well, Jennifer's email suggests otherwise.   Unfortunately  you do not
> control how the graphic is rendered in print and submitting a rendered
> figure as suggested by Jennifer and Jeff is one solution.  However,
> you loose print quality.
>
> My approach would be to look through a recent issues of JGR and see if
> the figures show these lines.   I always recognize grads plots -- I
> guess I stared at too many by now.   I am pretty sure it's fine to
> submit gxeps created EPS files to JGR.   There were no lines in the
> figures of my recent GRL paper.
>
>
> ... Matt
>
>
>
> Jennifer Adams wrote:
>> Alan et al., Those horizontal stripes in the ps/eps output are a
>> real nuisance. Potential sources of the problem start with the
>> contouring algorithm in the GrADS graphics layer, but the presence
>> of the stripes also seem to be influenced by gxps, gxeps, any
>> external or internal utility that converts the .eps or .ps files to
>> something else as they get incorporated into written documents, and
>> the printers used by scientists and publishers also seem to be a
>> factor. My recent experience is that it's nearly impossible to
>> predict whether you'll get stripes or not. It's seems more likely
>> that you'll have stripes than no stripes, and the stripes also seem
>> to be most garish in plots with shaded contours and white space.
>>
>> Here at COLA, we've begun using image format files (.png and .gif)
>> instead of vector graphic formats, simply because they're more
>> reliable even though they don't always look as good.
>>
>> COLA users are being weaned from using PCs running MS Windows, but
>> my sense is that the gv32 program allowed for conversion of GrADS
>> metafiles into something else that did not have stripes. I can't
>> verify that, perhaps the windows users out there can confirm or
>> deny.
>>
>> Brian is planning to rework the contouring algorithm, so there's
>> hope for the future; unfortunately, that hope doesn't help in the
>> short term. I would see if you can get the publisher to provide a
>> test print of your figures, and if that looks bad, see if you can
>> use an image format instead. A .png at 850x1100 resolution, shrunk
>> down to journal size, might not look so bad.
>>
>> Jennifer
>>
>>
>>
>> On Feb 8, 2007, at 11:03 AM, Alan Robock wrote:
>>
>>> Dear Friends,
>>>
>>> Has anyone found a solution to the age-old problem of horizontal
>>> lines between bands of color in shaded grads output?  We have eps
>>> files to submit for an accepted JGR paper and are concerned about
>>> how the final version will look.
>>>
>>> Is there anything we can do to the files before we submit them to
>>> fix the problem?
>>>
>>> Alan
>>>
>>> Alan Robock, Professor II Department of Environmental Sciences
>>> Phone: +1-732-932-9478 Rutgers University
>>> Fax: +1-732-932-8644 14 College Farm Road
>>> E-mail: robock at envsci.rutgers.edu
>>> <mailto:robock at envsci.rutgers.edu> New Brunswick, NJ 08901-8551
>>> USA http://envsci.rutgers.edu/~robock
>>>
>>
>> -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302
>> Calverton, MD 20705 jma at cola.iges.org <mailto:jma at cola.iges.org>
>>
>>
>>
>
>
> - --
> - --------------------------------
> Matthias Munnich
> Univ. of California, Los Angeles
> Dept. of Atmos. and Oceanic Sc. and
> Inst. of Geophysics and Planetary Physics
> 3845 Slichter Hall
> Los Angeles, CA 90095-1567
> Phone: +1-310-794 5899
> Fax: +1-310-206 3051
> Email: munnich at atmos.ucla.edu
> - --------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFy4e7idaDTh/cfhYRAkhyAKDYrNmXqc5O4m5L+DWrypw/kvsk4QCgn2rl
> Oo2eoszDJQ4TTyuFviUL6g0=
> =/obd
> -----END PGP SIGNATURE-----