Hi,
[my message below is a bit off-topic]
2009/12/14 Paul Murrell :
> I have thought a bit about drawing the same image multiple times (more in
> the context of using a bitmap for a plotting symbol). I imagine something
> like being able to "add" a raster image to a device and then simply "refe
Hi
baptiste auguie wrote:
Hi,
Thanks for the fix. I hope the quartz bugs are not related to a bad
configuration on my side (I don't have access to another Mac to test
it).
I have not been able to get hold of a 10.5 (Leopard) Mac either. Keen
to hear confirmation from anyone else with this
Hi,
Thanks for the fix. I hope the quartz bugs are not related to a bad
configuration on my side (I don't have access to another Mac to test
it).
I was quite happy with this proof-of-concept of filling patterns for
rectangles, and I was wondering if perhaps you had considered adding a
similar til
Hi,
2009/12/6 Paul Murrell :
> Hi
>
>
> baptiste auguie wrote:
>>
>> Dear all,
>>
>> It seems to me that grid.raster is a special case of grid.rect as far
>> as the intended visual output is concerned. The example below
>> illustrates how both can be used to produce an image of the volcano
>> data
Hi
baptiste auguie wrote:
Dear all,
It seems to me that grid.raster is a special case of grid.rect as far
as the intended visual output is concerned. The example below
illustrates how both can be used to produce an image of the volcano
data,
I disagree. A "rect" grob is a vector object and
Hi
baptiste auguie wrote:
Hi again,
I found two possible bugs related to grid.raster, one with the quartz
device and the other with pdf.
In my example I was playing with the idea of using grid.raster to
create a filling pattern for rectangles. The pdf output does not seem
to respect the clipp
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
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.
>>>
>>>
On 12/06/2009 02:24 PM, 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 ?
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 t
I can confirm. Last time I checked (that is recently), there was no way
to do it at the C level (beside possibly extreme hacks trying to work
around what R does not want to expose, or go for patched source trees
and builds).
What is the status of this patch (accepted ? rejected ? else ?)
Thi
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 e
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
Dear all,
It seems to me that grid.raster is a special case of grid.rect as far
as the intended visual output is concerned. The example below
illustrates how both can be used to produce an image of the volcano
data,
d <- volcano
cols <- grey(t(d)/max(c(d)))
xy <- expand.grid(x=seq(0, 1, length=n
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
> Its not just the time. Its also the nuisance of having to manage files that
> I never needed in the first place.
In general, it's much easier to create output from a R object than
create an R object from output.
It's good programming practice to minimise the number of functions
with side-effec
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
Its not just the time. Its also the nuisance of having to manage files that
I never needed in the first place.
On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois 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
Right.
On Fri, Dec 4, 2009 at 10:53 AM, hadley wickham wrote:
> > Just to explain a bit more I am thinking about something like this:
> >
> > con <- graphicsConnection() # I've just made this up
> > png(con)
> > plot(1:10)
> > dev.off()
> > raw.img <- readBin(con, "raw", size = 1, n = 1)
> Just to explain a bit more I am thinking about something like this:
>
> con <- graphicsConnection() # I've just made this up
> png(con)
> plot(1:10)
> dev.off()
> raw.img <- readBin(con, "raw", size = 1, n = 1)
It seems to me what you actually want is for graphics devices to
support conn
Just to explain a bit more I am thinking about something like this:
con <- graphicsConnection() # I've just made this up
png(con)
plot(1:10)
dev.off()
raw.img <- readBin(con, "raw", size = 1, n = 1)
On Fri, Dec 4, 2009 at 8:28 AM, Gabor Grothendieck
wrote:
> Currently I have an applicat
Thanks.
I am looking for the data to be just as if I had read in the png file (or
wmf file or whatever). 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.
Wha
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
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 = 1)
(I am doing this
graphics are also important. R is a flexible tool for prototyping new
graphical methods.
Why shoot ourselves in the foot?
Anyway, nough said.
Nicholas
> --
>
> Message: 9
> Date: Wed, 2 Dec 2009 12:36:18 +1200
> From: Charlotte Maia
> Subject: Re: [Rd]
On 12/2/09, Simon Urbanek wrote:
> Charlotte,
>
>
> I would like to point out that implicitly you have been already using raster
> graphics all the time in very inefficient form in heatmaps etc. The point
> here is not really about added functionality for the user but efficiency,
> because now we
Hi
baptiste auguie wrote:
Very nice, thank you for this great addition to R graphics! I can't
wait to see lattice and ggplot2 functions that use rasterGrob to
display images. The pdf output is so much better in every way!
Incidentally, I ran into a segfault with grid.cap on the quartz
device,
Very nice, thank you for this great addition to R graphics! I can't
wait to see lattice and ggplot2 functions that use rasterGrob to
display images. The pdf output is so much better in every way!
Incidentally, I ran into a segfault with grid.cap on the quartz
device, but maybe it's normal at this
Charlotte,
On Nov 30, 2009, at 23:48 , Charlotte Maia wrote:
I consider raster graphics highly problematic in statistics.
People get caught up in the idea of creating pretty pictures, rather
than effectively visualising information.
Plus a lot of people (who should know better) needlessly put
> "CM" == Charlotte Maia
> on Tue, 1 Dec 2009 17:48:33 +1300 writes:
CM> Hi,
CM> I consider raster graphics highly problematic in statistics.
CM> People get caught up in the idea of creating pretty pictures, rather
CM> than effectively visualising information.
CM>
Hi,
I consider raster graphics highly problematic in statistics.
People get caught up in the idea of creating pretty pictures, rather
than effectively visualising information.
Plus a lot of people (who should know better) needlessly put raster
images inside reports and articles (even books), whic
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_Rast
32 matches
Mail list logo
