[Rd] raster support in graphics devices

[baptiste auguie]

Hi,

2009/12/6 Paul Murrell <p.murrell at auckland.ac.nz>:
> Hi
>
>
> baptiste auguie wrote:
>>
>> 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,
>
>
> I disagree.  A "rect" grob is a vector object and a "raster" grob is a
> raster object and I think they should be kept distinct.  You could possibly
> create a higher-level "image" object that is agnostic with respect to how it
> is implemented and have both "rect"-based and "raster"-based versions of
> that, but "rect" and "raster" are graphical primitives and at that level I
> think the distinction is useful.

Fair point. I raised this question when trying to convert some ggplot2
code from grid.rect to grid.raster (for large images) and I came to
the conclusions that a) it wasn't completely trivial (for me anyway);
b) such conversion would probably be done over and over in the next
few months by several different people.

Your suggestion of a higher-level grob is interesting, and probably
more elegant than a function that converts one grob to the other as I
first envisaged.

Thanks,

baptiste




>
> Paul
>
>
>> 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
>>>
>
> --
> 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/
>