[GRASS-dev] Re: [GRASS-user] [off-topic] spoke too soon

GRASS GIS GRASS GIS developer
1

[taking this over to the devel list]

Parsing GRASS colour rules is very simple. It's all in the
GRASS Programmer's Manual.

Full docs for CPT format are here:

http://gmt.soest.hawaii.edu/gmt/doc/html/GMT_Docs/node58.html

(section 4.15 of the GMT docs)

Apparently, GMT supports HSV schemes, as well.

QUESTIONS:

1. Does GRASS also support colour models other than RGB?
2. Is '%" treated like a comment in the GRASS 'colr' files?
3. Is '#' as a comment indicator also OK in 'colr' files?
4. GMT also has labels for colour ranges. Would it be a good
idea to transfer those to the raster file (given that there
is no category labelling already or the user chooses to
overwrite it)?

Benjamin

Dylan Beaudette wrote:

On Wednesday 03 October 2007, Benjamin Ducke wrote:

Good stuff

All the palettes are available in GMT color format, which is just plain
ASCII and very similar to GRASS' own colour rule files in the 'cols'
database elements. The only major difference seems to be three
additional lines at the end of the file specifying colours for
foreground, background and no data areas which could simply be
discarded.

Indeed. Will have to poke around in the r.colors source -- anyone an expert on how the rules file is parsed?

So how about adding an option cpt=filename to r.colors, to set the
color rules for a raster map from a GMT ASCII file?

I think that this would be a great addition. The GMT folks might like it as well.

The best of these styles could still be hardcoded into r.colors'
database.

Agreed.

Benjamin

P.S.: Some of these palettes actually have licenses attached to them.
What sort of a world do we live in that requires the most trivial
things to be licensed? Come on people, you can give _some_ things to
the public domain w/o conditions ...

My thoughts exactly- however you are going to have to pay-up if you decide to implement this idea! j/k

Dylan

Dylan Beaudette wrote:

Sorry about those last two messages. My fingers where too fast for my
brain, and inadvertently caused the keys ctrl-enter to be pressed (curse
you Kmail!).

What I had tried to mention was the collection of color palette files
here:

http://sview01.wiredworkplace.net/pub/cpt-city/

Perhaps we can convert a pile of these into GRASS-compatible color rules
files.

Cheers,

Dylan

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

2

Benjamin Ducke wrote:

1. Does GRASS also support colour models other than RGB?

AFAIK, no. (but see r.his, d.his, d.rgb, i.his.rgb, i.rgb.his, ...)
CMYK is not supported. (but you can process the 4 channels as 4
different n-bit CELL raster maps if you like)

2. Is '%" treated like a comment in the GRASS 'colr' files?

No.

3. Is '#' as a comment indicator also OK in 'colr' files?

Yes. Blank lines are ok too.

currently lib/gis/color_rules.c uses fgets(), so only UNIX newlines are
accepted. Any reason not to make that use G_getl2()?

4. GMT also has labels for colour ranges. Would it be a good
idea to transfer those to the raster file (given that there
is no category labelling already or the user chooses to
overwrite it)?

an interesting idea, but let's get the color table working first before
we worry about that too much.

