[Rd] raster support in graphics devices

[baptiste auguie]

Dear all,

It seems to me that grid.raster is a special case of grid.rect as far
as the intended visual output is concerned. The example below
illustrates how both can be used to produce an image of the volcano
data,

d <- volcano

cols <- grey(t(d)/max(c(d)))
xy <- expand.grid(x=seq(0, 1, length=ncol(d)), y=seq(0, 1, length=nrow(d)))

pdf("comparison.pdf", width=10, height=10/2*ncol(d)/nrow(d))
pushViewport(viewport(layout=grid.layout(1, 2)))

pushViewport(viewport(layout.pos.r=1, layout.pos.c=1))
grid.rect(xy$y, rev(xy$x), 1/(nrow(d)), 1/(ncol(d)),  gp=gpar(col=NA,
fill=cols))
grid.text("grid.rect")
upViewport()

pushViewport(viewport(layout.pos.r=1, layout.pos.c=2))
cols.mat <- matrix(cols, ncol=ncol(d), byrow=T)
grid.raster(t(cols.mat))
grid.text("grid.raster")
dev.off()

Of course grid.raster provides a much better output in terms of file
size, speed, visualisation artifacts, and interpolation. My question
though: is it necessary to have a distinct grob for raster output?
Couldn't "raster" be an option in grid.rect when the width and height
are constant?

Alternatively, it might be useful to provide a function that converts
a rectGrob into a rasterGrob,

rect2raster <- function(g){

  with(g,
       rasterGrob(matrix(gp$fill, ncol=length(unique(x))), mean(x),mean(y)))
}

This way, much of the existing code relying on grid.rect (e.g in
lattice or ggplot2) could easily be adapted to work with grid.raster
in favorable cases.

Best regards,

baptiste



2009/12/1 Paul Murrell <p.murrell at auckland.ac.nz>:
> Hi
>
> This is for developers of extension packages that provide extra *graphics
> devices* for R.
>
> In the *development* version of R, support has been added to the graphics
> engine for sending raster images (bitmaps) to a graphics device.  This
> consists mainly of two new device functions:  dev_Raster() and dev_Cap().
>
> The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as a
> marker of this change.
>
> This means that, at a minimum, all graphics devices should be updated to
> provide dummy implementations of these new functions that just say the
> feature is not yet implemented (see for example the PicTeX and XFig devices
> in the 'grDevices' package).
>
> A full implementation of dev_Raster() should be able to draw a raster image
> (provided as an array of 32-bit R colors) at any size, possibly (bilinear)
> interpolated (otherwise nearest-neighbour), at any orientation, and with a
> per-pixel alpha channel.  Where these are not natively supported by a
> device, the graphics engine provides some routines for scaling and rotating
> raster images (see for example the X11 device).  The dev_Cap() function
> should return a representation of a raster image captured from the current
> device.  This will only make sense for some devices (see for example the
> Cairo device in the 'grDevices' package).
>
> A little more information and a couple of small examples are provided at
> http://developer.r-project.org/Raster/raster-RFC.html
>
> Paul
> --
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> paul at stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>