NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/graphics/visualiz/1973

Text File | 1993-01-07 | 19.8 KB | 388 lines

Newsgroups: comp.graphics.visualization
Path: sparky!uunet!mcsun!sun4nl!ruuinf!prisma.cv.ruu.nl!rvloon
From: [e-mail] (Ronald van Loon)
Subject: Re: SDSC Image Tools and PBM Plus
Originator: [e-mail]
Sender: [e-mail] (Usenet Network)
Message-ID: <[e-mail]>
Date: Thu, 7 Jan 1993 11:55:59 GMT
References: <[e-mail]>
Nntp-Posting-Host: triton.cv.ruu.nl
Organization: University of Utrecht, 3D Computer Vision Research Group
Lines: 374

In <[e-mail]> [e-mail] (Dave Nadeau,,45062) writes:

|"1.  The SDSC Image Tools were designed as a C function library rather than
|"    a set of independent tools, such as the PBMPlus package.  Using a function
|"    library, image manipulation algorithms are encapsulated into generic
|"    functions maintained in a central location.  Tool programmers are able to
|"    quickly write new tools by simply calling library routines.  Tool source
|"    is kept small and succinct.  If bugs are found in the underlying
|"    library's image algorithm, the bug is fixed in one place and all tools
|"    using that routine are relinked.  No tool source modification is required.

PBMPLUS also has libraries that help write new PBMPlus formats; the pbm, pgm,
ppm and pnm libraries.

|"  In a non-library-oriented package, such as PBMPlus, new tools are written
|"  by copying image manipulation code from prior tools.  If the original code
|"  has a bug in it, so does the new tool.  Fixing such a bug requires searching
|"    through all tools looking for copies of the original algorithm, updating
|"    that source, recompiling and relinking.  The hassles of such an approach
|"    are the prime reasons we have function libraries of any kind, such as the
|"    standard C library, the math library, and so on.  One algorithm.  One copy
|"    of the code.  One place to go to fix bugs.

One place - yes, maybe; what happens is that people will go and create copies
of the library, because fixing bugs introduce new ones, and people tend to
stick with what they know rather than trust something new.

[ SDSS: uses library for standard filling operations
  PBM+: has program;

  Programmer supposedly has to clone the code multiple times ]


No. The programmer can take the code from PBMPlus (as source is available) and
create his own library. Difference is that PBMPlus, as it provides source and
an easy to manipulate format, leaves it up to the programmer to use either its
fill function or a programmer supplied one. It is short-sighted to think that
programmers would not be able to do so. The difference with your package is
that you have made the decision on what fill algorithm to use, in other words,
it is you who made the decision to take whatever code and put it in a library,
thus saving the programmer the trouble.

|"2.  All SDSC Image Tools can read and write all of our supported image
|"    file formats.  This is another direct result of encapsulating file format
|"    handling within generic library functions.

[ examples of how to do this deleted ]

It also leads to huge executables, when shared libraries are not available;
even if the program only reads one format ever, it still has the code for all
the other formats in its executable!

|"    With PBMPlus, however, "pbm" tools only read PBM bitmaps, "pgm" tools only
|"    read PGM grayscale images, and "ppm" tools only read PPM RGB images.
|"    Fortunately, a combined set of "pnm" tools have been added that can
|"    read PBM, PGM, or PPM files.  This would be more cool, however, if there
|"    were actually "pnm" tools for all functionality available in the older
|"    "pbm", "pgm", and "ppm" tools.  However, some functionality only exists
|"    in "ppm" but not in "pnm", and so on.

Keep in mind that PBMPlus is volunteer work; Jef Poskanzer has done a great
job of creating portable software - due to the fact that the format is simple,
and easily extendable, a huge amount of conversion tools are available. The
things you mention are, of course, things to be done, but one lives and
learns; what you suggest will sure be included in PBMPlus, someday.

|"    Furthermore, PBMPlus tools that actually do something to images only work
|"    on PBMPlus file formats.  If you want to read any other kind of image, you
|"    first have to convert into one of the PBMPlus formats.  Then if you want
|"    a result in another format, such as for transfer to a Mac or PC, or use
|"    as a texture map in a ray tracer, you have to convert back out of the
|"    PBMPlus formats into what you really wanted in the first place.

That's the general idea - rather than dealing with millions of file formats,
one format that is easy to manipulate is used, thus greatly reducing the
amount of code needed. The beauty of the package is by introducing an
intermediary format suddenly the number of converters can be reduced from NxM
(your case) to N+M. A very basic strategy, which can be found in most
introductory courses on computer architecture and compiler writing.

