jimf@SABER.COM (09/26/90)
As soon as I finish ftp'ing it, xloadimage version 2.0 will be available on expo.lcs.mit.edu in /contrib/xloadimage.2.0.tar.Z. Older versions and patches have been removed. Version 2.0 contains the following enhancements and modifications: * There is now a single Makefile for a variety of different target environments. * New readers for MacPaint, FBM, CMU, Utah RLE and XWD image formats. * PGM and PPM support added to PBM loader. * Gamma equalization option. * Smoothing option. * Rotation option. * G3 FAX support was modified to cut down on false positive identifications. * Stdin can now be used as the image source. This change also included caching that improves normal performance. * Color slideshows now work. * Icon titles use an abbreviated titlebar title * The resource class name was changed from XLoadImage to xloadimage to be more predictable. * Several options now propagate to all images following them if the -slideshow option is specified. * Miscellaneous fixes to several existing loaders. For those who do not have ftp access, I can email you the update or you can watch comp.sources.x. Unfortunately the distribution is changed enough that patches would have been clumsy to deal with as well as quite large. For these reasons version 2.0 is not available as a patch from 1.06. If you ask for an emailed distribution, be aware that the shar distribution is 375k now, up from 180k in version 1.06. Happy hacking, jim frost saber software jimf@saber.com
gary@gouff.ncar.ucar.EDU (Gary Strand) (09/27/90)
I believe there's a fatal bug in xloadimage.2.0. The code compiles fine, but when I look at a series of images with the "xloadimage -slideshow" command, the 2nd image never gets fully drawn, my machine (Sun 3/60, xloadimage executing on Sun SS1+) locks up, and after a couple of minutes, I get kicked out of X completely. I never had this problem with xloadimage.1.06 (the latest one I had). -- Gary Strand *Damn* good coffee! And *hot*! Internet: strandwg@ncar.ucar.edu Voicenet: (303) 497-1383
wes@uh.msc.umn.edu (Wes Barris) (09/27/90)
The latest release of xloadimage (2.0) was said to support URT (.rle) files.
When built and ran it on an IRIS 4D/320 running IRIX 3.3 it produces the
following error message:
i1.arc.umn.edu> rlebg -s 646 485 -v 0.9 0.1 100 240 150 >junk.rle
i1.arc.umn.edu> xloadimage junk.rle
junk.rle: unknown or unsupported image type
No images to display
This image will display properly with "getx11" for example. Anyone
have similar problems?
o o o o o o o . . . ________________________________ _____=======_____
o _____ |Wes Barris | | wes@msc.edu |
.][__n_n_|DD[ ====_____ |Minnesota Supercomputer Center| |(612) 626-1854 |
>(________|__|_[_________]_|University of Minnesota_______|_|_FAX:_624-6550_|_
_/oo OOOOO oo` ooo ooo 'o^o^o o^o^o` 'o^o o^o`
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
His heart was yours from the first moment that you met.h1c5962@tamuts.tamu.edu (Lee Cox) (09/27/90)
In article <2666@uc.msc.umn.edu> wes@msc.edu writes: >The latest release of xloadimage (2.0) was said to support URT (.rle) files. >When built and ran it on an IRIS 4D/320 running IRIX 3.3 it produces the >following error message: > I ran the images from urt-img.tar through it and all but tack_with_shadow.rle displayed correctly. tack_with_shadow.rle, however, gave the unknown or unsupported image type error. ************************************************************************ Lee Cox BITnet: H1C5962@TAMSTAR HEPnet: FNBIT::TAMHEP::THOR::H1C5962 Asst. Systems Manager Internet: H1C5962@STAR.TAMU.EDU Academic Computing Services SPAN: UTSPAN::UTADNX::THOR::H1C5962 Texas A&M University THEnet: THOR::H1C5962 College Station, TX 77843-3154 GTEnet: (409)845-9577 Paranoia is our profession. ************************************************************************
jimf@SABER.COM (09/28/90)
| I believe there's a fatal bug in xloadimage.2.0. | | The code compiles fine, but when I look at a series of images with the | "xloadimage -slideshow" command, the 2nd image never gets fully drawn, | my machine (Sun 3/60, xloadimage executing on Sun SS1+) locks up, and | after a couple of minutes, I get kicked out of X completely. | | I never had this problem with xloadimage.1.06 (the latest one I had). A number of people are complaining about this. It is likely to be the result of the technique I use for handling colormap swapping between images. Given that it doesn't affect all servers (ie it doesn't crash mine :-) I suspect there's a bug in the MIT X server that I'm triggering. This will be fixed in the 2.01 patch, I just have to track it down. jim frost saber software jimf@saber.com
jimf@SABER.COM (09/28/90)
|This image will display properly with "getx11" for example. Anyone |have similar problems? This has to do with feof testing that breaks under the new zio. A fix will be in the 2.01 patch. jim frost saber software jimf@saber.com
graeme@labtam.oz (Graeme Gill) (10/01/90)
In article <2666@uc.msc.umn.edu>, wes@uh.msc.umn.edu (Wes Barris) writes: > The latest release of xloadimage (2.0) was said to support URT (.rle) files. > When built and ran it on an IRIS 4D/320 running IRIX 3.3 it produces the > following error message: > > i1.arc.umn.edu> rlebg -s 646 485 -v 0.9 0.1 100 240 150 >junk.rle > i1.arc.umn.edu> xloadimage junk.rle > junk.rle: unknown or unsupported image type > No images to display The Utah rle library support was done on an 80486 system running system VR3/R4 + X11R4. If the IRIS is big endian you might have to go into rle.h and make sure that BIG_ENDIAN is defined and LITTLE_ENDIAN is un-defined. I hope thats all it is. Sorry all this isn't done a bit better, but it was something I hacked together in about a day from the Utah toolkit code. Graeme Gill Labtam I.S.D. Pty. Ltd. graeme@labtam.oz.au
jimf@SABER.COM (10/02/90)
| The Utah rle library support was done on an 80486 system running |system VR3/R4 + X11R4. If the IRIS is big endian you might have to go into |rle.h and make sure that BIG_ENDIAN is defined and LITTLE_ENDIAN is |un-defined. I hope thats all it is. Sorry all this isn't done a bit |better, but it was something I hacked together in about a day from the |Utah toolkit code. I didn't know that or I would have fixed it, sorry. If someone could send me a couple of small rle images I'll have something to test with in the future. If you're feeling up to fixing it, be sure to use of the memToVal and valToMem/valToMemLSB functions to do the conversions portably. If someone sends me the patch I'll include it in the next patchlevel. jim frost saber software jimf@saber.com