[GRASS-dev] [GRASS GIS] #3043: Change default color table

[GRASS GIS]

#3043: Change default color table
--------------------------+---------------------------------------
  Reporter:  wenzeslaus   |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  blocker      |  Milestone:  7.2.0
 Component:  Raster       |    Version:  svn-trunk
Resolution:               |   Keywords:  r.colors, d.rast, rainbow
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+---------------------------------------

Comment (by wenzeslaus):

 Replying to [comment:5 mlennert]:
 > I think that if we provide a default color table (here ''map'') of which
 we say that it is good (better than rainbow), we should make our criteria
 more explicit.

 Article on Gnuplotting (citing Moreland, 2009) lists these features for a
 default color table and I'm adding my notes in the nested lists:

 * The map yields images that are aesthetically pleasing
  * Although some people consider `rainbow` pretty or are simply used to
 it, my claim is that it is objectively worse because things which contain
 less colors or less styles in general is considered a better graphical
 design.
  * `grey` is OK but black and white is a bit boring and then there is the
 "show color feature" thing Markus mentioned in comment:2
  * In cartography black and white have usually special purpose (like text
 and its halo), so this excludes color tables which start or end with one
 of them.
  * The black-body radiation color tables which include or are similar to
 color tables like `sepia` in GRASS GIS, or `hot`, `inferno`, `plasma`, and
 `magma` in Matplotlib are often recommend, but I haven't seen them used
 that much. There might a actually a aesthetic reason for it. The Better
 Default Colormap for Matplotlib video suggests that the reason is that
 these don't have a green color in them. However, in general, I think they
 are nice. Gnuplot default is actually similar to `inferno`, `plasma`, or
 `magma`.
  * The cubehelix color tables are often regarded as "rotten melon",
 although some variations look nice and some are very much like `viridis`,
 `plasma`, and others. See seaborn and palettable for examples.
  * `inferno`, `plasma`, `magma`, and `viridis` were considered for
 Matplotlib and `viridis` was selected because it was the one most people
 liked. As mentioned above, it was likely visual because unlike others, it
 had green in (the measurable/theoretical features were similar with the
 other three).
 * The map has a maximal perceptual resolution
  * In comment:9 showed that our `rainbow` doesn't always have it. Some
 revised rainbow-like color tables may have it quite high.
 * Interference with the shading of 3D surfaces is minimal
  * This rules out the `grey` and also the ones which go from very low
 brightness (black) to very high brightness (white).
 * The map is not sensitive to vision deficiencies
  * Although there is many different color blindness variations and
 sometimes the percentages of affected people are relatively low, this is
 often a requirement and my guess is that, similarly to web design,
 everybody at the end benefits.
  * This rules out anything which contains red and green at the same time
 like `rainbow` or `gyr`.
  * This also likely rules out anything which does not look good when
 converted to gray scale as the intensity is probably the last thing which
 is preserved. (I would need to do more here.) However, there is the
 benefit of printing in gray scale without much loss.
 * The order of the colors should be intuitively the same for all people
  * I guess the usual issue here is who can name colors of rainbow in the
 right order? Additionally, does the color table include all colors or does
 it skip some?
  * This likely rules out anything with a lot of colors, so probably also
 the rainbow-like color tables which fix some of the classic rainbow color
 table problems.
  * Simpler color tables with one or two colors like `summer` from
 Matplotlib doesn't require any knowledge of order.
  * As the order of colors is not clear even few colors may create
 confusion. Exception might black-body radiation color tables where the
 order might be intuitive (but that might be just result of the brightness
 as discussed in the following point).
  * I think this is also where the diverging color tables like
 `differences` or `curvature` fail here as defaults because the choice of
 order of individual colors is arbitrary and the often pronounced middle
 would be unsuitable. However, !ParaView uses diverging blue-white-red as a
 default and there are is some literature which suggests them.
  * Brightness seems to be only generally accepted natural ordering. This
 is in favor of `grey` and all color tables which look like grey when
 printing in black and white. This is the case for cubehelix color tables
 and `inferno`, `plasma`, `magma`, and `viridis`.
 * The perceptual interpolation matches the underlying scalars of the map
  * (I would need to do more reading here but) I think that it means that
 human should be able to guess what is the color in between two colors in
 the color table and the result should be the same as what is a more
 detailed color table would actually say. Simple color tables with
 predictable changes in brightness would fulfill this.

 > Why do you find viridis good (better than other color tables) ?

 As far as I can tell, the general trend in default color tables is
 simplicity, i.e. one, two or three colors, excluding white and black,
 clear brightness increase and black and white printing friendly, and color
 blind friendliness. Matplotlib's plasma and viridis fulfill those well
 together with some color tables from the cubelix and black-body radiation
 families (and perhaps some others designed in some other way but
 intentionally or unintentionally fulfilling the criteria - a lot of work
 would be needed, however, to find and check those).

 > Just aesthetics ?

 I think it is the final factor after the other things are fulfilled since
 many color tables would fulfill the other requirements, but wouldn't be
 nice (some of the cubehelix ones, for example). There are two things which
 support viridis as color table accepted by people for aesthetic reasons.
 viridis has won voting over inferno, plasma, and magma preceding its
 inclusion to Matplotlib and Matlab actually has similar color table to
 viridis called parula (and I don't think they would select something they
 wouldn't consider nice). viridis' authors actually claim (in the video)
 that viridis is little better than parula according to its behavior in
 some color space (default of both in the past was jet which is similar to
 rainbow); some people actually mention aesthetics as well, but that's
 quite subtle difference in case of viridis and parula.

 > What is good for matplotlib, might not be good for GRASS...

 They actually considered even terrain with shading as a use case. So, the
 question should be why it wouldn't be good for GRASS when it is good for
 Matplotlib?

 > More fundamentally, and to repeat myself: IMHO there is '''no''' good
 default color table. Color tables qualities are context and target
 dependent. I personally thus prefer not to pretend that we can provide a
 good color table by default.

 However, people simply use the default anywhere from tutorials to articles
 and the reasons range from trusting the defaults (because why would
 authors put there bad defaults?) to liking the rainbow color tables (which
 are considered bad for several reasons). Thus, I think we need to provide
 the best default we can. This doesn't mean that we should not promote
 usage of a proper color table for a given case. For example, digital
 elevation models, temperatures or water depth are good examples where the
 default is not appropriate.

 ''(I'm not including any links because Trac spam filter won't let me.)''

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3043#comment:10>
GRASS GIS <https://grass.osgeo.org>