© 1998 by mjh
elcome to the Graphics Muse! Why a « muse »? Well, except for the sisters aspect, the above definitions are pretty much the way I’d describe my own interest in computer graphics: it keeps me deep in thought and it is a daily source of inspiration.
his column is dedicated to the use, creation, distribution, and discussion of computer graphics tools for Linux systems. Well, there were quite a few announcements in the past month and I’m finding that not all are being cross posted to both comp.os.linux.announce and to freshmeat.net. It takes a little more diligence on my part to catch all the announcments, but since I visit both places fairly often it really isn’t that big of a problem. On the other hand, is it really necessary to repeat those announcements here? I thought about this for a while, and finally decided it is worth the effort since both c.o.l.a and freshmeat are sites for general announcements and the graphics-specific items can easily be overlooked. By gathering them up and reprinting them here, I can let my readers worry less about missing the important stuff through the sea of other announcements at other sites.
I’ve finally started to catch up on my Musings, too. This month’s issue includes discussions on:
- Managing your CGI Perl scripts using « require » in Web Wonderings
- A closer look at the libgr package of image file format libraries
- A little fun with the Gimp plugin « QBist »
I also considered taking a look at Blender, but I’m not certain my system is stable enough for that right now. It’s been acting a little strange of late – I’m beginning to think some recent power outages may have corrupted some libraries. I have plans to upgrade to Red Hat 5.2 whenever it comes out (I expect the difficulties with dealing with libc/glibc will all be worked out, much like the 4.2 release had worked out most of the a.out vs. ELF issues), plus take a look at Xi Graphics Maximum CDE at some point too. But I hadn’t planned on doing either until the October time frame. I may have to change my plans.
Anyway, a review of Blender is a definite future Musing. The last time I tried it, the program seemed to be stable, but the interface is rather complex. A general examination showed that this modeller is quite feature-rich. It’s just that the interface is not intuitive to a 3D newbie, perhaps not even to an experienced 3D graphic artist. A better set of documentation is reported to be on the way, due out some time in September. I’ll wait and see what this might offer before stepping up for a review of Blender.
You can also keep an eye out for a new and improved Graphics Muse Web site coming soon. I expect to be able to launch the new site sometime in the middle to end of September. It will combine the Linux Graphics mini-Howto with the Unix Graphics Utilities into a single searchable database, provide recommended reading material and allow you to post reviews of software, hardware and texts, plus it will provide more timely news related to computer graphics for Linux systems. And, of course, all the back issues of the Graphics Muse column from the Linux Gazette will be there too, in a semi-searchable format with topics for each month provided next to the links to each month’s issue. I’ll probably post an announcement about it to c.o.l.a when it’s ready.
Disclaimer: Before I get too far into this I should note that any of the news items I post in this section are just that – news. Either I happened to run across them via some mailing list I was on, via some Usenet newsgroup, or via email from someone. I’m not necessarily endorsing these products (some of which may be commercial), I’m just letting you know I’d heard about them in the past month.
|ParPov is a free (GNU), object-oriented library written in C++ for parsing Scene Files from the Persistence of Vision (POV-Ray) Ray-Tracer. It will read a scene written using version 1-3 syntax and creates a structure of C++-Objects, representing all details of the original description. You can query those objects and use the information to convert the scene to other formats or many other uses. Pov2Rib is also a freely available progam, which allows you to convert scene files from POV-Ray to a RenderMan Interface Bytestream (RIB). The tool is the first application of libParPov.
http://www9.informatik. uni-erlangen.de/ ~cnvogelg/pov2rib/index.html
GQview is an X11 image viewer for the Linux operating system. Its key features include single click file viewing, external editor support, thumbnail preview, thumbnail caching and adjustable zoom. GQview is currently available in source, binary, and rpm versions and requires the latest GTK and Imlib libraries.
|TKMatman is a tool that lets you interactively set and adjust parameters to RenderMan shaders and preview images with the given parameters. It can handle surface, displacement, interior, exterior, atmosphere, light and imager shaders and their combinations. The idea for the program comes from Sam Samai, who wrote the very useful IRIX version. With the availability of the Blue Moon Rendering Tools for different platforms the author of TkMatman thought that a lot more people will use the RenderMan interface and need ways to select their shaders. That’s why he published his private LINUX version of MatMan. The program was initially only meant for his own use, but it is in a pretty stable state now. All feedback is appreciated and new versions will be made available at the following site:
ImPress allows you to create good quality documents using vector graphics. You can use ImPress within a web browser with the Tcl/Tk plugin. It’s a reasonable desktop publishing and presentation tool in a small package designed for Linux and for integration with Ghostscript.
The GPL’d .03alpha release fixes many bugs and adds better web and presentation functionality.
|Slidedraw is a drawing program in Tcl/tk for presentation slides with postscript output and full-featured. You can see snapshots, get slide collections or the very latest package available from it’s new web page.
Beta testers are welcome. Contributors for slide collections and documentations are also invited.
MindsEye is a project to develop a free (in terms of the GPL) available 3D modelling program for Linux. It features modular design, Multi-scene/user concept, Kernel-system view instead of Modeler-system view, Object oriented modelling design and network support in a MindsEye-kernel way.
S.u.S.E. announces XFCom_P9x00 and new version of XFCom_3DLabs
It took a while, but finally a free server for Weitek P9100 based cards is available. XFCom_P9100 is not yet accelerated and has not received as much testing as we would have liked it to, but it should work fine on most P9100 boards.
With this version of XFCom_3DLabs, several problems with earlier versions should be solved. New features and fixes include:
- Permedia 2v support
- Permedia 2 AGP hangs fixed
- 24bpp mode improved
- many drawing bugs removed
- DPMS support added
You can find both servers (and the rest of the XFCom-family) at our web site http://www.suse.de/XSuSE/XSuSE_E.html
As always, these servers are freely available, the sources to these servers are already part of the XFree86 development source. Binaries for other OSs will be made available, time permitting.
XSuse Matrox Millenium G200 support
Suse appears to have also added support for the Matrox Millennium G200 AGP to their Matrox X server. No official announcement has been seen, but word of this development first appeared to ‘Muse’s eyes via Slashdot.org.
The driver is available from ftp://ftp.suse.com/pub/suse_update/XSuSE/xmatrox/.
The Visual Computer Journal
Special Issue on Real-time Virtual Worlds
Submissions due: October 31, 1998
Real-time Virtual Worlds are now possible on most workstations and PCs. The challenge is to design user-friendly systems for creating new applications and tools. This special issue of the Visual Computer is dedicated to new algorithms, methods, and systems in Real-time Virtual Worlds. Original, unpublished research, practice, and experience papers are sought that address issues in all aspects of Real-time Virtual Worlds. Topics include, but are not limited to:
- Modeling for Real-time Virtual Worlds
- Real-time animation
- Real-time rendering algorithms
- Real-time motion control and motion capture
- Real-time talking heads
- Intelligent interfaces for real-time computer animation
- Avatars and Real-time Autonomous Virtual Humans
- 3D interaction with Virtual Worlds
- Networked Virtual Environments
- Artificial Life in Virtual Worlds
- Virtual Worlds on the Web
- Real-time audio and speech for Virtual Worlds
- Real-time simulation
- Games and entertainment applications
|Paper Submission:||October 31, 1998|
|Acceptance/Rejection Notification:||January 15, 1999|
|Final Manuscript Submissions:||February 15, 1999|
The editors for this issue of the Visual Computer are:
Nadia Magnenat-Thalmann Associate Editor-in-Chief MIRALab, University of Geneva
Daniel Thalmann Computer Graphics Lab EPFL
Submission guidelines: Authors may submit their paper either as an HTML URL or by ftp. For ftp, the electronic version of your manuscript should be submitted in PDF (preferred) or Postscript (compressed with gzip) using anonymous ftp to ligsg2.epfl.ch. The paper should be submitted as one file. The file name should be first author’s name. Please follow the procedure:
- ftp ligsg2.epfl.ch
In any case, you should send an email to email@example.com with the title of the paper, the authors with affiliation, the contact author, and either the URL or the filename used for ftp. For author guidelines, please consult: http://www.computer.org/multimedia/edguide.htm
KIllustrator is a freely available vector-based drawing application for the K Desktop Environment similiar to Corel Draw(tm) or Adobe Illustrator(tm).
- different object types: polylines, circles, ellipses, squares, rectangles, (symmetric) polygons, freehand lines, bezier curves and multiline text
- tools for moving, scaling, rotating as well as grouping, ungrouping, aligning, distributing and reordering objects
- various line styles and arrows
- a multilevel undo/redo facility
- a property editor
- multi-window support with cut/copy/paste between the windows
- zooming and snapping to grid
- multilevel undo/redo
- (network-transparent) drop support with the KDE filemanager
- printing to PostScript (file or printer)
- preliminary WMF support
- export to raster image formats (GIF, PNG, XPM) and Encapsulated Postscript
- import of Xfig files
The installation requires a working KDE 1.0, QT 1.40 as well as gcc-2.8.1 or egc-1.03. KIllustrator is tested on Linux, FreeBSD and Solaris.
For further information (screenshots, download) please consult my homepage at:
Please, for question, comments, bug reports or contributions e-mail me at firstname.lastname@example.org.
RenderPark is a photo-realistic rendering tool being developed at the Computer Graphics Research Group of the Katholieke Universiteit Leuven, in Belgium. The goal is to offer a solid implementation of many existing photo-realistic rendering algorithms in order to compare them on a fair basis, evaluate benefits and shortcomings, find solutions for the latter and to develop new algorithms that are more robust and efficient than the algorithms that are available today. RenderPark will offer you several state-of-the-art rendering algorithms that are not yet present in other rendering packages, not even in expensive ones. Allthough RenderPark is in the first place a test-bed for rendering algorithms, it is evolving towards a full-featured physics-based global illumination rendering system.
Did You Know?
- …there are two True Type®font servers based on the FreeTypepackage: xfsftand xfstt. The latter is reported to have some problems with fonts over 90 pixels high and appears to go into « memory starved mode » after extensive use of the Text tool in the Gimp. Aside from these issues, however, both are reported to be fairly stable servers.
…The computer magazine PC Chip will be publishing an interview with Ton Roosendaal, owner of Not a Number which is the company bringing us the 3D modeller Blender. This interview has been placed online so readers can get an early glimpse at it.
Q and A
Q: Is there a way to include carriage returns with the text tool, or to align phrases created with individual uses of the text tool?
A: I didn’t know the answer to this one, but found the following answer on the Gimp-User mailing list (unfortunately I didn’t get the responder’s name – my apologies to that person):
Try the « Script-fu –> Utils –> ASCII 2 Image Layer » command. This allows you to import a text file as one or more layers of text.
Note that this Script is available either from the Image Window menu’s Script-Fu option or from the Xtns menu’s Script-Fu option.
Q: Mark Lenigan (email@example.com) wrote to the Gimp User mailing list:
I’m trying to create a transparent GIF with a drop shadow for the title graphic on my Web page. I’m pretty much following the cookbook from www.gimp.org/tutorials, except that I’m not including the background color layer and using « Merge Visible Layers » to keep the final image transparent. Everything goes fine until I need to convert the image to an indexed image just before I save it in the .gif format file. At that point the shadow in my image immediately disappears and the text seems to lose its anti-aliasing. Can anyone shed some light on to this?
A: Simon Budig responded:
Yes. Gimp can only handle 1-bit transparency in indexed color mode. So when you convert an image to indexed the different levels of transparency will get lost. There is the great « Filters/Colors/Semiflatten » plugin. It merges all partially transparent regions against the current Backgroundcolor. Select a BG-Color (i.e. matching to the BG-Color of your Web-page) and watch the effect of the plugin. Then you can convert your Image to Indexed and save it as GIF. (GIF can also handle just 1-bit transparency).
- I’d like to hear more technical details of the internals of Gimp, and comparing Gimp to photoshop – eg. Photoshop 5 is now out with multiple undo – undo history list, even.
‘Muse: Unfortunately, I can’t do this sort of comparison. I don’t run anything but Unix boxes (specifically Linux) at home and don’t have access to any Photoshop packages. I might be able to do the comparison based on Photoshop texts, but that’s the best I could do.
- Also modelling tools. Gimp is 2D. Where is 3D? Pov-Ray can render, but is there anything to compare with say Lightwave, or 3D-StudioMax?
‘Muse: There are no real competitors to Lightwave or 3D-StudioMax for Linux. There are quite a few modellers available, each with different levels of sophistication. But none that compares to the sophistication of either of the two tools you mention. You can find a list of modellers in my June 1997 Graphics Muse column. Not all of the links in that issue are still valid. Some of the modellers seem to have disappeared and some have changed URLs. You can try a search using the package name through freshmeat.net if the links in the June 1997 issue don’t work for you.
One modeller that was not listed in that issue but that looks quite interesting is Blender, which is a commercial package that has only recently been released for free (no source code) to Linux users. I hope to do a review of it soon. However, the last version I tried was not documented sufficiently to allow me to understand how to do even the most basic tasks. The interface is complex and feature rich, but not intuitive to 3D newbies. ‘Muse: I’ll see what I can do about this. One tool to consider is PVMPOV, a patch to POV-Ray to allow for distributed rendering across multiple systems on a network. PVM is the Parallel Virtual Machine, a package for distributed processing used on many Unix systems. You should probably note that this is a patch to POV-Ray, so you’ll need to understand how to apply patches to source code in order to use it.
- Just some things I’d be delighted to read about. Cheers,
‘Muse: Again, thanks for the ideas. I’ll see what I can do.
Managing your Perl scripts: using ‘require’
Last month we talked about accessing an mSQL database from CGI scripts using Perl with two modules: CGI.pm and Msql. In the example described there, we built a couple of HTML tables and embedded some text stored in a table in an mSQL database. It turns out that generating HTML using CGI.pm is quite simple, and using Perl with the Msql module makes combining your HTML output with information from a database really rather painless.
But that example was extremely simple. Real world examples often have dynamic pages that are built from multiple databases. And each page often links to other dynamically built pages that provide some, or even all, of the same information from those databases. In other words, parts of each page contain the same HTML formatting and data. How can you avoid having to duplicate that HTML in each page?
With older static page development methods, there really weren’t any methods for including common regions into multiple pages unless you used frames. The frames allowed you to create a region on the browser display that would be a single page of HTML that could be displayed along with various other pages. In this way, you need only maintain a single copy of that one common page. From a Web developer’s point of view, this was an ideal situation – it meant the probability of error in trying to update identical HTML in multiple pages was eliminated. It also meant less work. But to readers of those pages it could mean frustration, since not all browsers at the time supported frames. Even now, frame handling is not consistant between the two main browsers, Netscape Navigator and Microsoft’s Internet Explorer. Although frames can be used to produce some terrific Web pages, they are not the ideal solution for supporting different browsers, especially older browsers.
Fortunately, this problem can be overcome with our new friend Perl. The method for inclusion in multiple pages of common formats and data is simple. However, the management of these common regions takes a little thought. Let’s first look at how to include Perl code from different files in your main Perl script.
In Perl, a subroutine or other piece of common code would be written in a module, a separate file of Perl code. Modules can be included at any point within a Perl script. By default, Perl looks at a special variable called @INC to determine where to find these modules. Also by default, the current working directly, « . », is listed in the @INC variable as the last directory to search for modules. Note: @INC is a list variable, that is, it is an array of strings with each string being the name of a directory to search for modules.
To include a module into your main Perl cgi script you would use the require function. The format is simple: This function tells the Perl interpreter to include the named module, but only if it has not been included previously. In this way you can include the same module multiple times without worry that doing so will cause serious problems.
When the module is included, the code within it is run at the point of inclusion. You can, if you so desire, write the module to have code that runs right then and there using variables with a global scope (i.e., they are visible to the original program as well as the included module). However, it would probably make more sense to write the module as a subroutine call instead. You can still use globally scoped variables, but by making the module a subroutine call, you can guarantee the code is not run until you specifically request it. You can also run it more than one time if you want.
So how do you make a subroutine? Just wrap the code inside the following construct: The 1 at the end is important – modules must include this or else the require function will fail. Now invoke the subroutine with the following command: The ampersand is important – you should always prefix calls to your subroutines with the ampersand. Although things may work properly if you don’t, proper Perl syntax suggests the results can be unexpected if you don’t use the ampersand.
If you want to pass parameters into the subroutine, you can do so as a list. For example:
- &subname(« one item »);
&subname(« one item », « two items »);
To access the command line arguments in the subroutine, you can do something like the following:
- sub subname
# @_ contains all parameters to the subroutine.
# We first assign these to the @params variable because the variable
# name « @params » is a bit more intuitive than « @_ ».
@params = @_;
foreach $arg (@params)
# now run through each parameter one at a time
# and process it.
if ( « $arg » eq « » )
|Many users of graphics tools discussed in this column will find that those tools are dependent on any number of file format specific libraries. For example, the Gimp needs libraries for JPEG, PNG, PNM, MPEG and XPM in order to support these file formats. The Gimp doesn’t understand how to read these files directly – it is dependent on the image format libraries for assistance in reading and writing files in these formats. Since the Gimp (and other tools) don’t include these libraries in their source distributions, users are often required to retrieve and install these libraries manually.
Normally, users would download format-specific libraries and build them separately. Each of the formats mentioned earlier, plus a few others, are available somewhere on the Net in source format. Most are available somewhere on the Sunsite archives. Unfortunately, not all of these format specific libraries are easily built on Linux. The Gimp User Mailing list is often flooded with questions about how to get the JPEG library to build shared libraries. By default this library doesn’t build a Linux ELF shared library. In fact, even with the proper configuration it still only builds a.out shared libraries. A better solution is needed.
Enter libgr. This is a collection of image format libraries that have been packaged together and organized to easily build and install on Linux systems. The package builds both static and ELF shared libraries automatically. The distribution is maintained by Neal Becker (firstname.lastname@example.org) and is based on the work done originally by Rob Hooft (hooft@EMBL-Heidelberg.DE). The latest version, 2.0.13, of libgr can be retrieved from ftp.ctd.comsat.com:/pub/linux/ELF.
Libgr contains the following set of graphics libraries:
It also contains the zlib compression library which is used specifically by the TIFF and PNG graphics libraries. It may also, although I’m not sure of this, be used by the FBM library to (at a minimum) support the GIF format.
FBM is the Fuzzy Pixmap Manipulation library. This package is related to, but not part of, the PBMPlus package by Jef Poskazner. The library can read and write a number of formats, including:
It also supports quite a number of image operations, all of which are described in the Features text file in the fbm directory. Like PBM, FBM is a format designed specifically by the FBM library author for handling images internal to the library (although you can write that format to a file too).
JPEG is actually a standard that defines a suite of encodings for full-color and continuous-tone raster images1. The software for this library, which is essentially the same as the software that comes in the standalone JPEG library package found on the Gimp’s ftp site, comes from the Independent JPEG Group and, as far as I can tell, supports the complete JPEG definition. JPEG is a common format for the Web since it is one of the formats listed by the WC3 in the early HTML specifications for Web images.
The PBM, PGM, PNM, and PPM formats are all part of the NetPBM/PBMPlus packages. These formats are often used as intermediary formats for processing by the NetPBM/PBMPlus tools. Although these libraries provide the capability of saving image files in these formats, I have not seen this as a common practice. This is probably due to the fact that the files tend to be rather large and the image formats are not generally supported by non-Unix platforms. These formats are widely supported, however, by Unix-based graphics software.
The PNG library supports the relatively new Portable Network Graphics format. This format was designed, at least in part, to replace the GIF format which had both licensing as well as a few format limitations. PNG is now an officially supported format by the WC3 although support for these images is not commonly mentioned by either Netscape or MSIE. I’m not sure if either supports PNG yet.
RLE is Run Length Encoding, a format from the University of Utah designed for device independent multilevel raster images. Although the format is still in use today, you won’t see it referenced often in relation to tools like the Gimp (though the Gimp does support the format) or 3D rendering engines like BMRT or POV-Ray.
-Top of next column-
|Finally, the TIFF library is a set of routines for supporting the reading and writing of TIFF files. TIFF files are popular because of their wide support on multiple platforms (Mac, MS, and Unix) and because of their high quality images. However, they tend to be extremely large images since they do not use any form of compression on the image data. Once you have retrieved the libgr package you can unpack it with the following command:
This will create a directory called libgr-2.0.13. Under this directory you will find the format specific directories, Makefiles and a number of text files. In the INSTALL text file you will find instructions on how to build the software. For Linux this is a simple process of typing which will build all the software but not install it. I recommend doing this once to test that the build actually completes successfully for all directories before trying to install anything. If the build fails and you attempt to install you may confuse yourself as to what has and hasn’t been installed correctly. After the build completes, check each directory and see if the lib*.so files – the shared libraries – have been created. If all appears to have gone well, type This will install the libraries for you. There are other options available for building and installing. Read the INSTALL text file in the top level directory for details on the other options.
At this point you’re ready to use these libraries with other tools, such as the Gimp.
Why use libgr vs the individual libraries?
Libgr provides support for a large range of image file formats, but it doesn’t support every common and/or popular format. So why use it instead of the individual format libraries? One reason is convenience. Instead of having to retrieve a whole slew of packages you can grab one. Second, as mentioned earlier, not all of the individual packages are setup to build proper ELF shared libraries for Linux. Libgr is specifically designed for building these type of libraries.
What libraries does libgr not include that you might want? One fairly common X Windows format is XPM. Libgr does not support this format so you’ll need to retrieve the XPM library separately. Fortunately, most Linux distributions already come with this library prebuilt and available to you during installation of the operating system.
Libgr also does not support any animation file formats. If you have need to read or write files in MPEG, FLI or FLC formats, for example, you will need to locate and install those libraries individually.
One minor caveat to using the libgr package exists with the zlib distribution. According to the documentation for libgr (in the NEWS text file) the zlib release numbers went down at some point. This means it’s possible for you to have an older version of zlib installed even though its version number is higher than the one in libgr. How to resolve this is a tricky question but in my opinion it makes sense to install the zlib that comes with libgr because it’s known to work with the rest of the image libraries in the libgr package. If you agree with this logic then you will probably want to remove the old version of zlib first, before doing the make install for libgr.
Libgr is not a drop-in replacement for all your image file format needs, but it does offer added convenience to the Linux users by providing a Linux-specific, easy to use build and install environment. Since the libraries included in the libgr package do not change all that often it makes good system management sense to deal with the one distribution than to try to deal with updates to multiple image format packages. And if you’re dealing with building the Gimp, which requires many image libraries, libgr is a much simpler solution to get you up and running in the least amount of time and with the least amount of frustration.
1. C. Wayne Brown and Barry J. Shepherd, Graphics File Formats: Reference and Guide, Prentice Hall/Manning, 1995.
The following links are just starting points for finding more information about computer graphics and multimedia in general for Linux systems. If you have some application specific information for me, I’ll add them to my other pages or you can contact the maintainer of some other web site. I’ll consider adding other general references here, but application or site specific information needs to go into one of the following general references and not listed here.
Let me know what you’d like to hear about!
© 1998 Michael J. Hammel
Graphics Muse #1, November 1996
Graphics Muse #2, December 1996
Graphics Muse #3, January 1997
Graphics Muse #4, February 1997
Graphics Muse #5, March 1997
Graphics Muse #6, April 1997
Graphics Muse #7, May 1997
Graphics Muse #8, June 1997
Graphics Muse #9, July 1997
Graphics Muse #10, August 1997
Graphics Muse #11, October 1997
Graphics Muse #12, December 1997
Graphics Muse #13, February 1998
Graphics Muse #14, March 1998
Graphics Muse #15, April 1998
Graphics Muse #16, August 1998