fullmer@dover.sps.mot.com (Glen Fullmer) (06/16/89)
I am having a problem with IFF files written by DeluxePaint III. I edit
a good IFF file (lo-res or hi-res) by filling the background color to white,
transfer it to a Sun4 with Kermit (binary mode), run a program iff2sun to convert
it to a Sun raster file and it aborts with a core dump.
Also, I wrote a program that converts IFF files to Apollo bitmap files. It uses
the PD ifflib stuff and I get the message:
No BODY data.
These all work fine with IFF files edited with DeluxePaint II. Obviously, DPIII
is making assumptions that I don't take in account. Before jumping into a dump
of the file, I thought someone in net-land must know the answer. Funny thing,
some files that I create in DPIII work just fine!?
--
_____ _ "For a successful technology, reality must take precedence"
{____/ // "over public relations, for Nature cannot be fooled."
\ // _ __Richard P. Feynman, Appendix F of Shuttle Disaster Report
{____/ </_</_/ / <_ {sun!sunburn | cadillac} !dover!fullmer raz%kilowatt@Sun.COM (Steve -Raz- Berry) (06/17/89)
In article <1419@dover.sps.mot.com> fullmer@dover.sps.mot.com.UUCP (Glen Fullmer) writes: >I am having a problem with IFF files written by DeluxePaint III. I edit >a good IFF file (lo-res or hi-res) by filling the background color to white, >transfer it to a Sun4 with Kermit (binary mode), run a program iff2sun to convert >it to a Sun raster file and it aborts with a core dump. Well it shouldn't have done that. ;-( The problem that you are seeing is the new format of Dpaint III images. In all of the older IFF files that I was able to take a look at, all of the chunks (ILBM CAMG BODY etc..) were of an even size. EA decided in it's infinite wisdom, and to my chargin, to allow chunks of odd sizes. This screwed up my primitive IFF parsing so that iff2sun would probably only work half of the time (yech). >Also, I wrote a program that converts IFF files to Apollo bitmap files. It uses >the PD ifflib stuff and I get the message: > No BODY data. That's what iff2sun should have done. No matter, I fixed the problem with the newest release of iff2sun. I also tossed in HAM mode conversion. I think you'll like it. If you want a copy of the newest iff2sun, just send mail to the kilowatt archive server (archive-server%kilowatt@sun.com) with the message of 'send not-posted iff2sun.sh.1'. This will only be available for a limited time, until it shows up in comp.sources.amgia. >These all work fine with IFF files edited with DeluxePaint II. Obviously, DPIII >is making assumptions that I don't take in account. Before jumping into a dump >of the file, I thought someone in net-land must know the answer. Funny thing, >some files that I create in DPIII work just fine!? Well it's my fault in iff2sun, don't know about the PD lib your using, but it is kinda weird that I *never* had a problem until now. I mean why would anyone want go to the trouble of redoing the IFF routines to save just one byte ??? -- Steve -Raz- Berry Disclaimer: I didn't do nutin! UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com KILOWATT: sun!kilowatt!archive-server archive-server%kilowatt.EBay@sun.com
jwz@spice.cs.cmu.edu (Jamie Zawinski) (06/18/89)
(I tried to send this in mail, but it bounced.) > From: fullmer@dover.sps.mot.com (Glen Fullmer) > > I am having a problem with IFF files written by DeluxePaint III. I edit > a good IFF file (lo-res or hi-res) by filling the background color to white, > transfer it to a Sun4 with Kermit (binary mode), run a program iff2sun to convert > it to a Sun raster file and it aborts with a core dump. > > Also, I wrote a program that converts IFF files to Apollo bitmap files. It uses > the PD ifflib stuff and I get the message: > > No BODY data. I'd bet that it is the IFF conversion programs that are not conforming, rather than DPIII. There are a lot of programs that imporperly use the IFF standard; you cannot assume anything about the order or contents of an IFF ILBM file except that there will be a BMHD chunk, and a BODY chunk, and the BMHD chunk will preceed the body (though there may be intervening chunks). I started DPIII, cleared to white, and saved, and the file had these chunks: BMHD -- manditory header info, but not necessarily first CMAP -- optional color map, but almost always there DPPS -- private data to DPaint CRNG -- color cycling info (there were seven of these) BODY -- manditory bitmap data So I'd guess that DPII and DPIII have slightly different, but still conforming, IFF formats, and the programs you are using can't cope with the newer format. Besides, the IFFLib stuff is definately nonconforming. Try running the supplied "show" program on an 8x8 brush, like the "bobsled" brush that comes with DPaint - you get static, though other show programs work on it. Also consider: DPaint is from Electronic Arts, who developed the IFF standard. It's unlikely they would violate it :-). -- Jamie --
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (06/20/89)
> The problem that you are seeing is the new format of Dpaint > III images. In all of the older IFF files that I was able to take a > look at, all of the chunks (ILBM CAMG BODY etc..) were of an even > size. EA decided in it's infinite wisdom, and to my chargin, to allow > chunks of odd sizes. This screwed up my primitive IFF parsing so that > iff2sun would probably only work half of the time (yech). No! Someone tell me this isn't true. First, someone verify that Dpaint III does generate BROKEN IFF files in this manner. Second, where and when was the standard `revised'? I think this is a bug in Dpaint III if they are really doing this, and I will be seriously pissed if they've made this change . . . -tom
raz%kilowatt@Sun.COM (Steve -Raz- Berry) (06/20/89)
In article <10102@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >> EA decided in it's infinite wisdom, and to my chargin, to allow >> chunks of odd sizes. This screwed up my primitive IFF parsing so that >> iff2sun would probably only work half of the time (yech). >No! Someone tell me this isn't true. First, someone verify that >Dpaint III does generate BROKEN IFF files in this manner. Second, >where and when was the standard `revised'? I think this is a bug in >Dpaint III if they are really doing this, and I will be seriously >pissed if they've made this change . . . But does this mean that the IFF format is broken? I didn't think so. I though that IFF chunks were allowed to be of any length, it just so happened that everybody wrote ILBMs with chunks of an even size, so I didn't notice the problem until I got a bug report (and code fix). I mean, I *knew* that the way I do IFF parsing in iff2sun is not the _correct_ way. I don't read the length attribute and skip to the next chunk based on this value, I just skip along the file until I find the ascii string "BODY" (for example). In order for this hack to work, I needed to have all of the chunks aligned on an even boundary. This was true of all the IFF ILBMs I've tried until now. I don't have any DPaintIII files handy so I can't verify the change, but more than one person has complained of the problem to me, and my new and improved (although not really fixed) parsing scheme *works*. All I did was to do my checking on a byte basis rather than on a word. Before all you software types jump all over my case, try to keep in mind that I'm a hardware jock mostly. Software is something I do for fun. If you can do it better, please do and send the code to me. I'll thank you for it. :-) Steve -Raz- Berry Disclaimer: I didn't do nutin! UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com KILOWATT: sun!kilowatt!archive-server archive-server%kilowatt.EBay@sun.com
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (06/20/89)
> >> EA decided in it's infinite wisdom, and to my chargin, to allow > >> chunks of odd sizes. This screwed up my primitive IFF parsing so that > >No! Someone tell me this isn't true. First, someone verify that Here's the scoop on IFF. RKM, Includes and AutoDocs, the brand-new one, page 1-2, says: Each chunk is: char typeID[4] ; unsigned long datasize ; char data[] ; and - Every odd-length chunk must be followed by a 0 pad byte. This pad byte is not counted in datasize. So odd-length chunks are allowed, providing they are padded out to an even length. Now, anybody want to look at a Dpaint III file and tell me what they do? If I could get one that fails on most readers, I'd really love to take a look at it . . . -tom
addison@pollux.usc.edu (Richard Addison) (06/20/89)
In article <10102@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >> The problem that you are seeing is the new format of Dpaint >> III images. In all of the older IFF files that I was able to take a >> look at, all of the chunks (ILBM CAMG BODY etc..) were of an even >> size. EA decided in it's infinite wisdom, and to my chargin, to allow >> chunks of odd sizes. This screwed up my primitive IFF parsing so that >> iff2sun would probably only work half of the time (yech). > >No! Someone tell me this isn't true. First, someone verify that >Dpaint III does generate BROKEN IFF files in this manner. Second, >where and when was the standard `revised'? I think this is a bug in >Dpaint III if they are really doing this, and I will be seriously >pissed if they've made this change . . . > >-tom Well, since I have multitasking... The third IFF ILBM file I looked at (created by Dpaint III) has an odd length for the BODY length. But wait! (shuffle, shlaaack, ca-chung) Let us see what the Amiga ROM Kernel Reference Manual (Includes & AutoDocs) Version 1.3 has to say: "Fine points: ... * Every odd-length chunk must be followed by a 0 pad byte. This pad byte is not counted in dataSize." Right there on page I-2. Let me check (Floop, grrr, scrinch, ffffwwwaap) what the Amiga ROM Kernel Reference Manual (Exec) Version 1.1 said: "If ckData is an odd number of bytes long, a 0 pad byte follows, which is not included in ckSize. (See 'Alignment.')" Right there on the top of the second column on page B-33. Now clearly, it is much easier to locate this info in the new manual. (Thanks, Commodore!) Plus, it's a great work-out! (-; Now, for the real test. Yup, there is a pad byte at the end of that odd length BODY chunk. (Hmm, "BODY by IFF" Naaah.) Disclaimer: I have no association with Electronic Arts (except as an owner of some of their programs), with Commodore (except as an owner of some of their hardware and software), or with Addison Wesley (except, incidentally, sharing a name). In fact, I wouldn't usually defend EA because of some of the problems I've had with their software. But, well.... Richard Addison "Yeah, I'm a prog..., er, uh, a publisher. Yeah, that's the ticket!"
jbh@mibte.UUCP (James Harvey) (06/20/89)
In article <10102@polya.Stanford.EDU>, rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >> The problem that you are seeing is the new format of Dpaint >> III images. In all of the older IFF files that I was able to take a >> look at, all of the chunks (ILBM CAMG BODY etc..) were of an even >> size. EA decided in it's infinite wisdom, and to my chargin, to allow >> chunks of odd sizes. This screwed up my primitive IFF parsing so that >> iff2sun would probably only work half of the time (yech). > > No! Someone tell me this isn't true. First, someone verify that > Dpaint III does generate BROKEN IFF files in this manner. Second, > where and when was the standard `revised'? I think this is a bug in > Dpaint III if they are really doing this, and I will be seriously > pissed if they've made this change . . . > > -tom I have been using a PD program BrushIcon (not Brush2Icon) to convert DPaint brushes to Icons. Since I have DPaint III the conversion no longer works. I can load a DPaint III brush into DPaint II, re-save it and get a convertable brush. Does anybody know of a Brush to Icon program that will work with DPaint III brushes? I have Brush2Icon and it works with DPaint III but only produces tool icons. -- Jim Harvey | "Ask not for whom the bell Michigan Bell Telephone | tolls and you will only pay 29777 Telegraph | Station-to-Station rates." Southfield, Mich. 48034 | ulysses!gamma!mibte!jbh
raz%kilowatt@Sun.COM (Steve -Raz- Berry) (06/21/89)
In article <17962@usc.edu> addison@pollux.usc.edu (Richard Addison) writes: >>>In an article I wish I didn't write: >>> [I Describe a problem... but not with EA's iff images...] >In article <10102@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >> [Tom panic's because of my mis-information.] >>-tom >Now, for the real test. Yup, there is a pad byte at the end of that odd >length BODY chunk. (Hmm, "BODY by IFF" Naaah.) Yep, I looked too. The original problem was with the way I did the parsing. (surprize, surprize) Although the EA format is different than all the other IFF's I've seen, there is nothing wrong with it. Ok, now that I have admitted to messing up, you can all scream at me ;-) Now I guess I'll have to fix it. Steve -Raz- Berry Disclaimer: I didn't do nutin! UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com KILOWATT: sun!kilowatt!archive-server archive-server%kilowatt.EBay@sun.com
sjorr@rose.waterloo.edu (Stephen Orr) (06/22/89)
In article <2824@mibte.UUCP> jbh@mibte.UUCP (James Harvey) writes: > >I have been using a PD program BrushIcon (not Brush2Icon) to >convert DPaint brushes to Icons. Since I have DPaint III the >conversion no longer works. I can load a DPaint III brush into >DPaint II, re-save it and get a convertable brush. Can anyone tell me where to find ANY version of Brush2Icon? I've been looking for some time for this useful utility, and maybe one to go the other way too (Icon2Brush ?) Must be PD of course! Thanx in advance... sjorr { The opions expressed herin ARE the opinions of my employers... ... I'm self employed! - sjorr }
berry@stsci.EDU (Jim Berry) (06/24/89)
From article <111101@sun.Eng.Sun.COM>, by raz%kilowatt@Sun.COM (Steve -Raz- Berry):
> In article <10102@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes:
:>> EA decided in it's infinite wisdom, and to my chargin, to allow
:>> chunks of odd sizes. This screwed up my primitive IFF parsing so that
:>> iff2sun would probably only work half of the time (yech).
:>No! Someone tell me this isn't true. First, someone verify that
:>Dpaint III does generate BROKEN IFF files in this manner. Second,
:>where and when was the standard `revised'? I think this is a bug in
:>Dpaint III if they are really doing this, and I will be seriously
:>pissed if they've made this change . . .
: But does this mean that the IFF format is broken? I didn't think so.
: I though that IFF chunks were allowed to be of any length, it just so
: happened that everybody wrote ILBMs with chunks of an even size, so I
: didn't notice the problem until I got a bug report (and code fix).
No, chunks ARE allowed to have odd sizes, but if they do, there must
be a pad byte at the end. Note that this is NOT the same as requiring
even chunk sizes (the pad byte is not part of the chunk)
To tell you the truth, though, I've always assumed that chunks were
even-sized too.
--
------------------------------------------------------------------------------
Jim Berry | UUCP:{arizona,decvax,hao}!noao!stsci!berry
Space Telescope Science Institute | ARPA: berry@stsci.edu
Baltimore, Md. 21218 | SPAM: SCIVAX::BERRY, KEPLER::BERRYba@m2-net.UUCP (Bill Allen) (07/04/89)
Sender: Reply-To: ba@m-net.UUCP (Bill Allen) Followup-To: Distribution: na Organization: M-NET, Ann Arbor, MI Keywords: IFF DPIII You can find that Brush2Icon file you're looking for on The Amiga Shareware Headquarters at 313-473-2020. In c, in ASM, many other tooicon/brush tools. -- --------------------------------------------------------- Reply-To: ba@m2-net.UUCP (Bill Allen Beogelein) M-NET, Ann Arbor, MI or call Sharewarer's BBS at 313-473-2020 24hrs, PCP thru MIDET, 100% Amiga ---------------------------------------------------------