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
On 3/4/06, Jan Marius Hofert <m_hofert at web.de> 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?[These comments also hold for your post on '"Continuously colored" colorkey', which I'm not going to answer separately.] I'm not entirely sure I understand your description, perhaps you can give us an example and a screenshot (and read the posting guide while you are at it). If you mean what I think you mean, these may well be device and viewer specific issues that have nothing to do with R. For example, the description in your other (colorkey) post sounds suspiciously like you are using gv and forgotten to turn off anti-aliasing, but you have given us so little information that we can only guess. Deepayan -- http://www.stat.wisc.edu/~deepayan/
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 > > ______________________________________________ > R-help at stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! > http://www.R-project.org/posting-guide.html >
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. 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. 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 >>> >>> ______________________________________________ >>> R-help at stat.math.ethz.ch mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-help >>> PLEASE do read the posting guide! >>> http://www.R-project.org/posting-guide.html >>> >> > >
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
The png and jpeg devices were in fact first written on Windows. My understanding is that the intention is to record on a bitmap what would be rendered on screen, and to regard that as data.>From the followup, I understand the question was about anti-aliasing inthe viewer. The philosophy is that this is indeed an issue for the viewer, and best left to that stage. (You can make the same comment about sharpening in JPEG.) The default background *is* opaque, BTW. On Mon, 6 Mar 2006, Fran?ois Pinard wrote:> [Brian Ripley] >> On Mon, 6 Mar 2006, Martin Sandiford wrote: > >> [...] > >>> P.S. To me, the png() device does not appear to do sub-pixel >>> rendering. The postscript() and pdf() devices do. > >> What could you possibly mean by that? > > I would think the original poster refers to aliasing issues. > >> The png device writes on a bitmap. It outputs a rectangular grid of either >> pre-defined colour indices or RGB values. There is nothing in the PNG >> standard to allow anything finer. > > Granted. Yet, there are nuances. Anti-aliasing techniques may be applied to > bit-mapped images like PNGs, and a carefully computed alpha channel could be > included in the PNG as a way to acknowledge sub-pixel rendering matters. > > If the background of the generated image is opaque instead of transparent, > the graphics and the background might be combined at PNG generation, > swallowing what would have been an alpha channel and so, sparing the need of > including any in the generated PNG. > > However, on this Linux system, if I understood correctly, R goes through X11 > for generating PNGs, and so, does no better than X11 itself (at least as > currently driven by R) in the area of anti-aliasing. > > Anti-aliasing libraries exist (which I never really studied or used myself) > that could likely provide better PNG quality. Did some decision has been > reached among developers on this topic? I would guess, without really > knowing, that developers favor vector-to-raster rendering to be done outside > R, whenever quality is required. > > Using an anti-aliasing library for higher output quality within R would mean, > besides the obvious trouble of selecting one of those libraries and > programming the interface, adding yet another dependency at R build-time > (likely autoconfigured, of course), and an observable slowdown for graphics > which are more heavily loaded, especially in interactive mode. For one, I do > not need more than draft quality so far when using R interactively for plots. > Maybe some "draft", "quality" or "aa" flag is added to control anti-aliasing > behaviour? (I know that "quality" is already used to mean something else for > JPEG images). > > Just a few thoughts. Keep happy, all! > >-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595