You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, "markersize" means something quite heterogeneous for each different marker (see below). We could easily make it mean the same thing by scaling the "base" size of each marker's path so that it has unit area. This would have the upside of making plots with a constant markersize across different markers look perceptually uniform. And would fix a few ancient issues, like issue #1099.
An alternative would be to have markers be unit "width" (see below), which would fix all but the pentagon markers to at least be slightly more uniform. We could then use the actual areas of the unit marker sizes as a simple scaling factor in Axes.scatter to fix #1099.
The point is defined to be a half-radius circle. I guess this is fine.
The pixel of course has a fixed meaning, so need not be updated.
For several markers, markersize means "width" or "height" (many omitted for clarity, but happy to edit this to include all here for reference):
For some markers, markersize means "width of square used to create me", which seems pretty unexpected after all the above examples otherwise:
And for only some polygons (notice that there are many full-width triangles in the first list above), markersize means "radius of the circumscribing circle", which means it neither corresponds to the width/height NOR the area:
Expected outcome
Two proposals for fixing this:
make all markersize=1 markers have unit area. This is easy to do by scaling their paths appropriately. The non-fillable markers could be left as-is or scaled to the size at which their "fillable" counterpart would have unit area. (e.g. '1' would be scaled so that the equilateral triangle it draws the skeleton of would have unit area, 'x' and '+' would be scaled so that the squares they draw the skeleton of would have unit area).
make all markersize=1 markers have unit width/height (whichever is larger). This seems more in line with the current "zeitgeist" of marker design. It would only require changing a couple of markers:
a) 'd' (thin diamond) and 'D' (diamond) would be scaled to be of unit height instead of "D" being made from a rotated unit square (so a factor of 1/sqrt(2)).
b) '8' (octagon) and 'p'/'*' (pentagon/star) would be scaled up slightly to have unit width. Especially for octagon (see above) this would match MUCH better the current conventions for e.g. 'x'/'X'.
c) "triangle skeletons" (i.e. 'tri_left' and friends) should be scaled to be the same width as the 'caret' family, for consistency.
Every other marker could remain the same and this convention be matched.
I am happy to make either of these into a PR (code is written for option 2 already, tbh). However, if we go with option (2), I think we should definitely fix the s argument to scatter to actually be a measurement of the area of the marker in px^2, since each marker in that case will still have a different base area measurement (also code already written, tbh).
Closing this, as I basically moved the discussion to #15703. Will happily reopen if e.g. you think that a PR of a "geometrically uniform" marker size (as opposed to a "perceptually uniform" marker size) might be accepted, in which case it might make more sense to refer to this issue directly.
Bug report
Currently, "markersize" means something quite heterogeneous for each different marker (see below). We could easily make it mean the same thing by scaling the "base" size of each marker's path so that it has unit area. This would have the upside of making plots with a constant
markersize
across different markers look perceptually uniform. And would fix a few ancient issues, like issue #1099.An alternative would be to have markers be unit "width" (see below), which would fix all but the pentagon markers to at least be slightly more uniform. We could then use the actual areas of the unit marker sizes as a simple scaling factor in
Axes.scatter
to fix #1099.Code for reproduction
Actual outcome
The


point
is defined to be a half-radiuscircle
. I guess this is fine.The
pixel
of course has a fixed meaning, so need not be updated.For several markers,
markersize
means "width" or "height" (many omitted for clarity, but happy to edit this to include all here for reference):For some markers,


markersize
means "width of square used to create me", which seems pretty unexpected after all the above examples otherwise:And for only some polygons (notice that there are many full-width triangles in the first list above),







markersize
means "radius of the circumscribing circle", which means it neither corresponds to the width/height NOR the area:Expected outcome
Two proposals for fixing this:
make all
markersize=1
markers have unit area. This is easy to do by scaling their paths appropriately. The non-fillable markers could be left as-is or scaled to the size at which their "fillable" counterpart would have unit area. (e.g. '1' would be scaled so that the equilateral triangle it draws the skeleton of would have unit area, 'x' and '+' would be scaled so that the squares they draw the skeleton of would have unit area).make all
markersize=1
markers have unit width/height (whichever is larger). This seems more in line with the current "zeitgeist" of marker design. It would only require changing a couple of markers:a) 'd' (thin diamond) and 'D' (diamond) would be scaled to be of unit height instead of "D" being made from a rotated unit square (so a factor of 1/sqrt(2)).
b) '8' (octagon) and 'p'/'*' (pentagon/star) would be scaled up slightly to have unit width. Especially for octagon (see above) this would match MUCH better the current conventions for e.g. 'x'/'X'.
c) "triangle skeletons" (i.e.
'tri_left'
and friends) should be scaled to be the same width as the'caret'
family, for consistency.Every other marker could remain the same and this convention be matched.
I am happy to make either of these into a PR (code is written for option 2 already, tbh). However, if we go with option (2), I think we should definitely fix the
s
argument to scatter to actually be a measurement of the area of the marker in px^2, since each marker in that case will still have a different base area measurement (also code already written, tbh).Matplotlib version
print(matplotlib.get_backend())
): N/AThe text was updated successfully, but these errors were encountered: