[GRASSLIST:356] NVIZ : getting a script to run

Hello,
Under peer pressure, I decided to display results in 3D with NVIZ (I run
5.0.0.pre5 on a linux i386). Thanks to the tutorial, I eventually managed to
create a script displaying these maps and outputting a series of .PPM files.
Neat. Except that :

* the exportation seems to be run with image dump (screen capture). You
imagine the result, if I move windows other nviz or change of desktop to
check my emails. Is it one of the features that has been corrected in 5.0.2
? Is there a workaround (apart leaving the nviz window on the top, decreasing
the pause time to speed up the process, and not checking my emails) ?

* I now have nice '.RGB' or '.PPM ' files (well, the ones that are usable),
weighting each several hundreds of kb, if not several Mb, which causes a
problem of space. Is there a trick to run a conversion command in the nviz
script ? I'd like to store the pictures as .PNG, as I can always transform a
PNG in PPM during the creation of a MPEG (quality is less important than size
in my case), and cannot really wait for the exportation to end before startng
the conversion.

Apart from this:

* I'm embedding the nviz script in a larger bash script,as a here document.
Everything runs pretty smoothly (after escaping the $ of course), but how do
I quit nviz (still staying in the parent script) ?

*I'm afraid I missed something: can I change the state in a loop ? That'll
allow me to get a 'moving viepoint' animation, scripted.

* Is there any howto describing how to write a state, or, what's the meaning
of each line/variable in the state file ? I could figure some of them, but
hav no idea for the others.

Sorry, that's a lot of question at once, but any suggestion would be more than
welcome.

Thanks
P.

--
------------------------------
Soil and Water Laboratory
Biological and Environmental Engineering Department
Cornell University
Riley-Robb Hall
ITHACA, NY 14853 - USA

Soil & Water Lab. wrote:

* the exportation seems to be run with image dump (screen capture).
You imagine the result, if I move windows other nviz or change of
desktop to check my emails. Is it one of the features that has been
corrected in 5.0.2 ? Is there a workaround (apart leaving the nviz
window on the top, decreasing the pause time to speed up the
process, and not checking my emails) ?

I don't have answers for most of your questions, but (unfortunately) I
can say that this hasn't changed in 5.0.2. There have been some recent
developments regarding off-screen rendering in the CVS HEAD version,
but I don't know the precise situation (e.g. I don't know whether the
image dumping uses it yet).

--
Glynn Clements <glynn.clements@virgin.net>

* I now have nice '.RGB' or '.PPM ' files (well, the ones that are
usable), weighting each several hundreds of kb, if not several Mb,
which causes a problem of space. Is there a trick to run a conversion
command in the nviz script ? I'd like to store the pictures as .PNG,
as I can always transform a PNG in PPM during the creation of a MPEG
(quality is less important than size in my case), and cannot really
wait for the exportation to end before startng the conversion.

Use the ImageMagick tools:
pnmtopng < dump.ppm > dump.png
sgitopnm < dump.rgb | pnmtopng > dump.png

and to make YUV files for mpeg2enc (mjpeg tools) use:
ppmtoyuv

mencoder from the mplayer people may also be helpful to you.

gifsicle is pretty good for making GIF animations as well..

Also there is ppmtompeg for creating poor-quality MPEG-1s. (aka UCB's
mpeg_encode, as requried by r.out.mpeg: make a symlink somewhere in
$PATH to get this working)

I'll get around to writing a small GRASS/NVIZ MPEG1/2/4 howto at some
point.

re. double buffered screen dumps and key-frame animation scripting- you
might try the CVS version of NVIZ.. there seems to be a lot of good
things happening there right now.

* I'm embedding the nviz script in a larger bash script,as a here
document. Everything runs pretty smoothly (after escaping the $ of
course), but how do I quit nviz (still staying in the parent script)
?

killall nviz
:wink:
but maybe you want something cleaner.

regards,
Hamish

Use the ImageMagick tools:
pnmtopng < dump.ppm > dump.png
sgitopnm < dump.rgb | pnmtopng > dump.png

The question is : does it work *inside* the nviz script ? Does "dump"
correspond to a temp file created during the script, before the picture gets
its proper name ? If not, well, back to the beginning.

Actually, I thought about a workaround: instead of relying on nviz to loop on
the maps, I'd rely on my bash parent. That way, I'd write only one PPM that I
could convert on the fly. Besides, I feel I would have some troubles with
very long image list in nviz, whereas bash could handle it OK.

The problem I foresee is that it's gonna take a looong time, to start nviz,
load the state export, close, start over. So maybe an intermediary solution,
10 maps by 10 maps (I have about 900maps, you can imagine my pb).

and to make YUV files for mpeg2enc (mjpeg tools) use:
ppmtoyuv
mencoder from the mplayer people may also be helpful to you.

I've never been able to understand the parameters of the MPEG2 algorithm,
there are far toomany parameters for me. I had some fairly nice results with
MPEG1 (with conversion ppm-png embedded). Or fli (with pbm2fli). Gifsicle is
nice indeed, but there was this patent problem with GIFs that limited its
utilisation.
Or MNG, but it's not recognized by many softwares.

re. double buffered screen dumps and key-frame animation scripting- you
might try the CVS version of NVIZ.. there seems to be a lot of good
things happening there right now.

Great ! Can I compile the latest version of NVIZ on a old version of GRASS ?
IS there a pb of backward compatibility ?

I quit nviz (still staying in the parent script)

> ?

killall nviz
:wink:
but maybe you want something cleaner.

Well, "killall nviz" is a bit too much "shock and awe" for me :wink:

--
---------------------------------------------
Soil & Water Lab.
Biological and Environmental Engineering Dept.
Cornell University
222 Riley-Robb Hall
ITHACA, NY 14853 - USA
Tel : 607-255-2463/1819
"It's more fun to compute" - Kraftwerk
---------------------------------------------

> Use the ImageMagick tools:
> pnmtopng < dump.ppm > dump.png
> sgitopnm < dump.rgb | pnmtopng > dump.png

The question is : does it work *inside* the nviz script ? Does "dump"
correspond to a temp file created during the script, before the
picture gets its proper name ? If not, well, back to the beginning.

Those commands are just for the Bash prompt.
By with the NVIZ script do you mean in:
/usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script
?
That's a Tcl/Tk script, I'd guess there would be a "system()" command in
tcl, but I wouldn't know what it was.

Yet Bash another option would be to use X window dump (xwd):
(this is for dumping a GRASS monitor, but you get the idea..)
It suffers the same non-double buffered graphics as NVIZ image dump.

OLD_MON=`d.mon -p | awk '{printf "%s", $4}'`
GRASS_VER=`g.version | awk '{printf "%s", $1 " " $2}'`
export GRASS_PNGFILE="$1".png
echo "Exporting to $GRASS_PNGFILE from [$GRASS_VER- Monitor: $OLD_MON]"
xwd -name "$GRASS_VER- Monitor: $OLD_MON" | xwdtopnm | pnmtopng \
   > $GRASS_PNGFILE

Actually, I thought about a workaround: instead of relying on nviz to
loop on the maps, I rely on my bash parent. That way, I write only one
PPM that I can convert on the fly.

Another ugly hack might be to have a cron job which runs every 20
minutes: copy *.ppm to a temporary directory, convert everything in that
directory to PNG, delete *.ppm in that dir, and move the PNG files back.

I've never been able to understand the parameters of the MPEG2
algorithm, there are far toomany parameters for me.

mpeg2enc stream.yuv -f 3 -b 1500 -q 7 -4 2 -2 2 -a 1 -o stream.mpg

might get you started. Try the MJPEG web page (sf.net I think) and
mpeg2enc man page or the mencoder web page.. you might be able to encode
with the MPEG4 Xvid codec with mpeg2enc as well with better (but less
portable) results, although I couldn't give you specific instructions
how. Note MPEG2/4 share the same potential patent woes as GIF. Various
versions of PowerPoint tend to choke on large animated GIFs (eg 4mb 300
frames). Best way of presenting them I've found is to make a blank web
page with the embedded animation centered on the page, and show it in
full screen mode in Mozilla/Galeon with all the toolbars turned off.
There was a Knoppix variant for auto-booting into your scripted
presentation, but I haven't investigated that either.. but I'm
digressing here.

You'll want to either have a script sylinking dump0001.yuv to
frame0001.yuv->frame0025.yuv so your movie isn't over in 2 seconds, or
use frame rate control (mencoder?) to slow it down to 1 fps or so. I
haven't found a great solution for this yet.

Great ! Can I compile the latest version of NVIZ on a old version of
GRASS ? IS there a pb of backward compatibility ?

For the fewest headaches, I'd grab the 5.0 CVS snapshot and try from there.

good luck,
Hamish

H Bowman wrote:

> > Use the ImageMagick tools:
> > pnmtopng < dump.ppm > dump.png
> > sgitopnm < dump.rgb | pnmtopng > dump.png
>
> The question is : does it work *inside* the nviz script ? Does "dump"
> correspond to a temp file created during the script, before the
> picture gets its proper name ? If not, well, back to the beginning.

Those commands are just for the Bash prompt.
By with the NVIZ script do you mean in:
/usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script
?
That's a Tcl/Tk script, I'd guess there would be a "system()" command in
tcl, but I wouldn't know what it was.

"exec", e.g.

  exec pnmtopng < file.ppm > file.png

Although, if you're just looking to save space, and will be converting
back to PPM for processing, you may as well just gzip the PPM file:

  exec gzip -9 file.ppm

PNG uses the gzip compression algorithm, so a .png and a .ppm.gz would
be roughly the same size.

> Actually, I thought about a workaround: instead of relying on nviz to
> loop on the maps, I rely on my bash parent. That way, I write only one
> PPM that I can convert on the fly.

Another ugly hack might be to have a cron job which runs every 20
minutes: copy *.ppm to a temporary directory, convert everything in that
directory to PNG, delete *.ppm in that dir, and move the PNG files back.

The key issue here is that you need to avoid processing a PPM that's
in the process of being written, so check the file's size or
last-modified time first.

> Great ! Can I compile the latest version of NVIZ on a old version of
> GRASS ? IS there a pb of backward compatibility ?

You would definitely need to use the CVS HEAD version of the OGSF
library (src/libes/ogsf), and I can't entirely rule out the
possibility that the latest NVIZ might depend upon some other changes
which have been made since 5.0.2.

--
Glynn Clements <glynn.clements@virgin.net>