Category : Printer + Display Graphics
Archive   : CLIP.ZIP
Filename : CLIP.DOC

 
Output of file : CLIP.DOC contained in archive : CLIP.ZIP
ClipGIF 1.2 GIF RE-ENCODER UTILITY USER DOCUMENTATION







1.0 INTRODUCTION


ClipGIF is a utility for IBM PCs and close compatibles to decode,
modify and re-encode graphic images stored in CompuServe's Graphic
Interchange Format (GIF). It will run on any compatible regardless of which
graphic card you have or even on non-graphic systems because it does not
actually display the images.

Ok... so why use ClipGIF when I already own a paint program that clips
much easier than ClipGIF? Fine if you own a Super VGA with a zillion color
capability. But all I have is an EGA and when I first began developing
ClipGIF I didn't have that. How could I clip a 256 color digitized GIF?

ClipGIF was originally designed simply to clip GIF images into smaller
GIF images but it has grown to a general purpose GIF re-encoder that lets
you....

* Clip the top, bottom, left and right edges of a GIF image

* Move the origin of an image from the upper left to anywhere.

* Adjust the virtual screen size

* Automatically clip images that don't fit the virtual screen

* Interlace any non-interlaced image or un-lace interlaced images.

* Split multi-image GIF files into individual files.

* Merge individual images to create your own multi-image files.

* Efficiently re-encode images eliminating un-used colors.

Features of ClipGIF 1.2 not found in ClipGIF 1.0....

* Eliminates duplicate map entries for efficient re-encoding.

* Better buffering increases speed.

* Allows user to eliminate unnecessary local maps when possible.

So even if you have an excellent paint program with all the colors and
features you need, ClipGIF probably has features you'll find useful.

This utility is fully documented but we will not release the source
code at this time. This is a shareware product with a registration fee of
$20 payable to Cyborg Software Systems, Inc. 3119 Cossell Drive,
Indianapolis, IN 46224. This program, the documentation and the source and


Copyright (c) 1989 Cyborg Software Systems, Inc. page 1.




ClipGIF 1.2 GIF RE-ENCODER UTILITY USER DOCUMENTATION


executable code are all Copyright 1989 by Cyborg Software Systems, Inc.
TURNER.GIF, and SMILE.GIF are original works by Chris Young created on
PICTOR and released to the public domain. LIGHT.GIF is an original work by
Tom Mitchell and is used with permission.

You may use this material for personal non-commercial use. If you like
it we ask you to register it. If you use it in a commercial or government
setting you must register it. If you distribute it you must distribute it
in its original ARC form with all files intact. (One exception is you are
permitted to re-archive it if you prefer ZIP, LHARC or whatever else is the
latest fad.)

IF YOU DISTRIBUTE IT FOR A COPYING FEE OR UNDER CONTRACT, YOU MUST
REGISTER IT. This means that sysops or information providers of paid online
services may not distribute it unless they have registered one copy. Gimme
a break folks. I know you're doing me a favor by distributing it on your
BBS. But you're earning money by distributing my program. Set a good
example and register your copy.

Violation of the above terms infringes our copyright. Registered users
will receive the next update free of charge. Further updates will cost
registered users $5.

The distributed version will only allow screen sizes up to 720 by 480.
Upon registration we will send you a somewhat slower version which uses disk
buffers and can clip much larger images. We suggest you keep the original
version because it will be faster for small images.

"GIF" and "Graphic Interchange Format" are trademarks of H & R Block,
Inc. The GIF standard itself is in the public domain.



2.0 GIF STRUCTURE


In order to understand how to use ClipGIF, you need to understand what
information is stored in a GIF file.

All GIF files begin with some identifying bytes followed by a SCREEN
DESCRIPTOR. The screen descriptor defines a virtual screen size. All
images must fit entirely within that space. ClipGIF allocates dynamic
memory to hold the screen. If you do not have enough free memory, ClipGIF
tells you and aborts. The screen descriptor also tells you other
information which we will describe later. One of the things it tells you is
the presence of a GLOBAL COLOR MAP.

The global map is optional but the vast majority of GIF files contain
one. It consists of from 2 to 256 entries and can only contain 2, 4, 8, 16,
32, 64, 128 or 256 entries. Each entry tells the amount of red, green and
blue to use for a particular color. The internal workings of color maps are
of little importance to us because ClipGIF only allows us to change the size
and presence of the maps and only under particular circumstances which are
advantageous to us.


Copyright (c) 1989 Cyborg Software Systems, Inc. page 2.




ClipGIF 1.2 GIF RE-ENCODER UTILITY USER DOCUMENTATION