(I'm working on a proof of concept shell script first)

Hamish

3

Hamish wrote:

> 2. Is '%" treated like a comment in the GRASS 'colr' files?

No.

> 3. Is '#' as a comment indicator also OK in 'colr' files?

Yes. Blank lines are ok too.

Oh sorry, I was talking about input color rules files, not colr/ files.
Let the libgis fns deal with colr/, we shouldn't touch them.
We use "r.colors rules=filename" instead.

I now have a working .cpt -> grass color rules file, it will either output to a
ascii file, stdout, &/or apply them to an existing raster map.

I am working on a stretch flag as the GMT rules seem randomly to use ranges of
-1 to 1 or 0.0 to 1.0, or 0 to 32, etc. and only the global elevation in meters
rules are currently of use (but they look nice!)

Hamish

____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting

4

Please see below

On 10/3/07 12:13 PM, "Benjamin Ducke" <benjamin.ducke@ufg.uni-kiel.de>
wrote:

[taking this over to the devel list]

Parsing GRASS colour rules is very simple. It's all in the
GRASS Programmer's Manual.

Full docs for CPT format are here:

http://gmt.soest.hawaii.edu/gmt/doc/html/GMT_Docs/node58.html

(section 4.15 of the GMT docs)

Apparently, GMT supports HSV schemes, as well.

QUESTIONS:

1. Does GRASS also support colour models other than RGB?

GRASS color names (e.g., red, blue, yellow)

2. Is '%" treated like a comment in the GRASS 'colr' files?

It is treated like a percent.

0% black
50% red
100% green

is translated as make the lowest (0%) value black and grade to red at the
median value (50%), then continue to grade to blue to the highest value
(100%)

3. Is '#' as a comment indicator also OK in 'colr' files?

I don't think this is accepted. But try and see.

4. GMT also has labels for colour ranges. Would it be a good
idea to transfer those to the raster file (given that there
is no category labelling already or the user chooses to
overwrite it)?

Not sure what you mean here. Replace the label value with the RBG value?

Michael

Benjamin

Dylan Beaudette wrote:

On Wednesday 03 October 2007, Benjamin Ducke wrote:

Good stuff

All the palettes are available in GMT color format, which is just plain
ASCII and very similar to GRASS' own colour rule files in the 'cols'
database elements. The only major difference seems to be three
additional lines at the end of the file specifying colours for
foreground, background and no data areas which could simply be
discarded.

Indeed. Will have to poke around in the r.colors source -- anyone an expert
on
how the rules file is parsed?

So how about adding an option cpt=filename to r.colors, to set the
color rules for a raster map from a GMT ASCII file?

I think that this would be a great addition. The GMT folks might like it as
well.

The best of these styles could still be hardcoded into r.colors'
database.

Agreed.

Benjamin

P.S.: Some of these palettes actually have licenses attached to them.
What sort of a world do we live in that requires the most trivial
things to be licensed? Come on people, you can give _some_ things to
the public domain w/o conditions ...

My thoughts exactly- however you are going to have to pay-up if you decide to
implement this idea! j/k

Dylan

Dylan Beaudette wrote:

Sorry about those last two messages. My fingers where too fast for my
brain, and inadvertently caused the keys ctrl-enter to be pressed (curse
you Kmail!).

What I had tried to mention was the collection of color palette files
here:

http://sview01.wiredworkplace.net/pub/cpt-city/

Perhaps we can convert a pile of these into GRASS-compatible color rules
files.

Cheers,

Dylan

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

5

Benjamin Ducke wrote:

[taking this over to the devel list]

Parsing GRASS colour rules is very simple. It's all in the
GRASS Programmer's Manual.

Full docs for CPT format are here:

http://gmt.soest.hawaii.edu/gmt/doc/html/GMT_Docs/node58.html

(section 4.15 of the GMT docs)

Apparently, GMT supports HSV schemes, as well.

QUESTIONS:

1. Does GRASS also support colour models other than RGB?

No. It supports R/G/B, or a single (monochrome) intensity, or a named
colour.

Converting HSV->RGB on input won't produce the same result if GMT
interpolates the values in HSV space. Extending the core GRASS colour
handling to allow HSV colour rules isn't feasible, IMHO. If you want
to import HSV colour tables, the segments will need to be subdivided
to an adequate resolution.

2. Is '%" treated like a comment in the GRASS 'colr' files?
3. Is '#' as a comment indicator also OK in 'colr' files?

The format of "colr" files isn't relevant. Those files are read and
written by libgis; the file format isn't considered a public
interface.

The input format used by r.colors (lib/gis/color_rules.c) is
considered a public interface. That format uses # for comments, while
% is used for percentages.

4. GMT also has labels for colour ranges. Would it be a good
idea to transfer those to the raster file (given that there
is no category labelling already or the user chooses to
overwrite it)?

Maybe, but that isn't the job of r.colors; if you want to add that
feature, create a separate module (which could import both the colour
and label information).

--
Glynn Clements <glynn@gclements.plus.com>