Path: utzoo!attcan!uunet!husc6!uwvax!vanvleck!uwmcsd1!bbn!bbn.com!denbeste From: denbeste@bbn.com (Steven Den Beste) Newsgroups: comp.sys.amiga Subject: dilbm/pilbm/movie: a problem and a workaround Message-ID: <25962@bbn.COM> Date: 20 Jun 88 13:07:39 GMT Sender: news@bbn.COM Reply-To: denbeste@BBN.COM (Steven Den Beste) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 82 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)