Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!metro!ipso!fawlty!johnmac
From: johnmac@fawlty.towers.oz (John MacLean)
Newsgroups: comp.sys.apple2
Subject: Re: GIF => 3200 colors?
Message-ID: <443@fawlty.towers.oz>
Date: 29 Aug 90 06:43:52 GMT
References: <139800018@uxa.cso.uiuc.edu> <12421@sdcc6.ucsd.edu>
Reply-To: johnmac@fawlty.ips.oz (John MacLean)
Organization: Tower Technology, Lane Cove, NSW, Australia
Lines: 66

>All of these times are to convert a 320x200x25GIF into 16 colors. John's
>conversion looked the best, followed VERY closely by mine, and SHR Convert's
>was the worst.
>
>SHR Convert: 87 seconds
>TGE : 53 seconds
>Me: 12 seconds
>
>These were done with SHRConvert 2.1, a pre-release copy of TGE 4.2, and v0.1
>of my program.

There are good reasons for TGE suffering this speed loss.
The most important being:

1) TGE is not a 320 x 200 => 320 x 200 converter. This makes things real
easy. It lets you cut and paste and re-scale between any type and size
graphics from icons to print shop borders to 3200 mode graphics to lo-res
etc, etc. And it lets you manually map colors between source and
destination and mask out colors as required.

2) TGE does not assume every graphic you get will have < 16 colors on a
scanline (it stores and transfers every pixel as an RGB value).

3) TGE is extendable. Support for each mode is implemented as a toolset
so that others (once I release the docs - which will be as soon as the
first library disk is available) can add modules to TGE.
I use the IIGS user toolbox interface (not the system toolbox) which
*REALLY* slows things down (usually by a factor of 2 from some tests I did).
This is the price you pay for *REAL* expandability. I do not have to
re-compile TGE to add new modules to it and when I have had enough,
others can take over.

4) I treat loading and optimizing GIFs as seperate operations which is
really silly for a display program. TGE is not a display program - it
is a conversion program which aims at getting the best posiible
results. If you you try TGE on a 256 color GIF and optimize to 16
palettes you get static graphics as good as many 3200 graphics.
I presume the figure quoted above was for a load + optimize. The
optimize would not usually even be necessary unless you have more
than 30 colors in the GIF.

Having said all of this, there is an important role for a display
(and even a file conversion) program such as Jonahs. It is good to
be able to load a graphic and easily display it in various ways
(ie: without doing transfers). A program dedicated to this purpose
can do better than TGE - I have one in some sort of state myself.

TGE can do all of this, but it is NOT a dedicated 320 x 200
IFF <-> SHR <-> GIF <-> 3200 converter, so it will generally
be slower for the same quality. These represent only a small
subset of TGEs functions. It will probably produce the
best quality if you do not mind things a bit slower - and it
can be just as quick if you just want a quick view of the graphic.
TGE has several standard palette and grayscale toolsets which will
let you do this at compareable times to Jonah's software.

Just a quick question:
Can you compare the Save times for SHR Convert, TGE, and your program
for GIFs Jonah?

John MacLean.
-- 
This net: johnmac@fawlty.towers.oz.au                   Phone: +61 2 427 2999
That net: uunet!fawlty.towers.oz.au!johnmac             Fax:   +61 2 427 7072
Snail:    Tower Technology, Unit D 31-33 Sirius Rd,     Home:  +61 2 960 1453
          Lane Cove, NSW 2066, Australia.