it would be nice (eg for vector maps) to have something like r.colors
color=,rules= where you could pass r.what.color a FP value= and some
color rules and have it output value|RRR:GGG:BBB for insertion into
a vector's table with Markus's proposed v.colors script. (for use with
modules that use GRASS_RGB column to get color)
For massive point maps without a table (X,Y,Z lidar data), it is
preferable to incorporate that into d.vect (or whatver) so color mapping
could be calculated at run time, not having to store each cat's color in
a DB.
it would be nice (eg for vector maps) to have something like r.colors
color=,rules= where you could pass r.what.color a FP value= and some
color rules and have it output value|RRR:GGG:BBB for insertion into
a vector's table with Markus's proposed v.colors script. (for use with
modules that use GRASS_RGB column to get color)
On 5/9/07 4:53 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
it would be nice (eg for vector maps) to have something like r.colors
I've never seen this mentioned before, but it's a great idea. Have a module
v.colors, like r.colors, that creates a color table for vectors (fill and
line). Then have a flag in d.vect that will display the vector using the
color table. In a number of ways, this is considerably more flexible than
the current rgb column approach that requires updating the attribute table
whenever you want to change a vector color map.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Only by changing format= to use a list of built-in formats; analysing
a format string isn't practical.
mhh. ok. I don't like to impose limits on what people can do, as it is
impossible to guess needs, but allowing the segfault isn't nice either.
float 0.0-1.0 (but how many decimal places?).
3 decimal places give 1 part per thousand, which is higher resolution
than the 1/256 input. You may remember that some time ago we changed
ps.map output colors from 2 decimal places to three so we didn't lose
information.
2. Separator: none, comma, colon (others?)
3. R/G/B vs B/G/R.
I saw the reference to that in the man page, what uses BGR?
Is CMYK just a calculation or is it more involved? Would it be useful
for anything, or just a gimmick?
Normally you want CMYK if you have to print in a device using
four-color processes.
You can project back and forth between RGB and CMYK, but the exercise
is mostly futile in the absence of proper color profiling. The GIMP
has lacked CMYK support forever, and it is a major argument against
its adoption in printing-related shops.
I saw the reference to that in the man page, what uses BGR?
Nothing in GRASS uses it; I don't know how useful it would be
externally. Ultimately, you can always swap the fields by other means,
e.g. awk '{print $3,$2,$1}'.
Is CMYK just a calculation or is it more involved?
It depends.
At the simplest level, RGB->CMYK is:
C' = 1-R
M' = 1-G
Y' = 1-B
K = min(C',M',Y')
C = C'-K
M = M'-K
Y = Y'-K
However, there are more complex implementations which use a profile
describing the actual colours of the inks; a common implementation
uses a matrix transformation. With such transformations, it's possible
that certain R/G/B colours (typically the "corners", where all
components are close to 0 or 1) cannot be represented as CMYK (i.e.
you end up with C/M/Y values outside of the 0-1 range).
Would it be useful for anything, or just a gimmick?
I don't think that it's really the job of r.what.color to perform such
translations. If you need CMYK, it's quite likely that you'll want to
use a specific colour profile, gamma correction etc.
> it would be nice (eg for vector maps) to have something like
> r.colors
Michael Barton wrote:
I've never seen this mentioned before, but it's a great idea. Have a
module v.colors, like r.colors, that creates a color table for vectors
(fill and line). Then have a flag in d.vect that will display the
vector using the color table. In a number of ways, this is
considerably more flexible than the current rgb column approach that
requires updating the attribute table whenever you want to change a
vector color map.
I hadn't considered putting a colr file in the vector/$MAP/ dir, but
it's an idea. Adding a single flag is cleaner than adding two+ new
options to the already cluttered d.vect.
so new -t flag, which works with the -a flag, to Take the primary
drawing color* from the colr file.
[*] primary color means line color, or for filled things, fill color.
(see "d.vect -c bugsites" vs "d.vect -c fields")
but where does it get its value from? the cat? from numeric rgb_column=?
(thus -t would change meaning of rgb_column=) or from the Z value?
need a new option to specify that?
(use default "none" to avoid needing a new -t flag)
color_ref->options = "none,z,cat,rgb_column"
that could be neat. v.support or better v.colors (wish GF#382) could be
used to copy the colr file into vector/$MAP/