madd@world.std.com (jim frost) (02/22/90)
Xloadimage patchlevel 04 is now available. Bug fixes include: * an allocation error in newBitImage that caused some operations (particularly dithers) to fail. * -zoom and -view now work together * -border now works for monochrome displays * -onroot can clean up after previous loads The patch can be had from expo.lcs.mit.edu via anonymous ftp in /contrib/xloadimage.1.04.patch.Z. If you don't have patchlevel 03, it's also available in /contrib/xloadimage.1.03.tar.Z. A quick summary of xloadimage capabilities: Xloadimage is used to either display in a window or load onto the root window images in several common image formats. Currently supported image formats are X10/X11 bitmap, PBM (but not PGM et al yet), Sun Rasterfile (all but 24-bit formats), XPM, and GIF. Images are automatically identified while loading. Xloadimage has several simple image processing functions such as dithering, zooming, clipping, and color depth reduction built-in. What this means to many people is that it can display color images on a monochrome server or deep color images on shallow servers (eg 8 bit images on 4 bit servers), and that you can alter the aspect ratio of an image to match your display. Many of these operations happen automatically if xloadimage detects that your server could not display the image as-is. One question many people ask is "will it run on such-and-such". It has been tested on a very wide range of platforms using some strange servers -- such as ISC 386/ix with 2- and 4-bit servers. Most platforms require no changes to compile. Some platforms require minor changes (such as omission or inclusion of different header files), but these changes are usually very simple. Some future version will support the full range of PGM/etc formats, TIFF, and probably Sun Icon. Anyone who has sample loaders or format descriptions for these or other formats is encouraged to send them to me. Enjoy, jim frost saber software jimf@saber.com
jef@well.sf.ca.us (Jef Poskanzer) (02/22/90)
In the referenced message, madd@world.std.com (jim frost) wrote: }Some future version will support the full range of PGM/etc formats, }TIFF, and probably Sun Icon. Anyone who has sample loaders or format }descriptions for these or other formats is encouraged to send them to }me. Well, the PBMPLUS toolkit contains a whole bunch of "loaders" for different formats, but you probably know that! Jim, could you clarify something for me? I don't think I see the point of making xloadimage understand more than a few representative formats. Am I missing something? Can you explain the logic? I mean, I don't have anything against duplication of effort so long as someone else is doing the duplicating -- I'm just curious as to whether PBMPLUS could be improved somehow. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "We are building a fighting force of extraordinary magnitude. We forge our spirits in the tradition of our ancestors. You have our gratitude." -- Dr. Klahn
mccoy@ils.nwu.edu (Jim McCoy) (02/23/90)
In article <16331@well.sf.ca.us>, jef@well.sf.ca.us (Jef Poskanzer) writes: > In the referenced message, madd@world.std.com (jim frost) wrote: > }Some future version will support the full range of PGM/etc formats, > }TIFF, and probably Sun Icon. Anyone who has sample loaders or format > }descriptions for these or other formats is encouraged to send them to > }me. > > Well, the PBMPLUS toolkit contains a whole bunch of "loaders" for > different formats, but you probably know that! Jim, could you clarify > something for me? I don't think I see the point of making xloadimage > understand more than a few representative formats. Am I missing > something? Can you explain the logic? One thing that has always struck me as strange about the PBMPLUS package (which, I will admit is a marvelous utility) is that there are so many utilities to do each task. Xloadimage will allow me to open files of different format without my having to use xloadimagegif or xloadimagepbm, etc. > I mean, I don't have anything > against duplication of effort so long as someone else is doing the > duplicating While it is probably not my place to say what should be done with packages that I have nothing to do with (other than being a very satisfied user of both), perhaps you two could work together to merge both utilities into a standard image conversion and displaying program? > -- I'm just curious as to whether PBMPLUS could be > improved somehow. Other than perhaps giving people the option of rolling all the little programs into one comprehensive utility, I can't think of anything... jim ------------------------------< Jim McCoy >------------------------------------ mccoy@acns.nwu.edu | "...far too many notes for my taste" #include <disclaimer.h> | -Phantom of the Opera -----------------------<"To thine own self be true">--------------------------
madd@world.std.com (jim frost) (02/23/90)
jef@well.sf.ca.us (Jef Poskanzer) writes: >I don't think I see the point of making xloadimage >understand more than a few representative formats. Merely convenience. When I have time I'll build the loaders for the rest of the PBM+ formats and then things will be less pressing :-). jim frost saber software jimf@saber.com
amanda@mermaid.intercon.com (Amanda Walker) (02/24/90)
In article <4210@accuvax.nwu.edu>, mccoy@ils.nwu.edu (Jim McCoy) writes: > One thing that has always struck me as strange about the PBMPLUS > package (which, I will admit is a marvelous utility) is that there are > so many utilities to do each task. Xloadimage will allow me to open > files of different format without my having to use xloadimagegif or > xloadimagepbm, etc. This is my single favorite thing about xloadimage. PBMPLUS is truly wonderful for manipulating images, but xloadimage lets me take a directory chock full o' images and display any of them, without making me determine in advance what format each one is in, or worry about whether it is compressed or not, or whatever. Software tools are great, but there are times when a Swiss Army knife is useful too :-)... -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
jef@ace.ee.lbl.gov (Jef Poskanzer) (02/25/90)
In the referenced message, amanda@mermaid.intercon.com (Amanda Walker) wrote: } xloadimage lets me take a }directory chock full o' images and display any of them, without making }me determine in advance what format each one is in, or worry about whether }it is compressed or not, or whatever. Software tools are great, but there }are times when a Swiss Army knife is useful too :-)... Actually, I was thinking about making a trivial front-end program that looks at the magic numbers and execs the appropriate XXXtopXm reader, with a zcat thrown in if necessary. How does that grab you? Another possible design would be for the pXm-reading library routines to fork off such a magic-number switch when they don't recognize a file format. Note that this second suggestion, while a more complete solution, is dependent on Unix. I try to avoid putting Unix-specific stuff into PBMPLUS. I am a firm believer in the orthogonal tools approach. When someone tells me that an all-in-one monolithic program is the only solution, I begin to suspect that someone (perhaps me) hasn't been creative enough. Either that, or they're using MS-DOS or a Mac... By the way, one objection to PBMPLUS that I have heard before is that the multitude of executables takes up too much space. Thanks to some hacking by Craig Leres, the next version will optionally produce "merged" binaries - sort of a portable version of shared libraries. Total size for the 81 programs on a Sun3 is 460K. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "If I had known the microphone was on, I would not have taken the Lord's name in vain." -- George Bush
amanda@mermaid.intercon.com (Amanda Walker) (02/27/90)
First, I'd like to disclaim that for anything beyond throwing an image into an X window (or onto the root window), pbmplus is the way to go--much niftiness. In article <4953@helios.ee.lbl.gov>, jef@ace.ee.lbl.gov (Jef Poskanzer) writes: > Another possible design would be for the pXm-reading library routines to fork > off such a magic-number switch when they don't recognize a file format. I like this idea. It would also be nice if the magic-number switcher was driven by a configuration file somewhere, so that one could add formats at will (one of the strengths of pbmplus already). > I am a firm believer in the orthogonal tools approach. When someone > tells me that an all-in-one monolithic program is the only solution, I > begin to suspect that someone (perhaps me) hasn't been creative > enough. Either that, or they're using MS-DOS or a Mac... Well, I do make my living on the Mac, but please note that I didn't say that xloadimage was the only solution, only that it was less hassle for a common application. > the next version will optionally produce "merged" > binaries - sort of a portable version of shared libraries. Total size > for the 81 programs on a Sun3 is 460K. Not bad at all... One other thing I'd like to note is that pbmplus and xloadimage can complement each other quite nicely. Why, just the other day I typed: mtv < scene.nff | mtvtoppm | ppmquant -floyd 256 | ppmtogif >scene.gif xloadimage scene.gif Almost makes me forget my frame buffer's only 8 bits deep... -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
daniel@island.uu.net (Dan Smith "Ivana wanna, Trump chump") (03/01/90)
>In article <4953@helios.ee.lbl.gov>, jef@ace.ee.lbl.gov (Jef Poskanzer) writes: >> Another possible design would be for the pXm-reading library routines to fork >> off such a magic-number switch when they don't recognize a file format. > >I like this idea. It would also be nice if the magic-number switcher was >driven by a configuration file somewhere, so that one could add formats at >will (one of the strengths of pbmplus already). > A quickie solution that would go part of the way is to have a shell script wrapper that would work off of file name extensions: #! /bin/csh -f # # cvt_fmt if ($#argv != 2) then cat << +++ usage: cvt_fmt file fmt_to_convert_to example: "cvt_fmt foo.xbm rast" would give a "foo.rast" file +++ else set source=$1 set dest=$2 ${source:e}topbm $source | pbmto${dest} > ${source:r}.$dest endif add cases for color and graymap and additional seasoning to taste :-) dan -- dansmith@well.sf.ca.us daniel@island.uu.net unicom!daniel@pacbell.com ph: (415) 332 3278 (h), 491 1000 (w) disclaimer: Island's coffee was laced :-)
herald.usask.ca (Ian MacPhedran,2B13 Eng.,4832) (03/01/90)
From article <4210@accuvax.nwu.edu>, by mccoy@ils.nwu.edu (Jim McCoy): > In article <16331@well.sf.ca.us>, jef@well.sf.ca.us (Jef Poskanzer) writes: >> -- I'm just curious as to whether PBMPLUS could be >> improved somehow. > > Other than perhaps giving people the option of rolling all the little > programs into one comprehensive utility, I can't think of anything... > This is straying from the original topic, but... (I'd stay on the original, but I don't have access to the InterNet for ftp access to get the patches to xloadimage ...) A wrapper program could easily be written to take an arbitrary input and output format and convert between them, or use the other utilities in Jef's package. However, rolling all the programs into one would make one huge program, which would carry unnecessary overhead. As well, it may be difficult to automatically determine which input image file type is being used. (Michael Mauldin's FBM package does this for several types, but there are other types with no `magic numbers'.) I am somewhat more on Jef's ``side'' here ... I'd prefer to have a viewer for an ultimate image format, and conversion utlities to get other image types into/outof this format. Unfortunately, no such format exists (in my opinion). Sorry if this is somewhat out of date by the time it gets out. I'm behind in reading this group. Ian. Ian MacPhedran, Engineering Computer Centre, University of Saskatchewan. 2B13 Engineering Building, U. of S. Campus, Saskatoon, Sask., CANADA S7N 0W0 macphed@dvinci.USask.CA macphedran@sask.USask.CA macphedran@sask.BITNET