Crawly Crypt Collection 1/crawlyvol1.bin/graphics/gifspc/gifspc.doc

Text File | 1990-10-06 | 9KB | 194 lines

                              G I F S P C

             The GIF to Atari Spectrum 512 Picture Converter

                            by Steve Belczyk,
                SysOp of the Genesis BBS, [phone]
                        (Four lines, fifty megs)



Permission is granted to distribute this program freely, provided that this
documentation file accompanies it, unaltered.  Commercial use of this product
is prohibited without permission of the author.


Introduction:

For over a year I've been converting GIF pictures into Spectrum 512 format
for the Atari ST using two kludgy programs I wrote a long time ago.  After
receiving several requests, I finally munged them together and cleaned up
the result.  Here it is, at last!


Operation:

Those of you who are familiar with my IFFSPC program should feel quite
comfortable using GIFSPC.  If you haven't been using IFFSPC, however, here's
how to use GIFSPC:

GIFSPC must be run in low resolution.  It also requires a few big buffers,
so, if you're using a 520, get rid of that ramdisk and those greedy desk
accessories.  After the tacky title page, you will be presented with the
usual file selector dialog box.  Select the GIF file you wish to convert.

After selecting the victim, you will be tersely asked if you would like
dithering.  Pictures almost always look better dithered, so YES is most
likely your best bet.  It's also the default.  More on dithering below.

The screen will clear, the input file will be read, and then decompression
will begin.  This can take a while, especially for big files.  When
decompression is completed, row after row of ghastly colors will be plotted.
DON'T PANIC!  These colors bear little resemblance to the ultimate appearance
of the picture.  Nevertheless, I love to try and guess what the picture
will look like by scrutinizing these pseudo-colors.

Once the screen has been entirely painted, the disk drive will come on
again.  GIFSPC is now trying to write name.SPC (assuming you chose name.GIF
as the input file).  ANY EXISTING name.SPC WILL BE CLOBBERED!  If all goes
well, a message indicating success will appear.  At this point you'll rush
off to try the pic with SPSLIDE or SPECTRUM.  I hope it turned out well.


Error messages:

"Can't open input file."  This one's pretty straightforward.  Either you
specified a file that doesn't exist or it is badly damaged.

"Premature EOF."  The GIF file is too short.  Most likely cause of this
error is an incomplete file transfer at some point.

"Not a GIF pic."  The 6-byte header of the so-called GIF file indicates
that this is not an GIF file.  I get this if I forget to de-ARC the file.

"Bad GIF file."  At some point during decompression, the GIF file violated
the rules of the compression algorithm.

"Can't open output file."  The Fcreate failed on the output SPC file.  Either
the disk is full, damaged, or write-protected.

"Write error (disk full?)"  GIFSPC couldn't write the entire SPC file.  The
disk is either full or damaged.


Theory of operation (or, Why they don't always turn out great):

Each horizontal scan line of a GIF picture can contain as many as 256
different colors.  Spectrum, on the other hand, permits a maximum of 42
colors per scan line (plus black).  So, GIFSPC's main task is to take a line
of as many as 256 colors and somehow "dissolve" it into a line of no more
than 42 colors, while preserving as much of the quality of the original pic
as possible.  To make matters worse, Spectrum does not allow any pixel on the
line to have any of the 42 colors.  Each pixel has only 14 colors to choose
from.  This can make life pretty miserable for GIFSPC.

Generally speaking, the way GIFSPC handles this is to sort the pixels on the
scan line by how popular each desired color is on that particular line.  In
this way, popular colors get the most attention.  The remaining, less popular
colors are simply assigned the popular color that is the closest fit.  It is
unavoidable that what GIFSPC thinks is an unimportant color may turn out to
be a color that we humans think is very important.  This seems to happen most
often in pictures with faces; the bridge of the nose occupies very few pixels,
but it is exactly where we tend to focus on a face.  GIFSPC thinks these pixels
are unimportant, hence you may wind up with an unsightly blemish on the nose.
(To those of you who have used IFFSPC:  This effect is much less likely
when converting GIF files since GIF files have a maximum of 256 colors per
scan line, versus the Amiga's 640 colors.)


More on dithering:

Even the magic of Spectrum could not improve on the fact that the ST is
limited, in hardware, to a total of 512 colors, three bits for each of
the primary colors red, green, and blue.  The Amiga sports FOUR bits for
each primary, giving it 4096 colors.  This is a significant difference.

GIFSPC (and Spectrum) use a technique called "dithering" to increase the
number of available colors.  To render an Amiga color that the ST can't
produce, every other pixel is assigned one of the two closest ST colors.
This works much better than it may sound.  I find that the patterns
introduced by dithering actually contribute to the overall quality of
the picture.

Here's the rub:  Dithering can nearly double the number of colors that
GIFSPC has to deal with on each scan line.  That's why you are given the
option to dither or not to dither.  If a picture does not turn out too
well dithered, cross your fingers and try it without dithering.


                       Good luck with the program!

                              Steve Belczyk


P.S.  You can reach me electronically any of these ways:

    CompuServe: [75126,515]            Genie: sbelczyk

    UUCP: {harvard,vaxine}!bunny!seb3  CSNet: [e-mail]

    BBS: [phone] (1200 baud)    SteveNet: GENESIS:Steve1
         [phone] (2400 baud)              1/1:Steve1


              ----- Attention Bulletin Board SysOps! -----


The most powerful BBS software ever written is available now for your Atari
ST or IBM compatible.  Announcing...


                           S t e v e N e t !


The three Steves have combined their efforts and developed the BBS program
the world has been waiting for.  Here are some of SteveNet's unique features:


    o  Multi-tasking:  SteveNet supports multiple modems.  In addition,
       the system console is always available for your use.  You may log
       in, read messages, and perform system maintenance while other
       callers are using your system.

    o  Networking:  More than just the ability for one BBS to connect
       to another, SteveNet brings advanced computer networking concepts,
       hitherto available only on mainframe computers, to the micro-
       computer community.  Network message bases, network games,
       network chat, and network Email are all possible.

    o  Forth:  SteveNet includes a complete, no-holds-barred, multi-
       user Forth program development language.  You and your callers
       can write games, utilities, and even programs that communicate
       with one another over the network, using Forth.

    o  User Interface:  SteveNet offers two extremely powerful user
       interfaces:  a command language and a menu system.  You can create
       your own hot-keyed menus, with each key assigned to any sequence
       of shell commands.  The command shell supports batch files,
       command aliasing, variable substitution, and background execution.

    o  And much more:  Real-time chat (including network chat with an
       unlimited number of other SteveNet nodes), unlimited zero-
       maintenance message bases, Email, Xmodem and Ymodem transfers,
       FidoNet compatibility, a dumb terminal mode to allow outgoing
       calls (and file transfers!) on unused lines, full file and user
       security functions, and lots more.

SteveNet is currently running on both IBM compatible and Atari ST machines.
Macintosh and Amiga ports are planned.

In the hacker spirit, SteveNet is very reasonably priced.  For less than
you might spend on a single game, your BBS can join the SteveNet!

SteveNet authors:  Steve1 (Steve Belczyk)
                   Steve2 (Steve Gerakines)
                   Steve3 (Stephen Agneta)

For more information on SteveNet, please contact me at one of the electronic
addresses given above.

                                                                Steve1

--------------------------------- 8< ---------------------------------------