While a complete solution for bivariate color mapping has not been merged to main at the time of writing, the intention is to have it in place for the 3.10 release of Matplotlib (~October 2024). This represents a delay of the project as compared to the original timeline, caused by a change in the scope of the project.

Originally, this GSOC project was based on replacing cm.ScalarMappable with a vector version,cm.VectorMappable, (relevant PR). However, with the involvement of the API lead @timhoffm and project lead @tacasawell it was decided to rework the data→color pipeline before implementing bivariate color mapping.

Color by numbers (advanced version)

Representing data with color lies at the root of many of the plotting methods in Matplotlib. In practice, this is handled by the class cm.ScalarMappable which handles normalization (converting data to a 0-1 scale through colors.Normalize) and color mapping (converting the 0-1 encoding to colors through colors.Colormap). cm.ScalarMappable is therefore at the root of the inheritance tree, together with `artist.Artist`. The figure below shows all the top-level plotting methods that use the data→color transformation.

What @timhoffm argued was that the data→color pipeline may be shared by multiple elements in the same figure, but the current class hierarchy (subclassing cm.ScallarMappable) is not conducive to this use case, i.e. the user must manually add callbacks between different graphical objects to obtain functionality such as syncing the colormaps across plots

Changing the class hierarchy would have major positive implications:

1. Increased functionality when working with multiple graphical elements that share a data→color pipeline
2. Simplify code maintenance separating the artist (graphical element) from the data→color pipeline¹ (i.e. more modular code)
3. Simplify the introduction of bivariate and multivariate color mapping

The proposed architecture change is as follows:

Where the data→color transformation is contained in the new colorizer.Colorizer module, and one colorizer can control the data→color pipeline for multiple plots:

These changes are implemented in the New data → color pipeline PR, and the (slightly outdated) video shows how multiple images that share a colorizer behave.

Colormap classes for bivariate (and multivariate) colormaps

A separate PR, MultivarColormap and BivarColormap, introduces classes that hold bivariate and multivariate colormaps.

The bivariate colormaps come in different shapes:

while the multivariate colormaps come with different combination modes:

Exposing bivariate (and multivariate) colormaps to plotting methods

Using bivariate or multivariate colormaps requires a multivariate normalization, so before the new colormaps can be exposed to users, a colors.MultiNorm class must be implemented. By using a colors.MultiNorm and a colors.BivarColormap with a colorizer.Colorizer object, the new functionality can be exposed to the top level plotting functions (i.e. ax.imshow()).

Both of these features exist as commits (links above), and will be part of a PR after the two other PRs are merged.

Combined with the functionality of the colorizer.Colorizer, this solution allows for coupled plots where a single axes from a bivariate or multivariate colormap can be used together with the full colormap:

Choosing bivariate and multivariate colormaps

Once the functionality is implemented, there needs to be colormaps for the user to choose from. I have written two blogposts describing the design considerations relevant for their design:

Designing 2D colormaps

Multivariate colormaps for n dimensions

In an effort to separate different concerns, these have not been a part of PR#28454 MultivarColormap and BivarColormap, and will need to be introduced in a separate PR.

This should also feature a guide to how the new functionality can be used, and how to choose a colormap.

Colorbars

To complete the figure, a multidimensional colorbar must be added. There is a draft for this here, but some work still remains. Firstly, a BivarColorbar class must be created (in the multivariate case – a list of Colorbar objects will work). Secondly, the automatic positioning of the colorbars in the figure needs some improvement.

Summary

This project has grown in scope and now includes:

1. Classes for bivariate and multivariate colormaps #28454
2. Reworking the data→color pipeline#28658
3. Exposing bivariate and multivariate colormaps to the plotting methods
4. A selection of bivariate and multivariate colormaps
5. “Colorbar” objects for the bivariate and multivariate case

Of these, step 1 has been approved, and step 2 is (hopefully) near the end of code review. Step 3 waits for step 1 and 2 to be merged, but the PR will be made soon. Step 4 is similarly ready, but the PR should be made after the code review of step 3 has started. The PR for step 5 will similarly follow once step 4 is merged.

In other words, there is still some work to be done, but as there exists drafts for all the remaining functionality the remaining workloads are less code-intensive, and instead lean towards the collaborative aspects of open source. This project involves re-organizing the data→color pipeline for all relevant plotting methods, and it is therefore important that all the Matplotlib maintainers get to chime in at every step of the way. This process takes time, but ensures a better outcome.

Thank you to Hannah and Kyle for guiding me through GSOC, and to Elliot, Tom, Tim and Jody for feedback on the PRs.

¹ The distinction between the Colorizer and ColorizingArtist objects are as follows:

• ColorizingArtist subclasses Artist, i.e. it refers to a specific graphical element in a plot. It has the following atributes:
  • data
  • alpha (opacity)
  • colorizer
  • A .draw(renderer) method to render (display) the graphical elements.
  • …²
  • …³
• Colorizer holds the data→color pipeline. It consists of:
  • norm
  • cmap
  • A .to_rgba(data, alpha) method that assignes color (red, green, blue, alpha) to data using the norm and cmap.

When rendering a ColorizingArtist, it will invoke self.colorizer.to_rgba(data, alpha) to determine what colors to render.

² ColorizingArtist also has attributes required of an Artist, such as position, size, etc. relating to rendering of the artist in an Axes.

³ The norm and cmap are accessible as attributes on a ColorizingArtist through the use of @property. For many users, the distinction between the ColorizingArtist and Colorizer will therefore not be felt.

This post follows my previous post on 2D colormaps, and many of the design principles will be the same. However, with n ≥ 3, it quickly becomes unfeasible to create a full lookup table. With n = 3 channels and 256 values in each channel, the lookup table would be a matrix of 256^3 elements, likely much larger than the image the colormap is applied to. Instead, n independent 1D lookup tables are created, and the resulting colors are then combined.

The simplest approach is to assign one color channel (R, G, B) to each channel in the image; in the below image the same data is shown mapped to (R, G, B) and (G, B, R): [data source]

Both images above display the same data, with the same normalization, but by swapping the color different aspects are highlighted. The green channel has higher perceptual lightness and saturation, and the features of the green channel are therefore highlighted.
The lightness and saturation of the R, G and B channels can be visualized by displaying the three channels in a perceptually uniform colorspace.

We can define the following figures of merit for multivariate colormaps:

1. Each channel should be perceptually uniform.
2. All channels should have similar lightness and saturation.
3. The perceptual distance between the channels should be maximized.

Since there are perceptually uniform colorspaces available in literature (for example CAM02-LCD Luo et al. (2006)), we can use these to design colormaps that match the figures of merit above:

The above figure show the same data again but this time visualized with the newly generated colormaps. Again, they are shown with two different assignments to the three color channels. There are still perceptual differences, but there should be no features in the left image that are not visible in the right image. (Note that they will appear different to those that are colorblind, or if printed in black and white – more on this later.)

Combining colors

When the three channels are combined, they may produce colors that do not exist in any of the individual channels. In the above example, the colors are added, but there are a other possible blending modes:

• Additive: R = R₁ + R₂ + R₃ ← example above
• Lighten: R = max(R₁, R₂, R₃)
• Darken: R = min(R₁, R₂, R₃)
• Multiply: R = R₁ * R₂ * R₃
• Screen: R = (R₁⁻¹ * R₂⁻¹ * R₃⁻¹)⁻¹
• …

as well as more exotic ways to work within colorspace:

• Mixing in perceptual uniform space
• Non-linear mixing, e.g. R = √(R₁² + R₂² + R₃²)
• Choosing the colorbar corresponding to the highest input value, ignoring the others
• …

In terms of perceptual uniformity, it would be best to combine the colors in perceptually uniform colorspace, but there are pragmatic reasons to instead combine colors sRGB:

• The conversion sRGB ←→ CAM02-LCD is numerically costly
• The conversion sRGB ←→ CAM02-LCD is numerically unstable
• Combining colors in sRGB space gives acceptable results

It is therefore reasonable to design colormaps in a perceptually uniform space, but combine them in sRGB. However, we must be carefull to check that that this does not produce any unwanted artifacts when the colormaps are combined. This is most acute for n = 3 channels, where it is possible to create colormaps such that each color in the output image stems from a unique combination of input.

