[R] Colour depth reduced to 12 by bitmap devices
clive.jenkins at clara.net
Fri Jun 30 10:34:55 CEST 2000
Prof Brian D Ripley wrote:
> On Thu, 29 Jun 2000, Clive Jenkins wrote:
> > I am using R to create colour plots as bitmap files. I have created a
> > palette of 256 colours that I want to use, but the resultant output
> > files contain only 12 colours used in dither patterns. The result is the
> > same whether I use bmp() or png().
> What about bitmap()? Have you tried that?
I missed that one (it does not appear in the top-level List of Graphical
Devices in Devices.html or the output of ?device). I have tried it now,
but it only gives me 71 colourswith no dithering. This seems to be
independent of the screen graphics mode.
> Internally bmp/png/jpeg use take a copy of the screen, so what you get
> depends on your graphics card driver. If you are seeing dithering in the
> PNG file, do you see it on screen? Is your screen set to a truecolour
Yes, it is the same on-screen. I had not observed this before because I
have not been displaying the results on-screen: I thought I might avoid
any Windows-related colour restrictions by generating an image file
directly. This use of the graphics hardware would seem to imply that
bmp/png/jpeg cannot be used to create bitmap files using rterm on a
"traditional" UNIX machine with text-only terminals.
My screen was set to a 256-colour mode. After changing to a truecolour
mode, bmp() and png() now work exactly as I would expect (but I find my
image contains only 245 colours because of duplicates in my palette).
> bitmap() works via ghostscript.
> > How can I get the true colours that I specified instead of dither
> > patterns? (making the driver's job easier!)
> > I am using R 1.1.0 for Windows (rw1010). The attached files are:-
> > src256.R Test program to be run by source("src256.R")
> > col_256.R Colour palette read by src256.R
> > col_256.dat Test data representing a 16x16 square image using
> > all 256 colours
> > Rplot.png The resulting bitmap.
> > If anyone can improve on my code in src256.R, then please do so!
> > A further problem is that I cannot reduce the point size of the tick
> > labels (character strings in this case) using any of:-
> > par(cex=0.2)
> > par(cex.axis=0.2)
> > axis(..., cex=0.2, ...)
> > axis(..., cex.axis=0.2, ...)
This problem, although minor, is still unresolved. cex and cex.axis
settings also seem to be ignored when passed to image().
> > One final observation: in accordance with polymorphism of R, I would
> > prefer the function image() to take a data frame parameter directly,
> > e.g. image(a.df), so there would be no need to extract the row and
> > column names and pass them separately. Unfortunately this cannot be done
> > while retaining backward compatibility because the essential data item
> > is the third parameter not the first. As a messy compromise, perhaps
> > image() could be extended to accept image(,,a.df) where `a.df' is a data
> > frame.
> I just don't see how this can work. image requires x, y and z, and
> x and y are intended to be one longer than the rows and columns of the
> matrix z. That the equal-length case works is a historical anomaly,
> and only makes sense (to me) for reqularly spaced grids.
What I am suggesting is that image() should be able to display a data
frame as a table of colours instead of a table of numbers. It would
default to a regularly-spaced grid based on the number of rows and
columns of the data frame.
> You are quite at liberty to write a `myimage' function to your own
Yes, I might do that!
> Brian D. Ripley, ripley at stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272860 (secr)
> Oxford OX1 3TG, UK Fax: +44 1865 272595
Many thanks - my main problem is now resolved.
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch
More information about the R-help