Generating videos from the REPL

[samuelpowell]

In order to generate videos (from the REPL) I find myself issuing code such as the following:

GR.inline("mov")
for i in 1:n
   plot(...)
end
GR.show();     # Writes the file to disk

Is there an easier/better way to do this?

If not, then

• after doing this, how do I reset rendering back to the (OS X) GKS terminal (if I manually call GR.inline(400) then the above loop would then opens a new window for each plot, rather than the default behaviour)
• is it possible to introduce a macro (e.g., @mov "filename.mov" for i in 1:n) which could generate the video then revert rendering to the GKS terminal?

I have attempted to use Plots.jl's animation feature to achieve the same functionality, but I find that the rendered output is distorted (at least when drawing heatmaps).

[jheinen]

You can switch "back" to normal mode, e.g.

GR.inline()
GR.contourf(GR.peaks())

Does this help?

[samuelpowell]

Without any arguments this reverts to svg output:

julia> GR.inline()
"svg"

rather than returning to plotting in the GKS console...

[jheinen]

You can also use a beginprint / endprint combination to create a movie on the fly, e.g.

using GR

x = collect(0:0.01:2*pi)

beginprint("anim.mov")
for i = 1:200
    plot(x, sin(x + i / 10.0))
end
endprint()

plot(x, atan(x))

The size can be set by a figure command, e.g.

figure(size=(800,600))

Unfortunately, the current GR binaries create a file gks.mov (hardcoded). I have fixed that (this morning) and will provide new binaries ASAP.

[jheinen]

... could also be simplified by a macro:

using GR

macro save(path, args)
   beginprint(path)
   eval(args)
   endprint()
end

x = collect(0:0.01:2*pi)
@save("anim.mov", for i = 1:200
    plot(x, sin(x + i / 10.0))
end )

plot(x, atan(x))

If you think such a macro may be useful, I can add it to the API ...

[samuelpowell]

@jheinen beginprint/endprint works really well, thank you so much.

Note that I had not tried this approach since the reference specifies a certain set of output file types, of which .mov is not one.

I personally think an @save macro would be really handy (and more obviously named that than the functionality it encapsulates) - I'm sure it's a reasonable common use case that one wants to observe the output of some algorithm as it executes, and also record that output to a file.

[tbreloff]

@jheinen It would be great if this could be included in the Plots animations... how do you do it? Can it be generalized to other backends as well?

[jheinen]

@tbreloff , the GR movie plugin can be used like any other GR/GKS output device. It internally produces PDFs and, when closed, renders those PDFs (using the MuPDF library) and creates a video (using the FFMPEG libraries). There is no need for external conversion programs provided by ImageMagick.

So, this is different from how Plots creates movies and as the functionality is (statically) built into GR, I don't think it can be generalized to other backends. As opposed to GR, most of the other backends are not capable of producing different output files at the same time.

[jheinen]

@tbreloff. We could probably "override" the gif macro when the user switches to the gr backend :-)

[tbreloff]

Well we could also add a mov macro to Plots which does the built-in behavior for GR with the same interface as gif (with the "every" and "when" syntax which is handy). I'd like this functionality for myself.

On Thursday, August 11, 2016, Josef Heinen notifications@github.com wrote:

@tbreloff https://github.com/tbreloff. We could probably "override" the gif macro when the user switches to the gr backend :-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jheinen/GR.jl/issues/34#issuecomment-239182690, or mute the thread https://github.com/notifications/unsubscribe-auth/AA492miffaR7WdtBIr3p42y6KsvKgFcBks5qezVngaJpZM4Jg8JJ .

[samuelpowell]

@jheinen @tbreloff I would note that the reason I raised this issue is because I found that the videos produced via the Plots.jl animation procedure were distorted (the figure consisted of six heatmap subplots rendered by GR).

[jheinen]

@samuelpowell : the resolution for the PNGs was probably not good enough. Did other backends (pyplot) produce better results?

[samuelpowell]

@jheinen Perhaps so, would that correlate with the distortion seen in the attached screenshot?

I was unable to use the PyPlot backend because generating each heatmap was taking several seconds (whereas GR rendered 600 frames in a couple of seconds).

[tbreloff]

Did you look at the raw PNG files to see if the same artifacts are there? I'd like to know if it's GR or imagemagick/ffmpeg

On Thursday, August 11, 2016, Samuel Powell notifications@github.com wrote:

@jheinen https://github.com/jheinen Perhaps so, would that correlate with the distortion seen in the attached screenshot?

I was unable to use the PyPlot backend because generating each heatmap was taking several seconds (whereas GR rendered 600 frames in a couple of seconds).

[image: grplotsanim] https://cloud.githubusercontent.com/assets/6370657/17593787/f685e9c8-5fde-11e6-978a-b40e6449df60.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jheinen/GR.jl/issues/34#issuecomment-239193893, or mute the thread https://github.com/notifications/unsubscribe-auth/AA492ieMy8UA4IybRmq5SngNFg4Ub8Yrks5qez2HgaJpZM4Jg8JJ .

[samuelpowell]

@tbreloff it is the raw PNG files - I had to convert them to a video manually because ImageMagick installation was failing.

As a simple example:

using Plots
gr()
anim = @animate for i=1:100
   heatmap(rand(100,100))
end

produces frames such as the attached:

[tbreloff]

Super weird. @jheinen any idea what might be happening?

On Thursday, August 11, 2016, Samuel Powell notifications@github.com wrote:

@tbreloff https://github.com/tbreloff it is the raw PNG files - I had to convert them to a video manually because ImageMagick installation was failing.

As a simple example:

using Plots gr() anim = @animate for i=1:100 heatmap(rand(100,100)) end

produces frames such as the attached:

[image: 000007] https://cloud.githubusercontent.com/assets/6370657/17595792/66741410-5fe6-11e6-9534-f7de8775e437.png

[image: 000032] https://cloud.githubusercontent.com/assets/6370657/17595797/6d47ad10-5fe6-11e6-98c2-7d4f717584c6.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jheinen/GR.jl/issues/34#issuecomment-239211080, or mute the thread https://github.com/notifications/unsubscribe-auth/AA492gGTN3SAYxnwR9jNF7tuvMLMJPrpks5qe0rDgaJpZM4Jg8JJ .

[jheinen]

@tbreloff. I just decided to implement a plain heatmap procedure. The current implementation is too complicated and slow. I have to leave now - I'll fix the problem tomorrow ...

[tbreloff]

This:

I was unable to use the PyPlot backend because generating each heatmap was taking several seconds (whereas GR rendered 600 frames in a couple of seconds).

was immediately followed by:

The current implementation is too complicated and slow

Gotta love GR :)