Ben, I have committed something analogous to R-devel (your rotation code was not unlike mine, I replicated the color handling from R internals to be consistent, I fixed the drawing limits and added a check for x/y conformance). Note that useRaster can only be used when x, y form a regular grid. Although I tried a lot of corner cases (requiring quite a few fixes), I'm sure I did not test all of them, so volunteers please give it a go and compare it with non-raster output.
The only thing I'm not quite happy about is the argument name: useRaster. Personally, I hate camel case in R (it has crept in more recently making it horribly inconsistent) so please feel free to suggest a better name ;). Thanks, Simon On Feb 9, 2011, at 10:06 AM, Ben Bolker wrote: > On 11-02-08 10:03 PM, Simon Urbanek wrote: >> Ben, >> >> did you actually look at the result of your function with useRaster=TRUE ? >> ;) [Hint: don't use an image that is symmetric] >> >> Apart from that nice bug there are more issues as well, try >> image(matrix(1:4,2),col=1:3) >> The underlying issue is that as.raster() is not quite what you would hope. >> Unfortunately I'm not aware of an easy fix (that doesn't involve going > back to RGB decomposition). >> >> In general, I think it's a nice option, but I don't think you'll get away >> with only a few lines... >> >> Cheers, >> Simon >> >> >> >> On Feb 8, 2011, at 8:49 PM, Ben Bolker wrote: >> >>> >>> Has anyone yet tried incorporating rasterImage into the base image() >>> function? It seems to make a *huge* difference, with >>> a very small number of added/changed lines of code. (Of course I have >>> barely tested it at all.) >>> Is there any reason this *shouldn't* go into the next release? >>> >>>> source("image.R") >>>> z <- matrix(runif(1e6),nrow=1000) >>>> image(z) >>>> image(z,useRaster=TRUE) >>> >>> (Patch against SVN 54284 attached; people can contact me if it doesn't >>> go through and they want it.) >>> >>> Ben Bolker >>> >>> <image_diff.txt>______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel > > Trying again. Rotated counterclockwise within R (although this *could* > be coded in C if speed were important?) > Some brute-force testing suggests it is *slightly* slower for small > images (7 vs 8 seconds for 1000 reps) and still much faster (and > produces much smaller images, which don't suffer from antialiasing junk > in my PDF viewer) for large images. > <image_diff.txt><imagetest.R><image.R> ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel