[R] Remove "gray grid" from levelplot

[Prof Brian Ripley]

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 in 
the 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