[GRASS-dev] Nviz animation wish

Bob and Helena

I’m not sure where xganim went, but it no longer compiles by default on my Mac. It was pretty klunky, but it served a potentially important role that I miss. I wonder if something like it’s functionality could be incorporated into one of the nviz animation modules. That is, currently, the animation modules (or at least the one that works well) let you interpolate to create key-frame animations of different view positions. The result can be like a fly-through or similar display.

It would be nice if you could interpolate to animate a change in surface color maps, or even a change in surface maps. That is, if you could select (as xganim did) a series of color maps and have NVIZ smoothly interpolate through them to simulate such things as vegetation change. Even more interesting (and close to my own heart) would be to select a series of surface maps to interpolate and animate. This could display surface change.

I could do this with normal maps and TclTk in the 2D display, but it might be slow (though maybe a way to get around that by pre-rendering). It would be really neat to do this in NVIZ however.

I looked at the animation code and it looks like it calls a C (Togl?) command: “Ndo_framestep”. Does this command take a color value or just a positional value?

Just musing after attending a 3-day workshop on modeling.

Michael


Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael Barton wrote:

I¹m not sure where xganim went, but it no longer compiles by default
on my Mac.

xganim requires grass to be configured with Motif (lesstif) support.
[if we rewrite xganim, we can finally dump the motif dependancy]

It was pretty klunky, but it served a potentially
important role that I miss. I wonder if something like it¹s
functionality could be incorporated into one of the nviz animation
modules.

I suggest rewritting it (and everything else except NVIZ) using WxPython.
IMO there is no point in rewriting things in TclTk when we know we will
soon rewrite to WxPython- double the work & hurts what little WxPython
momentum we have. Better to make the leap sooner rather than later..

As a manual NVIZ animation solution, perhaps load both surfaces with
the Z slider of the 2nd surface set slightly below the 1st, then with
time have the 2nd surface rise as the 1st surface sinks? So 2 "blooms"
through 1. Perhaps tweak the Z-exag of surface 2 slightly to make the
transition less harsh.

Hamish

Good point.

It's time to get back to this.

Michael

On 1/24/07 11:29 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

I suggest rewritting it (and everything else except NVIZ) using WxPython.
IMO there is no point in rewriting things in TclTk when we know we will
soon rewrite to WxPython- double the work & hurts what little WxPython
momentum we have. Better to make the leap sooner rather than later..

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael - there is a file sequencing tool for that in nviz - I have been doing it for years (I also
had some of it at your workshop), just check my website.
My slides for the lausanne workshop should have a description how to do it along
with a sample data set. I need to run now but I can write you more later.
It may be broken in the latest CVS but it worked well in 6.1

It does not replace xganim - that is a module that is really needed when you
are working with time series because it allows to browse through the series
of data quickly and animate them and always use to to prepare the series
for nviz animation (check whether they animate smoothly etc.).

Glynn has written a tcltk version of xganim - I still have it my list of things to try out
but I did not get to it. so check with him.

Helena

Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/

On Jan 25, 2007, at 12:53 AM, Michael Barton wrote:

Bob and Helena

I’m not sure where xganim went, but it no longer compiles by default on my Mac. It was pretty klunky, but it served a potentially important role that I miss. I wonder if something like it’s functionality could be incorporated into one of the nviz animation modules. That is, currently, the animation modules (or at least the one that works well) let you interpolate to create key-frame animations of different view positions. The result can be like a fly-through or similar display.

It would be nice if you could interpolate to animate a change in surface color maps, or even a change in surface maps. That is, if you could select (as xganim did) a series of color maps and have NVIZ smoothly interpolate through them to simulate such things as vegetation change. Even more interesting (and close to my own heart) would be to select a series of surface maps to interpolate and animate. This could display surface change.

I could do this with normal maps and TclTk in the 2D display, but it might be slow (though maybe a way to get around that by pre-rendering). It would be really neat to do this in NVIZ however.

I looked at the animation code and it looks like it calls a C (Togl?) command: “Ndo_framestep”. Does this command take a color value or just a positional value?

Just musing after attending a 3-day workshop on modeling.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael I second you wish, for me is almost a dream.
Have been somebody able to run xganim in a Mac? I've tried in several
occasions to compile it with no success at all.
Agustin

Michael - there is a file sequencing tool for that in nviz - I have
been doing it for years (I also
had some of it at your workshop), just check my website.
My slides for the lausanne workshop should have a description how to
do it along
with a sample data set. I need to run now but I can write you more
later.
It may be broken in the latest CVS but it worked well in 6.1

It does not replace xganim - that is a module that is really needed
when you
are working with time series because it allows to browse through the
series
of data quickly and animate them and always use to to prepare the series
for nviz animation (check whether they animate smoothly etc.).

Glynn has written a tcltk version of xganim - I still have it my list
of things to try out
but I did not get to it. so check with him.

Helena

Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/

On Jan 25, 2007, at 12:53 AM, Michael Barton wrote:

> Bob and Helena
>
> I’m not sure where xganim went, but it no longer compiles by
> default on my Mac. It was pretty klunky, but it served a
> potentially important role that I miss. I wonder if something like
> it’s functionality could be incorporated into one of the nviz
> animation modules. That is, currently, the animation modules (or at
> least the one that works well) let you interpolate to create key-
> frame animations of different view positions. The result can be
> like a fly-through or similar display.
>
> It would be nice if you could interpolate to animate a change in
> surface color maps, or even a change in surface maps. That is, if
> you could select (as xganim did) a series of color maps and have
> NVIZ smoothly interpolate through them to simulate such things as
> vegetation change. Even more interesting (and close to my own
> heart) would be to select a series of surface maps to interpolate
> and animate. This could display surface change.
>
> I could do this with normal maps and TclTk in the 2D display, but
> it might be slow (though maybe a way to get around that by pre-
> rendering). It would be really neat to do this in NVIZ however.
>
> I looked at the animation code and it looks like it calls a C
> (Togl?) command: “Ndo_framestep”. Does this command take a color
> value or just a positional value?
>
> Just musing after attending a 3-day workshop on modeling.
>
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
>
> phone:
> fax:
> www: http://www.public.asu.edu/~cmbarton
>

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
******************************************************
Dr. Agustín Diez Castillo
Departament de Prehistòria i Arqueologia
Universitat de València Phone:
Avda. Blasco Ibañez, 28 Fax:
València 46010
******************************************************

On Jan 25, 2007, at 8:19 AM, Helena Mitasova wrote:

Michael - there is a file sequencing tool for that in nviz - I have been doing it for years (I also
had some of it at your workshop), just check my website.
My slides for the lausanne workshop should have a description how to do it along
with a sample data set. I need to run now but I can write you more later.
It may be broken in the latest CVS but it worked well in 6.1

I was going to mention this also. It looks like it can make a series of ppm images, or an mpeg if GRASS was built with ffmpeg support.

And this is where I have issues. I've been wrestling with this for a while, trying to get a usable ffmpeg library on Mac OS X. Because of the VERY unstable nature of the ffmpeg project (a perpetual beta), it's hard to get something that works at any given time. This probably applies to more than just OSX. Building a universal binary is more difficult because of different processor optimizations. Nobody makes binaries for the ffmpeg libraries, just the program. At least on OSX, and I don't want to resort to Fink or Darwinports.

As an alternative to directly in nviz, there is the r.out.mpeg module. You could create the ppms in nviz, then run those thru r.out.mpeg.

But that has a similar problem - no Mac binaries for the mpeg-encode program that it uses. And ancient code - I haven't tried building it yet, but I expect problems.

A possibility would be to rewrite the r.out.mpeg module to use the ffmpeg program or other mpeg encoder, which has readily available binaries. Or just run them manually thru ffmpeg.

A question about the ffmpeg support - is it limited to just the mpeg-1 output, or can it use any format supported by ffmpeg?

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled with hyena offal?
Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal?
First Pogril: I don't know either. Wretched, isn't it?

-HitchHiker's Guide to the Galaxy

William Kyngesburye wrote:

A question about the ffmpeg support - is it limited to just the
mpeg-1 output, or can it use any format supported by ffmpeg?

There is a compile-time option (USE_XVID) to use XviD instead. It
should be straightforward to allow the user to specify the codec by
name; there is already some (commented-out) code which attempts to do
this, although it should be using avcodec_find_encoder_by_name().

See lib/ogsf/gsd_img_ppm.c for details.

--
Glynn Clements <glynn@gclements.plus.com>

On Jan 25, 2007, at 11:27 AM, Agustin Diez Castillo wrote:

Michael I second you wish, for me is almost a dream.
Have been somebody able to run xganim in a Mac? I've tried in several
occasions to compile it with no success at all.

I have it running on Mac with Lorenzo's GRASS6.1 and I have been careful not to update it
so that I don't lose that capability. Whatever happened to it I would beg to put it back
before there is a reliable replacement.

Helena

Agustin

Michael - there is a file sequencing tool for that in nviz - I have
been doing it for years (I also
had some of it at your workshop), just check my website.
My slides for the lausanne workshop should have a description how to
do it along
with a sample data set. I need to run now but I can write you more
later.
It may be broken in the latest CVS but it worked well in 6.1

It does not replace xganim - that is a module that is really needed
when you
are working with time series because it allows to browse through the
series
of data quickly and animate them and always use to to prepare the series
for nviz animation (check whether they animate smoothly etc.).

Glynn has written a tcltk version of xganim - I still have it my list
of things to try out
but I did not get to it. so check with him.

Helena

Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/

On Jan 25, 2007, at 12:53 AM, Michael Barton wrote:

Bob and Helena

I’m not sure where xganim went, but it no longer compiles by
default on my Mac. It was pretty klunky, but it served a
potentially important role that I miss. I wonder if something like
it’s functionality could be incorporated into one of the nviz
animation modules. That is, currently, the animation modules (or at
least the one that works well) let you interpolate to create key-
frame animations of different view positions. The result can be
like a fly-through or similar display.

It would be nice if you could interpolate to animate a change in
surface color maps, or even a change in surface maps. That is, if
you could select (as xganim did) a series of color maps and have
NVIZ smoothly interpolate through them to simulate such things as
vegetation change. Even more interesting (and close to my own
heart) would be to select a series of surface maps to interpolate
and animate. This could display surface change.

I could do this with normal maps and TclTk in the 2D display, but
it might be slow (though maybe a way to get around that by pre-
rendering). It would be really neat to do this in NVIZ however.

I looked at the animation code and it looks like it calls a C
(Togl?) command: “Ndo_framestep”. Does this command take a color
value or just a positional value?

Just musing after attending a 3-day workshop on modeling.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone:
fax:
www: http://www.public.asu.edu/~cmbarton

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
******************************************************
Dr. Agustín Diez Castillo
Departament de Prehistòria i Arqueologia
Universitat de València Phone:
Avda. Blasco Ibañez, 28 Fax:
València 46010
******************************************************

William Kyngesburye wrote:

> Michael - there is a file sequencing tool for that in nviz - I have
> been doing it for years (I also had some of it at your workshop),
> just check my website. My slides for the lausanne workshop should
> have a description how to do it along with a sample data set. I need
> to run now but I can write you more later.
> It may be broken in the latest CVS but it worked well in 6.1

A link to that should be added to the animations help page on the wiki.
  http://grass.gdf-hannover.de/wiki/Movies
(please)

[slight change of topic]

As an alternative to directly in nviz, there is the r.out.mpeg
module. You could create the ppms in nviz, then run those thru
r.out.mpeg.

No, that is much more than is needed. Create series of PPM images with
NVIZ keyframe animator, then use mencoder (or similar [transcode?]) to
create the MPEG. see Maris's example:
http://grass.ibiblio.org/grass63/manuals/html63_user/nviz/nviz_panel_kanim.html

If less than 100 frames an animated GIF or PNG(MNG) might be a
preferable option.

But that has a similar problem - no Mac binaries for the mpeg-encode
program that it uses. And ancient code - I haven't tried building it
yet, but I expect problems.

Again, not needed. r.out.mpeg will work fine with "ppmtompeg" which
comes with NetPBM tools. AFAIK this comes with MacOSX already.
ppmtompeg is mpeg-encode renamed; r.out.mpeg should work out of
the box, ie without ffmpeg.

A possibility would be to rewrite the r.out.mpeg module to use the
ffmpeg program or other mpeg encoder, which has readily available
binaries. Or just run them manually thru ffmpeg.

IMO it would be much better to de-emphasise r.out.mpeg and rewrite as a
shell/python/perl script depending on mencoder (or similar FFMPEG tool).
Most of that module deals with creating the MPEG-1 encode spec file,
which is not needed with newer encoders.