Designing colormaps with n = 3 channels

With n=3 channels, we can think of colorspace as a cube, with each channel representing one of the axes. If we are working with dense data, such that the input spans the full 3D volume of the cube, then we can add the following two figures of merit:

4. Equal mixing of the components provides a grayscale
5. No combination leaves sRGB space

We can visualize the colormaps above as follows:

By visual inspection we can see that this is relatively uniform around the origin (black), but non-uniform around the other extreme (white), where it wants to leave the sRGB colorspace. The same can be seen in 3D, where it also becomes apparent that the “greyscale” has a weak tint.

We can adjust the colormap by reducing the maximum saturation and lightness of each channel, this to make sure the entire colormap fits in sRGB space. In the figure below the origin is fixed at (0, 0, 0) in sRGB space, and the maximum at (1, 1, 1). The grayscale has also been adjusted by minor shifts to the individual channels, so that the greyscale follows the sRGB greyscale.

This colormap fulfills all the figures of merit listed above, and will work for any 3-channel dataset. This particular example has sparse data (most pixels are only non-zero in one channel) and the resulting image therefore appears a little drab.

Colorblindness

Around 5-10% of the male population has some form of red-green colorblindness. For many of them, the colormap above looks as follows:

Note how the green and red channels appear almost identical. This is not an accident, but the result of a choice made when making the colormaps. The blue channel follows negative b (blue) closely in L*a*b* colorspace, and as a result the green and red channels have a very similar value of positive b (yellow). (red-green colorblindness is in practice the abscence of the a axis in L*a*b* colorspace).

It is impossible to accommodate colorblindness completely in a 3-channel image. However, the choice made above was particularly bad. A better choice is to fix one of the channels to be along the a axis. The resulting colormap will then also have three distinct channels for those that are colorblind (grey, yellow, blue).

This is by no means perfect, but it is clearly a better choice.
For those of use who are not colorblind, the colormap above looks as follows:

The problem with black

When discretized to 12 steps, the colormaps look like this:

On the right side, the individual segments can be easily discerned, but this is not true on the left, where several segments are effectively the same shade of black. I believe the issue is related to how most monitors cannot truly represent black in its purest form, and this is difficult to account for in the transformation form a perceptually linear colorspace to sRGB.

We can slighly shift the colors in the colormap in order to improve the perceptual fidelity in the darkest parts of the colormap.

The approach used here is similar to a gamma correction, but acts independently on the lightness and the saturation. There is also a non-linearity applied when the origin is fixed to (0,0,0) in sRGB. The changes are best visualized by plotting the lightness, saturation and hue of each component:

It is worth noting that this is not an issue in the bright part of colorspace, and colormaps with white at the origin perform better with regard to perceptual uniformity:
(I refer to these as subtractive colormaps, in contrast to the additive colormaps discussed so far.)

Colormaps with n ≥ 4 channels

For n ≥ 4, different each color in colorspace is no longer unique (there may be different ways to produce some of the same color in the image) and are therefore best applied only to sparse data (most pixels are only non-zero in one channel so that each pixel in the resulting image has a color close to one of the colorbars). This means that less attention should be paid to how the colormaps combine, as the combined colors are expected to rarely appear in the intended use case. We therefore use only the three first figures of merit:

1. Each channel should be perceptually uniform.
2. All channels should have similar lightness and saturation.
3. The perceptual distance between the channels should be maximized.
4. Equal mixing of the components provides a grayscale
5. No combination leaves sRGB space

Keeping all the other points discussed above in mind (adjusting dark colors, rotating the hues to maximize difference in color for those that are colorblind) we can produce colormaps with 4-8 colors:

We can evaluate these as we did with the n=3 colormaps, here for 4 and 8 colors.

We see that in both lightness and saturation there are some inconsistencies between different colors. This is because the colormaps approach the limits of sRGB space. The inconsistencies could have been avoided by reducing the maximum lightness and saturation, which would in turn results in more dull colormaps. These colormaps are the result of attempting to strike a balance between vibrant colormaps and perceptual uniformity.

