On Feb 14, 2011, at 2:28 PM, Paul Murrell wrote: > Hi > > On 15/02/2011 8:11 a.m., Simon Urbanek wrote: >> >> On Feb 14, 2011, at 12:26 PM, Ben Bolker wrote: >> >>> Paul Murrell<p.murrell<at> auckland.ac.nz> writes: >>> >>>> >>>> Hi >>>> >>>> On 12/02/2011 7:22 p.m., Michael Sumner wrote: >>>>> Hello, that appears to have fixed it. Thank you very much. >>>>> >>>>> I can now repeat the reported workflow and the image appears on >>>>> the fifth (and subsequent) calls. >>>> >>>> Great. Thanks for checking. >>>> >>>> Paul >>>> >>> >>> >>> That's great. >>> >>> Just a little bump: I would encourage Simon (in his copious spare >>> time), or other interested members of R-core, to decide on a good >>> name for the argument (as a reminder, I prefer >>> 'method=c("raster","image")'). Furthermore, I would strongly >>> encourage that "raster" be made the default behavior for the >>> development release of R ... >>> >> >> >> Unfortunately I just encountered a speed bump today - I had no idea >> that the Windows device doesn't even support transparent pixels. That >> needs to be fixed before we can make it the default... > > See the table at the bottom of > http://developer.r-project.org/Raster/raster-RFC.html for the full list of > limitations. >
Mea culpa - I had forgotten that the default for interpolate=TRUE (unfortunately) so all those dozens of warnings came from the fact that R was trying to interpolate on a device that doesn't support it. I stand corrected, transparent pixels are supported if interpolate=FALSE so image() should be safe. Thanks, Simon ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel