consider utilizing gif

[untzag]

We could get rid of our builtin / hacky animated gif support.

https://github.com/maxhumber/gif

[darienmorrow]

Here is an example usage of this library for a simulation of @ddkohler's.

import gif
import matplotlib.pyplot as plt
import WrightTools as wt
import numpy as np

chan = "dI_I"
p = "tdle_sim.wt5"
d = wt.open(p)
d.create_channel(name="dI_I", values=d.A[:] + d.B[:] + d.C[:] + d.D[:], signed=True)
for channel in d.channels:
    channel.normalize()

@gif.frame
def plot_wigner(pump):
    fig, gs = wt.artists.create_figure(cols=[1,'cbar'])
    ax = plt.subplot(gs[0])
    dx = d.chop("w_probe", "delay", at={"w_pump": [pump, "eV"]}, verbose=False)[0]
    dx.constants[0].format_spec = ".2f"
    label = dx.constants[0].label
    label = label.replace("w\;pump", "\\hslash\\omega_{pump}")  
    ax.contourf(dx, channel=chan, vmin=-1, vmax=1)
    ax.contour(dx, levels=np.array([0]), colors='k', channel=chan,)
    ax.set_title(label, fontsize=18)
    ax.grid()
    xlabel = '$\\mathsf{\\hslash\\omega_{probe} \\; (eV)}$'
    ylabel = '$\\mathsf{T \\; (ps)}$'
    wt.artists.set_fig_labels(xlabel=xlabel, ylabel=ylabel)
    cax = plt.subplot(gs[1])
    ticks = np.linspace(-1,1,11)
    label = '$\\mathsf{\\Delta I}$'
    wt.artists.plot_colorbar(cax=cax, cmap='signed', ticks=ticks, label=label)

frames = []
for pump in d.w_pump.points:
    frame = plot_wigner(pump)
    frames.append(frame)

gif.save(frames, "wigners.gif", duration=100)

tdle_sim.zip

[darienmorrow]

The way the color space is segmented is a bit problematic...

[ksunden]

Yeah, they do not seem to have a nice easy way to say "I want a large color palette" (or perhaps it is using a color palette that spans the entire range of colors, not just used colors, don't fully know)

We currently use imageio to do this in stitch_to_animation to accomplish this task. Both gif and imageio use Pillow under the hood (well imageio has a couple backends, but I think pillow is used by default) It may be pretty easy to PR gif to add palette size/explicit quantization.

That said, not sure I fully agree with the premise that our solution is "hacky", not any more so than gif is itself, at least.

[kameyer226]

Would going the ffmpeg way to making movies , rather than animated .gifs help? I was unable to get an older script to make a movie so I installed ffmpeg, as well as a sort of helper program called celluloid, and did the following:

from celluloid import Camera Writer = anim.writers['ffmpeg'] writer = Writer(fps=15, metadata=dict(artist='Me')) #, bitrate=1800)

<do work, generate 3d data>

fig, gs = wt.artists.create_figure(cols=[1, 'cbar'])
ax = plt.subplot(gs[0, 0])

ax.set_xlabel(exp.active_axes[0].name)
ax.set_ylabel(exp.active_axes[1].name)
camera=Camera(fig)

for i in range(0,nt-1,1):
    coll = ax.pcolor(xi,yi,zi[i][:][:],cmap='default')
    coll = ax.contour(xi,yi,zi[i][:][:],colors='k')
    cax=plt.subplot(gs[0,1])
    wt.artists.plot_colorbar(label='amplitude')

    camera.snap()

ani=camera.animate(repeat=True)
ani.save('animate.mp4', writer=writer)`

FFmpeg seems very versatile. It should also be able to convert animated GIFs. See https://opensource.com/article/17/6/ffmpeg-convert-media-file-formats and https://superuser.com/questions/556029/how-do-i-convert-a-video-to-gif-using-ffmpeg-with-reasonable-quality However I got a warning message running this script:

MatplotlibDeprecationWarning: Adding an axes using the same arguments as a previous axes currently reuses the earlier instance. In a future version, a new instance will always be created and returned. Meanwhile, this warning can be suppressed, and the future behavior ensured, by passing a unique label to each axes instance.

Which I cannot currently resolve and it is unknown if this "future version" will cause great problems with this above method.

[untzag]

@kameyer226 ffmpeg seems cool---in fact I used to use it back in the day when we first started playing with animated figures---see SI from this paper :arrow_right: http://doi.org/10.1021/acsnano.5b05198

@ksunden I think that my original "hacky" comment comes from the multiple steps involved in using stitch_to_animation. Our current support totally works, and maybe that's enough! The cool thing about gif is that you don't need to save images and then stitch them together. I could even imagine making a new quick3D method based on gif.

All of this is super low priority in my book---I mostly opened the issue as a way of bookmarking gif as something that exists :smile: