[Rd] raster support in graphics devices

Simon Urbanek simon.urbanek at r-project.org
Sun Dec 6 14:49:54 CET 2009


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



More information about the R-devel mailing list