kremer@cs.utwente.nl (Harro Kremer) (11/26/90)
Does anybody have a program to display pictures stored in GIF89a format on a machine running Xwindows X11R4 ? Harro +----------------------------------------------------------+ | Harro Kremer | | Dept. of Computer Science | | University of Twente | | P.O. Box 217 Email: kremer@cs.utwente.nl | | 7500 AE Enschede voice: +31 53 89 2819 | | Netherlands fax : +31 53 33 3815 | +----------------------------------------------------------+
pfuetz@zgdvda.zgdvda.uucp (Matthias Pfuetzner) (11/27/90)
There are at least two tools to achieve this goal: Try xloadimage or
xgif (now xv). They should be available at any archive of
comp.sources.x. xv is being posted two months ago, xloadimage nearly 5
months ago.
Hope this helps!
Matthias
P.S.: I'd prefer xloadimage. It can display much more graphic formats
than just gif89a. xv also can more than just gif, but xloadimage is
faster, does dithering on monochrome monitors, can set X-background,
can do any combination of multiple pictures into one, etc.
--
@work: | Matthias Pfuetzner | @home:
ZGDV, Wilhelminenstrasse 7 | 6100 Darmstadt, FRG | Lichtenbergstrasse 73
+49 6151 155-164 or -101 \ <- Tel.nr. -> / +49 6151 75717
pfuetzner@agd.fhg.de pfuetzner@zgdvda.UUCP XBR1YD3U@DDATHD21.BITNETjimf@SABER.COM (11/28/90)
|There are at least two tools to achieve this goal: Try xloadimage or |xgif (now xv). They should be available at any archive of |comp.sources.x. xv is being posted two months ago, xloadimage nearly 5 |months ago. Xloadimage does not yet support 89a, only 87a. I haven't had time to try adding support for 89a (probably won't have time in the near future unless someone does it for me). |P.S.: I'd prefer xloadimage. It can display much more graphic formats |than just gif89a. xv also can more than just gif, but xloadimage is |faster, does dithering on monochrome monitors, can set X-background, |can do any combination of multiple pictures into one, etc. Thanks for the plug :-). Some minor changes have improved display speed for most image types dramatically for the upcoming 2.02 release, so you'll be even happier. Happy hacking, jim frost saber software jimf@saber.com
dave@boingo.med.jhu.edu (David Heath) (11/29/90)
jimf@SABER.COM writes: >|There are at least two tools to achieve this goal: Try xloadimage or >|xgif (now xv). They should be available at any archive of >|comp.sources.x. xv is being posted two months ago, xloadimage nearly 5 >|months ago. >Xloadimage does not yet support 89a, only 87a. I haven't had time to >try adding support for 89a (probably won't have time in the near >future unless someone does it for me). From reading the compuserv GIF documentation, I was under the impression the GIF standard was meant to be easily extensible. Software written for old versions of the standard would just ignore blocks that they didn't understand. If this is so, they WHY do so many programmers who write GIF readers insist on checking for "GIF87a" in the header? This seems incredibly short sighted to me. If there is a good reason for this, I would like to hear it. -dave heath dave@boingo.med.jhu.edu
eeidson@eng.AUburn.EDU (Eric Eidson) (11/29/90)
In <1990Nov29.031653.28066@boingo.med.jhu.edu>, David Heath writes: |> >From reading the compuserv GIF documentation, I was under the impression |> the GIF standard was meant to be easily extensible. Software written for |> old versions of the standard would just ignore blocks that they didn't |> understand. If this is so, they WHY do so many programmers who write |> GIF readers insist on checking for "GIF87a" in the header? This seems |> incredibly short sighted to me. |> If there is a good reason for this, I would like to hear it. The only reasons that I can think of is: a) It's the easiest way to make sure that it is a gif format file...wouldn't want to read a MACPaint file as a GIF, would we? b) I only know of two GIF formats, gif87a and gif89a. Since most of the programs were written before gif89a was released for designers, why would anyone NOT use it to check to see if the file was a GIF??? I don't mean for the above to sound rude. You are right, the GIF format was designed to be easily extensible from what I remember reading. But when programmers weren't sure that there was ever going to be a new and improved format, that would just be an extension of the current format, why bother with programming in extensibility when the programmer would not be sure what needed extended? Furthermore, if the new format was just an extension of the old format, isn't the only thing needed to handle the new block (the ones you are currently ignoring) to add the pertinant code. So, it's not really a good reason, I just can't think of a good reason not to do it that way... -------------------- The above is just the way I understood the situation... If I'm wrong, tell me... Send me any comments, corrections (likely), flames, praises (doubtful), etc... Hunter Eidson +-------------------------------+-----------------------------+ | Hunter Eidson | "I am the bringer... | | Auburn University | I am the knower... | | eeidson@eng.auburn.edu | I am the owner... | | (205)844-7691 | PSYCHOPOMPS... | | (205)844-2280 | THE SPARROWS ARE FLYING." | +-------------------------------+-----------------------------+ Stephen King - The Dark Half
jimf@SABER.COM (11/29/90)
|From reading the compuserv GIF documentation, I was under the impression |the GIF standard was meant to be easily extensible. Software written for |old versions of the standard would just ignore blocks that they didn't |understand. If this is so, they WHY do so many programmers who write |GIF readers insist on checking for "GIF87a" in the header? This seems |incredibly short sighted to me. | |If there is a good reason for this, I would like to hear it. Xloadimage, for one, reads not only GIF files but twelve other graphics formats. It's often difficult to distinguish between formats quickly, and in some cases it's nearly impossible -- especially when some formats are derived from others. When an image format supplies a magic number of some sort, there's a strong tendency to look at that magic number to determine if you should bother going further. jim frost saber software jimf@saber.com
datri@convex.com (Anthony A. Datri) (11/30/90)
>|than just gif89a. xv also can more than just gif, but xloadimage is >|faster, does dithering on monochrome monitors >... What version of xv do you have? The one that I've got certainly does halftoning of multi-bit images on 1-bit displays. Both xloadimage and xv are fine programs, and I thank the respective authors for providing them. For run-of-the-mill image display, I use xloadimage. I use xv when I want to brighten an image, since it has the interactive gamma feature, and also when I want to crop an image (eg., to remove the big borders that seem to emanate from ms-dos land). --