Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!lsuc!jimomura
From: jimomura@lsuc.UUCP
Newsgroups: comp.sys.m6809
Subject: Re: Proposal for Graphics Format Std.
Message-ID: <2154@lsuc.UUCP>
Date: Thu, 12-Nov-87 23:09:54 EST
Article-I.D.: lsuc.2154
Posted: Thu Nov 12 23:09:54 1987
Date-Received: Sat, 14-Nov-87 15:15:33 EST
References: <2117@lsuc.UUCP> <1138@wlbr.EATON.COM>
Reply-To: jimomura@lsuc.UUCP (Jim Omura)
Distribution: na
Organization: Consultant, Toronto
Lines: 104
Summary: Sounds good so far

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