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 ...
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
