[R] Graphics device storable in a variable

Emmanuel Charpentier charpent at bacbuc.dyndns.org
Thu Nov 15 23:16:16 CET 2007


Just an couple of ideas that might or might not work ...

Josh Tolley a écrit :
> I'm using R embedded in PostgreSQL (via PL/R), and would like to use
> it to create images. It works fine, except that I have to create every
> image in a file (owned by and only readable by the PostgreSQL server),
> and then use PostgreSQL to read from that file and return it to the
> client. It would be much nicer if I could plot images into an R
> variable (for instance, a matrix), and return that variable through
> the PostgreSQL client. Leaving aside the details of returning the data
> to PostgreSQL (which I realize are beyond the scope of this list), I
> envision R code along the lines of the following:
> 
> # Create a png device, a handle to which is stored in myDevice
>> myDevice <- png.variable(height = 1280, width = 1024, bg = "white")
> # Plot some data into the current device
>> plot(myX, myY, col="red")
> # Finalize
>> dev.off()
> # Print out the contents of myDevice
>> myDevice
> 
> ...and the data would print out just like any other matrix or class or
> whatever type myDevice actually is.
> 
> So my question is does such a thing already exist? I know about
> piximage, but apparently I have to load image data from somewhere for
> it to work; I can't use plot(), etc. to create the piximage data. GDD
> would be a nice way to do it, because GD libraries are widely
> available for use with other languages I might use with PostgreSQL and
> PL/R (for instance, Perl would talk to PostgreSQL, call a PL/R
> function to use R to return an image, which Perl would then process
> further), but GDD requires temporary files as well, as far as I can
> see. Thanks for any help anyone can offer.

The documentation for the png device mentions a "filename" argument.
That might be a temporary file that another process (or a R or plpgsql
function, btw) could read and store in the correct Postgres table.

The package odfWeave uses something like this to insert graphs in an
Open Document file.

# What follows might work on unix and unix-alikes, possibly on Mac OS X
# (BSD-like). I do not know about Windows...

Furthermore, the png device doc cross-references the  postcript device
for details ; this latter doc mentions that a filename of the form
"|cmd" will effectively pipe device output to cmd, which is a
possibility that avoids file creation (but may well be as slow as with
temporary file creation, since one would have to go to the filesystem to
create a new process for cmd...). Furthermore, you'd have to pass
additional arguments to cmd (some reference for the graph, where is it
to be stored, and so on...). I do not know if the "| cmd" syntax would
pass additional arguments to cmd...

However, I wonder if the png device supports the "|cmd" syntax. It
*should*, but I've never tried that...

A third possibility would be to write to a named pipe whose output is
consumed by a process storing data in the relevant table
. This process should be somehow controlled (passing an identifier,
telling it what to store and when, etc...), possibly from *another*
named pipe

A fourth possibility would be to force the output (of plot and such) to
stdout and capture stdout with capture.output (package utils). However,
I have no idea on how to do that (from the outside, it seems
theoretically possible, but one might need special hooks in the
interpreter...

Of all those possibilities, the first one seems reasonable, easy to
implement, but has the drawback of using temporary files, which might be
a resource hog.

The second possibility is also a probable resource hog. The third might
be much more economical (a daemon might be set up with its input and
control pipes once for good), but might be difficult to set up in pl/r
(does this implementatin allows I/O from/to external files ?). The
fourth is much more problematic...

HTH

					Emmanuel Charpentier



More information about the R-help mailing list