|"3. Another natural result of developing the SDSC Image Tools as a C function
|"   library is the ease with which image file handling can be added to existing
|"   tools.  Non-SDSC users have built AVS and Explorer modules using the
|"   SDSC Image Tools library, added image handling support to existing tools,
|"   written windowing system user interfaces for the tools, and so on.

Great. The same can be done just as easily for PBMPLUS. I have done so; the
format is so simple, that implementation and use of it is no work at all.

|"    At SDSC, we have implemented a generic lpr-based print filter system that
|"    drives a number of computer graphics output devices from any of the
|"    supported image file formats.  For instance, users of the system can queue
|"    images to be printed to slides on a film recorder using:
|"
|"        vpr -Pslides title.rgb frames*.pix credits{1,2,3,4}.ras
|"
|"   There are no hardcopy device-specific file formats.  There is no need to
|"   convert your SGI RGB image to quirky device protocol streams, then
|"   transfer the file over to the specific host that drives the printer, then
|"   invoke printer-specific software to print your image.  Instead, vpr handles
|"   it all.  Images are transferred via lpr to the remote host that drives
|"   the printer.  The lpr daemon invokes a device-specific print filter that
|"   reads in the images, using the Image Tools library, adjusts image colors
|"   appropriately for the device, again using the Image Tools library, and
|"   scales the image up or down to the device resolution, once again using
|"   the Image Tools library.  The final image is written directly to the
|"   device, with communications protocol handled on the spot.

Nice. This can also be done by PBMPLUS, by having the program/driver convert
to PBMPLUS format upon arrival. No big deal.
|"
|"  This kind of integration of image file format I/O into existing tools is not
|"  possible using the PBMPlus package.  File format code is distributed all
|"  about into multiple PBMPlus tools.  There is no file format function
|"  library.

There is. Check the manual pages pbm(5),pgm(5),ppm(5) and pnm(5). I'll admit
that the documentation could use some work, but hey, what do you expect ? It
is FREE and it has SOURCE.
|"
|"4.  The SDSC Image Tools were designed to support a wide range of image
|"    storage types:  monochrome, grayscale, color indexed (also called
|"    pseudocolor), and RGB (also called truecolor), and images of all these
|"    types that have alpha channels, Z-buffers, and other non-visual pixel
|"    channels.
|"
|"    The PBMPlus tools, however, only support monochrome, grayscale, and RGB
|"    images.  Alpha channels are unsupported and silently stripped from input
|"    files as you convert into the less-functional PBMPlus file formats.  There
|"    is no support whatsoever for color indexed images, such as those used by
|"    non-RGB color graphics displays and most color image file formats.  To
|"    handle a color indexed image, PBMPlus converts it to RGB.  The color table
|"    is applied to the color indexes and then tossed.  The "indexed-ness" of
|"    the original image is lost.  This is unacceptable.

Not really; the original can always be regenerated by functions that are
present in the various p*m-libraries.
|"
|"    Consider a scientific data set that has been rendered by mapping different
|"    data values to different color indexes with no two data values sharing the
|"    same color table index.  Data values between 1 and 10, for instance,
|"    map to color indexes 1 to 10.  The color table is then loaded to
|"    illustrate a data classification scheme.  Color table entries 1-5 are
|"    mapped to red, while 6-10 are mapped to blue, and so on.  By simply
|"    changing the color table the scientist can highlight different data items
|"    to detect patterns and anomalies.
|"
|"    But if you map this color indexed image and its data classification color
|"    table to RGB, all color indexes that are red become permanently mapped to
|"    red in the RGB image.  They can never be reclassified.  Data exploration
|"    is impossible.  The color "indexed-ness" of the source image has been
|"    lost and the scientific usefulness of the image has been reduced.

Not really a good example, IMHO.

|"    If you use PBMPlus, you have no choice because PBMPlus does not support
|"    color indexed images.  The SDSC Image Tools do.

Nice. As you have the source of PBMPLUS, you could define your own extension
to it, then mail your changes to Jef, so the whole world could benefit.

|"    xwdtopnm input.xwd | pnmtoxwd > output.xwd
|"
|"    Format readers parse the input file and drop tags and values into the
|"    tag table.  Format writers scan the tag table for items relevant for the
|"    output format and write them out.  The XWD reader, for instance, reads
|"    in the image window name and drops it into the tag table along with the
|"    image pixels and color table.  The Sun rasterfile RAS writer scans the
|"    tag table for images and color tables and writes them out, but it ignores
|"    the image window name because the RAS format does not support image names.
|"    The XWD writer, on the other hand, does pick out the image name from the
|"    tag table and write it out to the output format.  It all depends upon the
|"    abilities and limitations of the output file format.  The SDSC Image Tools
|"    do not arbitrarily limit image data to those things that fit into an
|"    intermediate file format.

