Jupyter "inline" backend seems to misinterpret "figsize" with Axes3D #16463

mgeier · 2020-02-10T17:04:21Z

I don't know if this is a bug in Jupyter/IPython or in Matplotlib ...

Bug report

Bug summary

When creating 3D plots (using Axes3D) with the "inline" backend (which is the default) in a Jupyter notebook, the argument figsize doesn't seem to work as intended. It looks like the width is ignored when calculating the figure size (but it doesn't seem to be ignored when calculating the size of the "axes" object?).

Actual outcome

First, when using fig.gca(projection='3d'), which is used in the official Matplotlib examples:

The same thing happens when using fig.add_subplot(projection='3d'):

Interestingly, a slightly different thing happens when using fig.add_axes([0, 0, 1, 1], projection='3d') and Axes3D(fig) (which is discouraged?):

Expected outcome

When using a "normal" 2D Axes, it looks as expected:

The output from fig.add_axes([0, 0, 1, 1]) is also different in this case:

Matplotlib version

Operating system: Debian Linux
Matplotlib version: master
Matplotlib backend (print(matplotlib.get_backend())): module://ipykernel.pylab.backend_inline
Python version: 3.7.6
Jupyter version (if applicable): JupyterLab master

The text was updated successfully, but these errors were encountered:

jklymak · 2020-02-10T17:23:46Z

inline use bbox_inches='tight' and hence clips the figure to the size of the drawn objects. That will lead to different sized figures if your drawn axes are different sizes.

add_axes([0, 0, 1, 1]) says to fill the figure with the axes. bbox_inches='tight' then expands the figure to include the axes.

I'm going to close this as its understood behaviour and not a bug per-se, though I agree the decision to use bbox_inches='tight' can cause confusion.

mgeier · 2020-02-10T20:22:53Z

