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

Text File | 1993-01-11 | 6.7 KB | 126 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: Mon, 11 Jan 1993 09:45:12 GMT
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: triton.cv.ruu.nl
Organization: University of Utrecht, 3D Computer Vision Research Group
Lines: 112

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

|"
|>   [ 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.
|"
|"The programmer using the SDSC Image Tools is free to implement any fill
|"algorithm they choose using the rich set of data structures and data structure
|"access routines and macros provided within the SDSC Image Tools.  We have in
|"no way barred anybody from doing anything they feel like with image data.  We
|"have merely taken many of the most common actions and centralized them into
|"the image library.  If a user doesn't like our fill function, they are free
|"to and encouraged to implement their own.

That's not the point; point was that when code is needed multiple times, the
programmer is able to put the code in a library of his own. In your case you
already made that decision, and made one available.

[ huge executables as a result of having the ability to read or write all
  formats supported. ]

|"Quite true.  There is no perfect solution (that I am aware of).  We have
|"chosen to reduce the amount of tools the user must remember for doing image
|"file format conversion from 87+ to 1.  The increase in binary size is
|"compensated for by a decrease in user hassle.  The priority is placed on the
|"user's needs, rather than the disk drive's.

Which may be a problem, as not everyone has disk space to spare.

|>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.
|"
|"Indeed, the PBMPlus package is one everybody should have.  Jef Poskanzer has
|"done an excellent service to the industry and one we hope he will continue to
|"provide.  There is no such thing as having too many tools.  If one package
|"doesn't satisfy your needs, perhaps another will.  We developed the SDSC
|"Image Tools to satisfy a class of needs that we did not see as being satisfied
|"by other packages out there.  However, in the same vein, PBMPlus satisfies a
|"number of needs the Image Tools do not.  You are free to choose whatever
|"package you wish.  We recommend that you choose both.

I can only do so, when binaries are available for all the machines we have
here; I can run PBMPLUS on all our machines, even our crummy Tektronix XD88.
Besides, what you say here sounds a whole lot more reasonable than the
attitute you had (or rather: displayed) writing your previous comparison.

|"> |"    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.
|"
|"Not true.  Our internal data types do not constrain the type or quantity of
|"data read in from an input file or written out to an output file.  You are
|"free to read more about these data structures by checking out the "imintro"
|"and "tagintro" manual pages in the Image Tools, and libsdsc releases,
|"respectively.  Alternatively, you can read any of the published papers on
|"the tools.

You said that several times. Anyway, it is simply not true: the resulting
image, the image produced after certain operations, the image data written to
disk in a certain format, is limited to the arbitrary limits of the written
image format; I did not say anything about internal formats, of course it is
possible to keep all the information the original format gave you in memory, I
am just saying that the result is still limited by the final format written.

|"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).
|"
|"The hodge-podge nature of the PBMPlus package's support for portability,
|"consistency of user interface, extent of file format support, and completeness
|"of documentation are all fully understandable.  This doesn't make them any
|"less of a problem for the user faced with trying to learn to use the package.

Experience shows that people learn how to use PBMPLUS in virtually no time at
all, once the concept is made clear.

|">Next time, a more objective comparison would be a lot nicer and increase your
|">credibility.
|"
|"You, or anyone else, are certainly encouraged to do so.  Others have.  I
|"would, however, ask that reviwers of the two packages read both the PBMPlus
|"and the SDSC Image Tools documentation and papers first.  This will insure
|"that opinions formed are accurate.

The main reason I wrote my follow-up was that your first posting showed a
remarkable level of holier-than-thou-attitude, including claims that were not
entirely true or to the point. I have seen follow-ups that agree with that
opinion. I am merely saying that in future, your attitude and those on your
staff should be friendly and objective; this will encourage people to use your
package, as currently people may pass on your package because of this.
I haven't used your package yet. Given time, I might try.  Source code
availability for the library would help.
--
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"