Of course they do; they limit image data to have the arbitrarily limits of the
resulting data-type.

|"6.  The SDSC Image Tools and PBMPlus both support a wide range of image file
|"    formats.  The following is a list of those formats.  The first column is
|"    the source or vendor sponsoring the file format and the second column is
|"    the most common name for the format.  Columns three and four indicate
|"    whether the format has read (R), write (W), or both (RW) support in the
|"    PBMPlus or SDSC Image Tools packages.  A blank in these columns means the
|"    format is not supported in that package.  Formats have been roughly
|"    grouped by the type of image data they can store.
|"
[ list deleted ]
|"
|"    PBMPlus support is strongest for monochrome and grayscale file formats
|"    used on PCs, Ataris, Macs, and other low-end systems.  PBMPlus also
|"    focuses on smaller software packages (like QRT and MTV), games and
|"    cute programs (like PUZZ, and FS), and printer device protocol files
|"    (like PTX and EPSON).
|"
|"    The SDSC Image Tools instead concentrate on high-end systems and high-end
|"    color formats, such as Alias PIX, Wavefront RLA, Khoros VIFF, NCSA HDF,
|"    Sun TAAC IFF, PIXAR PIC, AVS X, and SGI RGB.  These file formats dominate
|"    the high-end workstation graphics world and are those we found ourselves
|"    most in need of during scientific visualization and animation work.
|"    PBMPlus supports none of these.

I am sorry; PBMPlus does not need to support these - those packages support
PBMPlus! By taking an attitude of 'we don't need these low-end formats anyway'
you first of all are arrogant - let the user decide what he wants if possible,
not you ! - and second of all, it is easy to write additional converters for
PBMPLUS (you have done so yourself).
|"
|"    PBMPlus image file format support is also strangely sparse.  Some formats
|"    can only be read, but not written.  Other formats can only be written,
|"    but not read.

This is due to the nature things get contributed to PBMPLUS: different people
all over the world have contributed to the package. Some of the stuff is well
written, others less so. PBMPLUS is not actively supported by people who get
paid to do so.

|"    The SDSC Image Tools support read and write handlers for all supported
|"    file formats, except PostScript and EPS.  These formats are written
|"    but not read.  To read PostScript or EPS files properly requires the
|"    implementation of a full PostScript interpreter and is well beyond
|"    the scope of this project.

Besides, it already exists in the form of GhostScript.
|"
|"7.  Image file format conversion in the PBMPlus package is done with a
|"    collection of ** 87 ** separate tools!  To read a Sun Rasterfile, use
|"    "rasttopbm" or "rasttoppm" or "rasttopnm".  To write it back out again,
|"    use "pbmtorast" or "ppmtorast" or "pnmtorast".  That's 6 tools for just
|"    one file format.

Nope. That's 6 *functions* for *3* formats - those formats you mention are not
the same. You have to do something similar to put those in a library.

|"    The prime tool for image file format conversion in the SDSC Image Tools
|"    is "imconv", which supports all 30+ formats within 1 tool, not 87.

The size of which is considerably more than the 87 tools together. Remember,
it is not size or quantity - it is quality!

|"8.  The SDSC Image Tools are implemented atop a binary I/O package that
|"    portably handles reading and writing binary data to files, streams, and
|"    data arrays.  Such a package is absolutely necessary in order to handle
|"    differences in byte order, word size, floating point format, and structure
|"    padding.  The use of such a binary I/O package has allowed us to port the
|"    Image Tools, without any change of higher-level code, to a dozen
|"    architectures, including Suns, SGIs, DEC hosts, and even our Cray Y-MP.
|"
|"    The PBMPlus package is not implemented with portability in mind.  There
|"    are numerous instances within the code where byte order or word size
|"    is assumed.  Such code will not work on a Cray, for instance.

The PBMPlus package did have portability in mind - the p*m-libraries allow you
to read and write binary data in a portable way. The people who contributed to
PBMPLUS may have chosen to not use those. That's unfortunate.
|"
|"9.  The SDSC Image Tools were designed to have a consistent and intuitive user
|"    interface.  All tools have -help arguments to display on-line help
|"    information distilled from the full man pages.  Argument parsing is
|"    consistent throughout the package.

Argument parsing can be done consistently in PBMPLUS, the facilities are
there; again, people chose to use their own when contributing, rather than
using the provide facilities. It's a matter of attitude: people who use your
library are not in any way restricted to use the routines you provide, are
they ?

