Here is a scenario for problems encountered and a work around for producing
a mpeg from NCARG meta files as experienced by a USGS scientist (Mike Dettinger).
Any thoughts on what is causing the problem with using ctrans to create an xwd
file, then rassplit to break it into frames, and the using xwdtoppm to convert
to ppm? Is there a better option to go from ncarg meta to mpegs?
Is there anyway to fix ncarg rassplit function
so that it turns out uncorrupted xwd files? This problem was encountered
on a Data General and Sun version of version 3.2
Here's the issue. I would like to
take a gmeta from ncarg that has many frames and split them into
xwd files. Then I intend to use xwdtoppm to turn them into ppm
files for use by another program. (Actually then I intend to use
ppmtoyuv to turn them into yuv files and then on into mpegs if
I can get mpeg_encoder to work right.)
If I just capture a screen using xwd, then xwdtoppm appears to
work just fine (and ppmtoyuv also). But if I generate the
xwd files by
% ctrans -d xwd dec82.meta > meta.xwd
% rassplit -f 5 meta.xwd
the xwd's that are formed cause xwdtoppm to choke with a simple
% xwdtoppm meta.0005.xwd > meta.0005.ppm
Segmentation fault
%
The xwd files that are formed by the ctrans/rassplit combination
can't be too far off since they will display properly with
% xwud -in meta.0005.xwd
I discovered another (workable) route from ncar to xwd to pNm and
from there the mpeg_ecode command that I grabbed for the sun in our
office is working. I have the source and may try to get mpeg_encode
going on the DG, but not until I am ready for the frustration.
Here's the drill for your notes:
1. Start with a file containing all of your images concatenated and in
.xwd format (at least, this is how I start).
2. I use an ncar graphic routine called rassplit to pull them a part into
indexed file names. (If you have them as separates already, bully for you.)
rassplit -f 1 2 3 4 5 6 7 8 9 10 11 12 winter83.xwd
will make a bunch of files called winter83.0001.xwd, winter83.0002.xwd, ...
of the first through twelfth images in the winter83.xwd.
3. Now convert each .xwd file into a .pnm format. This uses a pbmplus
routine as follows:
xwdtopnm winter83.0001.xwd > winter83.0001.pnm
xwdtopnm winter83.0002.xwd > winter83.0002.pnm
....
for each .xwd file in turn. This step can be cumbersome unless you
write a script or something to do it.
4. Finally making the mpeg is just like this
mpeg_encode params
where params is a file that tells mpeg_encode where the files are and
what kind of mpeg compression to use, etc. I can provide a working example
when you get around to trying it.
NOTE: This is pretty simple now, but the crucial step was discovering
that xwdtoppm DOESN'T work with ncar-generated xwd's but xwdtopnm DOES
work. Of course, there are about a dozen other file formats (at both
ends) that could have worked but didn't. I guess it was just a matter
of time to get to the right combination of filters.
FURTHER NOTE: It appears that you can get into this all-important but
obscure .pnm format via anytopnm (who knows how many 'any' entails but it
doesn't include postscript), rasttopnm, tifftopnm, and xwdtopnm in the pbmplus
library. Coming from ncar graphics, xwd was the only choice
(via ctrans -d xwd <ncar_meta_file>).
Well, I hope this is of some use to someone besides me some time.
**************************************************************************
R. Steven Regan rsregan@usgs.gov phone 703-648-5896 fax 703-648-5274
USGS, 12201 Sunrise Valley Dr, MS 415, Rm 5A429, Reston, VA 22092
workstation: hassrvares.er.usgs.gov internet: 130.11.51.203
**************************************************************************
This archive was generated by hypermail 2b29 : Wed Jun 28 2000 - 09:45:31 MDT