jimomura@lsuc.UUCP (11/18/87)
I still don't have a formal definition for GIF or any other
format for that matter, but my current impression is that GIF would
not be well suited to animation work. So I'm proceding on the
basis that this format has some value in the animation field.
My current intention is to write utilities supporting GF9 and,
provided I have formal definitions for them, GIF and other "standard"
formats.
Cheers! -- Jim O.
/* GF9 revision 87/11/16
Changes since last distribution:
The compression indicator has been shortened in order
to fit better with the file length value which is 3 bytes
in order to provide for files larger than we are currently
using, but may be of value if used with other OS-9 systems.
The file length is added and three compression forms
have been allocated.
Display duration for animation has been defined.
TITLE: 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 Compression style: Up to 255 forms of compression
may be defined.
0 is uncompressed.
1 is run length encoding. Run length encoding
will work as follows:
The picture file will consist of a series of variable
length "packets" in the form
[key value] [data bytes].
The Key Value is a single byte. If the high bit is
set, then the following byte is repeated the number
of times specified by the unsigned value of the rest
of the byte. I.e. if the byte is 10010000 binary,
then the first bit specifies that the "packet" is
compressed and the next byte is to be repeated
0010000 (16) times. The key value 10000000 is a
special case where the next byte repeated 256 times.
If the Key Value high bit is unset, then the rest of
the byte specifies the number of bytes are to be
considered "literal". I.e., if the byte is 01000000,
then the next 64 bytes are not compressed, and the
next byte after the last "literal" byte is the next
Key Value byte.
2 is delta compression.
Delta compression really isn't compression on its
own at all. Each byte in a frame is subtracted from the
corresponding byte in the previous frame and the difference
is stored. A delta frame is useful because the delta file
can be compressed by other means with a separate compression
utility. If you want to show animation, the uncompressed file
requires less alteration than a compressed deltafile for display.
Furthermore, with a multi-tasking OS, it is conceivable that
one might have uncompression of files occuring as a background
task separate from the display function, so there may be some
value in this separation of functions.
3 is delta and run length encoding combined. In storing
the file, the original frame is "delta"d from the previous
frame, and then the result is run length encoded using
the method described in compression #1.
0x03 - 0x05 File length. This is the number of bytes of
actual picture data, not including the header. If
the file is 5000 bytes of picture data and 64 bytes
of header, the total file will be 5064 bytes.
For the sake of portability with other computers
the file length is specified in 24 bits (3 bytes)
to be used as an unsigned integer value.
I don't feel that this will make a truly *universal*
format because such universality is very inefficent,
but there might be some value in using this file
format with some relatively similar machines.
0x06 - 0x07 Display Duration in 1/64 sec. increments. The
16 bit value is treated as an unsigned integer. Although
it is formally a 1/64 sec., it should be presumed that
due to the multi-tasking nature of the OS, some delay
may occur between frames. As such, specific frame synch
might require "something more". Display based on 1/60
sec. tickrates would not be considered "wrong". Maximum
duration is 1024 seconds, or a bit over 17 minutes.
0x08 - 0x1f Undefined
0x30 Color Pallette 0 (address FFB0)
0x32 Color Pallette 1 (address FFB1)
0x34 Color Pallette 2 (address FFB2)
0x36 Color Pallette 3 (address FFB3)
0x38 Color Pallette 4 (etc.)
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. File length
should *always* be provided, even in uncompressed files.
The reason for the "undefined" words is for such
things as color cycling, object motion (sprites?) and such.
It'll be useful for the future.
*/
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomurapete@wlbr.EATON.COM (Pete Lyall) (11/23/87)
Jim -
You say you still don't have a definition of the GIF format? Is that
to say you didn't get that mondo-large (36k) GIF description I posted?
If not, advise and I'll mail it to you.
Any others miss it that needed it?
By the way, I am looking into getting the binaries and potentially
the sources for the GIF tools posted here - there are a few
obstacles..
--
Pete Lyall (OS9 Users Group V.P.) Eaton Corporation (818)-706-5693
Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)
Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete