[R] Remove "gray grid" from levelplot

[Deepayan Sarkar]

On 3/6/06, Martin Sandiford <ms at mcdev.com.au> wrote:
> Hi Jan,
>
> The patch requires a recompile of R.  As I understand it,
> this is a fairly painful experience.  I haven't done it
> myself.
>
> I find that using the pdf() function to open a pdf device
> produces better quality output when printing than saving
> a quartz device from the menu.
>
> It appears that the postscript() and pdf() devices use
> sub-pixel rendering as well, as output shows evidence of gray
> lines on low resolution devices, however, for me, this isn't
> evident on a printer at 1200x1200dpi.
>
> My guess would be that, in general, levelplot is not a great
> function to use if the box size approaches the resolution of
> the underlying device.  The first example in help(levelplot)
> exhibits severe moire patterns on an approx 740x740 quartz or
> x11() device.  When the output from the postscript device is
> printed out, it looks more or less as expected.

740x740 what? I don't see any obvious problems on x11 on Linux.

> If there are more boxes in the levelplot than pixels on the
> device you are plotting to, then in effect you are asking
> the display device to do the averaging of the excess
> boxes for devices that support sub-pixel rendering.

That was my first instinct too, but based on (offlist) screenshots Jan
sent me, that isn't the issue here. I haven't been able reproduce his
results (since I don't have a mac) but the artifacts there are very
similar to what I often see in postscript output. The viewer matters
here, and with gv on Linux, these artifacts are present when
anti-aliasing is turned on, but they go away when AA is turned off.
I.e., anti-aliasing is doing more harm than good. If indeed the quartz
device performs anti-aliasing by default (as your other post
suggests), that would explain the behaviour. If it is possible to turn
of AA, that should help.

In any case, there doesn't seem to be much of an (R) issue here.
Printed output should be fine (since there's no AA involved).
Anti-aliasing distorts the true image in a manner that usually helps
but messes up in this case. That's the trade-off you have to accept if
you decide to use AA.

-Deepayan

> I'm still not 100% sure what it is that you are trying to do,
> but I'm guessing that it boils down to levelplot not being
> designed to plot analytic functions.
>
> Martin
>
> P.S. To me, the png() device does not appear to do sub-pixel
> rendering.  The postscript() and pdf() devices do.
>
> On 06/03/2006, at 1:43 AM, Jan Marius Hofert wrote:
>
> > Hi,
> >
> > I am using a Mac (Powerbook G4, Mac Os X 10.4) and this seems to be
> > the problem, but I have absolutely no idea how to use the "patch"
> > mentioned on
> > https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20060214/
> > 0b3e99c2/attachment.pl
> > I would also like to create *.ps files so this does not seem to be the
> > appropriate approach. I can also use x11 as trellis.device which fixes
> > the color-problem, but the lines are plotted in bad quality then.
> > Also, I can not save the graph then, when plotted with x11. All other
> > devices (png, pdf) have the same problem with the fine gray lines....
> >
> > so the R version for the mac must be the problem, but I have no idea
> > how to fix that. It would not matter if the plots via the quartz
> > device (on the screen) would be bad as long as the postscript file
> > comes out perfect.
> >
> > Thanks again and any more comments/hints are appreciated
> >
> > marius
> >
> >
> > On 05.03.2006, at 13:19, Martin Sandiford wrote:
> >
> >> I don't know what kind of computer you are using.
> >>
> >> If you are on a Mac, then this might be relevant:
> >> https://stat.ethz.ch/pipermail/r-sig-mac/2006-February/002679.html
> >>
> >> (Need to click through to the actual message.)
> >>
> >> Martin
> >>
> >>
> >> On 05/03/2006, at 2:52 AM, Jan Marius Hofert wrote:
> >>
> >>> Hi,
> >>>
> >>> If I use the levelplot function of the lattice library, I always see
> >>> small "squares" in the plot. They indicate the region for which the
> >>> same color is used. If you have a levelplot of a function which is
> >>> evaluated at 25x25 equally-spaced points you obtain 26 squares in x
> >>> and 26 squares in y direction. That does not bother too much (but
> >>> still bothers somehow...), but if you want to plot a function which
> >>> is evaluated at 1000x1000 equally-spaced points, then the "thickness"
> >>> of this gray grid cause the grid lines to hit each other so there is
> >>> no space for the color in the square anymore (since the "squares" are
> >>> actually not visible anymore)... this might change the color of the
> >>> whole levelplot!. (I tried it with the plot of f(x,y)=max(x+y-1,0)
> >>> for x,y in the unit interval, i.e. the Lower Frechet copula). So my
> >>> question is, if it is possible to remove this gray "grid" form the
> >>> levelplot graph?
> >>>
> >>> Thanks in advance
> >>>
> >>> marius