Certainly MPEG-1 is too cruddy to consider using for new development.
What it has going for it is a (the only?) truly patent-safe encoder
and widespread codec use. The movies it makes are huge and of poor
quality.

A question about the ffmpeg support - is it limited to just the
mpeg-1 output, or can it use any format supported by ffmpeg?

Glynn:

There is a compile-time option (USE_XVID) to use XviD instead. It
should be straightforward to allow the user to specify the codec by
name; there is already some (commented-out) code which attempts to do
this, although it should be using avcodec_find_encoder_by_name().
See lib/ogsf/gsd_img_ppm.c for details.

WRT the USE_XVID option -- I didn't finish that, it only writes the raw
stream and the output seems to be missing some header info. As such the
only player I found that would play the result was mplayer, which is
more forgiving. TODO: test with "mplayer -forceidx" & attempt fix with
mencoder (see -forceidx help in mplayer man page). Help appreciated.

Hamish

On Jan 25, 2007, at 11:51 AM, William Kyngesburye wrote:

On Jan 25, 2007, at 8:19 AM, Helena Mitasova wrote:

Michael - there is a file sequencing tool for that in nviz - I have been doing it for years (I also
had some of it at your workshop), just check my website.
My slides for the lausanne workshop should have a description how to do it along
with a sample data set. I need to run now but I can write you more later.
It may be broken in the latest CVS but it worked well in 6.1

I was going to mention this also. It looks like it can make a series of ppm images, or an mpeg if GRASS was built with ffmpeg support.

