GIF viewing problems
47 messages in this thread
One of my local IBM BBS's has compressed all his GIFs with one of the IBM
gif compressors that are out. He claims that any standard gif viewer will
still view them, but Virtgif won't, so I am afraid that only IBM viewers
may work. I hope I am wrong. Does anyone know if there are any Amiga
viewers that will view compressed GIFs that are supposed to be readable as
is? (Sorry I don't know the name of the IBM GIF compressor). I would like
to find a better GIF viewer anyway, as Virgif is real limited as to screen
sizes it will show, and with super VGA being as popular as it is with
graphics, and having such large screen sizes, the pictures are so big that
the color segments get blown up on my little 1084 screen. (Virtgif will
only show a small part of a large GIF, and lets you scroll; but it won't
shrink without bad distortion.) I understand Art Dept. Proff. will resize
pictures, but I am interested in shareware or PD.
Try HAMGIF with one of these GIFs. If it doesn't work, then tell this BBS
person that he's full of it. GIF files are a particular format, and CANNOT
BE FURTHER COMPRESSED without making them unreadable by GIF viewers. (One
correction: They can be compressed further by reducing the data contained
within, either by shrinking the image resolution, or playing games with the
data to make it more compressable, which will probably blur the data
somewhat…)
A number of GIF developers experimented with a technique which delayed
the LZW table clear code for some time after the table was filled. This
technique was virtually non-effective in further compressing images (some
images became larger, some smaller, most were no significant difference),
and broke over half the GIF viewers then in existance. Since the GIF spec
says to issue the clear code as soon as the table is full, it was decided
at that point that GIFs compressed with the delayed clear code were not
allowed according to spec, and would not be allowable here on CIS.
If HAMGIF doesn't display the file, it's not anywhere close to spec. If
that is the case, could you inquire as to the compression program's name,
so I can pass the info on to the Graphics Support forum and see if we can
get the developer to fix it (assuming he's a registered GIF developer,
which is hopefully the case…).
–>Steve Bennett
I'm sure this has been debated before, but maybe you can give me a short
summary. While LZW will probably shirnk images to a reasonable degree,
I've heard it is not suited for things like bitmaps. Obviously, DCT
compression ala JPEG is becoming more popular. Why was LZW picked? Were
other methods considered? And does H&R Block pay the patent license on
LZW? 🙂
LZW (actually, this is a varient on LZ which is similar but not quite the
same as LZW, and actually slightly predates LZW… It's what the COMPRESS
program under UNIX was based upon. I read an excellent article on the 12
or so varient compression schemes based on LZ, of which LZW is only *one*,
despite which everyone tends to label the whole group as LZW… 🙂 as used
in GIF is probably the most efficient means of packing bitmaps where the
number of bits per pixel is 8 or less, and you want 100% accurate
reproduction. Since the varient used starts with a code size of <bits per
pixel> + 1, you aren't compressing any filler bits, and have a relatively
larger number of codes to work with.
Admittedly, the maximum size of 12 bits per pixel is a limit. It should
really have been 16, but 8 bit machines don't really have enough memory for
the code table in that case (needs a table 128K bytes in length, plus
another of 64K bytes in length to decompress…) and possibly more
importantly for the GIF designers, it would have been more difficult to
implement on an IBM PC due to the 64K segmentation.
While JPEG does a better overall job of compression, it does so by LOSING
data. A reconstructed JPEG compressed image is only an approximation of
the original image. At resolutions of over 72dpi, it becomes relatively
unnoticable as far as the differences are concerned (except *really* sharp
lines will blur…) unless you look closely. As such, it's useful for
photographic quality images of high resolution, but it's pretty useless for
CAD/CAM drawings, and lower resolution images.
The original LZW scheme is indeed not a very effective bitmap image
compressor (although it's still on average about as effective as Huffman
encoding, which is the only real alternative to the LZ schemes) since it
uses a fixed size 12 bit code, which means that most of the codes generated
actually pad out the data with pad bits. Or if you pack the bits together
(as, for example, ILBM does) into a byte, you don't get much of the
advantage of duplicate patterns of bits (which is how the LZ encoding
works) unless
[Continued in reply]
[Continued from previous message]
the patterns happen to duplicate at 8 bit intervals, which they usually
don't. The variable code size encoding used by GIF allows any and all
repeating bit patterns to compress accordingly. This is much more
effective than the "standard" LZW scheme. It would be difficult to come up
with a better scheme which would still retain 100% of the data. (Huffman
encoding is the only real alternative to the LZ derivitives, and it isn't
anywhere near as effective as the GIF compression has been…)
Sorry to go on a bit about that, but it needed some explaining…
–>Steve Bennett
I was under the impression that there's a lossless JPEG, and a lossy JPEG.
Thanks for the complete answer, I know you're good at those. 🙂
Actually, that answer was almost "stock". The original GIF developers must
have hashed out that kind of stuff for months and months and months (and
months and months and months… 🙂 in our endless discussions of what GIF
"should have been" and "should become". <grin>
–>Steve Bennett
I will download Hamgif. The compression program does take out data. the
Sysop claims that picture quality is almost the same. I repeat almost. (
These people with only 256 colors dont know what theyre missing I guess.) I
will find out the name of the so-called compression program and get back to
you if Hamgif doesnt do the trick.
Well, Hamgif did read the so-called compressed gifs OK. Thanks for the tip.
They were the blurriest ones I have ever seen, tho. I will tell the guy.
Hamgif sure is alot faster than Virtgif, but It wont scroll the screen
apparently. Do you know how to exit the picture without having to reboot
the computer, by chance? (In Hamgif).
HAMGIF (which I wrote) badly needs upgrading for things like overscan,
scrolling, and a better display algorithm (probably some of that blurriness
is HAMGIF's HAM algorithm…). To exit the picture, click on the hidden
close box in the upper left hand corner. (At the time when HAMGIF was
written, nearly all IFF display programs were exited doing this, so I
assumed people would know about it. Again, an update is needed… 🙂 (Of
course, I've got so many other things to do, an update is not very likely,
unless I write a 2.0 specific version as an experiment in using the new 2.0
screen handling stuff… <grin>)
–>Steve Bennett
Yup, Hamgif needs upgrading, and you've promised it before. 🙂 Neither
here nor there at the moment though. Hamgif remains the most useful GIF
viewer available today. (I convert with ADPRO, but screen GIFs with
HAMGIF.) As such, I think it merits the label 'classic.'
Bill, K3OZM
Support America!
Thanks. The close button should get me fixed up. I have only had my Amiga
for a year now, so still am not familiar with all of the standard ways of
doing things. It is nice to have such a fast viewer, I will use it allot. I
think most of the blurrines was from the dumb compressor. Other gifs look
much better (normal GIFS).
Steve,
I find HAMGIF is a great little utility. I thank you for it. Now if it
just supported MIGs.<g> An AMGIF to make them would be nice to.
Dirk A. Jones
HAMGIF *does* support MIGs. Sortof. It's not guarenteed to show them
particularly well due to the HAM side effects, but 16 or 32 color MIGs
ought to show just fine. As for making them, personally I think the
multiple image stuff in GIF was ill-conceived in the first place, and ought
to be removed. Creating such beasties in a simple way simply doesn't
exist. It's even more complex when you add HAM conversion into the fray.
(I could probably manage to add relatively limited support for MIGs by
limiting things to 16 or 32 color input files, all with exactly the same
color palette…)
Does TAD support MIGs? If so, that might be a much better solution,
since there you can use palette matching and the like to get the correct
image…
–>Steve Bennett
Steve,
I found that HAMGIF goes GURU when it gets a MIG of 640 x 480 and 256
colors. I can get GIFFY to show them in 16 colors without a GURU.
ADPro does support MIGs. Sortof. You have to time hitting the cancel
button at just the right time between the frames. Not as easy as it sounds.
Keep a count as to what frames you have and dont have. But it can be done.
Dirk A. Jones
Is it a *valid* MIG? HAMGIF has been thoroughly tested with MIGs of that
size (and larger and smaller) ever since it was first released. Can you
give me an example of a file which causes this crash? Offhand, I can only
think of a few things which might cause HAMGIF to crash, and ALL of them
require the GIF to be invalid. (Things like a MIG which contains an image
which extends beyond the edge of the area specified as the viewing area, or
incorrectly extended blocks, or the like…)
–>Steve Bennett
Steve;
Check out GRNEYE.GIF, CHASE1.GIF, and CNTAUR.GIF. They are in ComArts
lib number 4. They get me a GURU every time. Hope this helps.
Dirk A. Jones
I'll check them out ASAP.
–>Steve Bennett
It helped immensely. I now know what the problem is and have fixed it
here, although it may be a bit before I can dig out the real HAMGIF sources
and fix it there as well. (I fixed it in my working copy of the "next
generation" GIFFY, which never really got anywhere near finished or
released… Who knows, maybe someday… 🙂
–>Steve Bennett
Steve;
Great. Glad to help. Hope its not too hard to find. Waiting for great
utilities is nerve racking. 🙂
Dirk A. Jones
John –
If the BBS uses GIFLite or somesuch, it's the same one as a BBS local to
me does. Bad news is, the only GIF viewer I found that would work on the PC
side (I tried 5 or 6) was one written for Windows. I have to load it in
there and re-save it in order for my regular viewer to work. So much for
standards … Good news is, ADPro has no trouble with them. I don't have
any information on PD converters, since I don't need one. Hope this helps
some.
Harry
That might be the one, I will check. If so, I will let the guy know. What
is Adpro? I am not totally averse to buying a commercial program, its just
I cant see spending $200 for a 24 bit utility and only using it as a GIF
viewer. (I refer to Art Dept. Pro.)
I've not followed this thread carefully, so I apolgize if this suggestion
is inappropriate…. but have you considered the HAM-E device for viewing
your GIF's? HAM-E will take most GIF's and show them to you the way they
were created, in 256 colors. Aside from the other myriad reasons for
getting a HAM-E, that one would seem important to you. Just thought that
I'd mention it….
–jp–seattle–
Ham-E is on my want list. I didn't think about using it as a GIF viewer,
though. HOpe I can get one sometime.
HAM-E has great GIF support. It's RegPaint program (256 color paint) loads
GIF directly, displaying them in full 256 colors, and the Image
Professional program now loads them directly as well. A bit pricey for
just GIF viewing, but beats most other methods!
–jp–seattle–
Wow, you really have my intereat up on Ham E. I already have been thinking
about it alot. One thing though: how does it do with the oversized GIFs?
(Like are created on Macs or IBM's with super VGA? (Excuse the typo.. I
meant interest up on Ham-E, in the first line.) REally, viewing the big
Gifs are my main concern, and being able to shrink them to my little 1084
screen.
Well, in RegPaint (support software that comes with HAM-E) you can scroll
around in the oversized images. There are several image display programs
that are supporting scrolling around in oversized HAM-E images now as well;
notable among them is one called 'TIV'. GIF viewing is real nice. I have
a nice collection of stuff from the other graphics forums, most of it in
GIF format.
If what is important to you is seeing the entire oversized pic on your 1084
*at the same time*, then you'll need to scale the image to at most 384×480,
which is the largest overscan the HAM-E can show at once. Image
Professional, which comes with HAM-E, will do the scaling and the color
rendering for you all at once, though, so it's pretty simple to do.
Have you downloaded 'Image Professional' (IP for short)? It's avail in the
Black Belt library in AmigaVend, and is somewhat (barely) useful without
the HAM-E hardware, but it is avail for you to try out. A truly amazing
piece of software. At least it would give you an idea of the scope of
operations it performs.
–jp–seattle–
Thanks for all the info. I will try out IP. Haavent downloaded it yet, but
will do that. Virtgif does let you scroll around on a big picture too.
View ing large pictures like that, it blows up the pixels and little color
splotches, so you lose the photograph-like quality that you get from
viewing the same picture on a higher resolition screen at normal size. I
hope I am not blowing too much smoke. I realize alot of the cause of such
resolution problems are caused by low quality scans. A good digitized
picture done on an Amiga will make a better quality GIF than a color scan
done on an MSDOS machine.
As I expect John will tell you, it does it no problem. Pan/scroll or
shrink – or scale – or anything else you like.
Ben
Amateur Radio Callsign is A A 7 A S
Both IP and RPaint can write GIF's too – IP can create them from 24 bit
files to boot.
Ben
Amateur Radio Callsign is A A 7 A S
Not only a GIF Viewer – but a GIF writer. Image Professional, the support
s/w that comes with the HAM-E, has an excellent GIF converter – uses an 18
bit color picker for the palette, which (I believe – I'm sure I'll be told
if I'm wrong :^) is the finest available on the Amiga at this time. Others
use 15 bits – or less – to do the color picking. So, you can load, process,
and save GIF directly. It's a lot of fun.
Ben
Amateur Radio Callsign is A A 7 A S
If you were told you were wrong, would it matter?
Sure it would, Perry – are you telling me?
It'd be nice if you improved the ADPro color picker up to the level of the
IP color picker. Everyone would benefit.
Ben
Amateur Radio Callsign is A A 7 A S
John –
ADPro is short(er) for Art Dept. Pro. 8^) I use it for other things, but
GIF viewing/conversion is a large part of it. Perhaps Art Dept. (regular)
and the GIF module (extra) would be less than ADPro and more within your
budget? I don't know how much they are, so I can't say.
Harry
Oh yeah. Thanks for the reply. I have wanted to get ADpro for that reason.
(viewing GIFS). Maybe it would be worth it.
$200? Around here it's only $149. But I know what you mean. However, to
me it was worth it. The GIF/PCX etc conversions are great, and it lets me
view 24 bit images in HAM mode. Saved me having to buy a $500-$600 24 bit
adaptor just to view the 24 bit images on my bbs.
Rick,
HAM-E goes for $299 and DCTV for $389.
Blaq! – via Whap!
CB>> HAM-E goes for $299 and DCTV for $389.
Thanks, I hadn't priced them mail order yet. I know locally, the DCTV is
$485 (The Amiga dealer tries to make 30% on everything). I do like the
idea of DCTV's builtin video capture.
Rick,
yes… while mst users here agree on HAM-E's superiority, the argument
falls a bit short when you don't already have a digitizer. If you do, it's
better to uy a HAM-E and DigiFex RGB-to-composite encoder; then, you have a
choice between displaying sharp RGB or video-compatible NTSC fuzziness.
However, for many people, to add the price of a digitizer to the package
pushes it beyond the point where HAM-E wins over DCTV.
Of course, there is that stupendous HAM-E support software, which gives
you most of the functionality of megabuck Mac programs like Adobe Photoshop
— for free! If you add those into the picture, the situation gets murky
again.
Blaq! – via Whap!
Actually, Charles, you can get a HAM-E for $299 from Black Belt (the
non-anti-alias version) and DigiView for $120 or so, and that's only
$420…. slightly more than I've seen DCTV selling for. (and that is the
direct HAM-E price…. have no idea what it sells for MO)
So I just don't see the big price advantage. About a push I'd say. I
still can't say poor about DCTV, cause I've never used one ALOT, but I have
seen them in action, and was nowhere near as impressed with either the
software or image as I am with the HAM-E.
And, as you point out, when you consider the HAM-E's image quality,
provided software, and the 3rd party software being written for it, the
situation becomes a bit less murky, no?
–jp–seattle–
ahh… there is an option if GIFLite that the sysop (or compressor) should
know about… some GIF viewers can't handle GIFS with the GIFLite header…
so there's an option to not put that in, so instead it says GIF89a or
whatever only. That's the option (-r if memory doesn't fail like it
usually does <g>) CIS requires for any GIFLited GIF uploaded here. (it
ensures compatibility).
It's a similar problem to that some IFF viewers have had on the Amiga.
Some of the authors expect blocks of data in IFF files to always be in a
certain order, while the IFF spec allows them to be in any order. So if a
program inserts a block of data (formtype? can't remember exactly what
this is called) in a different order, there's a lot of viewers that choke
on it.
Comes from following convention instead of specifications.
The GIFLite header, if it *does* fall before the "GIF89a", does *not*
follow the GIF specification for regular GIF files. (What little
specification there is of it, anyway. Basically a GIF file is supposed to
consist solely of a GIF data stream, which starts with "GIF89a".) However,
it does follow the specification for use of GIF within a specific
application. To wit, GIFLite. It is therefore to be assumed that ALL GIF
viewers out there will fail to view such a file unless they have been
rewritten to handle GIFLite files as well.
Personally, I feel GIFLite defeats the purpose behind GIF as well. GIF
is designed to be able to 100% reproduce the original image (provided it
was 256 or less colors), and anything like JPEG or GIFLite which reduces
that information, is, IMHO, not really GIF anymore.
–>Steve Bennett
Hmm… so far, VPic 4.0 has read the Giflited files with no problems in the
majority of the cases. And to my eye, they look as good as the originals.
At least with GIFLite, I can view the compressed gifs with VPic (haven't
tried CShow or others yet). With JPEG, nothing I have will view them
without running JPG2GIF first.
If he compressed the GIFs with GIFLite by Winfred Hu, they should be be
viewable. However, even GIFLite will occassionally screw things up. When
I compress my GIFs with it, I immediately view them with VPic (this is all
on the PC) and for every 40 or 50 I do, there's one that won't view
properly compressed, so I put the original back.
CIS has even put their blessing and stamp of approval on GIFLite, as unlike
the JPEG format, GIFLited GIFS are still universal.
If your sysop is using JPEG, and supports more than just the IBM types,
please remind him of the purposes of the GIF format and inform her (getting
politically correct here) that JPEG'd gifs defeat the purpose. Instead
turn him onto GIFLite. GIFLite only compresses about 30% compared to the
40%-50% claimed by JPEG but you don't have to unarchive them to view them.
John,
I've encountered the same problem. The compressed GIF files aren't
viewable with VirtGIF, but they should be viewable with HAMGIF. Only
problem is that HAMGIF only shows the upper left corner of the image, while
VirtGIF would let you scroll around. My solution has been to convert tem,
using HAMSharp, I think (I tried a couple of methods, and I've forgotten
which one I liked best, so I'll have to try them over again!). The other
methods were HAMLab and GIFMachine.
-tc
Santa Clara, California
Thanks for the info. Yes, I did find Hamgif to work. I will try out those
others you mention (Hamsharp, etc.)