After the global map, if any, are one or more images. Each image
begins with an IMAGE DESCRIPTOR. The image descriptor defines the size and
location of the image within the screen space. The image descriptor also
tells us whether or not the image is INTERLACED. It also tells us if an
optional LOCAL COLOR MAP is defined. Local maps have the same structure as
global maps. They override the global map for that image. Afterwards, a
decoder returns to using the global map again unless yet another local map
is encountered. After displaying an image, the local map is discarded.

Following the image description and local map is the compressed image
data itself. Multiple images may exist and each will have its own
description and optionally a map. The whole process ends with a semi-colon.


3.0 RUNNING CLIPGIF


To run ClipGIF simply type

CLIP or CLIP INFILE OUTFILE

Where INFILE.GIF and OUTFILE.GIF are the input and output files.
WARNING! DO NOT specify the same name in both places or you will destroy the
file. If you do not specify names, ClipGIF will prompt you.

The extension .GIF is always assumed but if another extension is given
it will be used. You may specify wild cards on the input file for a
directory to pop-up. The default entry is "*.GIF". You may point at the
file name to select it or type however many significant characters are
needed to define the file.. The output name must be given but a .GIF
extension is assumed. If the file already exists you will be warned. If
you respond "Y" to the warning it will erase the previous file.

All prompts in ClipGIF have default values which are entered when you
press [ENTER]. All answers to prompts may be fully edited except for yes or
no questions. In the examples below if you are asked a question you don't
yet understand, simply press [ENTER] for the default and we'll explain it
all eventually.



3.1 Modifying the Screen Description


The contents of the screen description for the input file is displayed
on the left side of the display.

The screen width and height in pixels is shown. The number of BITS PER
pixel is shown. This value ranges from 1 to 8. It is from this that we can
determine the number of colors in the color map.

Number_of_colors= 2 to the bits_per_pixel power.



Copyright (c) 1989 Cyborg Software Systems, Inc. page 3.




ClipGIF 1.2 GIF RE-ENCODER UTILITY USER DOCUMENTATION


The screen description also specifies the number of BITS PER PRIMARY
color. For example an EGA may use 2 bits of red, 2 blue and 2 green. This
makes for 64 possible colors. However the EGA can only display 16 of those
64 colors. It would therefore have Bits/pixel=4 and Bits/primary=2. Some
early encoders incorrectly set the Bits/primary value. ClipGIF will allow
you to change it.

After displaying the Screen Description, ClipGIF will prompt you for
new values for width, height and bits/primary. Simply pressing [ENTER] will
retain the original values. It will not prompt you to add or delete the
global color map or to change bits/pixel. Editing of color map entries
except to eliminate un-used entries is not done by ClipGIF.

To try this out, use Clip to change the screen size on the file
SMILE.GIF which is included in this ARC file. SMILE was created with a
screen size of 640x350 but the image is only 200x100. Enter the command...

CLIP SMILE SMILE320

When prompted for the screen size values, enter 320 and 200. Press
[ENTER] after all other questions. The file SMILE320.GIF will have a
smaller screen size.



3.2 Modifying the Image Description


After modifying the screen size, the contents of the image descriptor
is displayed next. The origin of the image is defined by the top-left
corner's location within the screen area. Values of Left Origin=0 and Top
Origin=0 will put the image in the upper left corner. Next are the screen
coordinates of all four edges of the image. Upon input, the left and top
edges will always be the same as the origin values.

You are also given Bits/Pixel and Interlace Flag information. The
number of colors in the map, if any, is computed from bits/pixel for your
convenience too. Images may have different bits/pixels from that specified
in the screen description as well as being different from each other. There
is no bits/primary information in an image description. You will be
prompted for new left and top origin values. Pressing [ENTER] gives the
default (previous) values.

Lets illustrate again this time using our newly created SMILE320.GIF as
a basis. Although its 320x200 size is better than the giant 640x350 size,
we still might like our 200x100 image centered on the screen. Enter the
command... CLIP SMILE320 SMILECNT

Use the default screen size which is now 320x200 but when we are
prompted for the new origin values, enter Left origin=60 and Top origin=50.
Simply press [ENTER] for all remaining questions. This will create
SMILECNT.GIF with our 200x100 image centered in its 320x200 screen. Note
that we could have done this all at once from the original SMILE.GIF by
reducing the screen size and adjusting the origin.


Copyright (c) 1989 Cyborg Software Systems, Inc. page 4.




ClipGIF 1.2 GIF RE-ENCODER UTILITY USER DOCUMENTATION



Now lets give an example of what ClipGIF is really designed to do -- to
clip off parts of images. LIGHT.GIF is an original image by Tom Mitchell
that has sentimental value to me. It was the first GIF image my decoder
ever correctly displayed. Its a simple 320x200x16 image. Suppose we want
to clip out a 100x100 area from the upper left corner of the screen to get a
piece of the star-filled background. You'd simply run CLIP and specify the
same default screen sizes. You could pick an origin other than 0/0 but
that's up to you. When prompted

"Clip everything left of what screen coordinate?"

You would enter 0. Similarly....

"Clip everything above what screen coordinate?"

The reply is 0. When asked where to clip right of or below you would
enter 99. This gives an image from 0-99 wide and 0-99 high or 100x100
pixels in all. When you are asked questions about color maps in this
example you should press [ENTER]. We'll cover this option later.

If you wanted to choose a new origin for the image you would still clip
at 0, 0, 99 and 99 because THESE VALUES ARE ALWAYS RELATIVE TO THE OLD
SCREEN COORDINATES REGARDLESS OF IMAGE SIZE, ORIGIN OR NEW SCREEN SIZE.

That seems like a pretty simple statement to put in all caps but its
not as easy as it looks. Take for example SMILECNT.GIF. Suppose you want
to clip 8 pixels off all four sides and to re-center it. You'd enter 64 for
the new left origin and 54 for the new top origin but where do you clip?

You might be tempted to enter 8 to clip 8 columns of pixels but you'd
be wrong. You might think "I've moved the image to column 64 so 64+8 is 72"
but that's wrong also. You SHOULD enter 68 because it says that the left
edge is currently 60 and these values are always relative to the OLD screen
coordinates. Similarly you would enter Clip above=58, Clip right=258 and
Clip below=141.

Just remember THESE VALUES ARE ALWAYS RELATIVE TO THE OLD SCREEN
COORDINATES REGARDLESS OF IMAGE SIZE, ORIGIN OR NEW SCREEN SIZE.

So there! I said it three times. This can be very confusing when
you're changing image size and screen size and origin all at once.

One more thing to try before we go on. If you re-encoded a file like
LIGHT.GIF with a new origin of 20/20 it would not fit in its screen space.
ClipGIF refuses to let you create files where the images don't fit in the
newly defined screen size. If you attempt to do so it changes the defaults
so it automatically clips the excess amount. Try creating a version of
LIGHT.GIF with a different origin. Note carefully the defaults for the Clip
right and Clip below.

We've skipped discussing one other prompt in the image description.
You are asked if you want the image interlaced. The default answer is
always to interlace images which are already interlaced and not to interlace


Copyright (c) 1989 Cyborg Software Systems, Inc. page 5.




ClipGIF 1.2 GIF RE-ENCODER UTILITY USER DOCUMENTATION


those that aren't. You could use ClipGIF just to lace or unlace images with
no other changes.



3.3 Reducing Color Maps


Nothing irritates me more than large 256 color files with only a few
colors actually used. These files can waste time trying to map colors that
don't appear in the image. They also waste space because the file
compression ability of GIF varies with the bits/pixel. Some high color
images when reduced to GIF's 256 color limit have been known to create
duplicate entries in the color map. This further degrades GIF's efficiency
in compressing data.

If you only have 32 or fewer colors used in a 256 color file, you can
reduce bits/pixel from 8 to 5. Although fewer such wasteful images exist
these days, ClipGIF risked becoming a source of such images. If the small
portion of your image you've clipped only contains a few colors, why bother
re-encoding it with more un-used colors? You've probably noticed by now
that ClipGIF keeps track of how many colors are actually used. It also
eliminates duplicate map entries. ClipGIF tries to use this information to
re-encode your images as efficiently as possible. However you can't just go
reducing color maps at will. Several special cases require your attention.

If the image you're re-encoding has a local color map associated with
it, ClipGIF can do everything it needs to do to reduce the color map. The
map is only used for that particular image. Other images in the file use
either the global map or a local map of its own. ClipGIF collects the map
entries for the used colors and puts them all in the first entries of its
map. Its clears all un-used entries to pure black. This alone saves time
because most decoders can easily map pure black.

If the number of colors is fewer than half than are in the map, then
the map can be cut in half. The bits/pixel value is decreased and the
resulting image is compressed even more. As an example, when you clipped
the stars out of the upper left corner of LIGHT.GIF, only 6 of the 16 colors
remained so we could reduce the map from 16 entries to 8 entries and two of
those eight could be blank. We cannot reduce it further because maps only
can have 2, 4, 8, 16, 32, 64, 128 or 256 entries. We can black-out the two
un-used entries.

Note that in all of this fooling around with color maps we are not
destroying any information. We are not talking about combining two colors
which are close or adjusting colors. We're just cutting away un-used junk.

If you are re-encoding an image with a local color map, ClipGIF does
all of the above described map reduction without asking your permission.

Why can't ClipGIF do the same for global maps? Lets take an example...
We've included a file called TURNER.GIF which is named after WTBS owner Ted
Turner. Ted is fond of turning black and white images into color.
TURNER.GIF is a two image GIF file with a 16 color global color map. There


Copyright (c) 1989 Cyborg Software Systems, Inc. page 6.




ClipGIF 1.2 GIF RE-ENCODER UTILITY USER DOCUMENTATION


are no local maps. The first image uses only two colors. Its a black and
white WTBS logo. The second image is the same logo in full color and
overlays the first image exactly. Suppose we run it through ClipGIF and it
decides that the global map can be reduced to two entries. If we write the
reduced map as a global map then the second image will not have all the
necessary colors.

Unless we scanned the entire file, we'd not know for sure if it was ok
to reduce the global map. Although ClipGIF can solve the TURNER.GIF
problem, we still feel its rather drastic to go messing with global maps
without asking permission. If you run a file through ClipGIF and the first
image has no local map and does not use all the colors... ClipGIF asks your
permission to reduce the global map. If you say YES then it will reduce the
global map but it saves an untouched copy of the original global map in
memory. Any subsequent images can still use it. It will be forced in as a
local map for any images that need it.

Try running ClipGIF on TURNER.GIF and create a new file TURNER2.GIF.
Just press [ENTER] on all questions. The global map will be reduced from 16
entries to 2 entries and ClipGIF keeps a copy of the original 16 color map
in memory. When ClipGIF notices that the second image needs a map and the
reduced map won't do, it recalls that untouched copy of the original global
map and makes it a local map for the 2nd image. It then reduces it if
necessary but always keeps a safe untouched global map stashed away for
subsequent images.

Suppose you refuse and do not let it modify the global map. You will
then be asked if you want to make a reduced local map. Because the first
image will only use two colors it will compress more efficiently even with
the extra local map. If you refuse again then the global map is left intact
and no local maps are created. TURNER2.GIF will be a duplicate of
TURNER.GIF.

Suppose the two images in TURNER.GIF were reversed and the full color
image was followed by a black and white image. The first image would be re-
encoded as-is. The second image however could be reduced to a two color map
with a smaller bits/pixel value. ClipGIF will ask your permission to create
local maps where none exist under these circumstances. Recall that ClipGIF
never needs permission to reduce existent local maps because that doesn't
hurt anything.



3.4 Splitting and Merging Multi-Image Files.


As you've noticed by now, ClipGIF asks you if you want to open new
input and output files from time to time. When your input file has multiple
images, between images it asks you if you want to open a new output file.
If you fed it TURNER.GIF and specified TEDBW.GIF as the output file you
could put Ted's black & white logo there. Then when asked for a new output
file you say YES and give it the name TEDCOLOR.GIF. You'll create two,
single image files.



Copyright (c) 1989 Cyborg Software Systems, Inc. page 7.




ClipGIF 1.2 GIF RE-ENCODER UTILITY USER DOCUMENTATION


Here's an interesting example of the reverse process. Run ClipGIF with
LIGHT.GIF for input and SMILIGHT.GIF as output. When it tells you the file
is complete, reply YES when prompted for an input file. Give it SMILE.GIF
for input file 2. Choose a new origin of Left=20 and Top=100. Clip the
image at Left=50, Top=0, Right=149 and Bottom=89. The resulting file puts
our smile logo in the hand of the girl. Note: This image points out the
difficulties in many multi-image GIFs with local maps. Many EGA decoders
either destroy the colors on LIGHT trying to get SMILE to work or they do a
poor job on matching SMILE's brilliant rainbow. Perhaps someday I'll write
a utility to fix that.

Previous versions of ClipGIF always created local maps for images from
second or subsequent input files. If I'm using ClipGIF to string together
many files, each with its own maps, chances are good that the original
global map wouldn't suffice. ClipGIF used to force local maps to make sure
that the proper colors were available. This newest version first checks the
global map of the original image to see if it can handle this new image.
You will be given the option to eliminate the local map and use the global
map.


4.0 FINAL WORDS


This program is written entirely in Turbo Pascal 5.0 using my DEGIF and
ENGIF units as well as units from Turbo Powersoft's Turbo Professional 4.0
and contains no assembler or Inline code. My #1 goal was to get this
available as soon as possible. My #2 goal will be to make it faster. After
that I'll add other features and any new extensions to the GIF87a standard.

To make it worth my trouble I need your support. Please show your
appreciation and register this product. We also welcome your comments, bug
reports and suggestions. Note that your registration entitles you to an
enhanced version which will clip bigger files.





















Copyright (c) 1989 Cyborg Software Systems, Inc. page 8.


  3 Responses to “Category : Printer + Display Graphics
Archive   : CLIP.ZIP
Filename : CLIP.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/