-
Notifications
You must be signed in to change notification settings - Fork 339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing colormaps in GMT documentation figures #4864
Comments
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. |
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 |
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. |
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
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:
I would like to hear from more of the @GenericMappingTools/core and @GenericMappingTools/gmt-contributors on these thoughts. |
I agree with your list of default CPTs. I would be against replacing the turbo with one of SCM cpt as the default CPT. https://github.com/peterkovesi/PerceptualColourMaps.jl |
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. |
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 |
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.
|
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. |
AFAIK, parula is copy righted by Mathworks. |
Yes, Mathworks appears to claim intellectual property rights. Our colleagues from the Python library matplotlib faced the same question, went to the source, and got this answer: https://discourse.matplotlib.org/t/matlab-parula-colormap/18870 So that means that like matplotlib, the GMT team will not distribute a parula colormap unless Mathworks changes their stand on this. |
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)?
The text was updated successfully, but these errors were encountered: