Vertex body and outline are not consistent when using high DPI with matplotlib backend

[szhorvat]

Describe the bug

By default, each vertex is drawn as a disk, with an outline. Under specific circumstances (using high DPI settings), the two are not drawn consistently. The outline may be much bigger than the vertex body, and there may be a gap between the two.

To reproduce

import igraph as ig
import matplotlib.pyplot as plt

g = ig.Graph.Ring(4)

fig, ax = plt.subplots(dpi=1000)

ig.plot(g, target=ax, layout=[[-10,-10], [10,-10], [10,10], [-10,10]], edge_width=0.1, edge_color='blue', vertex_size=0.1)

ax.autoscale_view()

fig.set_size_inches(1,1)

plt.show()

Screenshot from Jupyter notebook:

Notice that there is a gap between the outline and the vertex body.

Version information

0.10.4

[ntamas]

Here's a pure Matplotlib repro, igraph not involved:

from matplotlib.patches import Circle
import matplotlib.pyplot as plt

fig, ax = plt.subplots(dpi=1000)

ax.add_patch(Circle((0, 0), 0.1, linewidth=1, edgecolor="black"))
ax.add_patch(Circle((0, 50), 0.1, linewidth=1, edgecolor="black"))
ax.add_patch(Circle((50, 0), 0.1, linewidth=1, edgecolor="black"))
ax.add_patch(Circle((50, 50), 0.1, linewidth=1, edgecolor="black"))

ax.get_xaxis().set_ticks([])
ax.get_yaxis().set_ticks([])

ax.spines['top'].set_visible(False)
ax.spines['right'].set_visible(False)
ax.spines['bottom'].set_visible(False)
ax.spines['left'].set_visible(False)

ax.autoscale_view()

fig.set_size_inches(1,1)

plt.show()

I guess it's due to the line width being much larger than the vertex size. The same effect can be achieved if the line width is 10 (instead of 1) and the vertex size is 1 (instead of 0.1).

[szhorvat]

It would be useful to be able to control not only the vertex colour, but also the colour of the outline and its width. In Mathematica this is fairly easy, and I find it quite useful.

[iosonofabio]

This is kind of by design in mpl. Some plotting functions (e.g. scatter) scale differently upon zoom in/out and probably DPI scaling from others (e g. Circle).

I suggest we reach out to @tacaswell asking for enlightenment

[tacaswell]

By an extreme coincidence we just had matplotlib/matplotlib#25410 opened (see matplotlib/matplotlib#25410 (comment) for useful links and matplotlib/matplotlib#25410 (comment) for an SVG related analysis).

The source of the problem is that the edgewidth is bigger than the size size of the marker and the logic for drawing the stroke for the edge grows confused (because what should it draw for a shape where the edge in bigger than the shape?).

In base Matplotlib (and hence I will assume in igraph) you do have full control over the size, colour, the outline colour, and the outline width but at some settings of size and edge width you are in the realm of undefined behavior and get artifacts.

---

@iosonofabio Is correct, some of the plotting tools (e.g. scatter and plot) draw markers that are placed (normally) in data space and sized in screen space (so if you change the view limits in/out they will stay the same size, which means you can change the apparent overlap of adjacent markers by zooming but it means they will always be visible no matter your view limits). Patches (like Circle) are both place and sized in data units (so they will never move / overlap relative to each other but at some view limits they may be too big or too small to see).

[ntamas]

Okay, so it seems like there are two ways to fix this in igraph:

1. We change the semantics of the vertex_frame_width parameter of plot() calls. Right now it is passed as-is to Matplitlib, and the default is 1, so if you have vertex sizes smaller than that, you'll see these artifacts. We can change 1 to mean "whatever looks nice with the default marker size" and treat it as a relative scaling factor (e.g., vertex_frame_width=2 would mean "twice the default outline width"). I don't quite like this because all the other width-like plotting parameters are treated as absolute values in canvas units. Plus, we would be breaking the figures of everyone who happened to use vertex_frame_width in the past.
2. We change the default value of vertex_frame_width to None and make None mean "just come up with a frame width that looks nice". We can then use something like max(1, vertex_size / 20) as the default, and we can be sure that people who have used vertex_frame_width in their own plots would still get the same results - but people who did not specify an outline width and used vertex sizes smaller than 20 would see slightly different outline widths.

So, I'm gonna implement 2 next week unless there are objections or better ideas.

Plus, the existence of vertex_frame_width and vertex_frame_color should clearly be documented for the Matplotlib backend.

[szhorvat]

I do not have a clear understanding of the various types of units used by matplotlib, but it seems to me that just like in Mathematica, there's a distinction between absolute units (absolute in print sizes) and units for the coordinate frame? And the vertex outline is in absolute units, meaning that the width is the same (1 point?) regardless of the vertex size?

If so, I think that's good design. The outline should be in absolute units and should not scale with the vertex size. This is necessary for predictable line widths in print and for figures with good aesthetics.

