Skip to content

Rolling image if the FFMpegWriter dpi setting does not match that specified when a figure is created #8852

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Patrick5 opened this issue Jul 9, 2017 · 4 comments
Milestone

Comments

@Patrick5
Copy link

Patrick5 commented Jul 9, 2017

Bug report

Bug summary
Playback of mp4 files written by FFMpegWriter shows a rolling image if the dpi setting does not match that specified when a figure is created. In particular, this happens if the movie frame images are being displayed on the screen, e.g. during creation of the movie. (There is also an annoying flicker.)

Code for reproduction

Animation in the code below fails, resulting in a rolling image on playback of the saved mp4 movie. Either of two modifications indicated in the comments make the saved movie play back normally.

import matplotlib.animation
import numpy
import pylab

fig = pylab.figure(figsize=(6,6), dpi=120)
writer = matplotlib.animation.FFMpegWriter(fps=10)
x = numpy.linspace(0, 6.28, 100)

with writer.saving(fig, 'rolling_bug.mp4', dpi=100):           # saving OK if dpi=120
    for offset in numpy.linspace(0, 6.28, 30):
        pylab.plot(numpy.cos(x-offset), color='black')
        # saving OK if the next line is commented out
        pylab.pause(0.01)
        writer.grab_frame()

Note that commenting out the pylab.pause() call results in no image being displayed on the screen until the end of the script.

Actual outcome
Inspection of the figure vertical dimension in pixels shows that it has changed across the call to grab_frame(), from 600 to 590 in the above example. The horizontal dimension does not change.
A screen grab from VLC Media Player is shown here:
rolling_bug_screengrab

Expected outcome

The writer.grab_frame() should not change the vertical dimension of the figure.

The flickering did not occur in the last version of Matplotlib I had installed, but I do not know what version that was. I'm pretty sure the vertical image dimension also stayed constant across the grab_frame() call, since this was (abstracted from) working code from about a year ago.

Version info

Windows 8.1
Matplotlib 2.0.2
Python 3.6.1
Anaconda 4.4.0

Installed from conda

@tacaswell tacaswell added this to the 2.1 (next point release) milestone Jul 9, 2017
@tacaswell
Copy link
Member

The problem is that when you update the on-screen graphic it re-draws it's self at 100 DPI. This means that the rendered image takes up a different number of pixels so the GUI window needs to be resized. In the vertical direction we need to make space for the toolbar so the GUI window is set to the size of your graph + the toolbar size. When the GUI window is resized there is a callback that in-turn resizes the figure (so that if you grab the corner of the window and resize it that way that gets reflected back down into the the figure size as you would expect).

The bug is miss-padding the window size for the toolbar and probably a duplicate of #8736.

@tacaswell
Copy link
Member

I can not reproduce the rolling behavior on current master.

@tacaswell
Copy link
Member

But I can still reproduce the jumping, punting to 2.1.1

@tacaswell tacaswell modified the milestones: 2.1.1 (next bug fix release), 2.1 (next point release) Aug 31, 2017
@tacaswell tacaswell modified the milestones: 2.1.1 (next bug fix release), 2.2 (next feature release) Oct 9, 2017
@anntzer
Copy link
Contributor

anntzer commented Jan 28, 2018

AFAICT, closed by #10292. Feel free to request a reopen if not.

@anntzer anntzer closed this as completed Jan 28, 2018
@QuLogic QuLogic modified the milestones: needs sorting, v2.2.0 Feb 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants