# Provide unified plotting abstraction layer

XMLWordPrintable

#### Details

• Type: Epic
• Status: To Do
• Resolution: Unresolved
• Fix Version/s: None
• Component/s:
• Labels:
• Epic Name:
plotting abstraction layer

#### Description

The stack has dozens of "import matplotlib" statements scattered around. This can cause unexpected behavior, slowdowns and can mess up subsequent matplot commands (e.g. if a implicit import prevents a subsequent explicit import from setting the backend).

We provide an afw.display abstraction for doing ds9-related things, so we should also have an afw.plot or similar abstraction for plotting. One could then swap in Seaborn or another plotting system more easily, and it would reduce the "import matplotlib" to one place, which would only occur when e.g. that class is instantiated.

A first step of this would be a simple class that just handles the import and environment setup, while not actually abstracting away any of the matplotlib calls. We could then make it a more general abstraction layer if desired.

#### Activity

Hide
Paul Price added a comment -

This is a worthy goal, but given all the different kinds of plots there are I think it would be difficult to do well. I strongly suggest you RFC this before starting anything to minimise frustration.

Show
Paul Price added a comment - This is a worthy goal, but given all the different kinds of plots there are I think it would be difficult to do well. I strongly suggest you RFC this before starting anything to minimise frustration.
Hide
John Parejko added a comment -

An RFC with an example interface is a good idea.

I think if nothing else, we want a single place to import and setup matplotlib from (which could come with an LSST "stamp of approval" set of font sizes, etc.). Even if it's not a fully-abstract system, something that lets us safely do something like this would be a big help:

 if self.plot:  plt = afw.Matplotlib()  plt.scatter(matplotlib_stuff) 

Show
John Parejko added a comment - An RFC with an example interface is a good idea. I think if nothing else, we want a single place to import and setup matplotlib from (which could come with an LSST "stamp of approval" set of font sizes, etc.). Even if it's not a fully-abstract system, something that lets us safely do something like this would be a big help: if self.plot: plt = afw.Matplotlib() plt.scatter(matplotlib_stuff)
Hide
Jonathan Sick added a comment -

Also keep in mind this prior art regarding a unified plotting abstraction layer:

https://vega.github.io and https://vega.github.io/vega-lite/ (JSON Schema / visualization grammar).

Show
Jonathan Sick added a comment - Also keep in mind this prior art regarding a unified plotting abstraction layer: https://vega.github.io and https://vega.github.io/vega-lite/ (JSON Schema / visualization grammar).
Hide
John Parejko added a comment - - edited

Related to this (since I'm having trouble setting the backend in my own code), I just tried some quick matplotlib hacking we'll have to to take care of any exposed matplotlib.use(), import matplotlib.pyplot, import matplotlib.pylab, or import matplotlib.backends calls as well. Some of that work was done as part of DM-8656, but there may be more such imports lurking.

Show
John Parejko added a comment - - edited Related to this (since I'm having trouble setting the backend in my own code), I just tried some quick matplotlib hacking we'll have to to take care of any exposed matplotlib.use() , import matplotlib.pyplot , import matplotlib.pylab , or import matplotlib.backends calls as well. Some of that work was done as part of DM-8656 , but there may be more such imports lurking.

#### People

Assignee:
Unassigned
Reporter:
John Parejko
Watchers:
David Shupe, John Parejko, John Swinbank, Jonathan Sick, Michael Wood-Vasey [X] (Inactive), Paul Price, Simon Krughoff, Tim Jenness