On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek <simon.urba...@r-project.org> wrote: > > On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote: > >> On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek >> <simon.urba...@r-project.org> wrote: >>> 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 ;). >> >> It.is.spelled.camelCase. >> > > Fortunately not in English ;) > > >> What about style=c("image", "raster")? This allows for future extensions >> too. >> > > Hmm.. it's not really a "style" - the output doesn't change (ideally) - it's > more of a back-end specification .. also we already have oldstyle argument in > image() adding to the confusion ...
flavor=c("image", "raster") renderer=c("image", "raster") backend=c("image", "raster") ... ? /H > > Thanks, > Simon > > >>> >>> 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 >>> >> >> > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel