jimomura@lsuc.UUCP (10/31/87)
Proposal for Graphics File Format Standard
For OS-9 / Color Computer Users
I've been waiting for a while now for some sort of standard
to arise, but nothing has happened. As such, this is what I'm
going to use for now. If something better comes along, I state
right now that I intend to abandon this format. But I'll
only do so if there is an alternative which looks to be better
than this. I don't like the idea of wasting my efforts, but
I believe more strongly in establishing standards which are
useful in the industry generally. So if I drop this without
"a fight" that's why.
Proposed Name :
I've arbitrarily called it 'GF9' for Graphics Format 9.
Files need not use this as an extension, but it wouldn't hurt
if you did.
The Header Format:
The key is 64 bytes which are, for the most, to be thought
of as 32 "words". Where a word is 16 bits. These 32 words make
up the header. There is no "tail" information defined at this
time.
Offset in Bytes:
0x00 The first byte defines screen mode class.
0 Old Color Computer
1 CoCo3 Alphanumerics
2 CoCo3 Graphics modes
0x01 The 2nd byte is a submode.
For mode 0 they are:
0 Alphanumerics
1 Inverted Alphanumerics
2 SemiGraphics - 4
3 64 * 64 Color Graphics
4 128 * 64 Graphics
5 128 * 64 Color Graphics
6 128 * 96 Graphics
7 128 * 96 Color Graphics
8 128 * 192 Graphics
9 128 * 192 Color Graphics
0x0a 128 * 256 Graphics
For mode 1 they are:
0 32 char.
1 40 char.
2 80 char.
For mode 2 they are:
0 160 * 16
1 256 * 2
3 256 * 4
4 256 * 16
5 320 * 4
6 320 * 16
7 512 * 2
8 512 * 4
9 640 * 2
0x0a 640 * 4
0x02-3 Compression style: 0 is uncompressed.
0x04 - 0x1f Undefined
0x30 Color Pallette 0 (address FFB0)
0x32 Color Pallette 1 (address FFB1)
0x34 Color Pallette 2 (address FFB2)
0x36 Color Pallette 3 (etc.)
0x38
0x3a
0x3c
0x3e
0x40
0x42
0x44
0x46
0x48
0x4a
0x4c
0x4e Color Pallette 15 (address FFBF)
The bytes of the file follow as a straight memory dump
if there is no defined compression. There are no special
delimiter characters in the uncompressed formats.
The reason for the "undefined" words is for such
things as animation display timing, color cycling, compression
information and such. It'll be useful for the future.
Anyway, as I said, I intend to start using this format
immediately, as far as I've defined it, but I'm willing to abandon
it, so don't think that just because I'm barging ahead with it
that I won't consider something else. Also there's a lot
to be defined in the future, so post any ideas you have and
we'll see. . . .
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomurapete@wlbr.UUCP (11/10/87)
In article <2117@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: > >Proposal for Graphics File Format Standard >For OS-9 / Color Computer Users > > I've been waiting for a while now for some sort of standard >to arise, but nothing has happened. As such, this is what I'm >going to use for now. If something better comes along, I state >right now that I intend to abandon this format. Uh Jim - the CIS folks have a rather versatile standard for graphics interchange that was released earlier this year. It's called GIF, which is short for GRAPHICS INTERCHANGE FORMAT. It has no practical limitations of resolution, number of colors, or whatever. It is machine independant (many popular machines have GIF viewers available in the public domain), and the files are compressed. A while back, the VEF style files were the rage in the CIS OS9 community, as that's all we had. A few tools are capable of saving, loading, and massaging VEF files (VEF is essentially a memory dump of HIRES VDG memory). Mike Dziedzick wrote a suite of GIF tools (a viewer, an information scanner, a GIF->VEF converter, a VEF->GIF converter, a VEF slide show, and a GIF slide show), and I understand that he will be working on GIF capable terminal program. The VEF files may also be converted to ColorMax3 and probably Coco Max3 formats for easy diddling. I'd like to recommend that before we create another protocol/standard/format/whatever, that we investigate this one. It looks like a goody, and is machine independant to boot! -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)
jejones@mcrware.UUCP (James Jones) (11/11/87)
In article <1138@wlbr.EATON.COM>, pete@wlbr.EATON.COM (Pete Lyall) writes: > Uh Jim - the CIS folks have a rather versatile standard for graphics > interchange that was released earlier this year. It's called GIF, > which is short for GRAPHICS INTERCHANGE FORMAT. It has no practical > limitations of resolution, number of colors, or whatever. It is > machine independent (many popular machines have GIF viewers available > in the public domain), and the files are compressed. Well...GIF *is* machine-independent, and I appreciate Mike Dziedzic's work, but--machine-independence doesn't look like it's coming out to mean that you can display *any* GIF picture using, for example, gifos9. gifos9 can't handle GIF files with more than sixteen colors. I can understand why this is the case (we're talking a two-pass algorithm to boil down a 256-color GIF file to sixteen colors; presumably you'd keep some kind of 3-D histogram in RGB space and figure out where "most" of the pixels went so you could minimize the error when you pick the sixteen colors you'll use), but that nevertheless takes the glitter off the "machine-independent" label unless someone does write that conversion program. The other thing is--when you say "public domain," do you mean that the source is available? I for one haven't seen hide nor hair of the source to gifos9 available for download. James Jones
jimomura@lsuc.UUCP (11/13/87)
In article <1138@wlbr.EATON.COM> pete@wlbr.UUCP (0000-Pete Lyall) writes: >In article <2117@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: >>Proposal for Graphics File Format Standard >>For OS-9 / Color Computer Users ... >Uh Jim - the CIS folks have a rather versatile standard for graphics >interchange that was released earlier this year. It's called GIF, >which is short for GRAPHICS INTERCHANGE FORMAT. It has no practical >limitations of resolution, number of colors, or whatever. It is I've heard a *bit* about GIF from John Ruley, but there's a lot I don't know about it. In particular, I haven't seen a formal definition. If there is one, then I'll definitely consider it. So far, nothing public domain has shown up on the Net. I don't even mind if the current program on CIS are not public domain as long as the definition is. Heck, I can write my own stuff if I have to (and the standard is reasonably simple :-). But, I'm stipulating that the definition MUST be public domain for me to support. Let me soap box for a second here: Just recently, I got fed up with some of the postings on the Net. *Not* CIS, but right here! The restrictions that some people are coming up with work against all that I hold dear. That is in particular, I dislike stupid pluriferation of formats and practices where standards can reasonably arise and particularly where such standards can be beneficial. Now, recently somebody posted a program which creates backup storage files something like 'tar' files. On it, he has put a restriction to stop it from being posted on "commercial" systems -- like BIX and CIS. Wonnnnnderfullll. He's come up with a new nonstandard format and has *ensured* that it will *never* become a standard because he's forced us users of commercial systems to come up with something different! Thousands of Usenet dollars have been wasted on his intellectual masturbation. The shear hypocracy of his posting -- that nobody makes "commercial" gain from his work is laughable to me. I wonder who pays *his* bills? Frankly, I do *not* mind shareware posting much at all compared to this stuff. Shareware programs generally do not try to force people into paying. Some do, and I'm not happy about that, but this isn't different to me. Anyway, enough soapboxing on that point. You will have noticed that the vast majority of my own code, good or bad is *real* public domain. Not all of it, but even the stuff that isn't public domain has never had restrictions agains people trying to make a living using my code. This is the first and probably last time I'll mention that fact, but it was a conscious decision -- for the good of the *industry*. >machine independant (many popular machines have GIF viewers available >in the public domain), and the files are compressed. Again just to clarify my position, I want to see the definition. I'd love to have a viewer too if you can post one, but I'm in the middle of writing a few things and am waiting to write the storage support routines. >A while back, the VEF style files were the rage in the CIS OS9 >community, as that's all we had. A few tools are capable of saving, >loading, and massaging VEF files (VEF is essentially a memory dump of >HIRES VDG memory). Mike Dziedzick wrote a suite of GIF tools I never had a definition for VEF either. This has been the problem. >(a viewer, an information scanner, a GIF->VEF converter, a VEF->GIF >converter, a VEF slide show, and a GIF slide show), and I understand >that he will be working on GIF capable terminal program. The VEF files >may also be converted to ColorMax3 and probably Coco Max3 formats for >easy diddling. Well, if you can post the VEF definition as well, and it is a public domain definition, I'd like to see that too. One thing that's missing so far is any mention of animation support. I've specifically set aside space for this in the header that I was designing. That and compression. I need compression "through" from one frame to the next (delta frames) and then run length in order to achieve sufficiently compact file size. Does GIF or VEF support animation in this way? >I'd like to recommend that before we create another >protocol/standard/format/whatever, that we investigate this one. It >looks like a goody, and is machine independant to boot! Like I said, it all sounds pretty good so far. I think I'd like to support either GIF or VEF in the stuff I'm working on, whether or not I need to use anything else besides. I think I may still need the format I'm designing for animation support, but there's no reason I can't do more than 1 format. Cheers! -- Jim O. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
koonce@maypo (tim koonce) (11/14/87)
I agree to a large extent with some of what you're saying, Jim. As a good example, Ward Christensen (inventor of the XModem protocol) claims that the only reason his protocol became so popular is because it was developed early in the development of micro communications, and because he immediately posted it in the public domain, and because it was a simple protocol to implement. i.e. If someone wants to develop a protocol to be popular, the best way to do it is to make the protocol and software PD. That's pretty clear, I think. And, from what I've heard, the GIF and VEF formats *are* Public Domain. I could be wrong on this, though. Unfortunately, that doesn't always make the specs easy to find. (I'm still trying to find the Kermit specs, and spent a good while looking for the YModem specs.) On the other hand, some people *do* like to see a little cash-in-pocket after spending thousands of hours on a program. It's a curious conflict of interests. One typically has the choice between a program becoming popular (PD or shareware), or making some money from it. Plus, your concern over animation/sequencing may be easily solvable through a modification to an existing standard. Most protocols try to build in some extra flexibility for future additions, often through leaving undefined mode bytes, etc. Seems that the thing for you to do is to *first* find out as much as possible about *existing* formats, and then modify them, if necessary, to suit your needs before complaining about them. Tim Koonce +-----------------------------------------------------------------------------+ |ARPA: koonce@bosco.berkeley.edu | | |Delphi: TIMKOONCE | | |CIS: [72276,1135] | | +-----------------------------------------------------------------------------+ Tim Koonce
V3R@PSUVMA.BITNET (Vic Ricker) (11/16/87)
I'd like to see the info on the GIF and VEF formats also!
Vic