{ "cells": [ { "cell_type": "code", "execution_count": null, "metadata": { "collapsed": false }, "outputs": [], "source": [ "%matplotlib inline" ] }, { "cell_type": "markdown", "metadata": {}, "source": [ "\nColormap Normalization\n======================\n\nObjects that use colormaps by default linearly map the colors in the\ncolormap from data values *vmin* to *vmax*. For example::\n\n pcm = ax.pcolormesh(x, y, Z, vmin=-1., vmax=1., cmap='RdBu_r')\n\nwill map the data in *Z* linearly from -1 to +1, so *Z=0* will\ngive a color at the center of the colormap *RdBu_r* (white in this\ncase).\n\nMatplotlib does this mapping in two steps, with a normalization from\n[0,1] occurring first, and then mapping onto the indices in the\ncolormap. Normalizations are classes defined in the\n:func:`matplotlib.colors` module. The default, linear normalization is\n:func:`matplotlib.colors.Normalize`.\n\nArtists that map data to color pass the arguments *vmin* and *vmax* to\nconstruct a :func:`matplotlib.colors.Normalize` instance, then call it:\n\n.. ipython::\n\n In [1]: import matplotlib as mpl\n\n In [2]: norm = mpl.colors.Normalize(vmin=-1.,vmax=1.)\n\n In [3]: norm(0.)\n Out[3]: 0.5\n\nHowever, there are sometimes cases where it is useful to map data to\ncolormaps in a non-linear fashion.\n\nLogarithmic\n-----------\n\nOne of the most common transformations is to plot data by taking\nits logarithm (to the base-10). This transformation is useful to\ndisplay changes across disparate scales. Using :func:`colors.LogNorm`\nnormalizes the data via $log_{10}$. In the example below,\nthere are two bumps, one much smaller than the other. Using\n:func:`colors.LogNorm`, the shape and location of each bump can clearly\nbe seen:\n\n" ] }, { "cell_type": "code", "execution_count": null, "metadata": { "collapsed": false }, "outputs": [], "source": [ "import numpy as np\nimport matplotlib.pyplot as plt\nimport matplotlib.colors as colors\n\nN = 100\nX, Y = np.mgrid[-3:3:complex(0, N), -2:2:complex(0, N)]\n\n# A low hump with a spike coming out of the top right. Needs to have\n# z/colour axis on a log scale so we see both hump and spike. linear\n# scale only shows the spike.\nZ1 = np.exp(-(X)**2 - (Y)**2)\nZ2 = np.exp(-(X * 10)**2 - (Y * 10)**2)\nZ = Z1 + 50 * Z2\n\nfig, ax = plt.subplots(2, 1)\n\npcm = ax[0].pcolor(X, Y, Z,\n norm=colors.LogNorm(vmin=Z.min(), vmax=Z.max()),\n cmap='PuBu_r')\nfig.colorbar(pcm, ax=ax[0], extend='max')\n\npcm = ax[1].pcolor(X, Y, Z, cmap='PuBu_r')\nfig.colorbar(pcm, ax=ax[1], extend='max')\nfig.show()" ] }, { "cell_type": "markdown", "metadata": {}, "source": [ "Symmetric logarithmic\n---------------------\n\nSimilarly, it sometimes happens that there is data that is positive\nand negative, but we would still like a logarithmic scaling applied to\nboth. In this case, the negative numbers are also scaled\nlogarithmically, and mapped to smaller numbers; e.g., if `vmin=-vmax`,\nthen they the negative numbers are mapped from 0 to 0.5 and the\npositive from 0.5 to 1.\n\nSince the logarithm of values close to zero tends toward infinity, a\nsmall range around zero needs to be mapped linearly. The parameter\n*linthresh* allows the user to specify the size of this range\n(-*linthresh*, *linthresh*). The size of this range in the colormap is\nset by *linscale*. When *linscale* == 1.0 (the default), the space used\nfor the positive and negative halves of the linear range will be equal\nto one decade in the logarithmic range.\n\n" ] }, { "cell_type": "code", "execution_count": null, "metadata": { "collapsed": false }, "outputs": [], "source": [ "N = 100\nX, Y = np.mgrid[-3:3:complex(0, N), -2:2:complex(0, N)]\nZ1 = np.exp(-X**2 - Y**2)\nZ2 = np.exp(-(X - 1)**2 - (Y - 1)**2)\nZ = (Z1 - Z2) * 2\n\nfig, ax = plt.subplots(2, 1)\n\npcm = ax[0].pcolormesh(X, Y, Z,\n norm=colors.SymLogNorm(linthresh=0.03, linscale=0.03,\n vmin=-1.0, vmax=1.0),\n cmap='RdBu_r')\nfig.colorbar(pcm, ax=ax[0], extend='both')\n\npcm = ax[1].pcolormesh(X, Y, Z, cmap='RdBu_r', vmin=-np.max(Z))\nfig.colorbar(pcm, ax=ax[1], extend='both')\nfig.show()" ] }, { "cell_type": "markdown", "metadata": {}, "source": [ "Power-law\n---------\n\nSometimes it is useful to remap the colors onto a power-law\nrelationship (i.e. $y=x^{\\gamma}$, where $\\gamma$ is the\npower). For this we use the :func:`colors.PowerNorm`. It takes as an\nargument *gamma* (*gamma* == 1.0 will just yield the default linear\nnormalization):\n\n
There should probably be a good reason for plotting the data using\n this type of transformation. Technical viewers are used to linear\n and logarithmic axes and data transformations. Power laws are less\n common, and viewers should explicitly be made aware that they have\n been used.
This may appear soon as :func:`colors.OffsetNorm`.\n\n As above, non-symmetric mapping of data to color is non-standard\n practice for quantitative data, and should only be used advisedly. A\n practical example is having an ocean/land colormap where the land and\n ocean data span different ranges.