Changing colormaps in GMT documentation figures

[maxrjones]

Many figures in the GMT documentation do not use perceptually uniform colormaps (e.g., rainbow in the tutorial). 260+ images in the GMT docs and tests will be updated as part of this PR. Should we take this opportunity to update the scripts to use 'scientifically derived color maps' based on the research presented in Crameri et al. (2020)?

[PaulWessel]

I think not all figure are trying to scientifically portray data accurately via color but are instead showing other aspects of the data, e.g., gradients, via illumination, and for that the SCM are not as good. I am OK with mixing up more though, and especially in cases where no illumination is used at all.

[maxrjones]

That makes sense. For the tutorial example of color images, do you think it is better to keep the current colormap given that a purpose is to show the use of -I in grdimage? For comparison, here is the output for batlow instead of rainbow:

[PaulWessel]

Maybe my kneejerk thinking on this is not quite kosher. Your examples actually looks better than our originals, especially in the right third of the map. so maybe at least for the tutorial we should do the right thing here. Let's see what @joa-quim has to say. @joa-quim please compare this to the version we post online using rainbow.

[joa-quim]

I never really liked rainbow but because of the violets. The default turbo already looks much better and topo (I think that's what I have as default in Julia for topography) looks even better. But I don't want to look like censuring the the perceptually uniform dull colormaps.

[PaulWessel]

Despite what Fabio says (and both @meghanrjones and I saw his TGIF talk in my department yesterday that followed his 2020 Nature Comm. paper), there is often a bit of both art and science in making appealing illustrations. Apart from questionable people, most do not select a CPT to deceive the viewer. Yet, it is unquestionable that anyone who is not aware of the pitfalls is likely to attribute too much meaning to bands and changes in the color image which may have little to do with changes in the data - it is such interpretations by authors and readers alike that is the problem. For my department's 6 by 2 meter world map I used a CPT like the topo above for land, thus distorting reality. Yet, the map is beautiful and serves lots of purposes - nobody is trying to read too much into the finer nuances of the color near sea level. And like @joa-quim choice for geo for this piece of land: It just does not look great with a blue color table like batlow (or jet for that matter) for land topography - we all associate blue with water. In the tutorial or examples, it may be helpful that we (a) select a CPT that is appropriate for the data type we are displaying and (b) that we comment on why we made that choice.

Some actions we can discuss

1. Add more language about color science and scientific color scales when we introduce CPTs, with a citation to Fabio. Just point out the pitfalls and try to educate the users about color. That is a job we should take on.
2. Immediately replace the use of rainbow in the Tutorial, scripts 14-16 with either turbo, geo, or even hawaii (which is a nice symbolic gesture - Fabio did make that specifically for us).
3. Change the use of rainbow in the 11-12 examples that use it to a broader representation of our CPTs, including some of the SCMs
4. There is no need to make such changes in existing test scripts but try to remember to use a broader palette (no pun intended) of CPTs in tests going forward.

The bolder action would be to change again our default CPTs to be SCM, to reflect that GMT was written by scientists for scientists. To remind you, not terribly long ago we changed from the decades-old default of rainbow to Google's turbo, which addresses many of the shortcomings that Fabio points out without being perfect. Then, remote data sets are each assigned a default CPT to use when the user does not select one. Hence this is our status for default CPTs:

1. If using remote data, use what is listed in gmt_data_server.txt: geo for DEMs, @age_chrons_GTS2012_2020.cpt for crustal ages. If using the special srtm_relief* reference to earth_relief*, use the srtm.cpt.
2. Otherwise, use turbo.

I would like to hear from more of the @GenericMappingTools/core and @GenericMappingTools/gmt-contributors on these thoughts.

[joa-quim]

I agree with your list of default CPTs. I would be against replacing the turbo with one of SCM cpt as the default CPT.
And for the record, this story of of the perceptual color maps started with Steve Eddins in Matlab that lead to the Parula cpt (now the Matlab's default). And before Fabio there was this guy work

https://github.com/peterkovesi/PerceptualColourMaps.jl
https://arxiv.org/abs/1509.03700

[maxrjones]

I agree with action items 1-4. I do not have any strong objections to keeping turbo as the default CPT.

I do not agree with the interpretation that the perceptual color maps story started with Steve Eddins’ work at MATLAB. Steve’s 2014 technical report includes an annotated bibliography that describes a subset of the research that preceded the development of parula. Given’s GMT’s specialization in mapping, Cynthia Brewer's research on perceptual color maps for cartography, including the 2002 publication of ColorBrewer, is particularly relevant for this discussion about the history of perceptual color maps.

[leouieda]

I agree that making an appealing map is both science and art. But the default option should not be targeted at people who understand this. Most users aren’t aware and never change the defaults (Paul just loves the huge default borders in tiny maps). So to me the default should always be the safest option for people who don’t really know what they are doing in depth. Again, making a scm cpt the default does not mean removing the option of using rainbow/turbo. To appease users who don’t want to change, this could be configured globally by a configuration variable.

It would be great to have a page in docs discussing this since there is diverse set of opinions in the GMT team (which is wonderful) and a lot of collective experience. Matplotib’s page on choosing a colormap is a good place to start: https://matplotlib.org/stable/tutorials/colors/colormaps.html

[WalterHFSmith]

Leo, That is a fantastically good page that you linked. Very well written and explained, lots of excellent examples and references. When we first implemented something other than RGB, it was HSV, as that was what I had info about and wanted to enable, because Dave Sandwell was using it to make gravity anomaly map images. I wish I had implemented HSL instead. It would be good to have some options in GMT that are perceptually linear in L. Walter

…

On Mar 4, 2021, at 4:22 AM, Leonardo Uieda ***@***.***> wrote: I agree that making an appealing map is both science and art. But the default option should not be targeted at people who understand this. Most users aren’t aware and never change the defaults (Paul just loves the huge default borders in tiny maps). So to me the default should always be the safest option for people who don’t really know what they are doing in depth. Again, making a scm cpt the default does not mean removing the option of using rainbow/turbo. To appease users who don’t want to change, this could be configured globally by a configuration variable. It would be great to have a page in docs discussing this since there is diverse set of opinions in the GMT team (which is wonderful) and a lot of collective experience. Matplotib’s page on choosing a colormap is a good place to start: https://matplotlib.org/stable/tutorials/colors/colormaps.html — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jpesicek]

Hi, I came across this thread when hoping to find matlab's Parula color map available in GMT. Since is is now the matlab default as discussed above, would be nice to have it available in the gmt options.