denbeste@bbn.com (Steven Den Beste) (06/20/88)
Have you seen 'Rocker' or the 'Juggler'? (You haven't? Where have you been?) Those are immense data files played by a program called 'movie'. 'dilbm' and 'pilbm' are the programs that put that data file together from a series of IFF pictures. 'dilbm' generates a difference between two images. 'pilbm' puts together a lot of files into a file that 'movie' can play. I only discovered a few days ago that they were available - I only thought that the player was PD and that I had to pay for the others. Nope - I found that on Fish #116 the whole package is available. So, here it is, Friday night and the computer store where I get Fish disks is closed, so I get onto trusty INTERNET and go to uxe.cso.uiuc.edu (thanks, guys, wherever you are) found a 650K zoo archive called 'movie.zoo' - and me without zoo on either my sun or my Amiga. (Capitalization intended.) So... I got onto the archives at j.cc.purdue.edu (thanks, you guys too, and I *know* where YOU are) and got the zoo binaries. Then I had to uuencode movie.zoo, increasing its size to over 850K and download it at 2400 baud (3 hours - good thing I could play a game at the same time!) and uudecode and unzoo it. ...and found out that of the 650K, only about 40K was what I was interested with the rest being Kahnankas and Rocker and other such stuff which I already had. Sigh. BUT, I had dilbm, pilbm and a relatively short document describing how to use them. I hauled my trusty videodisk player into the computer room and wired it up to Digiview and put on a disk containing Voyager Jupiter pictures (more particularly, the red-spot sequence) and digitized in 320*200 about six frames to try to use with these programs. (Good old hard disk - I can't imagine trying to do this with just floppies.) dilbm without the "q" parameter would guru. dilbm with the "q" parameter would run. (Ostensibly, without the "q" parameter, it displays the difference as it runs.) pilbm would process the results, but when 'movie' tried to use it, it said "cannot open window" or some such cryptic comment. Well, the bottom line is this: The documentation DOESN'T tell you that these programs can only process 320*200 HAM COLOR and 320*400 HAM COLOR and get very very confused by any other format - but they don't check, they just blow up. (Actually, dilbm will process anything, it is just that the result doesn't make any sense. pilbm isn't using the data - it just concatanates it together. movie tries to open a screen and fails but doesn't tell you why.) When you digitize B/W with digiview, it generates a different save format which these programs cannot handle. If you try to feed the same B/W source into Digiview and digitize it in R, G and then in B, you won't get gray, you'll get gray with strange color fringes. This is due to minor variations in the three conversions. The solution I found was to take my B/W pictures and read them into 'DigiPaint' - and then write them back out again immediately. The images get slightly bigger. I gather that DigiPaint is converting them from B/W pictures to HAM COLOR images which just happen to only have gray tones right now... Regardless, it leaves them in a format which the other programs can handle correctly, and I used a few of them in an animation just to prove it. I know, I know, what do you expect from PD and all that, but seems like dilbm could check, or the document could at least describe this limitation. In any case, I thought I would pass this along in case someone else got frustrated and gave up without knowing how to work around it. By the way, did you know that succeeding pictures don't have anything to do with each other? You can use this system (with enormous delays between steps like 5-20 thousand) to generate a slide show. Steven C. Den Beste, Bolt Beranek & Newman, Cambridge MA denbeste@bbn.com(ARPA/CSNET/UUCP) harvard!bbn.com!denbeste(UUCP)
lel@wuphys.UUCP (Lyle E. Levine) (06/22/88)
In article <25962@bbn.COM> denbeste@BBN.COM (Steven Den Beste) writes: > >Well, the bottom line is this: The documentation DOESN'T tell you that these >programs can only process 320*200 HAM COLOR and 320*400 HAM COLOR and get very >very confused by any other format - but they don't check, they just blow up. >(Actually, dilbm will process anything, it is just that the result doesn't make >any sense. pilbm isn't using the data - it just concatanates it together. movie >tries to open a screen and fails but doesn't tell you why.) > I have used dilbm and pilbm quite a bit and never had this problem. The frames must have the same resolution and palette but that's it. I have used 640x400x4, 640x400x3, 640x400x2 with no trouble. HAM is not necessary. The animations get rather big sometimes (one I made is over 2 Meg in size) but the process works great (if a bit slow). ========== IBM is a Division of Sirius Cybernetics Corporation "their fundamental design flaws are completely hidden by their superficial design flaws." - "So Long And Thanks For All The Fish" Lyle Levine: Paths -> ihnp4!wuphys!lel Best way: (314)889-6379 uunet!wucs!wuphys!lel