Re: Generating a movie

From: OKUMURA, Akira <oxon_at_ceres.phys.s.u-tokyo.ac.jp>
Date: Fri, 13 Mar 2009 10:38:13 +0900


Hello Tom,

gifsicle may be a candidate.

see,
http://root.cern.ch/root/roottalk/roottalk06/0586.html

If your definition of "best" means image quality, optimized GIF animation is the best.

Regards,

OKUMURA, Akira oxon_at_ceres.phys.s.u-tokyo.ac.jp Department of Physics, The University of Tokyo 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033
TEL/FAX +81 3-5841-4173/4059
Skype : okumura.akira

On 2009/03/13, at 1:06, Tom Roberts wrote:

> I want to generate a movie of the data contained in a TNtuple.
>
> The TNtuple rows each contain one sample of a track:
> t,x,y,z,Px,Py,Pz,trackID,particleID.
> There are ~100 tracks in the TNtuple, ~100,000 total rows.
> The beam center is along the z axis.
>
> My current plan is to generate successive frames using an x-y plot
> of the TNtuple with a cut on t, do canvas->SaveAs("movie_%d.png")
> [%d = frame number], then increment the cut on t and the frame
> number, repeating until the TNtuple has no remaining entries. I'll
> increment t corresponding to the movie's frame rate, interpolating
> the TNtuple data (ensuring that each existing track has exactly 1
> entry).
>
> [I have more sophisticated plans; this is the simplest to
> describe and covers the essential issues.]
>
> That generates hundreds to thousands of .png files. I then use
> ffmpeg to convert them to a movie (this is a remarkable, open-source
> tool). http://www.ffmpeg.org/
>
> The attached macro generates 500 frames of a 21-second movie using
> test data (25 trajectories each moving in a randomized circle):
> root movie.C
> --- took 73 sec
> ffmpeg -r 24 -i m_%d.png m.mov
> --- took 6 sec
> Commenting out the SaveAs(), the macro executes in 4 sec,
> essentially all of which is overhead, so there's not much point in
> optimizing or compiling it.
>
> This is not bad, creating the movie at a rate of 1/4 real time. But
> I am new to making movies and wonder if I'm missing something
> obvious. So I ask:
>
> Is there a better way to do this?
> Are there better tools available?
> Is there any way to speed up the SaveAs()?
> The canvas was clearly visible and updated at each frame; can that
> be avoided to speed it up?
> Which image format is best? (ffmpeg supports most)
> Which movie format is best? (ffmpeg supports most)
>
>
> BTW I salute the entire Root team for making such a flexible program!
> It's amazing that I could start from just a vague notion and create
> such a test movie in about 1/2 day (half of which was finding ffmpeg).
>
>
> Tom Roberts
>
> class Traj {
> double centerX;
> double centerY;
> double radius;
> double speed;
> double phi;
> TMarker *marker;
> static TRandom *rand;
> public:
> Traj(double x, double y, double r, double s, int m) {
> if(rand == 0) rand = new TRandom();
> if(x < 0.0) x = rand->Uniform();
> if(y < 0.0) y = rand->Uniform();
> if(r < 0.0) r = 0.1*rand->Uniform() + 0.1;
> if(s < 0.0) s = 0.1*rand->Uniform();
> centerX=x; centerY=y; radius=r; speed=s;
> phi=2.0*3.14159*rand->Uniform();
> marker = new TMarker(x,y,m);
> marker->Draw();
> }
> void draw() {
> double x=radius*cos(phi) + centerX;
> double y=radius*sin(phi) + centerY;
> marker->SetX(x);
> marker->SetY(y);
> phi += speed;
> if(phi > 2.0*3.14159) phi -= 2.0*3.14159;
> }
> };
> TRandom *Traj::rand=0;
>
> void movie()
> {
> printf("movie.C begun\n");
> #define N 25
> Traj *t[N];
>
> c = new TCanvas();
>
> for(int i=0; i<N; ++i)
> t[i] = new Traj(-1,-1,-1,-1,21);
>
> for(int i=0; i<500; ++i) {
> for(int j=0; j<N; ++j)
> t[j]->draw();
> //c->Update();
> char tmp[64];
> sprintf(tmp,"m_%d.png",i);
> c->SaveAs(tmp);
> }
> delete c;
> printf("movie.C ends\n");
> gApplication->Terminate(0);
> }
Received on Fri Mar 13 2009 - 02:38:22 CET

This archive was generated by hypermail 2.2.0 : Fri Mar 13 2009 - 11:50:02 CET