Thanks for the quick answer @jklymak!
I was actually already aware of the bbox_inches='tight' problem (I've even mentioned it in my pamphlet about wrong default values in the inline backend), but I didn't realize that it was also the culprit in this case!

I'm going to close this as its understood behaviour and not a bug per-se, though I agree the decision to use bbox_inches='tight' can cause confusion.

I was still surprised that the aspect ratio of the figure was completely changed. I would understand if some empty space were removed from all sides, but in this case a lot of "empty" space was removed from the left and right sides, but apparently not from the top and bottom?

Are you sure that's not a bug in the bbox_inches='tight' algorithm?

Here are a few updated screenshots. First, for comparison, two cases repeated from above:

And now without the bbox_inches='tight' setting:

And here's how "normal" 2D plots look without the bbox_inches='tight' setting:

WeatherGod · 2020-02-10T20:26:49Z

I can't remember, but it might be that the tick labels for an Axes3D object is stored in a separate location special for Axes3D. Therefore, the "tight" algorithm doesn't know to check for those tick label's boxes.

…

On Mon, Feb 10, 2020 at 3:22 PM Matthias Geier ***@***.***> wrote: Thanks for the quick answer @jklymak <https://github.com/jklymak>! I was actually already aware of the bbox_inches='tight' problem (I've even mentioned it in my pamphlet about wrong default values in the inline backend <https://nbviewer.jupyter.org/github/mgeier/python-audio/blob/master/plotting/matplotlib-inline-defaults.ipynb>), but I didn't realize that it was also the culprit in this case! I'm going to close this as its understood behaviour and not a bug per-se, though I agree the decision to use bbox_inches='tight' can cause confusion. I was still surprised that the aspect ratio of the figure was completely changed. I would understand if some empty space were removed from all sides, but in this case a lot of "empty" space was removed from the left and right sides, but apparently not from the top and bottom? Are you sure that's not a bug in the bbox_inches='tight' algorithm? Here are a few updated screenshots. First, for comparison, two cases repeated from above: [image: image] <https://user-images.githubusercontent.com/705404/74185869-c7679780-4c49-11ea-830e-82a592d9bba8.png> And now without the bbox_inches='tight' setting: [image: image] <https://user-images.githubusercontent.com/705404/74185956-fc73ea00-4c49-11ea-9404-7726327a1ca5.png> And here's how "normal" 2D plots look without the bbox_inches='tight' setting: [image: image] <https://user-images.githubusercontent.com/705404/74186199-70ae8d80-4c4a-11ea-90be-790ea110d8be.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#16463?email_source=notifications&email_token=AACHF6D5ZP6WC3WP3JXVDS3RCGZR7A5CNFSM4KSR66V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELKECCI#issuecomment-584335625>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACHF6BGVXC5SDPREJFCCGDRCGZR7ANCNFSM4KSR66VQ> .

mgeier · 2020-02-14T17:38:45Z

Thanks @WeatherGod, so are you saying this could be a bug?

If yes, could you (or @jklymak) please re-open this issue?

kopytjuk · 2020-02-21T19:29:30Z

Hmm on my system everything works as expected:

Windows 10
Python 3.7.3
matplotlib-3.1.3

Seems to be a problem for newer releases, could reproduce it on 2bdf82b

WeatherGod · 2020-02-21T20:06:25Z

You might have a setting somewhere that turns off jupyter or ipython's auto cropping setting.

…

On Fri, Feb 21, 2020 at 2:29 PM Marat K. ***@***.***> wrote: Hmm on my system everything works as expected: [image: image] <https://user-images.githubusercontent.com/12762439/75065122-817fbe80-54e8-11ea-8678-47bfb3f9423a.png> Windows 10 Python 3.7.3 matplotlib-3.1.3 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16463?email_source=notifications&email_token=AACHF6DESLIYOCKE2ZQOVTDREATRVA5CNFSM4KSR66V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMT2HKY#issuecomment-589800363>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACHF6BAGJBM3RELOLDOXITREATRVANCNFSM4KSR66VQ> .

ImportanceOfBeingErnest · 2020-02-21T20:33:28Z

This bisects to 64f197b which has apparently been recreated via #16472.
So it's not visible in any released version yet.

To make sure we're all on the same page here, let's take jupyter (lab) out of the equation and create a clear bug report here:

import matplotlib.pyplot as plt
from  mpl_toolkits.mplot3d import Axes3D

plt.rcParams["axes.facecolor"] = "yellow"

plt.subplots(dpi=72, figsize=(6,3), subplot_kw={"projection" : "3d"})

plt.savefig("test1.png", facecolor="cyan")
plt.savefig("test2.png", facecolor="cyan", bbox_inches="tight")
plt.show()

Actual outcome in 3.1.3

direct save

with bbox_inches="tight"

Outcome in current master

direct save

with bbox_inches="tight"

Expected outcome

The direct save is expected. What's unexpected is the aspect ratio changing in the with bbox_inches="tight" case. The expected outcome would be something like this instead:

jklymak · 2020-02-21T20:37:06Z

ping @eric-wieser

eric-wieser · 2020-02-21T20:52:47Z

What does bbox_inches="tight" do with axis("equal") in a 2d plot?

jklymak · 2020-02-21T21:01:11Z

It trims the figure size to encompass just the 2d-plot.

anntzer · 2020-02-22T11:25:16Z

Should this block 3.2? Let's say yes for safety, but feel free to untag if you think not.

QuLogic · 2020-02-24T11:20:46Z

That PR is only in master, so I don't think we need to block 3.2. That is, the outcome of @ImportanceOfBeingErnest's test on v3.2.x is the same as the 3.1.3 result.

talaikis · 2020-03-24T10:36:31Z

For me, this bug is only in Linux (Ubuntu), Windows saves images ok.

tacaswell · 2020-05-26T23:53:17Z

ok, sorted out why this is happening.

In

matplotlib/lib/matplotlib/tight_bbox.py

Lines 28 to 36 in 9ccdb1d

    
           for ax in fig.axes: 
        
               pos = ax.get_position(original=False).frozen() 
        
               locator_list.append(ax.get_axes_locator()) 
        
               asp_list.append(ax.get_aspect()) 
        
               def _l(a, r, pos=pos): 
        
                   return pos 
        
               ax.set_axes_locator(_l) 
        
               ax.set_aspect("auto")

we freeze all of the axes postiions and set the aspect to auto for all of the axes having relied on a previous draw to have put them all in the right place. The next time we draw (for the render we actually emit) none of the axes adjust their positions / limits / etc and the transforms all progate through as we expect. Very previously Axes3D would do something about set_aspect('equal') that was sometimes right but sometimes very wrong so we disabled (to some notable protest). Previously (as of 3.2) Axes3D was always in auto mode. On master, we now treat Axes3D like it always has a fixed aspect ratio (which is not 1:1:1 but 4:4:3, see #17172). Thus on master when we set the aspect to "auto" in tight_bbox.adjust_bbox that effectively gets ignored and in the second draw we do adjust the position of the axes, the transforms all propgate and we get this issue. The pragmatic solution is to special case Axes3D and make sure that we suppress adjusting the limits is this case.

To make bbox_inches='tight' work correctly, we cache the positions of all of the axes, change their aspect to 'auto', adjust the transforms on the figure, render the output, and then restore the previous setting of aspect to each of the figures. This prevent the Axes from trying to adjust their size on draw. This matters because for the render that is emitted the figure transforms are out of sync with the figure size. As part of cleaning fixing the rendering of Axes3D in matplotlib#8896 / matplotlib#16472 we started to use apply_aspect to re-size the area the Axes3D takes up to maintain a fixed ratio between the axes when the aspect is "auto". However this conflicts with the expectation in tight_bbox.adjust_bbox as it assumes setting the aspect to "auto" will prevent any axes resizing. This commit addresses this by: - exiting the Axes3D.apply_aspect early if aspect is auto - adding a new aspect mode 'auto_pb' which is the default for Axes3D which maintains the current master branch behavior of maintaining a fixed ratio between the sizes of the x, y z axis independent of the data limits. - re implement several functions on Axes3D to make sure they handle sharez correctly. closes matplotlib#16463.

The way that bbox_inches='tight' is implemented we need to ensure that we do not try to adjust the aspect during the draw (because we have temporarily de-coupled the reported figure size from the transforms which results in the being distorted). Previously we did not have a way to fix the aspect ratio in screen space of the Axes (only the aspect ratio in dataspace) however in 3.3 we gained this ability for both Axes (matplotlib#14917) and Axes3D (matplotlib#8896 / matplotlib#16472). Rather than add an aspect value to `set_aspect` to handle this case, in the tight_bbox code we monkey-patch the `apply_aspect` method with a no-op function and then restore it when we are done. Previously we would set the aspect to "auto" and restore it in the same places. closes matplotlib#16463.

beasteers · 2022-04-21T17:32:10Z

Hmm I'm still seeing this in 3.5.1 (on mac, python 3.10) - reproduced with and without jupyter

fig = plt.figure(figsize=(20, 6))
fig.subplots_adjust(left=0, right=1, bottom=0, top=1, wspace=0, hspace=0)
ax = fig.add_subplot(111, projection="3d", facecolor='#000000', elev=70., azim=0, aspect='auto')
ax.axis('off')
ax.plot_surface(X, Y, S / 10, cmap=plt.get_cmap('magma'))

No matter what I try I can't change the axis aspect ratio to fill the figure.

fig.subplots_adjust(left=-1, right=2) doesn't stretch it, it just moves it back and forth

tacaswell · 2022-04-21T22:00:03Z

@beasteers I think you want https://matplotlib.org/stable/api/_as_gen/mpl_toolkits.mplot3d.axes3d.Axes3D.html#mpl_toolkits.mplot3d.axes3d.Axes3D.set_box_aspect

Could you please post this at https://discourse.matplotlib.org (if you think it is a usage question) or open a new issue (if you think it is a bug)?

diplodocuslongus · 2024-05-10T14:07:51Z

I was observing exactly the same as @beasteers , Linux, python 3.10, Matplotlib 3.7.1.
The trick to fill the figure is to use the proper combination of aspect and zoom (parameters of Axes3D.set_box_aspect), and figsize.
An example:

fig,ax1 = plt.subplots(1,1,figsize=(10, 6), constrained_layout=False,subplot_kw=dict(projection='3d'))
azi = 30
ax1.view_init(elev = 10, azim = azi)
ax1.set_box_aspect((3,7,3),zoom = 1.5)
fig.savefig('test.png')

jklymak closed this as completed Feb 10, 2020

jklymak added the Community support Users in need of help. label Feb 10, 2020

jklymak reopened this Feb 14, 2020

ImportanceOfBeingErnest added topic: geometry manager LayoutEngine, Constrained layout, Tight layout topic: mplot3d and removed Community support Users in need of help. labels Feb 14, 2020

anntzer added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label Feb 22, 2020

anntzer added this to the v3.2.0 milestone Feb 22, 2020

QuLogic modified the milestones: v3.2.0, v3.3.0 Feb 24, 2020

tacaswell mentioned this issue May 27, 2020

FIX: add set_box_aspect, improve tight bounding box for Axes3D + fix bbox_inches support with fixed box_aspect #17515

Merged

6 tasks

QuLogic closed this as completed in #17515 Jun 6, 2020

jklymak mentioned this issue Apr 1, 2021

Positioning floating_axes.FloatingSubplot #19832

Open

Uh oh!

Jupyter "inline" backend seems to misinterpret "figsize" with Axes3D #16463

Jupyter "inline" backend seems to misinterpret "figsize" with Axes3D #16463

Comments

mgeier commented Feb 10, 2020

Bug report

jklymak commented Feb 10, 2020

Uh oh!

mgeier commented Feb 10, 2020

Uh oh!

WeatherGod commented Feb 10, 2020 via email

Uh oh!

mgeier commented Feb 14, 2020

Uh oh!

kopytjuk commented Feb 21, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

WeatherGod commented Feb 21, 2020 via email

Uh oh!

ImportanceOfBeingErnest commented Feb 21, 2020

Actual outcome in 3.1.3

Outcome in current master

Expected outcome

Uh oh!

jklymak commented Feb 21, 2020

Uh oh!

eric-wieser commented Feb 21, 2020

Uh oh!

jklymak commented Feb 21, 2020

Uh oh!

anntzer commented Feb 22, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

QuLogic commented Feb 24, 2020

Uh oh!

talaikis commented Mar 24, 2020

Uh oh!

tacaswell commented May 26, 2020

Uh oh!

beasteers commented Apr 21, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tacaswell commented Apr 21, 2022

Uh oh!

diplodocuslongus commented May 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kopytjuk commented Feb 21, 2020 •

edited

Loading

anntzer commented Feb 22, 2020 •

edited

Loading

beasteers commented Apr 21, 2022 •

edited

Loading

diplodocuslongus commented May 10, 2024 •

edited

Loading