Jens Oehlschlägel-Akiyoshi
2000-Mar-29 16:37 UTC
[Rd] pre summary: mapping of colornames into hsv?
Hi Martin,
Great that you follow this. My original intention was to be able to
translate colornames to hsv because this would allow using colornames to cut
out a certain part of the colorwheel for colorcoding (HSV component H, see
my code below)
I think internally we might have colors represented as
Colornames, ColorIntegers, ColorHexcodes, ColorRGBs, ColorHSVs (ColorCMYs?)
however the R-user probably shouldn't see the internal ColorIntegers of the
C-code, as this might lead to confusion with the colornumbers resulting from
the palette settings.
So the R-user should see functions translating
ColorName2ColorHexcode() ColorHexcode2ColorRGB() and ColorRGB2ColorHSV()
and backwards
ColorHSV2ColorRGB() ColorRGB2ColorHexcode(), rather not
ColorHexcode2Colorname() as not every possible color is granted to have a
name.
Regards
Jens
P.S. the folowing function colorcode() I think is more general than
rainbow() in three aspects:
1) works also with not-equidistant colorcodings
2) works around the 'borders' of the colorwheel
3) works both directions along the colorwheel
With the above mentioned translation functions one could specify start= and
end= as colornames, which would make code more readable. Feel free to
include into R.
# 0 = red
# 1/6 = yellow
# 2/6 = green
# 3/6 = cyan
# 4/6 = blue
# 5/6 = violet
# go from red via yellow to green: start=0, stop=2/6
# go from green via yellow to red: start=2/6, stop=0
# go from green via cyan-blue-violet to red: start=2/6, stop=1
# go from red via violet-blue-cyan to green: start=0, stop=-4/6
colorcode <- function (p, start=0, end=2/6, s=1, v=1, ...)
{
# make p 0..1
r <- range(p)
p <- (p - r[1])/diff(r)
# wrap hue
up <- start <= end
start <- start %% 1
end <- end %% 1
if (up)
if (start < end){
h <- (start + p*(end-start)) %% 1
}else{
h <- (start + p*(1+end-start)) %% 1
}
else
if (end < start){
h <- (start - p*(start-end)) %% 1
}else{
h <- (start - p*(1+start-end)) %% 1
}
# round against bug if start=1 end=4/3 with p=seq(0, 1, 0.05)
hsv( round(h, 5), s, v, ...)
}
> -----Original Message-----
> From: Martin Maechler [mailto:maechler@stat.math.ethz.ch]
> Sent: Tuesday, March 28, 2000 4:07 PM
> To: jens.oehlschlaegel-akiyoshi@mdfactory.de
> Cc: R-core@stat.math.ethz.ch
> Subject: Re: [Rd] pre summary: mapping of colornames into hsv?
>
>
> >>>>> <jens.oehlschlaegel-akiyoshi@mdfactory.de>
writes on
> Feb.28, 2000 :
>
> Jens> etc/colors.big doesn't do the job currently, as:
>
> Jens> colors.big maps 455 names to rgb in S syntax
> Jens> rgb.txt maps 657 names to rgb in C syntax, but
> unlike colors() it has
> Jens> mixed upper and lower case
>
> Jens> The C source has the information twice
> Jens> rgb.c maps 657 names to rgb (mixed upper and lower case)
> Jens> graphics.c maps 657 names tp colorstrings (lower case only)
>
> Jens> internal name2col() and R colors() accesses those
> in graphics.c
>
> Jens> I tend to create a R representation which copies
> the info from
> Jens> graphics.c, unless someone plans to export internal
> name2col() to
> Jens> become an official R function, which of course
> would be a less
> Jens> redundant solution.
>
> and a day later, Jens provided
>
> .ColorDataBase <- matrix(c(
> "white", "#FFFFFF",
> "aliceblue", "#F0F8FF",
> "antiquewhite", "#FAEBD7",
> "antiquewhite1", "#FFEFDB",
> "antiquewhite2", "#EEDFCC",
> "antiquewhite3", "#CDC0B0",
> .............
> ))
>
> Now, we should stand back for a moment and
> think about what functionality we should provide on the R level.
>
> I think we should use the internal accessor functions to ColorDataBase
> (in graphics.c) in order ensure consistency not to further
> duplicate the
> information.
>
> {{Guido: Jens is right that src/gnuwin32/graphapp/rgb.c
> kind of replicates the table already available in
> src/main/graphics.c
> should we separate out this definition from graphics.c
> into a global src/main/rgb.c or something else
> after which (most of) graphapp/rgb.c wouldn't be needed anymore ?
> -- or just declare the tables in Graphics.h and use them in
> graphapp as well?
> }}
>
>
> Potential useful functions {from graphics.c} to be made
> available on the R
> level are
>
> hsv2rgb() (h,s,v) |-> (r,g,b)
>
> rgb2hsv() does *NOT* exist in graphics.c ;
> is it possible at all (i.e. is hsv <--> rgb 1:1 ?)}
>
> rgb2col(rgb_ch) |-> uint { := unsigned int }
> name2col (ch) |-> uint
> number2col(ch) |-> uint
> str2col (ch) |-> uint {calling one of the above 3 functions !}
>
> RGB2rgb(r,g,b) |-> #RRGGBB string
> col2name(uint) |-> name from colors() or #RRGGBB string
>
> -------
> I would tend to provide only
>
> * str2col() returning an R integer() {instead of uint; the
> R color model
> only needs the low order 24 bits,
> see beginning of Graphics.h }
> * col2name()
>
> at first, but one might also want
>
> uint <--> (r,g,b) <--> (h,s,v)
>
> o Further ideas ?
> o Are 24bit colors okay?
> gnuwin32's graphapp seems to use "transparency"
> additionally to 3x8 bit RGB {didn't look closely}
>
>
> Martin
>
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel 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-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
This has been an old topic, brought up last year by
Jens Oehlschlaegel and even before by Ben Bolker and maybe others.
Over the weekend I've finally taken some time,
and have implemented one new function on the R level,
basically exposing the underlying C function str2col() [main/graphics.c]
col2rgb() accepts a vector of all three kind of R colors :
1:n = indices into palette()
name = an element of colors()
#rrggbb = character with the rgb hex code.
Per color, it returns an integer(3) vector c(red,green,blue)
with elements from 0:255.
Currently {in my implementation},
when
r <- col2rgb(col)
r is a list() of the same length as col, and r[[j]] = c(red_j, green_j, blue_j)
e.g.
> str(col2rgb(paste("gold", 1:4, sep="")))
List of 4
$ : int [1:3] 255 215 0
$ : int [1:3] 238 201 0
$ : int [1:3] 205 173 0
$ : int [1:3] 139 117 0
>
This has been the easiest way of a vectorizing implementation.
Are the strong reasons why, e.g. a matrix should be returned instead ?
The matrix can `easily' be built by, e.g.
matrix(c(col2rgb(...) , recursive = TRUE), nrow = 3))
If it is felt that one always wanted this matrix (and dimnames, too),
it would maybe make sense to compute it in C.
---
Opinions?
Martin Maechler <maechler@stat.math.ethz.ch>
http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum LEO D10 Leonhardstr. 27
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-1-632-3408 fax: ...-1228 <><
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel 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-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._