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 <ggrothendi...@gmail.com>:
> > Currently I have an application that saves the current graphics image
> (that
> > was created with classic graphics or grid graphics) to a file and then
> reads
> > the file back in using readBin:
> >
> > png("my.png")
> > plot(1:10)
> > dev.off()
> > raw.img <- readBin("my.png", "raw", size = 1, n = 100000000)
> >
> > (I am doing this on Windows but would like to be able to do it on any
> > platform.)
> >
> > Does the new raster functionality give me any way to get the object
> raw.img
> > without creating the intermediate file, my.png? If so what is the
> > corresponding code?
> >
> >
> > On Mon, Nov 30, 2009 at 8:17 PM, Paul Murrell <p.murr...@auckland.ac.nz
> >wrote:
> >
> >> Hi
> >>
> >> This is for developers of extension packages that provide extra
> *graphics
> >> devices* for R.
> >>
> >> In the *development* version of R, support has been added to the
> graphics
> >> engine for sending raster images (bitmaps) to a graphics device. This
> >> consists mainly of two new device functions: dev_Raster() and
> dev_Cap().
> >>
> >> The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6
> as
> >> a marker of this change.
> >>
> >> This means that, at a minimum, all graphics devices should be updated to
> >> provide dummy implementations of these new functions that just say the
> >> feature is not yet implemented (see for example the PicTeX and XFig
> devices
> >> in the 'grDevices' package).
> >>
> >> A full implementation of dev_Raster() should be able to draw a raster
> image
> >> (provided as an array of 32-bit R colors) at any size, possibly
> (bilinear)
> >> interpolated (otherwise nearest-neighbour), at any orientation, and with
> a
> >> per-pixel alpha channel. Where these are not natively supported by a
> >> device, the graphics engine provides some routines for scaling and
> rotating
> >> raster images (see for example the X11 device). The dev_Cap() function
> >> should return a representation of a raster image captured from the
> current
> >> device. This will only make sense for some devices (see for example the
> >> Cairo device in the 'grDevices' package).
> >>
> >> A little more information and a couple of small examples are provided at
> >> http://developer.r-project.org/Raster/raster-RFC.html
> >>
> >> Paul
> >> --
> >> Dr Paul Murrell
> >> Department of Statistics
> >> The University of Auckland
> >> Private Bag 92019
> >> Auckland
> >> New Zealand
> >> 64 9 3737599 x85392
> >> p...@stat.auckland.ac.nz
> >> http://www.stat.auckland.ac.nz/~paul/<http://www.stat.auckland.ac.nz/%7Epaul/>
> <http://www.stat.auckland.ac.nz/%7Epaul/>
> >>
> >> ______________________________________________
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> > [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
