Revise monochromatic color tables

[landam]

Reported by wenzeslaus on 5 Jun 2016 03:09 UTC The monochromatic color tables namely blues, greens, oranges and reds added in https://trac.osgeo.org/grass/changeset/64283 start with white. It is probably obvious that it is good that there is no black but I think that they also should not contain white.

Using r.mapcalc, r.colors, and r.colors.matplotlib (g.extension r.colors.matplotlib), you can try how the Matplotlib Blues, Greens, Oranges and Reds look like.

color=blues
map=m_$color
g.region cols=500 rows=300 n=-300 s=-600 w=0 e=500
r.mapcalc "$map = col() / 10 + 2 * cos(col() * 100)"
r.colors map=$map color=$color

color=Blues
map=m2_$color
g.region cols=500 rows=300 n=-600 s=-900 w=0 e=500
r.mapcalc "$map = col() / 10 + 2 * cos(col() * 100)"
r.colors.matplotlib map=$map color=$color

Also Moritz mentioned off-list that ''a quick look at Color Brewer shows that they use values such as:''

255:255:229 for greens
255:247:236 for reds

You can notice that besides different start color Matplotlib uses also different end color. Our color versions end e.g. with 0:0:255 (called blue in GRASS) which is an arbitrary color based on its special position in the RGB model not on its optical or aesthetic features. For the technical part, the greens and blues does not show the waves on the right and in comparison with the Matplotlib versions it seems to me that even reds and oranges show less waves on the right.

I'm not sure how many color steps are needed for the Matplotlib colors. I used 6 but perhaps just 2 (start and end) are enough.

The sepia color table from https://trac.osgeo.org/grass/changeset/33163 actually starts with white, 0:0:0, and ends with (almost) black, 255:254:251, (or the other way around when you don't use -n), so that's not good I think. I'm usually not able to use it because of the black color. The gray scale image and the waves are good (these two look like good indicators, see https://trac.osgeo.org/grass/ticket/3043). So, I would just remove the stretch the current colors unless there is some good sepia color table source.

The sepia color table from https://trac.osgeo.org/grass/changeset/68464 (from r.lake) doesn't show a big gradient in gray scale (which might be good thing sometimes, but not now). However, there is some and I don't know how to change it while preserving other features especially the look which I think is really good here.

Note that changing these would be more serious change in behavior because your result is changed even if you explicitly specify what you want (which is not the case for change of default in https://trac.osgeo.org/grass/ticket/3043 where you just trust the default which is changed for your good).

Note also that a monochromatic color tables are candidacies for new default color table (https://trac.osgeo.org/grass/ticket/3043).

Migrated-From: https://trac.osgeo.org/grass/ticket/3055

[landam]

Attachment from wenzeslaus on 5 Jun 2016 03:16 UTC Current color tables (grey, blues, greens, oranges, reds, sepia, water) - in grey scale - Matplotlib versions of Blues through Reds - in grey scale https://trac.osgeo.org/grass/attachment/ticket/3055/mono_current_grey_mpl_grey.png

[landam]

Attachment from wenzeslaus on 20 Oct 2016 01:17 UTC Patch to change monochromatic/monochrome color tables from https://trac.osgeo.org/grass/changeset/64283 (https://trac.osgeo.org/grass/ticket/2557) to Matplotlib ones https://trac.osgeo.org/grass/attachment/ticket/3055/monochromatic_to_matplotlib.diff

[landam]

Comment by wenzeslaus on 5 Jun 2016 03:21 UTC [[Image(mono_current_grey_mpl_grey.png)]]

In column:

• grey
• blues
• greens
• oranges
• reds
• sepia
• water

In row: current state - current state in grey scale - b. g. o. r. from Matplotlib - again in grey scale

Raster:

r.mapcalc "map = col() / 10 + 2 * cos(col() * 100)"

[landam]

Comment by wenzeslaus on 24 Jun 2016 02:42 UTC In [changeset:"68755\"] https://trac.osgeo.org/grass/changeset/68755:

add GRASS green color table by Vincent Bain (see https://trac.osgeo.org/grass/ticket/3043 and #222)

[landam]

Comment by wenzeslaus on 9 Jul 2016 18:01 UTC In [changeset:"68907\"] https://trac.osgeo.org/grass/changeset/68907:

add GRASS green color table by Vincent Bain (see https://trac.osgeo.org/grass/ticket/3043 and #222, backport https://trac.osgeo.org/grass/changeset/68755)

[landam]

Comment by mlennert on 20 Oct 2016 06:32 UTC I don't have any strong feelings about my original ones (which were just quick hacks). I find that for some the contrast seems to stronger in my versions (blues for example), but I don't think we can find any one color scheme that would satisfy everyone for every usage. And I agree that not having white as the starting color is a good idea.

So, please go ahead and commit.

[landam]

Comment by neteler on 28 Dec 2016 15:04 UTC Ticket retargeted after milestone closed

[landam]

Modified by @landam on 5 May 2017 20:41 UTC

[landam]

Comment by neteler on 16 Sep 2017 13:27 UTC Ticket retargeted after milestone closed

[landam]

Comment by @landam on 25 Mar 2018 10:21 UTC Ticket retargeted after milestone closed

[landam]

Modified by @landam on 25 Mar 2018 10:28 UTC

[landam]

Comment by wenzeslaus on 12 Jun 2018 01:55 UTC As mentioned in the original description, it is a change of behavior, so it should wait for version 8 (and must be deiced before the release, so blocker).

[landam]

Comment by SBL on 13 Jun 2018 06:29 UTC Would be nice if custom color tables could be picked up from one or more user-defined directories that is refered to e.g. in an environment variable (lets say GRASS_CUSTOM_COLORS) That way, anyone can add institutioal or personal color tables, independent from the GRASS installation...