I think you're saying the same here @ntamas, right?

We can change 1 to mean "whatever looks nice with the default marker size" and treat it as a relative scaling factor (e.g., vertex_frame_width=2 would mean "twice the default outline width"). I don't quite like this because all the other width-like plotting parameters are treated as absolute values in canvas units.

---

Plus, the existence of vertex_frame_width and vertex_frame_color should clearly be documented for the Matplotlib backend.

I was not aware of these. I would say that clearly documenting these, and including these in the table within the tutorial is a sufficient fix. If the user is setting a very small vertex size that is not compatible with the default vertex frame width, they should manually reduce the frame width as well.

I know that my colleague was looking at the various styling options in the tutorial here. Just include the options there and add "(matplotlib only)" to the description.

One last comment is that there should be a clean way to request not to draw a vertex frame at all. vertex_frame_width=0 achieves that, but is that really a clean way that includes no line in the output, or does it actually include a zero-width line which may get rendered badly in some formats (e.g. when exported to PDF)?

[iosonofabio]

see also #651 which touched upon similar issues with scaling as mentioned here

[iosonofabio]

btw I have on my agenda to implement a composite artist for our graphs as suggested by @tacaswell a while back. Just have not had time to get around it yet. Hopefully in the next month or two.

[tacaswell]

but it seems to me that just like in Mathematica, there's a distinction between absolute units (absolute in print sizes) and units for the coordinate frame?

yes, and we a zoo of coordinate systems: https://matplotlib.org/stable/tutorials/advanced/transforms_tutorial.html and sizes which are a mix of absolute (figure size, font size, line widths, some marker sizes), relative/scaled (data coordinates), and fractional (axes fraction, figure fraction).

And the vertex outline is in absolute units, meaning that the width is the same (1 point?) regardless of the vertex size?

Yes, that is the case.

vertex_frame_width=0 achieves that, but is that really a clean way that includes no line in the output, or does it actually include a zero-width line which may get rendered badly in some formats (e.g. when exported to PDF)?

I'm 95% sure this is the right way to do this because for patches the filled region + edges are 1 entity in the vector backends. Setting the width to 0 gives the actual renderer the chance to do the right thing.

[szhorvat]

Does matplotlib allow for specifying the offset in "absolute" units, i.e. the same type of units that are currently used for the vertex outline, as well as for the font size?

---

For some inspiration, here's how Mathematica's positioning system works:

In the most general case, when adding a label to an object, one can specify the location of a reference point relative to both the object and the label. This is done using "fractional" coordinates that are relative to the bounding box of each, running between 0 and 1.

For example, we can put the reference point in the centre of the object (the vertex) using {0.5, 0.5}, and then align the centre of the label there using {0.5, 0.5} again. Or we can put the reference point on the right edge of the vertex, and on the left edge of the label, using {{1, 0.5}, {0, 0.5}}, causing the label to be drawn directly to the right of the vertex, just touching it. Want some space? Move the reference point in the vertex to the right by 30%: {{1.3, 0.5}, {0, 0.5}}.

Normally one does not work with these coordinates directly, but keyword presets, such as Before, Above, {Top, Left}, Center, etc.

This system is very flexible because it makes it possible to take both the individual label size and the individual vertex size into account (both of which can vary from vertex to vertex within the same graph). One needs both measurements to reliably place labels to the right or left of vertices, and not have the space between the vertex and the label vary in unusual ways.

@iosonofabio @tacaswell Does matplotlib provide the flexibility to implement something like this? Does it have features that would allow calculating coordinates / sizes relative to the size of various objects?

[tacaswell]

Yes, see https://matplotlib.org/stable/tutorials/text/annotations.html#basic-annotation and the more complex examples at the bottom of that page (particularly https://matplotlib.org/stable/tutorials/text/annotations.html#coordinate-systems-for-annotations). It is verbose and general, but I suspect that it would be possible to put a more tuned API on top of it.

[iosonofabio]

I have implemented a version of this in #655 now, @szhorvat please take a look if still interested

[iosonofabio]

#669 deals with some of the issues above in more detail. This thread has become a little confused but roughly speaking I'll try and check again whether vertex_frame_color and width are documented.

I don't think we should add logic to deal with cases where the vertex size is smaller than one: that type of "smart" behavior can become tricky to debug later on when the lore is forgotten.

In terms of offsets for labels, it's implemented correctly in #669, independent of zoom level.

In terms of edge start and end touching the vertex border rather than running all the way to the vertex centre, it is 99% correct in #669 and the remaining 1% is very tricky and not terribly relevant I don't think.

[szhorvat]

I have implemented a version of this in #655 now, @szhorvat please take a look if still interested

With so many things going on, I'm a bit lost. Can you clarify what change has been made that relates to this issue? The output of the code from the top post didn't change, but perhaps I'm misunderstanding something.