nviz will create series of rgb files - I used moviemaker to make them into movies on SGI.
I had troubles to create decent animations after moving to PCs - as mpeg movies weren't
very good for small number of frames so I used gifmerge to create animated gifs.
That was until somebody suggested convert (thank you million times, I don't remember who it was)
- it has many options and you can create high quality
animated gifs from series of rgb images (or images in other formats)
http://linux.about.com/od/commands/l/blcmdl1_convert.htm
Here are the workshop slides that describe how to do the animations from series of raster maps
in nviz including some examples:
http://skagit.meas.ncsu.edu/~helena/grasswork/foss4g/FOSS4G06WKSVisual4anim.odp (34Mb)

Helena

And this is where I have issues. I've been wrestling with this for a while, trying to get a usable ffmpeg library on Mac OS X. Because of the VERY unstable nature of the ffmpeg project (a perpetual beta), it's hard to get something that works at any given time. This probably applies to more than just OSX. Building a universal binary is more difficult because of different processor optimizations. Nobody makes binaries for the ffmpeg libraries, just the program. At least on OSX, and I don't want to resort to Fink or Darwinports.

As an alternative to directly in nviz, there is the r.out.mpeg module. You could create the ppms in nviz, then run those thru r.out.mpeg.

But that has a similar problem - no Mac binaries for the mpeg-encode program that it uses. And ancient code - I haven't tried building it yet, but I expect problems.

A possibility would be to rewrite the r.out.mpeg module to use the ffmpeg program or other mpeg encoder, which has readily available binaries. Or just run them manually thru ffmpeg.

A question about the ffmpeg support - is it limited to just the mpeg-1 output, or can it use any format supported by ffmpeg?

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled with hyena offal?
Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal?
First Pogril: I don't know either. Wretched, isn't it?

-HitchHiker's Guide to the Galaxy

On Jan 25, 2007, at 6:22 PM, Hamish wrote:

William Kyngesburye wrote:

Michael - there is a file sequencing tool for that in nviz - I have
been doing it for years (I also had some of it at your workshop),
just check my website. My slides for the lausanne workshop should
have a description how to do it along with a sample data set. I need
to run now but I can write you more later.
It may be broken in the latest CVS but it worked well in 6.1

A link to that should be added to the animations help page on the wiki.
  http://grass.gdf-hannover.de/wiki/Movies
(please)

I just put it there, Helena

[slight change of topic]

As an alternative to directly in nviz, there is the r.out.mpeg
module. You could create the ppms in nviz, then run those thru
r.out.mpeg.

No, that is much more than is needed. Create series of PPM images with
NVIZ keyframe animator, then use mencoder (or similar [transcode?]) to
create the MPEG. see Maris's example:
http://grass.ibiblio.org/grass63/manuals/html63_user/nviz/nviz_panel_kanim.html

If less than 100 frames an animated GIF or PNG(MNG) might be a
preferable option.

But that has a similar problem - no Mac binaries for the mpeg-encode
program that it uses. And ancient code - I haven't tried building it
yet, but I expect problems.

Again, not needed. r.out.mpeg will work fine with "ppmtompeg" which
comes with NetPBM tools. AFAIK this comes with MacOSX already.
ppmtompeg is mpeg-encode renamed; r.out.mpeg should work out of
the box, ie without ffmpeg.

A possibility would be to rewrite the r.out.mpeg module to use the
ffmpeg program or other mpeg encoder, which has readily available
binaries. Or just run them manually thru ffmpeg.

IMO it would be much better to de-emphasise r.out.mpeg and rewrite as a
shell/python/perl script depending on mencoder (or similar FFMPEG tool).
Most of that module deals with creating the MPEG-1 encode spec file,
which is not needed with newer encoders.

Certainly MPEG-1 is too cruddy to consider using for new development.
What it has going for it is a (the only?) truly patent-safe encoder
and widespread codec use. The movies it makes are huge and of poor
quality.

A question about the ffmpeg support - is it limited to just the
mpeg-1 output, or can it use any format supported by ffmpeg?

Glynn:

There is a compile-time option (USE_XVID) to use XviD instead. It
should be straightforward to allow the user to specify the codec by
name; there is already some (commented-out) code which attempts to do
this, although it should be using avcodec_find_encoder_by_name().
See lib/ogsf/gsd_img_ppm.c for details.

WRT the USE_XVID option -- I didn't finish that, it only writes the raw
stream and the output seems to be missing some header info. As such the
only player I found that would play the result was mplayer, which is
more forgiving. TODO: test with "mplayer -forceidx" & attempt fix with
mencoder (see -forceidx help in mplayer man page). Help appreciated.

Hamish

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

On Jan 25, 2007, at 5:22 PM, Hamish wrote:

Again, not needed. r.out.mpeg will work fine with "ppmtompeg" which
comes with NetPBM tools. AFAIK this comes with MacOSX already.
ppmtompeg is mpeg-encode renamed; r.out.mpeg should work out of
the box, ie without ffmpeg.

No, there are no commandline mpeg tools that come preinstalled with OSX. But some are readily available and up-to-date - ffmpeg, mencoder come to mind. You can also find some in Fink and Darwinports, but some people prefer to not use those.

A possibility would be to rewrite the r.out.mpeg module to use the
ffmpeg program or other mpeg encoder, which has readily available
binaries. Or just run them manually thru ffmpeg.

IMO it would be much better to de-emphasise r.out.mpeg and rewrite as a
shell/python/perl script depending on mencoder (or similar FFMPEG tool).
Most of that module deals with creating the MPEG-1 encode spec file,
which is not needed with newer encoders.

Just giving options. But a script to interface with an external mpeg encoding program of choice would be nice. If possible it should be able to handle multiple common encoders, so the user can use what they can get. (Sorry, I'm not good with shell scripting.)

On Jan 25, 2007, at 5:18 PM, Helena Mitasova wrote:

On Jan 25, 2007, at 11:27 AM, Agustin Diez Castillo wrote:

Michael I second you wish, for me is almost a dream.
Have been somebody able to run xganim in a Mac? I've tried in several
occasions to compile it with no success at all.

I have it running on Mac with Lorenzo's GRASS6.1 and I have been careful not to update it
so that I don't lose that capability. Whatever happened to it I would beg to put it back
before there is a reliable replacement.

Hm, I decided for my OSX binaries to not include xganim because I didn't want to also bloat the package with a copy of lesstif. That tcltk-based xganim of Glynn's would be great if it works comparably to the motif-based one.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy

Hamish:

> Again, not needed. r.out.mpeg will work fine with "ppmtompeg" which
> comes with NetPBM tools. AFAIK this comes with MacOSX already.
> ppmtompeg is mpeg-encode renamed; r.out.mpeg should work out of
> the box, ie without ffmpeg.

William:

No, there are no commandline mpeg tools that come preinstalled with
OSX.

Hmph. I could have sworn OSX included NetPBM...apparently not. It
would make a great candidate for inclusion the frameworks pacakge,
as several grass scripts use them.

But some are readily available and up-to-date - ffmpeg,
mencoder come to mind. You can also find some in Fink and
Darwinports, but some people prefer to not use those.

Indeed, Lorenzo included a ffmpeg binary and some img2img conversion
programs in his grasslibs/bin/ directory.

Helena:

nviz will create series of rgb files - I used moviemaker to make them
into movies on SGI.

fyi, support for SGI's RGB format was removed from NVIZ after GRASS 6.0.2.

Hamish

On Jan 25, 2007, at 7:58 PM, Hamish wrote:

William:

No, there are no commandline mpeg tools that come preinstalled with
OSX.

It
would make a great candidate for inclusion the frameworks pacakge,
as several grass scripts use them.

Really? I didn't realize. I'll look into that and see about bundling needed progs.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

On 1/25/07 4:22 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Again, not needed. r.out.mpeg will work fine with "ppmtompeg" which
comes with NetPBM tools. AFAIK this comes with MacOSX already.
ppmtompeg is mpeg-encode renamed; r.out.mpeg should work out of
the box, ie without ffmpeg.

cmb-MBP:~ cmbarton$ ppmtompeg
-bash: ppmtompeg: command not found

This on a MacBook Pro Intel with 10.4.8.

Manual searching didn't turn it up in /bin /sbin /usr/bin /usr/sbin
/usr/local/bin

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Hamish wrote:

> There is a compile-time option (USE_XVID) to use XviD instead. It
> should be straightforward to allow the user to specify the codec by
> name; there is already some (commented-out) code which attempts to do
> this, although it should be using avcodec_find_encoder_by_name().
> See lib/ogsf/gsd_img_ppm.c for details.

WRT the USE_XVID option -- I didn't finish that, it only writes the raw
stream and the output seems to be missing some header info. As such the
only player I found that would play the result was mplayer, which is
more forgiving. TODO: test with "mplayer -forceidx" & attempt fix with
mencoder (see -forceidx help in mplayer man page). Help appreciated.

Right. I suspect that you need to use libavformat to wrap the stream
inside an AVI (or similar) container.

Ultimately, the only sane approach to generating animation is to write
out a sequence of image files then use a dedicated encoding program
such as ffmpeg. Video encoding is a complex task with many parameters.
Any built-in encoding functionality is inevitably going to do a
half-baked job.

--
Glynn Clements <glynn@gclements.plus.com>

Hi all,

IMHO we should NOT add a yet another dependency for GRASS especialy
that duplicates already working utilities with not-as-good in-house
wonder. We do not have enough manpower to implement YetAnother video
encoder.

As Glynn notes, creating animation from image sequence is better. One
of best things of encoding image series into movie is that You can
play around with various video encoding options to find best
quality/size ratio for Your artwork without need to recreate
(rerender) every scene in Your animation. Stacking together all PNG's
in one movie with mplayer's encoder is described in GRASS wiki [1]
with basic options that You will need. Mplayers encoder (mencoder)
offers many other options - lot more than may offer any GRASS encoding
tool.

The hardest part of creating animations is getting those PNG frames to
disk - controling camera and saving result. When I last time had to
make movie in nviz, I ended with TCL script controlling camera movment
and orientation, as, unfortunately, I find built-in nviz tools hard to
use :frowning:
IMHO it would be better to improve nviz animation tool (one and not
many) and leave video encoding to other apps. Unfortunately I had no
time to check nviz progress in this area or to study new documentation
about this topic (FOSS4G06 demos) - maybee my opinion is outdated :wink:
Anyway - You can check animations created frame by frame and then
encoded with mencoder here [2].

Just my 0.02 Ls,
Maris.

[1] http://grass.gdf-hannover.de/wiki/Movies
[2] http://mpa.itc.it/markus/grass61/demos/rlake/

2007/1/26, Glynn Clements <glynn@gclements.plus.com>:

Ultimately, the only sane approach to generating animation is to write
out a sequence of image files then use a dedicated encoding program
such as ffmpeg. Video encoding is a complex task with many parameters.
Any built-in encoding functionality is inevitably going to do a
half-baked job.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn:

Ultimately, the only sane approach to generating animation is to
> write out a sequence of image files then use a dedicated encoding
> program such as ffmpeg. Video encoding is a complex task with many
> parameters. Any built-in encoding functionality is inevitably going
> to do a half-baked job.

NVIZ animations will almost always be of similar ilk, so it is
reasonable to assume we can derive and suggest some good defaults to use
for the encoding, and include an optional button to automatically encode
using those defaults. (e.g. value quality over encoding time, FPS, test
XviD "cartoon mode" hinting, etc) I don't mind if the actual encoding is
done by a wrapper script calling mencoder (or whatever), or if it is
simple enough to use the FFMPEG C api to drive it. I do think we should
offer some sort of "encode on-the-fly" button though.

Maris Nartiss wrote:

IMHO we should NOT add a yet another dependency for GRASS especialy
that duplicates already working utilities with not-as-good in-house
wonder. We do not have enough manpower to implement YetAnother video
encoder.

I agree with both points individually [limit new deps when reasonable +
don't reinvent the wheel], but together they conflict-- we have an
optional ffmpeg dependancy which is used to do the encoding. We're
simply connecting to their encoding API, not rewriting a new enocder all
of our own. To do automatic encoding (which I think is a very nice
feature, as it can be a complex thing), we either have to 1) depend on
something new or 2) implement YetAnother video encoder.

And to be clear, we're not actually implementing our own encoder, we are
simply calling avcodec_encode_video() and writing the result to disk.

FWIW, I'm not a big fan of "manpower" arguements -- if someone qualified
and motivated can do a job [in this case Bob], we shouldn't stop that,
as long is it is done in a maintainable way. It's up to them to work on
it or not, and we can't expect them to work on something else instead.
i.e. open source workforces are not faced with (a) or (b) choices of
what to work on, and you can't force a volunteer to work on project (b)
when they really are only interested in project (a).

As Glynn notes, creating animation from image sequence is better.

Yes, you can get better results _if_ you have lots of experience in
running and tuning a video encoder, which most users won't have.
Otherwise the "better" solution is the one which will lead to a
successful result without hours of study + trial & error.
(wiki/Movies is a huge help of course, thanks)

One of best things of encoding image series into movie is that You can
play around with various video encoding options to find best
quality/size ratio for Your artwork without need to recreate
(rerender) every scene in Your animation. Stacking together all PNG's
in one movie with mplayer's encoder is described in GRASS wiki [1]
with basic options that You will need. Mplayers encoder (mencoder)
offers many other options - lot more than may offer any GRASS encoding
tool.

Sure, for advanced users, but at the same time we should offer
"good-enough" defaults for the casual user who wants a quick result.

[1] http://grass.gdf-hannover.de/wiki/Movies

[I added your mencoder example to the NVIZ keyframe animation help page
as well]

The hardest part of creating animations is getting those PNG frames to
disk - controling camera and saving result. When I last time had to
make movie in nviz, I ended with TCL script controlling camera movment
and orientation, as, unfortunately, I find built-in nviz tools hard to
use :frowning:

All are welcome to improve the d.nviz module or rewrite a replacement
using WxPython. (eg use a vector line to set the camera route)

Also I think the nviz keyframe panel's spline interpolator needs a
wider smoothing window, i.e. don't treat each keyframe as an endpoint,
but take next keyframe on either side into account for a smooth
transition versus current bunny hops.

IMHO it would be better to improve nviz animation tool (one and not
many) and leave video encoding to other apps.

I don't think they are mutually exclusive options, and both could be
interesting projects to different people. It is my hope that we _do_
leave the bulk of the encoding to FFMEG, just we use C as a more direct
wrapper, versus UNIX shell scripting. Currently we set variables for
the bit-rate and codec, then feed it a stream. Nothing too low level.

It's just 2 lines of code: lib/ogsf/gsd_img_ppm.c

  /* encode the image */
  out_size = avcodec_encode_video(c, outbuf, DEFAULT_BUFFER_SIZE, picture);
  fwrite(outbuf, 1, out_size, fmpg);

Hamish

This discussion has been enlightening. However, it might be good to get back
to the original wish that prompted it.

Currently, in the NVIZ animation panel, you can set key frames and NVIZ will
interpolate between the key frames to produce an on-screen animation. It
will optionally save an image sequence (as per discussion below) that can be
transformed into an animation file by 3rd party software. This is fine.
However, the only characteristics animated are the position and orientation
of the 2.5D rendering.

What I asked was if this could be enhanced to also include the color and
other features of the rendering. That is, keyframe 1 shows the landscape
with one color drape, keyframe 2 shows it in a second color drape, and
keyframe 3 shows it in a 3rd color drape. Then when the animation is run,
you would see the landscape changing smoothly from color 1 to 2 to 3. If
desired, you would still output these to an image sequence (rather than to
an mpeg or other animation file). Similarly, could it handle something like
z-exaggeration or lighting direction?

So, does the Togl command that drives the keyframe animation now also accept
color rendering (and other) information, or only position and orientation?

Michael

On 1/26/07 12:42 PM, "Maris Nartiss" <maris.gis@gmail.com> wrote:

Hi all,

IMHO we should NOT add a yet another dependency for GRASS especialy
that duplicates already working utilities with not-as-good in-house
wonder. We do not have enough manpower to implement YetAnother video
encoder.

As Glynn notes, creating animation from image sequence is better. One
of best things of encoding image series into movie is that You can
play around with various video encoding options to find best
quality/size ratio for Your artwork without need to recreate
(rerender) every scene in Your animation. Stacking together all PNG's
in one movie with mplayer's encoder is described in GRASS wiki [1]
with basic options that You will need. Mplayers encoder (mencoder)
offers many other options - lot more than may offer any GRASS encoding
tool.

The hardest part of creating animations is getting those PNG frames to
disk - controling camera and saving result. When I last time had to
make movie in nviz, I ended with TCL script controlling camera movment
and orientation, as, unfortunately, I find built-in nviz tools hard to
use :frowning:
IMHO it would be better to improve nviz animation tool (one and not
many) and leave video encoding to other apps. Unfortunately I had no
time to check nviz progress in this area or to study new documentation
about this topic (FOSS4G06 demos) - maybee my opinion is outdated :wink:
Anyway - You can check animations created frame by frame and then
encoded with mencoder here [2].

Just my 0.02 Ls,
Maris.

[1] http://grass.gdf-hannover.de/wiki/Movies
[2] http://mpa.itc.it/markus/grass61/demos/rlake/

2007/1/26, Glynn Clements <glynn@gclements.plus.com>:

Ultimately, the only sane approach to generating animation is to write
out a sequence of image files then use a dedicated encoding program
such as ffmpeg. Video encoding is a complex task with many parameters.
Any built-in encoding functionality is inevitably going to do a
half-baked job.

--
Glynn Clements <glynn@gclements.plus.com>

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Hi Michael and others,

as I wrote, some time a go I found using NVIZ animation tools too
complex and ended with custom script controlling camera position, view
angle and scene contents. As whole NVIZ is just a large tcl/tk script,
it's not so hard to create own, similar script. Today I wonder how
it's possible, that script was working, but as I have some nice
animations created with that script [1], it should be working :wink:

So - if You are short on time to learn how to use NVIZ animation tools
and not affraid from tcl code, feel free to use it for ideas.

NVIZ dev's - sorry for ugly hack around Your hard work,
Maris.

[1] http://mpa.itc.it/markus/grass61/demos/rlake/

2007/1/29, Michael Barton <michael.barton@asu.edu>:

This discussion has been enlightening. However, it might be good to get back
to the original wish that prompted it.

Currently, in the NVIZ animation panel, you can set key frames and NVIZ will
interpolate between the key frames to produce an on-screen animation. It
will optionally save an image sequence (as per discussion below) that can be
transformed into an animation file by 3rd party software. This is fine.
However, the only characteristics animated are the position and orientation
of the 2.5D rendering.

What I asked was if this could be enhanced to also include the color and
other features of the rendering. That is, keyframe 1 shows the landscape
with one color drape, keyframe 2 shows it in a second color drape, and
keyframe 3 shows it in a 3rd color drape. Then when the animation is run,
you would see the landscape changing smoothly from color 1 to 2 to 3. If
desired, you would still output these to an image sequence (rather than to
an mpeg or other animation file). Similarly, could it handle something like
z-exaggeration or lighting direction?

So, does the Togl command that drives the keyframe animation now also accept
color rendering (and other) information, or only position and orientation?

Michael

(attachments)

nviz_fly_script2.txt (3.45 KB)