|"   PBMPlus tools, however, use a mish-mash of command-line argument styles and
|"   virtually never have on-line help.  Man pages are sparse and almost never
|"   include usage examples.  The following, for instance, is the entire
|"   PBMPlus man page for the "icontopbm" converter for the Sun icon file format:

A non example. As said, you have the means and manpower to write this
documentation and are probably even *required* to do so. PBMPLUS is volunteer
work. A free, spare-time kind of project. Invest dollars and it will improve.

|"  The SDSC Image Tools man page on the Sun icon format takes three pages.

I am not impressed.

|"And so on.  There are significant differences between the SDSC Image Tools
|"and the PBMPlus package.  Let us return to the net posting that sparked this
|"discussion:
|"
|"    >Don't forget pbmplus *is* available in source code and does 99 percent
|"    >of what imconv does (and often does it faster!).  It's available with
|"    >the X11 distribution in the contrib directory or from your favorite
|"    >FTP site (wuarchive.uwstl.edu comes to mind).
|"
|"-  PBMPlus clearly does *not* do 99% of what the SDSC Image Tools do.

Ah, a matter of pride :-).
|"
|"-  PBMPlus is not faster.  It couldn't be.  To do anything in it you first
|"   have to convert your image file to one of the PBMPlus file formats.  Then,
|"   after doing your task, you have to convert back out again into the format
|"   you really want your result in.  At a minimum this requires two extra file
|"   reads and two extra file writes.

No. Ever heard of pipes ? After all, we are talking high-end machines here!
|"
|"   For example, to rotate an 8-bit Sun Rasterfile by 45 degrees, you must do
|"   the following operations in PBMPlus:
|"
|"    rasttopnm file.ras > file.pnm        -- RAS to PNM
|"    pnmrotate 45.0 file.pnm > rfile.pnm    -- Rotate by 45
|"    ppmquant 256 rfile.pnm > r256file.pnm    -- Reduce to 256 colors
|"    pnmtorast r256file.pnm > rfile.ras    -- PNM to RAS

this of course is:

rasttopnm file.ras | pnmrotate 45.0 | ppmquant 256 | pnmtorast >rfile.ras

Where are the intermediate files ? I don't see any...

|"   The "ppmquant" is necessary because the rotated image will have more than
|"   256 colors (an artifact of the rotation algorithm).  Calling "pnmtorast"
|"   on an image with more than 256 colors generates an RGB RAS file, not an
|"   8-bit RAS file suitable for display on a SPARCstation.  So, if we want an
|"   8-bit RAS file, we first have to quantize the image back down to 256 colors.

No, you should use Xloadimage instead.
|
"
|"   This same task may be accomplished using the SDSC Image Tools:
|"
|"    imrotate file.ras -rot 45.0 -outindex rfile.ras
|"
|"   These operations were timed using an 8-bit 512x480 Sun Rasterfile of the
|"   standard Mandrill.  File I/O was to and from local disk on a Sun
|"   SPARCstation 2.
|"
|"            Execution Times (in seconds)
|"            Real    User    Sys
|"            ----    ----    ---
|"    PBMPlus        95.9    90.7    3.0
|"    Image Tools    11.5    10.7    0.5
|"
|"   On this operation, the SDSC Image Tools accomplished the task 8.3 times
|"   faster than PBMPlus.

Apples and Oranges.

|"
|"- Version 2.1 of the SDSC Image Tools are available via anonymous ftp from
|"   "ftp.sdsc.edu".  Tool source code is included.  Library source code is not.
|"
|"- Version 2.1 of the SDSC Utilities library, including the binary I/O package,
|"  argument parsing package, and tag table package are also available via
|"  anonymous ftp from "ftp.sdsc.edu".  Library source code is not included.
|"
|"Thank you.

Reading your article, you apparently feel the need to 'defend' yourself
against PBMPLUS, either because you feel your package is not so great after
all, or for some other reason. Furthermore, you make a number of claims in a
condescending, ivory tower sort of way (by using phrases like 'high-end
systems', 'PBMPLUS can't do this, while', 'even our CRAY-1'). You should
consider yourself lucky to work on a package and get paid (I suppose you get
paid). Comparing PBMPLUS and SDSS is not really useful: PBMPLUS is freely
available, widely used, easy to extend. No need to learn how to do it, it's
that simple! PBMPLUS utilities in our group are widely used, noone ever
complained that features were missing.

Next time, a more objective comparison would be a lot nicer and increase your
credibility.

Regards,
--
Ronald van Loon     | Consider this: In the United States, an automobile is
([e-mail])  | stolen EVERY 14.7 SECONDS.
3DCV Group, Utrecht |   If that statistic scares you, think how we felt when we
The Netherlands     | made it up. - Dave Barry, "CHRISTMAS BUYERS GUIDE"