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/
Hi, I consider raster graphics highly problematic in statistics. People get caught up in the idea of creating pretty pictures, rather than effectively visualising information. Plus a lot of people (who should know better) needlessly put raster images inside reports and articles (even books), which either makes the files large (and very difficult to view), or creates blurry images, or both. It's always good to have more functionality. However, I certainly hope that most of the R community stick to vector graphics (with conservative colour use), unless it is absolutely necessary to do otherwise (and the only example I can think of, is modelling images themselves). On a side issue, I have found that R plots tend to be getting slower over the years. I think cairo was a bad move, however that's just my opinion... regards -- Charlotte Maia http://sites.google.com/site/maiagx/home
Very nice, thank you for this great addition to R graphics! I can't
wait to see lattice and ggplot2 functions that use rasterGrob to
display images. The pdf output is so much better in every way!
Incidentally, I ran into a segfault with grid.cap on the quartz
device, but maybe it's normal at this stage.
This works fine:
library(grid)
x11()
grid.text("test")
cap <- grid.cap()
This doesn't:
library(grid)
quartz()
grid.text("test")
cap <- grid.cap()
*** caught segfault ***
address 0x18330001, cause 'memory not mapped'
Traceback:
1: .Call(fnname, ..., PACKAGE = "grid")
2: grid.Call("L_cap")
3: grid.cap()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
[R.app GUI 1.30 (5527) i386-apple-darwin9.8.0]
> sessionInfo()
R version 2.11.0 Under development (unstable) (2009-11-30 r50622)
i386-apple-darwin9.8.0
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
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
>
Hi Charlotte, I think I would have to respectfully disagree with you on many points. While we all sigh when we see heatmaps used as data to explain everything, they do have their uses. But beyond heat maps, the nature and demands of modern statistical graphics has changed. Plotting huge data sets requires generalization, eg binning. Plotting binned data is more efficient in raster form. Further, information visualization often requires blending raster images with vector graphics. There is as great many more examples where efficient use of raster graphics in an R device is a step forward. With regards to the X11 device I think we can safely say that it is a legacy device. We have all hit up on the limitations of what can be done on the x11 device, and hence the slew of new devices that have been introduced to fill the void. Cairo is slower, but I think we can safely assume that speed will improve as optimizations are added and Moores law kicks in. Paul has added many interesting 2d vector graphics tools. Look at the svn commits over the years, xsplines, line joining (mitre), fonts, plotmath, ... There is plenty of work on refining 2d graphics. 3d graphics and interactive graphics are also important. R is a flexible tool for prototyping new graphical methods. Why shoot ourselves in the foot? Anyway, nough said. Nicholas> ------------------------------ > > Message: 9 > Date: Wed, 2 Dec 2009 12:36:18 +1200 > From: Charlotte Maia <maiagx at gmail.com> > Subject: Re: [Rd] raster support in graphics devices > To: Simon Urbanek <simon.urbanek at r-project.org> > Cc: r-devel at r-project.org > Message-ID: > <b7bfe54e0912011636n4cb4636i587caab5bc5e6b68 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 12/2/09, Simon Urbanek <simon.urbanek at r-project.org> wrote: > > Charlotte, > > > > > > I would like to point out that implicitly you have been already using raster > > graphics all the time in very inefficient form in heatmaps etc. The point > > here is not really about added functionality for the user but efficiency, > > because now we can finally use efficient encoding of heatmaps, matrix > > visualizations, overlay data over satellite images etc. Although all this > > was always possible in R, it was very inefficient and caused unwanted side > > effects (see the constant anti-aliasing discussions). > > > > Cheers, > > Simon > > I might be unpopular for saying this, heatmaps are horrible things. > The first time I created a heatmap, I thought this is pretty, I've > since learnt better. > > If I wasn't unpopular for saying that, this will certainly make me > unpopular, what is with that image at the top of JSS? There is bad > typesetting, and then there is bad typesetting... > > I think many users are getting caught up in creating pretty images, > and the impression I'm getting is that various software (not just R) > is making this easier. > Whenever I'm reading an article and I see a heatmap, I say a few curse > words and then just settle for reading the abstract, and maybe the > first page of the introduction, if I've had a good day... > > There are still substantial problems with R's vector graphics, > creating curves and circles for example. On evince, my plots just look > like a bunch of "q"s (not sure whether it's evince's fault or R's > fault). Plus including figures in sweave is relatively difficult in my > opinion. > > Regarding Martins comments on changing the graphics device, I have > noticed some errors in doing so, hence have been (reluctantly) > sticking to cairo. What that saying, if you can't beat them, joint > them... or something like that... > > Then there's all those people (have no idea if this is correct or not) > that say creating plots in SAS and Matlab is faster than R. > > Overall, I think there is substantial room for improvement both in the > use and implementation of vector graphics, especially static 2D vector > graphics, however trends for implementing interactive graphics, 3d > graphics, and raster images seem to be getting too much precedence. > > In regards to Simon's comments, if we are going to focus on > efficiency, shouldn't we make the useful things efficient first, and > not gett too distracted. > > I don't know anything about matrix visualisation, however I'm > sceptical that it is a good idea to take a giant matrix, and map one > element to one pixel, say with colour indexing (essentially just > another heatmap). > > Noting my opinions here are in regards to the entire R community > (really the entire statistical community), not just the original post. > > > regards > -- > Charlotte Maia > http://sites.google.com/site/maiagx/home > > >
Currently I have an application that saves the current graphics image (that
was created with classic graphics or grid graphics) to a file and then reads
the file back in using readBin:
png("my.png")
plot(1:10)
dev.off()
raw.img <- readBin("my.png", "raw", size = 1, n =
100000000)
(I am doing this on Windows but would like to be able to do it on any
platform.)
Does the new raster functionality give me any way to get the object raw.img
without creating the intermediate file, my.png? If so what is the
corresponding code?
On Mon, Nov 30, 2009 at 8:17 PM, Paul Murrell
<p.murrell@auckland.ac.nz>wrote:
> 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@stat.auckland.ac.nz
>
http://www.stat.auckland.ac.nz/~paul/<http://www.stat.auckland.ac.nz/%7Epaul/>
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
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
>
I can confirm. Last time I checked (that is recently), there was no way to do it at the C level (beside possibly extreme hacks trying to work around what R does not want to expose, or go for patched source trees and builds). What is the status of this patch (accepted ? rejected ? else ?) This subject keeps appearing on the list, with the existence of a patch once contributed (3 years ago) acknowledged: http://www.mail-archive.com/r-help at r-project.org/msg67172.html L.> ------------------------------ > > On Dec 5, 2009, at 4:11 PM, Romain Francois wrote: > >>> I agree too, I was just trying to put on the balance the amount >>> of work that would require graphics supporting connections. >>> >>> Who's willing to do it ? >>> > The issue is not the will nor complexity on the GD side, but > connections are not exposed outside of R (or at the C level), so > there is currently no way to do it (AFAIR). Jeff Horner has proposed > a patch long ago and Cairo works with connections if you patch R, but > connections are to date still not part of the API. So I suspect the > real issue is to create a connection API so packages (and devices) > can use it. > > Cheers, Simon > > >