[Rd] raster support in graphics devices

Romain Francois romain.francois at dbmail.com
Sun Dec 6 17:26:52 CET 2009 

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


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