Hi, The move to sRGB is nice, is there any interest in adding an interface to lcms, http://www.littlecms.com, to allow gamut matching? I can think of a lot of instances where I would like to render a figure as it would appear on my printer. This is probably best done as a separate package though, at least at first. Nicholas
Martin Maechler wrote:
"Paul" == Paul Murrell <p.murrell at auckland.ac.nz>
on Wed, 05 Dec 2007 08:53:10 +1300 writes:
Paul> Hi
Paul> Achim and I have been looking at tidying up the colorspace package (see
Paul> http://r-forge.r-project.org/projects/colorspace/) to fix a few
Paul> inaccuracies, PLUS the possibility of declaring R's internal color space
Paul> to be sRGB.
Paul> I have started an RFC on the r-developer site
Paul> (http://developer.r-project.org/sRGB-RFC.html) to discuss some possible
Paul> changes to the core engine and add-on packages.
Paul> One of the issues will be consolidating some of the double-ups (e.g.,
Paul> hcl() in base and the counterpart in package 'colorspace'; I did not
Paul> even know about convertColor()!).
Paul> Ideally, we would have only one copy of the conversions between the
Paul> various colorspaces (probably C code, then the various R-level front
Paul> ends can all just run off the same internal code).
Paul> A lot of these conversions exist now in 'colorspace', but as Thomas
Paul> pointed out, the S4-ness of 'colorspace' is a problem for making these
Paul> conversions part of base R.
Hmm, I think we are currently only required to keep 'base' not
dependent on 'methods'.
Why should 'grDevices' or new "standard R" package not be
dependent on 'methods' ?
Many of us would like to see S4 been used much more widely.
Great. I will keep working on the RFC to see if I can propose a way to reconcile all of the color-conversion and palette-selection code based on a single sRGB representation in the R core and only one set of conversion functions. Paul
Martin