savefig('boo.png', bbox_inches='tight') or savefig('boo.png', bbox_inches=Bbox([[0, 1], [2, 3]])) crops a figure before saving.
The current algorithm basically makes a new canvas that is the new dimensions, applies an extra transform to take into account the crop, and then writes the file to disk. This is problematic, in particular, because our axes are specified in figure-relative units, so changing the size of the figure is a major instability. While it usually works, it did interfere with constrained_layout (#19342, #19339) and fixed-aspect axes. In general, it is a roundabout way to achieve a crop.
It seems instead we should just compose the figure as usual, and then crop just before we save. For raster backends, this is quite trivial - we just crop the image data before the save (pillow even has a crop: https://pillow.readthedocs.io/en/stable/reference/Image.html#PIL.Image.Image.crop). The vector backends also seem to have viewports:
Simply adjusting these should be adequate to fulfill bbox_inches requirements without transforming every artist. I imagine this is also substantially faster to draw given the slowness of the transform stack.
savefig('boo.png', bbox_inches='tight')
orsavefig('boo.png', bbox_inches=Bbox([[0, 1], [2, 3]]))
crops a figure before saving.The current algorithm basically makes a new canvas that is the new dimensions, applies an extra transform to take into account the crop, and then writes the file to disk. This is problematic, in particular, because our axes are specified in figure-relative units, so changing the size of the figure is a major instability. While it usually works, it did interfere with
constrained_layout
(#19342, #19339) and fixed-aspect axes. In general, it is a roundabout way to achieve a crop.It seems instead we should just compose the figure as usual, and then crop just before we save. For raster backends, this is quite trivial - we just crop the image data before the save (pillow even has a
crop
: https://pillow.readthedocs.io/en/stable/reference/Image.html#PIL.Image.Image.crop). The vector backends also seem to have viewports:%%BoundingBox: 0 0 503 503
TrimBox
(I think)Simply adjusting these should be adequate to fulfill bbox_inches requirements without transforming every artist. I imagine this is also substantially faster to draw given the slowness of the transform stack.
ping @anntzer
The text was updated successfully, but these errors were encountered: