The artist layer consists of a hierarchy of Python classes that facilitate creating a figure and embellishing it with any and all of the features we might desire: axes, data points, curves, axes labels, legends, titles, annotations, and everything else. The first step is to create a figure and place it on a canvas (figure window, whether on a computer screen or a computer file). To the figure, we add axes, data, labels, etc. When we have everything the way we want it, we send it to the screen to display and/or save it to a file.
To make this concrete, consider the program below:
from matplotlib.backends.backend_qt5agg import FigureCanvasQTAgg as FigureCanvas
from matplotlib.figure import Figure
fig = Figure(figsize=(6, 4))
canvas = FigureCanvas(fig)
ax = fig.add_subplot(111)
ax.plot([1, 2, 3, 2, 3, 4, 3, 4, 5])
ax.set_title('A simple plot')
ax.grid(True)
ax.set_xlabel('time')
ax.set_ylabel('volts')
canvas.print_figure('figures/oopTest.pdf')
canvas.show()
The output of the program is shown below:
First, we import the FigureCanvas from the qt5Agg backend. Then we import Figure from matplotlib.figure. After finishing our imports, the first step is to define and name (fig) the Figure object that will serve as a container for our plot. The next step is to attach the figure to an instance of FigureCanvas, whichwe name canvas, from the qt5Agg backend. This places the canvas on the screen and connects all the matplotlib routines to the Qt and Agg C++ routines that write to the screen. Next, in line 7, we create a set of axes on our figure, making a single subplot that takes up the entire frame of the figure. Finally, we write the plot to a file (line 13) and to the screen (line 14) from the canvas, which makes sense, because that’s what connects the matplotlib routines to the hardware.
The code in this example is native matplotlib object-oriented (OO) code. In its purest form, it’s the way matplotlib code is supposed to be written. The code is entirely transportable from one computer to another irrespective of the operating system, so long as the qt5Agg backend has been included in the local machine’s Python installation. In this case, the output should look the same, whether it’s on the screen or in a file, on Microsoft Windows, macOS, or any of the different flavors of Linux. By the way, if another machine does not have the qt5Agg backend installed, you can simply change lines 1 and 2 to a different backend that is installed, and the program should work as expected, with no discernible differences.
Before moving on to the next layer of matplotlib, it’s useful to introduce some matplotlib terminology—jargon—for describing the artist layer. All of the routines called in lines 5 and 7–12 are part of the Artist module and the eponymous Artist class of matplotlib. Collectively and individually, all the routines that get attached to fig and its descendant ax are known as Artists: add_subplot, plot, title, grid, xlabel, etc. Artists are those matplotlib objects that draw on the canvas, including figure. You will see the term Artist employed liberally in online documentation and commentary on matplotlib. It’s simply a part of the matplotlib lexicon, along with backend, PyPlot, and the
yet to be mentioned, PyLab.
In the next post we'll discuss the PyPlot (scripting) layer.
To make this concrete, consider the program below:
from matplotlib.backends.backend_qt5agg import FigureCanvasQTAgg as FigureCanvas
from matplotlib.figure import Figure
fig = Figure(figsize=(6, 4))
canvas = FigureCanvas(fig)
ax = fig.add_subplot(111)
ax.plot([1, 2, 3, 2, 3, 4, 3, 4, 5])
ax.set_title('A simple plot')
ax.grid(True)
ax.set_xlabel('time')
ax.set_ylabel('volts')
canvas.print_figure('figures/oopTest.pdf')
canvas.show()
The output of the program is shown below:
First, we import the FigureCanvas from the qt5Agg backend. Then we import Figure from matplotlib.figure. After finishing our imports, the first step is to define and name (fig) the Figure object that will serve as a container for our plot. The next step is to attach the figure to an instance of FigureCanvas, whichwe name canvas, from the qt5Agg backend. This places the canvas on the screen and connects all the matplotlib routines to the Qt and Agg C++ routines that write to the screen. Next, in line 7, we create a set of axes on our figure, making a single subplot that takes up the entire frame of the figure. Finally, we write the plot to a file (line 13) and to the screen (line 14) from the canvas, which makes sense, because that’s what connects the matplotlib routines to the hardware.
The code in this example is native matplotlib object-oriented (OO) code. In its purest form, it’s the way matplotlib code is supposed to be written. The code is entirely transportable from one computer to another irrespective of the operating system, so long as the qt5Agg backend has been included in the local machine’s Python installation. In this case, the output should look the same, whether it’s on the screen or in a file, on Microsoft Windows, macOS, or any of the different flavors of Linux. By the way, if another machine does not have the qt5Agg backend installed, you can simply change lines 1 and 2 to a different backend that is installed, and the program should work as expected, with no discernible differences.
Before moving on to the next layer of matplotlib, it’s useful to introduce some matplotlib terminology—jargon—for describing the artist layer. All of the routines called in lines 5 and 7–12 are part of the Artist module and the eponymous Artist class of matplotlib. Collectively and individually, all the routines that get attached to fig and its descendant ax are known as Artists: add_subplot, plot, title, grid, xlabel, etc. Artists are those matplotlib objects that draw on the canvas, including figure. You will see the term Artist employed liberally in online documentation and commentary on matplotlib. It’s simply a part of the matplotlib lexicon, along with backend, PyPlot, and the
yet to be mentioned, PyLab.
In the next post we'll discuss the PyPlot (scripting) layer.
0 comments:
Post a Comment