[Rd] raster support in graphics devices

Sun Dec 6 14:24:17 CET 2009

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

-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/Gq7i : ohloh
|- http://tr.im/FtUu : new package : highlight
`- http://tr.im/EAD5 : LondonR slides