I am trying to use R to create a bitmap from a data matrix. However, I get some strange artifacts at the edge of my image.
The code I use is as follows:
# From the example for rasterImage(). A 3 pixel by 5 pixel b/w checkerboard. testImage <- as.raster(0:1, nrow=3, ncol=5) testImage [,1] [,2] [,3] [,4] [,5] [1,] "#000000" "#FFFFFF" "#000000" "#FFFFFF" "#000000" [2,] "#FFFFFF" "#000000" "#FFFFFF" "#000000" "#FFFFFF" [3,] "#000000" "#FFFFFF" "#000000" "#FFFFFF" "#000000" png('test.png', width=5, height=3, units='px')
This was done in R 2.12.0 on OS X, but I get the same result from R 2.11.0.
The output I get is the following (scaled from 5x3 to 150x90)

The pixels in the corners should be black, which suggests some form of interpolation.
The output I expect to see is:

Any suggestions on why my code cannot accurately reproduce a bitmap from a matrix?
Intended Use
This is for the package I'm working on, so I would like to stay in the basic R packages, if possible, so as not to introduce additional dependencies. The package has a graphics device, so if someone has a C-level solution, it captures the information passed to GERaster() in src/main/engine.c and creates a PNG using only the R libraries, I would also like to give this snapshot.
OS X Solutions
As nico pointed out, erroneous behavior is the result of smoothing. The plot behaves as expected if png() told to use an output method for which you can turn off anti-aliasing, for example, Cairo graphics:
png('test.png', width=5, height=3, units='px', type='cairo', antialias=NULL)
In OS X, the default backend for png() is Quartz, however png(..., type='quartz') currently ignores the directives set by quartz.options() . The correct output can be produced initially on OS X if the device starts when you call quartz() directly instead of using png() :
quartz(file='test.png', type='png', width=5, height=3, dpi=1, antialias=FALSE)
Windows thinks differently
On Windows, the following output is generated:

According to the answer provided by Paul Merrell (the benevolent dictator of the device’s R-graphics) on the R-help mailing list:
This is a rounding (truncation) problem. Work on the fix.
This behavior on Windows should not be noticeable if the bitmap does not contain a very small number of pixels.