(For data that is not sparse a different combination mode may be used, but that topic goes beyond the scope of this post.)

A set of colormaps with no bad choices

Combining all these together produces the following colormaps:

• Two (A, B) variants for n = 2 with different hues
  • Both variants stay within sRGB and end at white when combined at the maximum
• Four colormaps for n = 3
  • A and B are designed so that all combinations stay within sRGB space
    • A and B have different hues
  • C and D are designed to exceed sRGB space
    • C has the same hue as A and D has the same hue as B
• Two colormaps for n = 4 with different hues
  • Both alternatives exceed sRGB space
• One alternative for each of n = 5, 6, 7 and 8
  • At n=8 is the result of combining the two sets at n = 4

As noted previously, the subtractive colormaps are more perceptually uniform:

By conforming to the figures of merit, we ensure that the most common pitfalls when choosing a colormap can be avoided. I.e. these colormaps will never be a bad choice. As such, they form a suitable basis set for general-purpose plotting software, such as matplotlib, pyplot, pyqtgraph, and others.

If you are not familiar with bivariate color maps, they come in handy to visualize complex numbers, here exemplified by the Mandelbrot set:

But bivariate colormaps are not limited to the number plane, and have a number of uses in different disciplines. Where the above graph shows correlated data (complex numbers), the figure below uses a bivariate colormap to visualize two independent datasets, GDP per capita, and growth (data source):

Implementing bivariate colormaps in matplotlib requires adding functionality deep in the class hierarchy. By making these changes, it will be easy to also implement multivariate colormaps for visualizing more than two images/datasets together, as with the cells shown below (data source):

There is a lot of work to be done, both on the implementation side of things, and for designing suitable colormaps. Check out the development branch if you want to compare the changes yourself!

For the design of colormaps, Peter Kovesis paper (2015) covers the topic with great diligence, as is Nathaniel Smith and Stéfan van der Walts talk (2015) explaining the origin of the now-ubiquitous (at least in academia) ‘viridis’ colormap. They outline an approach centered on human perception, where colormaps are designed to be perceptually uniform while maximizing the number of levels that can be distinguished. For multivariate colormaps, this approach has not previously been implemented.

2D colormaps
Just as any continuous 1D colormap is a curve in colorspace, any continuous 2D colormap is a surface. Peter Kovesis, Nathaniel Smith and Stéfan van der Walts made the point that one should use a perceptually uniform colormap, such as CIELAB when designing 1D colormaps, and this remains true for 2D colormaps. The sRBG color gamut is illustrated below in the colorspace CAM02-LCD (Large Color Difference) Luo et al. (2006).

CAM02-LCD (and CIELAB) describes colorspace using three orthogonal axes: L*: lightness, a*: green-red, and b*: blue-yellow. The colorspace is designed to be perceptually uniform, i.e. the distance you need to move along an axis before you notice a change, should be the same along L*, a*, and b*.

Colormap design is further determined by the kind of data the colormap is designed to represent. Matplotlib groups colormaps as sequential, diverging, and cyclic (in addition to qualitative), designed to represent data that fit into those categories. For 2D colormaps, the two axis can represent categorically different data, making 6 different categories: sequential×sequential, sequential×diverging, sequential×cyclic, diverging×diverging, diverging×cyclic, cyclic×cyclic. One can compare the different categories to the axis in CIELAB space, where L* is sequential, a*/b* is diverging, and the hue (azimuthal around a*=b*=0) is cyclic.

These most relevant categories, are shown as 2D planes in 3D L*a*b* space above.

Using the shapes above to slice the sRGB color gamut will produce 2D colormaps.

Note that defining colormaps in L*a*b*-space limits how much of the color gamut we can utilize. Colormaps defined in sRGB space provide a better utilization of the color gamut. Consider the following blue-orange bi-sequential colormaps:

The colormap defined in sRGB space has increased saturation because it is not limited by perceptual uniformity (i.e. the maximum orange has higher L* than the maximum blue). For many applications, the loss of perceptual uniformity is an acceptable trade for increased saturation (making the colormap ‘pop’ more).

