[Rd] raster support in graphics devices

[Romain Francois]

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