From jens.oehlschlaegel-akiyoshi@mdfactory.de  Wed Mar 29 17:37:29 2000
From: jens.oehlschlaegel-akiyoshi@mdfactory.de (=?iso-8859-1?Q?Jens_Oehlschl=E4gel-Akiyoshi?=)
Date: Wed, 29 Mar 2000 18:37:29 +0200
Subject: [Rd] pre summary: mapping of colornames into hsv?
In-Reply-To: <14560.48243.200487.325190@lynne.ethz.ch>
Message-ID: <000801bf999d$13c36170$a9021aac@joelschlaegel>



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


[Rd] pre summary: mapping of colornames into hsv?
=?iso-8859-1?Q?Jens_Oehlschl=E4gel-Akiyoshi?=