Additional colormaps can be generated using the same design principles:

The circular colormaps are useful for applications where the data has rotational symmetry.

3D colormaps – alpha, a* and b*

One can design a 3D colormap based on the three axes L*, a* and b*. On a black background L* can be replaced by an alpha channel, if the colormap is constant in L*. The colormaps ‘flat’ and ‘disk’ (above) are designed to be used in this way.

Adapting for colorblindness

It is not possible to fully accommodate the various kinds of colorblindness in multi-dimensional colormaps. However, it is worth noting all the common forms of color-blindness affect primarily the a* (red-green) axis in L*a*b* colorspace. Thus, when we design colormaps by slicing L*a*b* space, we should preferentially slice along the b* (blue-yellow) axis, as is done above for the colormaps ‘orangeBlue’ and ‘cut’. However, when making use of a the hue in a cyclic colormap, this is not possible.

However, the hue can be cycled freely, and for the relevant colormaps the axes can be chosen such that the main features of the data are accessible also to those with common forms of colorblindness. The following figure shows the same data as seen by someone with normal color vision, and someone whom is red-green colorblind. For both cases, the data is shown with two different rotations of the colormap. With normal color vision, it is easily discernible that the two circled regions have different hue, but for someone who is red-green colorblind, this is only apparent if the colormap is rotated so that they are differentiated along the blue-yellow axis.

The rotation of the colormap is therefore of critical importance for accommodating those with common forms of colorblindness.

For reference, the above colormaps are shown below as they appear for someone with deuteranopia (unable to perceive ‘green’ light – the most common form of color blindness).

Tools used:

colorspacious to convert between colorspaces and simulated colorblindness
plotly to make 3d figures
matplotlib to make 2d figures
The colormaps were originally made for colorstamps

Other resources:

Bernard, Jürgen, et al. “A survey and task-based quality assessment of static 2D colormaps.” Visualization and Data Analysis 2015. Vol. 9397. SPIE, 2015.

Strode, Georgianna, et al. “Operationalizing Trumbo’s principles of bivariate choropleth map design.” Cartographic perspectives 94 (2019): 5-24.

Kruse, Andrew W., et al. “User study comparing linearity and orthogonalization for polarimetric visualizations.” IEEE Access 10 (2022): 28308-28321.

There is an associated publication in the Journal of Open Source Software

The project contains a number of 2d colormaps (stamps), suitable for different data types, it is useful to distinguish between data of like-type, and data of different type, and also unimodal (only positive) and bimodal (positive and negative) data.

• If both axes are bimodal, and of like type, the axis should have a round shape with an origin in the middle, and ‘disk’/’cone’/’funnel’ are suitable.
• With one unimodal and one bimodal axis (i.e. intensity + phase shift etc.) ‘cut’ is a suitable colormap, and this exists in mulitple variations. If one axis is circular, ‘barrel’ loops on the x-axis.
• With two unimodal axis, ‘orangeBlue’ is recommended.

Data outside the colormap must be projected into the valid space, and there are multiple options.

Finally, the RGB colorspace on a computer can only represent a fraction of the CAM02-LCD colorspace, and colorstamps will limit the colors in the colormap to fit the RGB colorspace. A tool for evaluation of 2d colormaps are included.

An interactive demo is hosted at Streamlit, while the source is hosted on Github.

The model is presented in A unified approach for the calculation of in-plane dielectric constant of films with interdigitated electrodes.

This work builds upon a knowledge base of a a series of works detailing how to accurately characterize in-plane ferroelectric properties of thin films, started in the group of Paul Muralt at EPFL, with works such as 1 2 and 3.

Pychrysvis is a Streamlit app for making vector graphics from crystal structures (.cif files), with source on github.

The you can then edit the vector graphics further in Inkscape, and make more advanced figures.

like an explanation of dark-field X-ray microscopy:

Diamond viewed along different axes:

I prefer to work with vector graphics wherever possible, and I was not able to find a suitable tool online, so I built this tool from leftover scraps of other projects.

There is minimal documentation, but perhaps someone else will find it useful nonetheless.