Michael Lachmann
2011-Aug-03 07:25 UTC
[Rd] one way to solve bad looking density plots in postscript
Hi,
When R generates density plots and these are exported to postscript(
a=matrix(1:100,10,10);image(a,col=rainbow(100);dev.copy2eps(file="image.eps")
)
The result often looks bad when rendered on screen. The help page states that
this is because programs use anti-aliasing. That seems to be true - turning off
anti-aliasing for gs (-dGraphicsAlphaBits=1) of in OSX's preview makes the
plots look really smooth, but makes everything else look bad (personal
opinion..). The plots do look ok in acrobat reader. I think it would be much
better if R corrected this problem - even if it is not totally R's fault.
It seems that using the option useRaster=T in image() solved this problem, but
creates other problems for OSX's Preview (it seems that OSX's preview
first anti-aliases the raster, and then scales it... creating a mess).
Density plots produced by gnuplot do not seem to have this problem:
---
set pm3d map
set pm3d at b
set ticslevel 0.8
set isosample 40,40
set output "gtest.eps"
set term postscript eps color
splot [-3:3] [-3:3] x*x*exp(-x*x)*y*y*exp(-y*y)
--
But I haven't figured out why that is. Maybe someone who understands more
about postscript can. Maybe it is something about the order that the rectangles
are rendered? I did notice that rectangles are plotted with slightly different
sizes - 50, 51, 50, 51 and so on. Is that it?
After a lot of experimentation, I found that a small change in the eps file can
correct the output.
If in the eps file produced above, you change the line
/p2 { gsave bg fill grestore newpath } def
with
/p2 { bg gsave fill grestore stroke newpath } def
and add
0.0001 setlinewidth
two lines before the next p2 - i.e. before we start plotting the rectangles of
the image:
change:
/bg { 1 0 0 setrgb } def
59.04 73.44 41.47 37.15 r p2
to:
0.0001 setlinewidth
/bg { 1 0 0 setrgb } def
59.04 73.44 41.47 37.15 r p2
What this does is plot the outline of each rectangle in addition to filling it.
The page at:
http://pages.uoregon.edu/noeckel/MathematicaGraphics.html#ExportGraphics
Claims that Mathematica also has/had this problem, and how it can be solved
there (sadly, I don't know enough Mathematica to understand that solution)
The output of the image would look even better if the axes were drawn AFTER the
density rectangles, not before. That would cause the rectangles not to overwrite
part of the lines of the axes. But that is probably a change in the image()
routine, not in the postscript driver....
Thanks for listening,
Michael Lachmann
Michael Lachmann
2011-Aug-03 12:23 UTC
[Rd] one way to solve bad looking density plots in postscript
Some more digging.
1.
The following code will fix density plots for me:
---
.ps.prolog=grDevices:::.ps.prolog
i=grep("/p2",.ps.prolog)
.ps.prolog[i] = "/p2 { bg gsave fill grestore 0.001 setlinewidth stroke
newpath } def"
---
2.
It seems that it doesn't matter where in image.default() the box is drawn,
before or after
.Internal(image(as.double(x), as.double(y), as.integer(zi),
col))
is called, the resulting eps has the box in front.
Michael
On 3 Aug 2011, at 9:25AM, Michael Lachmann wrote:
> When R generates density plots and these are exported to postscript(
>
a=matrix(1:100,10,10);image(a,col=rainbow(100);dev.copy2eps(file="image.eps")
> )
> The result often looks bad when rendered on screen. The help page states
that this is because programs use anti-aliasing. That seems to be true - turning
off anti-aliasing for gs (-dGraphicsAlphaBits=1) of in OSX's preview makes
the plots look really smooth, but makes everything else look bad (personal
opinion..). The plots do look ok in acrobat reader. I think it would be much
better if R corrected this problem - even if it is not totally R's fault.
> It seems that using the option useRaster=T in image() solved this problem,
but creates other problems for OSX's Preview (it seems that OSX's
preview first anti-aliases the raster, and then scales it... creating a mess).
>
> Density plots produced by gnuplot do not seem to have this problem:
> ---
> set pm3d map
> set pm3d at b
> set ticslevel 0.8
> set isosample 40,40
> set output "gtest.eps"
> set term postscript eps color
> splot [-3:3] [-3:3] x*x*exp(-x*x)*y*y*exp(-y*y)
> --
> But I haven't figured out why that is. Maybe someone who understands
more about postscript can. Maybe it is something about the order that the
rectangles are rendered? I did notice that rectangles are plotted with slightly
different sizes - 50, 51, 50, 51 and so on. Is that it?
>
> After a lot of experimentation, I found that a small change in the eps file
can correct the output.
> If in the eps file produced above, you change the line
> /p2 { gsave bg fill grestore newpath } def
> with
> /p2 { bg gsave fill grestore stroke newpath } def
> and add
> 0.0001 setlinewidth
> two lines before the next p2 - i.e. before we start plotting the rectangles
of the image:
> change:
> /bg { 1 0 0 setrgb } def
> 59.04 73.44 41.47 37.15 r p2
> to:
> 0.0001 setlinewidth
> /bg { 1 0 0 setrgb } def
> 59.04 73.44 41.47 37.15 r p2
>
> What this does is plot the outline of each rectangle in addition to filling
it.
> The page at:
> http://pages.uoregon.edu/noeckel/MathematicaGraphics.html#ExportGraphics
> Claims that Mathematica also has/had this problem, and how it can be solved
there (sadly, I don't know enough Mathematica to understand that solution)
>
> The output of the image would look even better if the axes were drawn AFTER
the density rectangles, not before. That would cause the rectangles not to
overwrite part of the lines of the axes. But that is probably a change in the
image() routine, not in the postscript driver....
>
> Thanks for listening,
>
> Michael Lachmann
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>