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, [EMAIL PROTECTED]
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
______________________________________________
R-help@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
