#TOTAL CONFUSION
26 messages in this thread
PLEASE RECOMEND A GIF FILE TO DOWNLOAD THAT WILL ENABLE ME TO UTILIZE ALL
OF THE PICTURE-GRAPH FORMATS THAT ARE IN THE LIBRARY. WHEN DOWNLOADING WHAT
DO I HAVE THE FILE DOWNLOADED TO? DO I NEED A DE-COMPRESSION PROGRAM IN
ORDER TO USE THE PROGRAM? AND WILL THESE PROGRAMS HAVE ICONS TO OPERATE OR
MUST THEY BE RUN FROM THE CLI? I WOULD APPRICIATE ANY HELP, PLEAS
CONDESENDING AS POSSIBLE, FOR I AM LIMITED IN MY SKILLS AS A COMPUTER
PROGRAMMER. IN OTHER WORDS, I DON'T KNOW SQUAT ABOUT THIS STUFF. I JUST
WANT TO BE ABLE TO SEE EVERYTHING! THANX FOR UNDERSTANDING SINCERELY, DAVID
FEASTER
David,
It is going to take more than one message (from you and also from me) to
get all of this worked out, but we can do it.
First of all – almost everything on this and all other boards is archived
using either ARC, LHARC, or ZOO. This is done for several reasons. Mainly,
it keeps all the files that belong together in a single file for
downloading, and also, it compacts the data so you have a much shorter
download time. It does mean, though, that you have to unpack the data once
you have it downloaded. For that, you need to go to Library 5 of AmigaUser
and download:
ARC.EXE to unpack files whose names end with .ARC
ZOO.EXE to unpack files whose names end with .ZOO
LHARC.EXE to unpack files whose names end with .LZH
ARCHLP.EXE to teach you how to use the other three.
Second, you will need a viewer that can display most of the graphics. The
two I like best are SuperVIEW and MOSTRA. Both of those are in Library 14
of AMigaArts.
I would suggest that you format a clean disk to hold your downloads, and
name it DL. Then, when the CIS computer asks: Name for your computer: you
can type DL:FILENAME.EXT whatever the filename and extension might be,
such as SVIEW.LZH
Most of the things will not have icons, but once you have learned to
download and to unarc, I'll tell you how to do that, too.
Let me know if you need more help.
Betty
Betty, perhaps you can clear something up for me. Why aren't GIF
files compressed on CI$ or any other BBS? Is it due to differences in
computer decompression programs? GIF files are usually pretty big and
timely <sp> to download.
GIF is a compressed format. Additonal archiving over the GIF file will, in
most cases, increase the size of the file.
Bill, K3OZM
I've notice that if I convert a GIF to Amiga-HAM, the file size is dereased
by a great deal! And if I GIF that file, the end result is almost *half*
that of the original GIF file, with no loss in quality.
Why is that?
<Dave>
GIF has enough information in it to recreate a one-byte-per-pixel image,
which is 8 bits per pixel. When you convert it to HAM, you convert it to a
six-bits-per-pixel format. That is a 25% reduction right there in gross
data terms. Compression of the HAM image results in a smaller GIF. That's
my guess.
THol() { cout << "Sir, I exist." ;}
When you convert a GIF to HAM, you generally cut the resolution of the
original image by about half. (Based on a typical 640×480 GIF created on a
clone, you would convert to 320×400 or 320×200 to get into HAM mode.) The
lower resolution of the HAM file allows for a smaller file size. Converting
the HAM file to GIF impresses compression on the HAM file – not the
original image. You would realize approximately the same file compression
by using the archive utility ARC, which uses the same method of
compression. (As does the utility LHARC, though the compression routine
was refined in LHARC.)
Bill, K3OZM
Actually, GIF's compression is typically better than ARC, and depending on
the image, often better than LHARC as well. That is because it doesn't
start at the same higher bits per compression code, and is somewhat more
oriented to a graphics display than general file compression.
–>Steve Bennett
True enough, but those utilities do provide a valid comparison, and they
use essentially the same compression routines. Of course, the compression
on a HAM image isn't really all that significant in any of those methods,
while compression of a RGB bitmap can be very significant. All of which
really has nothing to do with the original question. 🙂
Ya cuts the resolution of a picture in half, and ya gets a smaller file,
bottom line.
Bill, K3OZM
Thanks, Bill. I wasn't aware that GIF's were already compressed.
Leslie,
I'm no expert on GIF formats, but it is my understanding that they are
already compressed. That is, the GIF format is compressed as a part of the
format itself. To then compress them with yet another program could even
result in making them bigger. Almost any file that has to contain a bitmap
showing lots of colors is going to be big!
Betty
It depends on how "busy" the image is, Betty, but I have run GifSCAN on a
number or images and find the GIF file is compressed around 30-50%,
typically, over the bitmap. I have one on one of my disks right now that
is 159k in GIF format, but 774k as a RGB bitmap…….. too big for me to
process in TAD <sigh>. That is a rather unusual amount of compression, but
the image is mostly solid colors on a solid background. On the other side,
I'd expect something like the CF thing (the one that looked like a full
color clambake) Perry did to demonstrate one of his scanlab products to
compress closer to 20%, if that. I have seen some GIF files recompressed
on some local BBS, and the archived file has always been larger than the
GIF file. I have never had the interest to really look into the subject to
see what degree of expansion such a "recompression" would cause.
Bill, K3OZM
To tell the truth, Bill – I never tried it either. I just quoted what I've
read so many times here.
Betty
I didn't know that GIF's were compressed already. I had always thought
that it was safest to compress files in someway before downloading for the
Amiga due to Amy needing the exact file size. I thought that downloading
(and uploading) with some protocols pad the file making them useless to the
Amiga.
Some protocols, like Xmodem, do pad transmissions to meet protocol
standards. Almost every Amiga term program in use today is equipped to
strip that padding automatically, however. Quite a few protocols don't use
any padding nowdays anyway. In any event, padding would be more likely to
affect the decompression utility than a raw file.
Bill, K3OZM
Having downloaded files come out with the exact same size is a lot more of
a problem with executable programs than with data files.
Jim Maurer
That would seem to make sense. I guess data files could stand to have an
extra few bytes without many problems. I am saving a lot of my GIF files
in the hope that Amiga resolution will increase somewhere down the road.
Leslie, it is XModem that pads the files. GIF files are compressed,
though.
Betty
Betty,
You've mentioned something about working with icons. I have a
question along those lines. I have been downloading (long) text files from
a school account using the Kermit protocol, under the assumption that it
would be faster than capturing text. Previously, when I've used capture,
my comm program would give the file an icon which, when double-clicked,
would automatically run 'more' and would view the file. This is not the
case, however, when I use the Kermit protocol. It just gives it an icon
that somewhat resembles a terminal, and it doesn't call up 'more'.
The question is, then, how can I change the icon so that it will get 'more'
to read the file? Thanks for any help..
– Mark
Mark, click once on that icon, and then move to the Project menu and select
"Info". On the Infor screen that then comes up, first look and see if you
have a project icon. If so, then look down at the line that says Default
tool. Change that to the reader you want, paying close attention to the
path.
For example, if 'more' is on the c directory of your workbench, etc., that
tool need only say MORE
if it is in a c: directory of the disk on which the text file is, the tool
would say :C/MORE
If it is in a c: directory on something other than your boot disk, you
might have to say
Diskname:c/more
You get the idea, I'm sure. After you fix it, click on SAVE. After that,
it ought to work.
Betty
Shouldn't that have been "C:MORE" and not ":C/MORE"? I always use the
former, because that way it will always get MORE off the correct disk even
if the icon you are clicking upon is on a different disk. Otherwise I need
to have copies of MORE scattered about. (In fact, that's one minor
annoyance about certain uploads… Icons should always refer either to a
specific disk name [ie. "FRED:RUNME"] or a common defined system name [ie.
"C:MORE"], or should avoid the volume entirely and reference something
solely from the current directory. [ie. "fred/runme"]
One should avoid references based on the root directory of the current
disk [ie. ":fred/runme"] because there is NO guarentee that the user will
decide to unarchive the files at the root or in a specific subdirectory. I
know *I* never do…)
–>Steve Bennett
That seems to be a very common problem. It is even more frustrating when
the author specifies "Less", or
"DH21:Fred'sSuperThingies/Fred'sSuperFileReader" as the default tool. I
think it should be incumbent on the uploader to insure the default tool is
either included, with approriate pathing in the icon, or only tools
available on the standard WB be specified. (Must think I'm in Hyde Park…
climbing off soapbox.)
Bill, K3OZM
Yeah, I've been frustrated by that one too, and agree that the uploader
should stick to the basic tools included with the Amiga for things like
that, or supply what's needed. On the other hand, that could get awfully
annoying to the downloader who has just downloaded Yet Another Archive
containing "MuchMore" or something like that… You lose either way. <sigh>
–>Steve Bennett
One other thing that really gets to me is the assumption by many that
EVERYONE uses ARP, or at least has ARP.LIBRARY on their sys:. I have some
disks that have it, and others that don't. Lots of folks don't have it at
all. I think uploaders should inform the user that ARP is required in the
file description. It would save a lot of time in downloading a utility,
then deleting it. 🙂
Bill, K3OZM
Even worse – some of them insist on a particular version of ARP. I have
the latest version available here, and quite a few programs complain that I
have the wrong version, and refuse to run because of it.
Betty
The disks I make for my club always have a c: directory, and the icon has
to say :c/more – indicating to look in the c directory of THIS disk for
more. I believe that c:More looks in the C directory under which the
machine was booted. Perhaps I'm wrong – just fixed something that worked
for me.
Betty