From simon.urbanek at r-project.org  Sun Dec  6 01:20:38 2009
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Sat, 5 Dec 2009 19:20:38 -0500
Subject: [Rd] raster support in graphics devices
In-Reply-To: <4B1ACC79.90805@dbmail.com>
References: <4B146EC6.2000502@auckland.ac.nz>	<971536df0912040528w4226179el7f833c736941406d@mail.gmail.com>
	<de4e29f50912040606r365a932by697fd500460773aa@mail.gmail.com>
	<971536df0912040619r13f7d79bj340e8c2f7718b61f@mail.gmail.com>
	<4B193276.5010001@dbmail.com>
	<971536df0912040806v57bf8c5p3cb36e634208a9dc@mail.gmail.com>
	<4B1AA10E.3090004@gmail.com> <4B1ACC79.90805@dbmail.com>
Message-ID: <56EBD53C-DB97-4EF0-BB28-BD57E2BA4BFD@r-project.org>


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



> 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
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 



[Rd] raster support in graphics devices
Simon Urbanek