Re: [Rd] raster support in graphics devices
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
> "CM" == Charlotte Maia
> on Tue, 1 Dec 2009 17:48:33 +1300 writes:
CM> Hi,
CM> I consider raster graphics highly problematic in statistics.
CM> People get caught up in the idea of creating pretty pictures, rather
CM> than effectively visualising information.
CM> Plus a lot of people (who should know better) needlessly put raster
CM> images inside reports and articles (even books), which either makes
CM> the files large (and very difficult to view), or creates blurry
CM> images, or both.
CM> It's always good to have more functionality.
Yes indeed, and Paul has to be thanked loudly and heartfully and
very much for providing it in the realm of graphics !!!
CM> However, I certainly hope that most of the R community stick to vector
CM> graphics (with conservative colour use), unless it is absolutely
CM> necessary to do otherwise
I agree with your reasoning *pro* using vector graphics
as much as possible, and warning against the overuse of raster
graphics in scientific work !
CM> necessary to do otherwise (and the only example I can think of, is
CM> modelling images themselves).
Did you look at the interesting page Paul sent the URL for,
http://developer.r-project.org/Raster/raster-RFC.html ?
Yes, modelling images is probably *the* most important
application area, but *fast* direct plotting of a large matrix,
mapping one matrix entry A_{i,j} to one pixel is also quite
attractive, and the Matrix package authors (me being one) are
quite interested to eventually see a version of
lattice::levelplot() that builds on Paul's new
grid::grid.raster() or grid::rasterGrob() functions.
CM> On a side issue, I have found that R plots tend to be getting slower
CM> over the years.
CM> I think cairo was a bad move, however that's just my opinion...
Dear me...
using Cairo features for X11 graphics is just the new default,
so users notice the nice new possibilities !
If you want the very fast (but not so very nice looking)
previous default X11() graphics, please do read the help pages:
--> ?X11
--> ?X11.options
and then either X11.options(type = "Xlib")
or X11(type = "Xlib")
will give you the very fast (non-aliased, no alpha blending)
X11 graphics that used to be the only one in R originally.
Martin Maechler, ETH Zurich
CM> regards
CM> --
CM> Charlotte Maia
CM> http://sites.google.com/site/maiagx/home
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Charlotte, On Nov 30, 2009, at 23:48 , Charlotte Maia wrote: 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. 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 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
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 :
> 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
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Hi
baptiste auguie wrote:
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 may be due to the fact that I tested the changes on Mac OS X 10.6
(looks like you have 10.5 ?), plus the fact that I am feeling my way a
bit on the Mac. I have access to a 10.4 machine so I will try to take a
look there. Thanks for the report.
Paul
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 :
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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
On 12/2/09, Simon Urbanek 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
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 > Subject: Re: [Rd] raster support in graphics devices > To: Simon Urbanek > Cc: r-devel@r-project.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On 12/2/09, Simon Urbanek 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 > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
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 = 1)
(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 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
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
Re: [Rd] raster support in graphics devices
Hi,
You can use grid.cap,
x11()
plot(1:10)
g = grid.cap()
dev.off()
str(g)
# chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
but as far as I understand in ?grid.cap and the underlying code there
is no "capGrob" equivalent that wouldn't require opening a new device
before capturing the output.
I hope I'm mistaken.
Best,
baptiste
2009/12/4 Gabor Grothendieck :
> 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 = 1)
>
> (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 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
>> p...@stat.auckland.ac.nz
>> http://www.stat.auckland.ac.nz/~paul/
Re: [Rd] raster support in graphics devices
Thanks.
I am looking for the data to be just as if I had read in the png file (or
wmf file or whatever). grid.cap seems to give a bitmap and then would
require some sort of processing to get the png or wmf, etc. form. Also note
that I need it for classic graphics and not just grid graphics.
What I have right now works just as I want it _except_ I have to create a
file and then read it back in which seems a waste.
On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie <
baptiste.aug...@googlemail.com> wrote:
> Hi,
>
> You can use grid.cap,
>
> x11()
> plot(1:10)
> g = grid.cap()
> dev.off()
> str(g)
> # chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
>
> but as far as I understand in ?grid.cap and the underlying code there
> is no "capGrob" equivalent that wouldn't require opening a new device
> before capturing the output.
>
> I hope I'm mistaken.
>
> Best,
>
> baptiste
>
> 2009/12/4 Gabor Grothendieck :
> > 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 = 1)
> >
> > (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 >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
> >> p...@stat.auckland.ac.nz
> >> http://www.stat.auckland.ac.nz/~paul/
Re: [Rd] raster support in graphics devices
Just to explain a bit more I am thinking about something like this:
con <- graphicsConnection() # I've just made this up
png(con)
plot(1:10)
dev.off()
raw.img <- readBin(con, "raw", size = 1, n = 1)
On Fri, Dec 4, 2009 at 8:28 AM, Gabor Grothendieck
wrote:
> 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 = 1)
>
> (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 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
>> p...@stat.auckland.ac.nz
>> http://www.stat.auckland.ac.nz/~paul/
Re: [Rd] raster support in graphics devices
> Just to explain a bit more I am thinking about something like this:
>
> con <- graphicsConnection() # I've just made this up
> png(con)
> plot(1:10)
> dev.off()
> raw.img <- readBin(con, "raw", size = 1, n = 1)
It seems to me what you actually want is for graphics devices to
support connections:
rc <- rawConnection("raw.img", "w")
png(rc)
plot(1:10)
dev.off()
close(rc)
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Right.
On Fri, Dec 4, 2009 at 10:53 AM, hadley wickham wrote:
> > Just to explain a bit more I am thinking about something like this:
> >
> > con <- graphicsConnection() # I've just made this up
> > png(con)
> > plot(1:10)
> > dev.off()
> > raw.img <- readBin(con, "raw", size = 1, n = 1)
>
> It seems to me what you actually want is for graphics devices to
> support connections:
>
> rc <- rawConnection("raw.img", "w")
> png(rc)
> plot(1:10)
> dev.off()
> close(rc)
>
> Hadley
>
> --
> http://had.co.nz/
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Its not just the time. Its also the nuisance of having to manage files that
I never needed in the first place.
On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois wrote:
> On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:
>
>>
>> Thanks.
>>
>> I am looking for the data to be just as if I had read in the png file (or
>> wmf file or whatever).
>>
>
> Hi,
>
> You are after the binary payload of the rendered graph as a png file. So
> you are going to have to go through a png file.
>
> It would be nice to be able to render to a binary connection, like a
> rawConnection, but it seems like an expensive "nice to have"
>
>
> grid.cap seems to give a bitmap and then would
>> require some sort of processing to get the png or wmf, etc. form. Also
>> note
>> that I need it for classic graphics and not just grid graphics.
>>
>
> grid.cap does not seem to care, baptiste code uses traditional graphics
>
>
> What I have right now works just as I want it _except_ I have to create a
>> file and then read it back in which seems a waste.
>>
>
> Can you measure the time it takes to do dev.off() and readBin ?
>
>
> On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
>> baptiste.aug...@googlemail.com> wrote:
>>
>> Hi,
>>>
>>> You can use grid.cap,
>>>
>>> x11()
>>> plot(1:10)
>>> g = grid.cap()
>>> dev.off()
>>> str(g)
>>> # chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
>>>
>>> but as far as I understand in ?grid.cap and the underlying code there
>>> is no "capGrob" equivalent that wouldn't require opening a new device
>>> before capturing the output.
>>>
>>> I hope I'm mistaken.
>>>
>>> Best,
>>>
>>> baptiste
>>>
>>> 2009/12/4 Gabor Grothendieck:
>>>
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 = 1)
(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>>> 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
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
Re: [Rd] raster support in graphics devices
On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:
Thanks.
I am looking for the data to be just as if I had read in the png file (or
wmf file or whatever).
Hi,
You are after the binary payload of the rendered graph as a png file. So
you are going to have to go through a png file.
It would be nice to be able to render to a binary connection, like a
rawConnection, but it seems like an expensive "nice to have"
grid.cap seems to give a bitmap and then would
require some sort of processing to get the png or wmf, etc. form. Also note
that I need it for classic graphics and not just grid graphics.
grid.cap does not seem to care, baptiste code uses traditional graphics
What I have right now works just as I want it _except_ I have to create a
file and then read it back in which seems a waste.
Can you measure the time it takes to do dev.off() and readBin ?
On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
baptiste.aug...@googlemail.com> wrote:
Hi,
You can use grid.cap,
x11()
plot(1:10)
g = grid.cap()
dev.off()
str(g)
# chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
but as far as I understand in ?grid.cap and the underlying code there
is no "capGrob" equivalent that wouldn't require opening a new device
before capturing the output.
I hope I'm mistaken.
Best,
baptiste
2009/12/4 Gabor Grothendieck:
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 = 1)
(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
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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
Re: [Rd] raster support in graphics devices
> Its not just the time. Its also the nuisance of having to manage files that > I never needed in the first place. In general, it's much easier to create output from a R object than create an R object from output. It's good programming practice to minimise the number of functions with side-effects - if all input and output went through connections, many parts of R would be much easier to program against. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Hi,
Gabor Grothendieck wrote:
Its not just the time. Its also the nuisance of having to manage files that
I never needed in the first place.
I agree with Gabor that it is more than a 'nice to have'.
There are situations (when integrating R with other
applications) you don't want to touch a disk and
manage files afterwards (e.g. when one wants to pass
a byte string).
A recent question on the topic can be found here:
http://tolstoy.newcastle.edu.au/R/e8/help/09/11/5902.html
Best,
Tobias
On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois
wrote:
On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:
Thanks.
I am looking for the data to be just as if I had read in the png file (or
wmf file or whatever).
Hi,
You are after the binary payload of the rendered graph as a png file. So
you are going to have to go through a png file.
It would be nice to be able to render to a binary connection, like a
rawConnection, but it seems like an expensive "nice to have"
grid.cap seems to give a bitmap and then would
require some sort of processing to get the png or wmf, etc. form. Also
note
that I need it for classic graphics and not just grid graphics.
grid.cap does not seem to care, baptiste code uses traditional graphics
What I have right now works just as I want it _except_ I have to create a
file and then read it back in which seems a waste.
Can you measure the time it takes to do dev.off() and readBin ?
On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
baptiste.aug...@googlemail.com> wrote:
Hi,
You can use grid.cap,
x11()
plot(1:10)
g = grid.cap()
dev.off()
str(g)
# chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
but as far as I understand in ?grid.cap and the underlying code there
is no "capGrob" equivalent that wouldn't require opening a new device
before capturing the output.
I hope I'm mistaken.
Best,
baptiste
2009/12/4 Gabor Grothendieck:
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 = 1)
(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
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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
Re: [Rd] raster support in graphics devices
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 :
> 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
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
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 ?
On 12/05/2009 07:06 PM, Tobias Verbeke wrote:
Hi,
Gabor Grothendieck wrote:
Its not just the time. Its also the nuisance of having to manage files
that
I never needed in the first place.
I agree with Gabor that it is more than a 'nice to have'.
There are situations (when integrating R with other
applications) you don't want to touch a disk and
manage files afterwards (e.g. when one wants to pass
a byte string).
A recent question on the topic can be found here:
http://tolstoy.newcastle.edu.au/R/e8/help/09/11/5902.html
Best,
Tobias
On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois
wrote:
On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:
Thanks.
I am looking for the data to be just as if I had read in the png
file (or
wmf file or whatever).
Hi,
You are after the binary payload of the rendered graph as a png file. So
you are going to have to go through a png file.
It would be nice to be able to render to a binary connection, like a
rawConnection, but it seems like an expensive "nice to have"
grid.cap seems to give a bitmap and then would
require some sort of processing to get the png or wmf, etc. form. Also
note
that I need it for classic graphics and not just grid graphics.
grid.cap does not seem to care, baptiste code uses traditional graphics
What I have right now works just as I want it _except_ I have to
create a
file and then read it back in which seems a waste.
Can you measure the time it takes to do dev.off() and readBin ?
On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
baptiste.aug...@googlemail.com> wrote:
Hi,
You can use grid.cap,
x11()
plot(1:10)
g = grid.cap()
dev.off()
str(g)
# chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
but as far as I understand in ?grid.cap and the underlying code there
is no "capGrob" equivalent that wouldn't require opening a new device
before capturing the output.
I hope I'm mistaken.
Best,
baptiste
2009/12/4 Gabor Grothendieck:
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 = 1)
(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
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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
Re: [Rd] raster support in graphics devices
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
> On 12/05/2009 07:06 PM, Tobias Verbeke wrote:
>>
>> Hi,
>>
>> Gabor Grothendieck wrote:
>>
>>> Its not just the time. Its also the nuisance of having to manage files
>>> that
>>> I never needed in the first place.
>>
>> I agree with Gabor that it is more than a 'nice to have'.
>>
>> There are situations (when integrating R with other
>> applications) you don't want to touch a disk and
>> manage files afterwards (e.g. when one wants to pass
>> a byte string).
>>
>> A recent question on the topic can be found here:
>>
>> http://tolstoy.newcastle.edu.au/R/e8/help/09/11/5902.html
>>
>> Best,
>> Tobias
>>
>>> On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois
>>> >>> wrote:
>>>
On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:
> Thanks.
>
> I am looking for the data to be just as if I had read in the png
> file (or
> wmf file or whatever).
>
Hi,
You are after the binary payload of the rendered graph as a png file. So
you are going to have to go through a png file.
It would be nice to be able to render to a binary connection, like a
rawConnection, but it seems like an expensive "nice to have"
grid.cap seems to give a bitmap and then would
> require some sort of processing to get the png or wmf, etc. form. Also
> note
> that I need it for classic graphics and not just grid graphics.
>
grid.cap does not seem to care, baptiste code uses traditional graphics
What I have right now works just as I want it _except_ I have to
create a
> file and then read it back in which seems a waste.
>
Can you measure the time it takes to do dev.off() and readBin ?
On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
> baptiste.aug...@googlemail.com> wrote:
>
> Hi,
>> You can use grid.cap,
>>
>> x11()
>> plot(1:10)
>> g = grid.cap()
>> dev.off()
>> str(g)
>> # chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
>>
>> but as far as I understand in ?grid.cap and the underlying code there
>> is no "capGrob" equivalent that wouldn't require opening a new device
>> before capturing the output.
>>
>> I hope I'm mistaken.
>>
>> Best,
>>
>> baptiste
>>
>> 2009/12/4 Gabor Grothendieck:
>>
>>> 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 = 1)
>>>
>>> (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>> 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), a
Re: [Rd] raster support in graphics devices
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-h...@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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
On 12/06/2009 01:20 AM, Simon Urbanek wrote:
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
As much as I'd love a C API for connections, streaming graphics out to
connections don't necessarily have to depend on a C api. The trick we
use in the RProtoBuf package to stream out to a binary connection is to
call the R function writeBin several times. Something like:
/* next element is some raw vector we want to stream out */
SEXP nextElement = PROTECT( getNextElement() ) ;
/* con is the INTSXP connection number */
/* create the call : writeBin( nextElement, con ) */
SEXP call = PROTECT( lang3( "writeBin", nextElement, con ) );
SEXP res = PROTECT( eval( call, R_GlobalEnv) ) ;
/* grab the number of bytes actually sent out */
int n = INTEGER(res)[0] ;
UNPROTECT(3) ; /* res, call, nextElement */
We do the same with "readBin" to read from a binary connection chunk by
chunk.
Romain
On 12/05/2009 07:06 PM, Tobias Verbeke wrote:
Hi,
Gabor Grothendieck wrote:
Its not just the time. Its also the nuisance of having to manage files
that
I never needed in the first place.
I agree with Gabor that it is more than a 'nice to have'.
There are situations (when integrating R with other
applications) you don't want to touch a disk and
manage files afterwards (e.g. when one wants to pass
a byte string).
A recent question on the topic can be found here:
http://tolstoy.newcastle.edu.au/R/e8/help/09/11/5902.html
Best,
Tobias
On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois
wrote:
On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:
Thanks.
I am looking for the data to be just as if I had read in the png
file (or
wmf file or whatever).
Hi,
You are after the binary payload of the rendered graph as a png file. So
you are going to have to go through a png file.
It would be nice to be able to render to a binary connection, like a
rawConnection, but it seems like an expensive "nice to have"
grid.cap seems to give a bitmap and then would
require some sort of processing to get the png or wmf, etc. form. Also
note
that I need it for classic graphics and not just grid graphics.
grid.cap does not seem to care, baptiste code uses traditional graphics
What I have right now works just as I want it _except_ I have to
create a
file and then read it back in which seems a waste.
Can you measure the time it takes to do dev.off() and readBin ?
On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
baptiste.aug...@googlemail.com> wrote:
Hi,
You can use grid.cap,
x11()
plot(1:10)
g = grid.cap()
dev.off()
str(g)
# chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
but as far as I understand in ?grid.cap and the underlying code there
is no "capGrob" equivalent that wouldn't require opening a new device
before capturing the output.
I hope I'm mistaken.
Best,
baptiste
2009/12/4 Gabor Grothendieck:
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 = 1)
(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
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 su
Re: [Rd] raster support in graphics devices
On 12/06/2009 02:24 PM, Romain Francois wrote:
On 12/06/2009 01:20 AM, Simon Urbanek wrote:
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
As much as I'd love a C API for connections, streaming graphics out to
connections don't necessarily have to depend on a C api. The trick we
use in the RProtoBuf package to stream out to a binary connection is to
call the R function writeBin several times. Something like:
/* next element is some raw vector we want to stream out */
SEXP nextElement = PROTECT( getNextElement() ) ;
/* con is the INTSXP connection number */
/* create the call : writeBin( nextElement, con ) */
SEXP call = PROTECT( lang3( "writeBin", nextElement, con ) );
I meant : lang3( install( "writeBin"), nextElement, con )
SEXP res = PROTECT( eval( call, R_GlobalEnv) ) ;
/* grab the number of bytes actually sent out */
int n = INTEGER(res)[0] ;
UNPROTECT(3) ; /* res, call, nextElement */
We do the same with "readBin" to read from a binary connection chunk by
chunk.
Romain
On 12/05/2009 07:06 PM, Tobias Verbeke wrote:
Hi,
Gabor Grothendieck wrote:
Its not just the time. Its also the nuisance of having to manage files
that
I never needed in the first place.
I agree with Gabor that it is more than a 'nice to have'.
There are situations (when integrating R with other
applications) you don't want to touch a disk and
manage files afterwards (e.g. when one wants to pass
a byte string).
A recent question on the topic can be found here:
http://tolstoy.newcastle.edu.au/R/e8/help/09/11/5902.html
Best,
Tobias
On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois
wrote:
On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:
Thanks.
I am looking for the data to be just as if I had read in the png
file (or
wmf file or whatever).
Hi,
You are after the binary payload of the rendered graph as a png
file. So
you are going to have to go through a png file.
It would be nice to be able to render to a binary connection, like a
rawConnection, but it seems like an expensive "nice to have"
grid.cap seems to give a bitmap and then would
require some sort of processing to get the png or wmf, etc. form.
Also
note
that I need it for classic graphics and not just grid graphics.
grid.cap does not seem to care, baptiste code uses traditional
graphics
What I have right now works just as I want it _except_ I have to
create a
file and then read it back in which seems a waste.
Can you measure the time it takes to do dev.off() and readBin ?
On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
baptiste.aug...@googlemail.com> wrote:
Hi,
You can use grid.cap,
x11()
plot(1:10)
g = grid.cap()
dev.off()
str(g)
# chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
but as far as I understand in ?grid.cap and the underlying code
there
is no "capGrob" equivalent that wouldn't require opening a new
device
before capturing the output.
I hope I'm mistaken.
Best,
baptiste
2009/12/4 Gabor Grothendieck:
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 = 1)
(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
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-nei
Re: [Rd] raster support in graphics devices
On Dec 6, 2009, at 8:24 AM, Romain Francois wrote:
> On 12/06/2009 01:20 AM, Simon Urbanek wrote:
>> 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
>
> As much as I'd love a C API for connections, streaming graphics out to
> connections don't necessarily have to depend on a C api. The trick we use in
> the RProtoBuf package to stream out to a binary connection is to call the R
> function writeBin several times. Something like:
>
> /* next element is some raw vector we want to stream out */
> SEXP nextElement = PROTECT( getNextElement() ) ;
>
> /* con is the INTSXP connection number */
> /* create the call : writeBin( nextElement, con ) */
> SEXP call = PROTECT( lang3( "writeBin", nextElement, con ) );
> SEXP res = PROTECT( eval( call, R_GlobalEnv) ) ;
>
> /* grab the number of bytes actually sent out */
> int n = INTEGER(res)[0] ;
>
> UNPROTECT(3) ; /* res, call, nextElement */
>
> We do the same with "readBin" to read from a binary connection chunk by chunk.
>
Well, that's a hack like any other and error handling will be a pain. Of course
you can always use the evaluator, but I would not want to write or maintain a
hack like that :)
Cheers,
Simon
>
>
>
>>> On 12/05/2009 07:06 PM, Tobias Verbeke wrote:
Hi,
Gabor Grothendieck wrote:
> Its not just the time. Its also the nuisance of having to manage files
> that
> I never needed in the first place.
I agree with Gabor that it is more than a 'nice to have'.
There are situations (when integrating R with other
applications) you don't want to touch a disk and
manage files afterwards (e.g. when one wants to pass
a byte string).
A recent question on the topic can be found here:
http://tolstoy.newcastle.edu.au/R/e8/help/09/11/5902.html
Best,
Tobias
> On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois
> > wrote:
>
>> On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:
>>
>>> Thanks.
>>>
>>> I am looking for the data to be just as if I had read in the png
>>> file (or
>>> wmf file or whatever).
>>>
>> Hi,
>>
>> You are after the binary payload of the rendered graph as a png file. So
>> you are going to have to go through a png file.
>>
>> It would be nice to be able to render to a binary connection, like a
>> rawConnection, but it seems like an expensive "nice to have"
>>
>>
>> grid.cap seems to give a bitmap and then would
>>> require some sort of processing to get the png or wmf, etc. form. Also
>>> note
>>> that I need it for classic graphics and not just grid graphics.
>>>
>> grid.cap does not seem to care, baptiste code uses traditional graphics
>>
>>
>> What I have right now works just as I want it _except_ I have to
>> create a
>>> file and then read it back in which seems a waste.
>>>
>> Can you measure the time it takes to do dev.off() and readBin ?
>>
>>
>> On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
>>> baptiste.aug...@googlemail.com> wrote:
>>>
>>> Hi,
You can use grid.cap,
x11()
plot(1:10)
g = grid.cap()
dev.off()
str(g)
# chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
but as far as I understand in ?grid.cap and the underlying code there
is no "capGrob" equivalent that wouldn't require opening a new device
before capturing the output.
I hope I'm mistaken.
Best,
baptiste
2009/12/4 Gabor Grothendieck:
> 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 = 1)
>
> (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 t
Re: [Rd] raster support in graphics devices
On 12/06/2009 02:49 PM, Simon Urbanek wrote:
On Dec 6, 2009, at 8:24 AM, Romain Francois wrote:
On 12/06/2009 01:20 AM, Simon Urbanek wrote:
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
As much as I'd love a C API for connections, streaming graphics out to
connections don't necessarily have to depend on a C api. The trick we use in
the RProtoBuf package to stream out to a binary connection is to call the R
function writeBin several times. Something like:
/* next element is some raw vector we want to stream out */
SEXP nextElement = PROTECT( getNextElement() ) ;
/* con is the INTSXP connection number */
/* create the call : writeBin( nextElement, con ) */
SEXP call = PROTECT( lang3( "writeBin", nextElement, con ) );
SEXP res = PROTECT( eval( call, R_GlobalEnv) ) ;
/* grab the number of bytes actually sent out */
int n = INTEGER(res)[0] ;
UNPROTECT(3) ; /* res, call, nextElement */
We do the same with "readBin" to read from a binary connection chunk by chunk.
Well, that's a hack like any other and error handling will be a pain. Of course
you can always use the evaluator, but I would not want to write or maintain a
hack like that :)
Cheers,
Simon
Fair enough, so back to square one with Jeff's patch. Since jeff's
original post or other reminders did not get replied (at least
publicly), it is not clear what one can do to help moving to the
direction of a C api for connection: a patch providing a higher level
api, testing, documentation ?
On 12/05/2009 07:06 PM, Tobias Verbeke wrote:
Hi,
Gabor Grothendieck wrote:
Its not just the time. Its also the nuisance of having to manage files
that
I never needed in the first place.
I agree with Gabor that it is more than a 'nice to have'.
There are situations (when integrating R with other
applications) you don't want to touch a disk and
manage files afterwards (e.g. when one wants to pass
a byte string).
A recent question on the topic can be found here:
http://tolstoy.newcastle.edu.au/R/e8/help/09/11/5902.html
Best,
Tobias
On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois
wrote:
On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:
Thanks.
I am looking for the data to be just as if I had read in the png
file (or
wmf file or whatever).
Hi,
You are after the binary payload of the rendered graph as a png file. So
you are going to have to go through a png file.
It would be nice to be able to render to a binary connection, like a
rawConnection, but it seems like an expensive "nice to have"
grid.cap seems to give a bitmap and then would
require some sort of processing to get the png or wmf, etc. form. Also
note
that I need it for classic graphics and not just grid graphics.
grid.cap does not seem to care, baptiste code uses traditional graphics
What I have right now works just as I want it _except_ I have to
create a
file and then read it back in which seems a waste.
Can you measure the time it takes to do dev.off() and readBin ?
On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
baptiste.aug...@googlemail.com> wrote:
Hi,
You can use grid.cap,
x11()
plot(1:10)
g = grid.cap()
dev.off()
str(g)
# chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
but as far as I understand in ?grid.cap and the underlying code there
is no "capGrob" equivalent that wouldn't require opening a new device
before capturing the output.
I hope I'm mistaken.
Best,
baptiste
2009/12/4 Gabor Grothendieck:
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 = 1)
(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
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 b
Re: [Rd] raster support in graphics devices
Hi
baptiste auguie wrote:
Hi again,
I found two possible bugs related to grid.raster, one with the quartz
device and the other with pdf.
In my example I was playing with the idea of using grid.raster to
create a filling pattern for rectangles. The pdf output does not seem
to respect the clipping (it may have nothing to do with grid.raster
though), whilst the quartz device with pdf file output often crashes
for more than 4 different raster objects (but not always). I'm afraid
I couldn't pinpoint the exact circumstance of the crash with a more
concise example.
Thanks again for the report.
I have committed a fix for the PDF clipping.
Still looking at the Quartz crashes.
Paul
Thanks in advance for any insights,
baptiste
### Start example ###
library(grid)
## create a motif
grid45 <- function(..., width=0.5, height=0.5){
x11(width=width, height=height)
grid.polygon(...)
m <- grid.cap()
dev.off()
invisible(m)
}
.grid45 <- grid45()
## grid.raster(.grid45)
tile.motif <- function(m, nx=10, ny=nx){
cols <- matrix(rep(m, nx), ncol=ncol(m)*nx, byrow=F)
matrix(rep(t(cols), ny), nrow=nrow(cols)*ny, byrow=T)
}
## quartz()
## grid.raster(tile.motif(.grid45, 2, 3))
patternGrob <- function(x=unit(0.5, "npc"), y=unit(0.5, "npc"),
width=unit(1, "npc"), height=unit(1, "npc"),
motif=matrix("white"), AR=1,
motif.width=unit(5, "mm"),
motif.height=AR*motif.width,
pattern.offset=c(0, 0), # unimplemented
default.units="npc",
clip=TRUE, # testing purposes
gp=gpar(fill=NA), ...)
{
grob(x=x, y=y, width=width, height=height,
motif=motif, motif.width=motif.width,
motif.height=motif.height, clip=clip, gp=gp, ..., cl="pattern")
}
widthDetails.pattern <- function(x) x$width
heightDetails.pattern <- function(x) x$height
drawDetails.pattern <- function(x, recording=TRUE){
## calculate the number of tiles
nx <- ceiling(convertUnit(x$width, "in", value=TRUE) /
convertUnit(x$motif.width, "in", value=TRUE)) + 1
ny <- ceiling(convertUnit(x$height, "in", axisFrom = "y", value=TRUE) /
convertUnit(x$motif.height, "in", axisFrom = "y",
value=TRUE)) + 1
width <- convertUnit(x$width, "in")
height <- convertUnit(x$height, "in", axisFrom = "y")
## clip the raster
pushViewport(viewport(x=x$x, y=x$y,
width=x$width, height=x$height, clip=x$clip))
grid.raster(tile.motif(x$motif, nx, ny), width=nx*x$motif.width,
height=ny*x$motif.height)
upViewport()
## overlay the rectangle
grid.rect(x=x$x, y=x$y,
width=x$width, height=x$height,
just="center", gp=x$gp)
}
g <- patternGrob(x=0.7, width=unit(0.3, "npc"),
height=unit(5.2, "cm"),
clip=TRUE, motif=.grid45)
## interactive use: OK
quartz()
grid.newpage()
grid.draw(g)
## png: OK
png(file="pngClip.png")
grid.newpage()
grid.draw(g)
dev.off()
## pdf: clipping does not occur
pdf(file="pdfClip.pdf")
grid.newpage()
grid.draw(g)
dev.off()
## quartz pdf: OK, but see below
quartz(file="quartzClip.pdf", type="pdf")
grid.newpage()
grid.draw(g)
dev.off()
g1 <- patternGrob(x=0.2, width=unit(0.2, "npc"),
height=unit(5.2, "cm"),
clip=TRUE, motif=.grid45)
g2 <- patternGrob(x=0.4, width=unit(0.2, "npc"),
height=unit(5.2, "cm"),
clip=TRUE, motif=.grid45)
g3 <- patternGrob(x=0.6, width=unit(0.2, "npc"),
height=unit(5.2, "cm"),
clip=TRUE, motif=.grid45)
g4 <- patternGrob(x=0.8, width=unit(0.2, "npc"),
height=unit(5.2, "cm"),
clip=TRUE, motif=.grid45)
quartz(file="quartzClip2.pdf", type="pdf")
grid.newpage()
grid.draw(g1)
grid.draw(g2)
grid.draw(g3)
grid.draw(g4)
dev.off()
*** caught segfault ***
address 0x15dda018, cause 'memory not mapped'
Traceback:
1: dev.off()
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] grid stats graphics grDevices utils datasets methods
[8] base
2009/12/2 Paul Murrell :
Hi
baptiste auguie wrote:
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 may be due to the fact that I tested the changes on Mac OS X 10.6
(looks like you have 10.5 ?), plus the fact that I am feeling my way a bit
on the Mac. I have access to a 10.4 machine so I will try to take a look
there. Thanks for the report.
Paul
This works fine:
library(grid)
x1
Re: [Rd] raster support in graphics devices
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.
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 :
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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Hi,
2009/12/6 Paul Murrell :
> 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 :
>>>
>>> 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
>>> p...@stat.auckland.ac.nz
>>> http://www.stat.auckland.ac.nz/~paul/
>>>
>>> __
>>> R-devel@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
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] raster support in graphics devices
Hi,
Thanks for the fix. I hope the quartz bugs are not related to a bad
configuration on my side (I don't have access to another Mac to test
it).
I was quite happy with this proof-of-concept of filling patterns for
rectangles, and I was wondering if perhaps you had considered adding a
similar tiling option to grid.raster (at the C level)?
Best regards,
baptiste
2009/12/6 Paul Murrell :
> Hi
>
>
> baptiste auguie wrote:
>>
>> Hi again,
>>
>> I found two possible bugs related to grid.raster, one with the quartz
>> device and the other with pdf.
>>
>> In my example I was playing with the idea of using grid.raster to
>> create a filling pattern for rectangles. The pdf output does not seem
>> to respect the clipping (it may have nothing to do with grid.raster
>> though), whilst the quartz device with pdf file output often crashes
>> for more than 4 different raster objects (but not always). I'm afraid
>> I couldn't pinpoint the exact circumstance of the crash with a more
>> concise example.
>
>
> Thanks again for the report.
>
> I have committed a fix for the PDF clipping.
>
> Still looking at the Quartz crashes.
>
> Paul
>
>
>> Thanks in advance for any insights,
>>
>> baptiste
>>
>> ### Start example ###
>>
>> library(grid)
>>
>> ## create a motif
>> grid45 <- function(..., width=0.5, height=0.5){
>> x11(width=width, height=height)
>> grid.polygon(...)
>> m <- grid.cap()
>> dev.off()
>> invisible(m)
>> }
>>
>> .grid45 <- grid45()
>> ## grid.raster(.grid45)
>>
>> tile.motif <- function(m, nx=10, ny=nx){
>> cols <- matrix(rep(m, nx), ncol=ncol(m)*nx, byrow=F)
>> matrix(rep(t(cols), ny), nrow=nrow(cols)*ny, byrow=T)
>> }
>>
>> ## quartz()
>> ## grid.raster(tile.motif(.grid45, 2, 3))
>>
>> patternGrob <- function(x=unit(0.5, "npc"), y=unit(0.5, "npc"),
>> width=unit(1, "npc"), height=unit(1, "npc"),
>> motif=matrix("white"), AR=1,
>> motif.width=unit(5, "mm"),
>> motif.height=AR*motif.width,
>> pattern.offset=c(0, 0), # unimplemented
>> default.units="npc",
>> clip=TRUE, # testing purposes
>> gp=gpar(fill=NA), ...)
>> {
>> grob(x=x, y=y, width=width, height=height,
>> motif=motif, motif.width=motif.width,
>> motif.height=motif.height, clip=clip, gp=gp, ..., cl="pattern")
>> }
>>
>> widthDetails.pattern <- function(x) x$width
>> heightDetails.pattern <- function(x) x$height
>>
>> drawDetails.pattern <- function(x, recording=TRUE){
>>
>> ## calculate the number of tiles
>> nx <- ceiling(convertUnit(x$width, "in", value=TRUE) /
>> convertUnit(x$motif.width, "in", value=TRUE)) + 1
>> ny <- ceiling(convertUnit(x$height, "in", axisFrom = "y", value=TRUE) /
>> convertUnit(x$motif.height, "in", axisFrom = "y",
>> value=TRUE)) + 1
>>
>> width <- convertUnit(x$width, "in")
>> height <- convertUnit(x$height, "in", axisFrom = "y")
>>
>> ## clip the raster
>> pushViewport(viewport(x=x$x, y=x$y,
>> width=x$width, height=x$height, clip=x$clip))
>>
>> grid.raster(tile.motif(x$motif, nx, ny), width=nx*x$motif.width,
>> height=ny*x$motif.height)
>> upViewport()
>>
>> ## overlay the rectangle
>> grid.rect(x=x$x, y=x$y,
>> width=x$width, height=x$height,
>> just="center", gp=x$gp)
>> }
>>
>>
>> g <- patternGrob(x=0.7, width=unit(0.3, "npc"),
>> height=unit(5.2, "cm"),
>> clip=TRUE, motif=.grid45)
>>
>> ## interactive use: OK
>> quartz()
>> grid.newpage()
>> grid.draw(g)
>>
>> ## png: OK
>> png(file="pngClip.png")
>> grid.newpage()
>> grid.draw(g)
>> dev.off()
>>
>> ## pdf: clipping does not occur
>> pdf(file="pdfClip.pdf")
>> grid.newpage()
>> grid.draw(g)
>> dev.off()
>>
>> ## quartz pdf: OK, but see below
>> quartz(file="quartzClip.pdf", type="pdf")
>> grid.newpage()
>> grid.draw(g)
>> dev.off()
>>
>> g1 <- patternGrob(x=0.2, width=unit(0.2, "npc"),
>> height=unit(5.2, "cm"),
>> clip=TRUE, motif=.grid45)
>>
>> g2 <- patternGrob(x=0.4, width=unit(0.2, "npc"),
>> height=unit(5.2, "cm"),
>> clip=TRUE, motif=.grid45)
>>
>> g3 <- patternGrob(x=0.6, width=unit(0.2, "npc"),
>> height=unit(5.2, "cm"),
>> clip=TRUE, motif=.grid45)
>>
>> g4 <- patternGrob(x=0.8, width=unit(0.2, "npc"),
>> height=unit(5.2, "cm"),
>> clip=TRUE, motif=.grid45)
>>
>> quartz(file="quartzClip2.pdf", type="pdf")
>> grid.newpage()
>> grid.draw(g1)
>> grid.draw(g2)
>> grid.draw(g3)
>> grid.draw(g4)
>> dev.off()
>>
>> *** caught segfault ***
>> address 0x15dda018, cause 'memory not mapped'
>>
>> Traceback:
>> 1: dev.off()
>>
>> 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.UT
Re: [Rd] raster support in graphics devices
Hi
baptiste auguie wrote:
Hi,
Thanks for the fix. I hope the quartz bugs are not related to a bad
configuration on my side (I don't have access to another Mac to test
it).
I have not been able to get hold of a 10.5 (Leopard) Mac either. Keen
to hear confirmation from anyone else with this problem.
I was quite happy with this proof-of-concept of filling patterns for
rectangles, and I was wondering if perhaps you had considered adding a
similar tiling option to grid.raster (at the C level)?
I have thought a bit about drawing the same image multiple times (more
in the context of using a bitmap for a plotting symbol). I imagine
something like being able to "add" a raster image to a device and then
simply "refer" to that image (e.g., by name) is needed. Still thinking
about the right way to go about that though.
Paul
Best regards,
baptiste
2009/12/6 Paul Murrell :
Hi
baptiste auguie wrote:
Hi again,
I found two possible bugs related to grid.raster, one with the quartz
device and the other with pdf.
In my example I was playing with the idea of using grid.raster to
create a filling pattern for rectangles. The pdf output does not seem
to respect the clipping (it may have nothing to do with grid.raster
though), whilst the quartz device with pdf file output often crashes
for more than 4 different raster objects (but not always). I'm afraid
I couldn't pinpoint the exact circumstance of the crash with a more
concise example.
Thanks again for the report.
I have committed a fix for the PDF clipping.
Still looking at the Quartz crashes.
Paul
Thanks in advance for any insights,
baptiste
### Start example ###
library(grid)
## create a motif
grid45 <- function(..., width=0.5, height=0.5){
x11(width=width, height=height)
grid.polygon(...)
m <- grid.cap()
dev.off()
invisible(m)
}
.grid45 <- grid45()
## grid.raster(.grid45)
tile.motif <- function(m, nx=10, ny=nx){
cols <- matrix(rep(m, nx), ncol=ncol(m)*nx, byrow=F)
matrix(rep(t(cols), ny), nrow=nrow(cols)*ny, byrow=T)
}
## quartz()
## grid.raster(tile.motif(.grid45, 2, 3))
patternGrob <- function(x=unit(0.5, "npc"), y=unit(0.5, "npc"),
width=unit(1, "npc"), height=unit(1, "npc"),
motif=matrix("white"), AR=1,
motif.width=unit(5, "mm"),
motif.height=AR*motif.width,
pattern.offset=c(0, 0), # unimplemented
default.units="npc",
clip=TRUE, # testing purposes
gp=gpar(fill=NA), ...)
{
grob(x=x, y=y, width=width, height=height,
motif=motif, motif.width=motif.width,
motif.height=motif.height, clip=clip, gp=gp, ..., cl="pattern")
}
widthDetails.pattern <- function(x) x$width
heightDetails.pattern <- function(x) x$height
drawDetails.pattern <- function(x, recording=TRUE){
## calculate the number of tiles
nx <- ceiling(convertUnit(x$width, "in", value=TRUE) /
convertUnit(x$motif.width, "in", value=TRUE)) + 1
ny <- ceiling(convertUnit(x$height, "in", axisFrom = "y", value=TRUE) /
convertUnit(x$motif.height, "in", axisFrom = "y",
value=TRUE)) + 1
width <- convertUnit(x$width, "in")
height <- convertUnit(x$height, "in", axisFrom = "y")
## clip the raster
pushViewport(viewport(x=x$x, y=x$y,
width=x$width, height=x$height, clip=x$clip))
grid.raster(tile.motif(x$motif, nx, ny), width=nx*x$motif.width,
height=ny*x$motif.height)
upViewport()
## overlay the rectangle
grid.rect(x=x$x, y=x$y,
width=x$width, height=x$height,
just="center", gp=x$gp)
}
g <- patternGrob(x=0.7, width=unit(0.3, "npc"),
height=unit(5.2, "cm"),
clip=TRUE, motif=.grid45)
## interactive use: OK
quartz()
grid.newpage()
grid.draw(g)
## png: OK
png(file="pngClip.png")
grid.newpage()
grid.draw(g)
dev.off()
## pdf: clipping does not occur
pdf(file="pdfClip.pdf")
grid.newpage()
grid.draw(g)
dev.off()
## quartz pdf: OK, but see below
quartz(file="quartzClip.pdf", type="pdf")
grid.newpage()
grid.draw(g)
dev.off()
g1 <- patternGrob(x=0.2, width=unit(0.2, "npc"),
height=unit(5.2, "cm"),
clip=TRUE, motif=.grid45)
g2 <- patternGrob(x=0.4, width=unit(0.2, "npc"),
height=unit(5.2, "cm"),
clip=TRUE, motif=.grid45)
g3 <- patternGrob(x=0.6, width=unit(0.2, "npc"),
height=unit(5.2, "cm"),
clip=TRUE, motif=.grid45)
g4 <- patternGrob(x=0.8, width=unit(0.2, "npc"),
height=unit(5.2, "cm"),
clip=TRUE, motif=.grid45)
quartz(file="quartzClip2.pdf", type="pdf")
grid.newpage()
grid.draw(g1)
grid.draw(g2)
grid.draw(g3)
grid.draw(g4)
dev.off()
*** caught segfault ***
address 0x15dda018, cause 'memory not mapped'
Traceback:
1: dev.off()
sessionInfo()
R version 2.11.0 Under development (unstable) (2009-11-30 r5062
Re: [Rd] raster support in graphics devices
Hi,
[my message below is a bit off-topic]
2009/12/14 Paul Murrell :
> I have thought a bit about drawing the same image multiple times (more in
> the context of using a bitmap for a plotting symbol). I imagine something
> like being able to "add" a raster image to a device and then simply "refer"
> to that image (e.g., by name) is needed.
That would be nice.
I first thought that this new rasterGrob would be a good way to
implement some kind of filling pattern for grid graphics, but after
some more testing I was surprised to see that a similar approach with
vector patterns could result in more efficient, better output. Of
course raster filling patterns could still be nice to have for fancy
images or gradients.
One thing that worries me with the approach I've taken below is that
the grob is not vectorized. In particular, if one was to use it as a
building block for histograms (as in base graphics' density parameter)
each rectangle would have to be drawn in sequence. I can of course
Vectorize() this grob into a new one (gTree) but I haven't seen any
examples like this before. Does this sound reasonable? (argument
explosion might be another problem...)
Best regards,
baptiste
Below is the gist of my experiments (the first part is not related to
grid.raster and runs in current R).
library(grid)
## vector patterns
source("http://gridextra.googlecode.com/svn/trunk/R/vpattern.r";)
dev.new()
grid.newpage()
grid.vpattern(x=0.2, width=unit(3,"cm"), height=unit(0.5,"npc"),
motif="points", motif.params=list(pch=22,
gp=gpar(cex=0.8, lwd=5, col="grey90",
fill="grey95")), clip=T)
grid.vpattern(x=0.5, width=unit(0.3,"npc"), height=unit(0.5,"npc"),
motif="segments", motif.params=list(angle=45,
gp=gpar(lty=2, col="grey", lwd=2.4)))
grid.vpattern(x=0.5, y=0.9, width=unit(0.5,"npc"), height=unit(1,"cm"),
motif="points", motif.params=list(pch="+"), clip=F,
pattern.offset=c(1, 0.5))
grid.vpattern(x=0.8, width=unit(0.2,"npc"), height=unit(0.2,"npc"),
motif="grid", motif.params=list(angle=45,
gp=gpar(lwd=10, col="grey90")), clip=T,
pattern.offset=c(-1, 0.5))
grid.vpattern(x=0.5, y=0.1, width=unit(0.9,"npc"), height=unit(0.1,"npc"),
motif="grid", motif.params=list(angle=30, gp=gpar(col="red")),
gp=gpar(alpha=0.1, fill="red"))
## raster patterns
source("http://gridextra.googlecode.com/svn/trunk/R/rpattern.r";)
## a raster motif
plus <- function(..., width=5, height=5){
x11(width=width/25.4, height=height/25.4)
grid.points(x=unit(0.5, "npc"), y=unit(0.5, "npc"),
pch=3, size=unit(2, "mm"), gp=gpar(), ...)
m <- grid.cap()
dev.off()
invisible(m)
}
.plus <- plus()
g1 <- rpatternGrob(x=0.5, y=0.4, width=unit(3.7, "cm"),
height=unit(0.4, "npc"),
clip=TRUE, motif=.plus)
dev.new()
grid.draw(g1)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
