summaryrefslogtreecommitdiffstats
path: root/upstream/opensuse-leap-15-6/man1/pamscale.1
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-15 19:43:11 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-15 19:43:11 +0000
commitfc22b3d6507c6745911b9dfcc68f1e665ae13dbc (patch)
treece1e3bce06471410239a6f41282e328770aa404a /upstream/opensuse-leap-15-6/man1/pamscale.1
parentInitial commit. (diff)
downloadmanpages-l10n-fc22b3d6507c6745911b9dfcc68f1e665ae13dbc.tar.xz
manpages-l10n-fc22b3d6507c6745911b9dfcc68f1e665ae13dbc.zip
Adding upstream version 4.22.0.upstream/4.22.0
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'upstream/opensuse-leap-15-6/man1/pamscale.1')
-rw-r--r--upstream/opensuse-leap-15-6/man1/pamscale.1620
1 files changed, 620 insertions, 0 deletions
diff --git a/upstream/opensuse-leap-15-6/man1/pamscale.1 b/upstream/opensuse-leap-15-6/man1/pamscale.1
new file mode 100644
index 00000000..008e617a
--- /dev/null
+++ b/upstream/opensuse-leap-15-6/man1/pamscale.1
@@ -0,0 +1,620 @@
+\
+.\" This man page was generated by the Netpbm tool 'makeman' from HTML source.
+.\" Do not hand-hack it! If you have bug fixes or improvements, please find
+.\" the corresponding HTML page on the Netpbm website, generate a patch
+.\" against that, and send it to the Netpbm maintainer.
+.TH "Pamscale User Manual" 0 "29 December 2009" "netpbm documentation"
+
+.SH NAME
+
+pamscale - scale a Netpbm image
+
+.UN synopsis
+.SH SYNOPSIS
+
+.nf
+ \fBpamscale\fP
+ [
+ \fIscale_factor\fP
+ |
+ {\fB-xyfit\fP | \fB-xyfill\fP | \fB-xysize\fP} \fIcols\fP \fIrows\fP
+ |
+ \fB-reduce\fP \fIreduction_factor\fP
+ |
+ [\fB-xsize=\fP\fIcols\fP | \fB-width=\fP\fIcols\fP | \fB-xscale=\fP\fIfactor\fP]
+ [\fB-ysize=\fP\fIrows\fP | \fB-height=\fP\fIrows\fP | \fB-yscale=\fP\fIfactor\fP]
+ |
+ \fB-pixels\fP \fIn\fP
+ ]
+ [
+ [\fB-verbose\fP]
+ [
+ \fB-nomix\fP
+ |
+ \fB-filter=\fP\fIfunctionName\fP [\fB-window=\fPfunctionName]
+ ]
+ [\fB-linear\fP]
+ }
+ [\fIpnmfile\fP]
+
+.fi
+.PP
+Minimum unique abbreviation of option is acceptable. You may use
+double hyphens instead of single hyphen to denote options. You may use
+white space in place of the equals sign to separate an option name
+from its value.
+
+.UN description
+.SH DESCRIPTION
+.PP
+This program is part of
+.BR "Netpbm" (1)\c
+\&.
+.PP
+\fBpamscale\fP scales a Netpbm image by a specified factor, or
+scales individually horizontally and vertically by specified factors.
+.PP
+You can either enlarge (scale factor > 1) or reduce (scale factor
+< 1).
+.PP
+\fBpamscale\fP work on multi-image streams, scaling each one independently.
+But before Netpbm 10.49 (December 2009), it scales only the first image and
+ignores the rest of the stream.
+
+.UN scalefactor
+.SS The Scale Factors
+.PP
+The options \fB-width\fP, \fB-height\fP, \fB-xsize\fP, \fB-ysize\fP,
+\fB-xscale\fP, \fB-yscale\fP, \fB-xyfit\fP, \fB-xyfill\fP, \fB-reduce\fP,
+and \fB-pixels\fP control the amount of scaling. For backward compatibility,
+there is also \fB-xysize\fP and the \fIscale_factor\fP argument, but you
+shouldn't use those.
+.PP
+\fB-width\fP and \fB-height\fP specify the width and height in pixels
+you want the resulting image to be. See below for rules when you specify
+one and not the other.
+.PP
+\fB-xsize\fP and \fB-ysize\fP are synonyms for \fB-width\fP and
+\fB-height\fP, respectively.
+.PP
+\fB-xscale\fP and \fB-yscale\fP tell the factor by which you want the
+width and height of the image to change from source to result (e.g.
+\fB-xscale 2\fP means you want to double the width; \fB-xscale .5\fP
+means you want to halve it). See below for rules when you specify one and
+not the other.
+.PP
+When you specify an absolute size or scale factor for both
+dimensions, \fBpamscale\fP scales each dimension independently
+without consideration of the aspect ratio.
+.PP
+If you specify one dimension as a pixel size and don't specify the
+other dimension, \fBpamscale\fP scales the unspecified dimension to
+preserve the aspect ratio.
+.PP
+If you specify one dimension as a scale factor and don't specify
+the other dimension, \fBpamscale\fP leaves the unspecified dimension
+unchanged from the input.
+.PP
+If you specify the \fIscale_factor\fP parameter instead of
+dimension options, that is the scale factor for both dimensions. It
+is equivalent to \fB-xscale=\fP\fIscale_factor\fP\fB
+-yscale=\fP\fIscale_factor\fP.
+.PP
+Specifying the \fB-reduce\fP \fIreduction_factor\fP option is
+equivalent to specifying the \fIscale_factor \fP parameter, where
+\fIscale_factor\fP is the reciprocal of \fIreduction_factor\fP.
+.PP
+\fB-xyfit\fP specifies a bounding box. \fBpamscale\fP scales
+the input image to the largest size that fits within the box, while
+preserving its aspect ratio. \fB-xysize\fP is a synonym for this.
+Before Netpbm 10.20 (January 2004), \fB-xyfit\fP did not exist, but
+\fB-xysize\fP did.
+.PP
+\fB-xyfill\fP is similar, but \fBpamscale\fP scales the input image
+to the smallest size that completely fills the box, while preserving
+its aspect ratio. This option has existed since Netpbm 10.20 (January
+2004).
+.PP
+\fB-pixels\fP specifies a maximum total number of output pixels.
+\fBpamscale\fP scales the image down to that number of pixels. If
+the input image is already no more than that many pixels,
+\fBpamscale\fP just copies it as output; \fBpamscale\fP does not
+scale up with \fB-pixels\fP.
+.PP
+If you enlarge by a factor of 3 or more, you should probably add a
+\fIpnmsmooth\fP step; otherwise, you can see the original pixels in
+the resulting image.
+
+
+.UN usage
+.SS Usage Notes
+.PP
+A useful application of \fBpamscale\fP is to blur an image. Scale
+it down (without \fB-nomix\fP) to discard some information, then
+scale it back up using \fBpamstretch\fP.
+.PP
+Or scale it back up with \fBpamscale\fP and create a
+"pixelized" image, which is sort of a computer-age version
+of blurring.
+
+
+.UN transparency
+.SS Transparency
+.PP
+\fBpamscale\fP understands transparency and properly mixes pixels
+considering the pixels' transparency.
+.PP
+Proper mixing \fIdoes not\fP mean just mixing the transparency
+value and the color component values separately. In a PAM image, a
+pixel which is not opaque represents a color that contains light of
+the foreground color indicated explicitly in the PAM and light of a
+background color to be named later. But the numerical scale of a
+color component sample in a PAM is as if the pixel is opaque. So a
+pixel that is supposed to contain half-strength red light for the
+foreground plus some light from the background has a red color sample
+that says \fIfull\fP red and a transparency sample that says 50%
+opaque. In order to mix pixels, you have to first convert the color
+sample values to numbers that represent amount of light directly
+(i.e. multiply by the opaqueness) and after mixing, convert back
+(divide by the opaqueness).
+
+.UN imagetype
+.SS Input And Output Image Types
+.PP
+\fBpamscale\fP produces output of the same type (and tuple type if
+the type is PAM) as the input, except if the input is PBM. In that
+case, the output is PGM with maxval 255. The purpose of this is to
+allow meaningful pixel mixing. Note that there is no equivalent
+exception when the input is PAM. If the PAM input tuple type is
+BLACKANDWHITE, the PAM output tuple type is also BLACKANDWHITE, and
+you get no meaningful pixel mixing.
+.PP
+If you want PBM output with PBM input, use \fBpamditherbw\fP to
+convert \fBpamscale\fP's output to PBM. Also consider
+\fBpbmreduce\fP.
+.PP
+\fBpamscale\fP's function is essentially undefined for PAM input
+images that are not of tuple type RGB, GRAYSCALE, BLACKANDWHITE, or
+the _ALPHA variations of those. (By standard Netpbm backward compatibility,
+this includes PBM, PGM, and PPM images).
+.PP
+You might think it would have an obvious effect on other tuple
+types, but remember that the aforementioned tuple types have
+gamma-adjusted sample values, and \fBpamscale\fP uses that fact in
+its calculations. And it treats a transparency plane different from any
+other plane.
+.PP
+\fBpamscale\fP does not simply reject unrecognized tuple types
+because there's a possibility that just by coincidence you can get
+useful function out of it with some other tuple type and the right
+combination of options (consider \fB-linear\fP in particular).
+
+
+.UN methods
+.SS Methods Of Scaling
+.PP
+There are numerous ways to scale an image. \fBpamscale\fP implements
+a bunch of them; you select among them with invocation options.
+
+.UN mixing
+.B Pixel Mixing
+.PP
+Pamscale's default method is pixel mixing. To understand this, imagine the
+source image as composed of square tiles. Each tile is a pixel and has
+uniform color. The tiles are all the same size. Now take a transparent sheet
+the size of the target image, marked with a square grid of tiles the same
+size. Stretch or compress the source image to the size of the sheet and lay
+the sheet over the source.
+.PP
+Each cell in the overlay grid stands for a pixel of the target
+image. For example, if you are scaling a 100x200 image up by 1.5, the
+source image is 100 x 200 tiles, and the transparent sheet is marked
+off in 150 x 300 cells.
+.PP
+Each cell covers parts of multiple tiles. To make the target image,
+just color in each cell with the color which is the average of the colors
+the cell covers -- weighted by the amount of that color it covers. A
+cell in our example might cover 4/9 of a blue tile, 2/9 of a red tile,
+2/9 of a green tile, and 1/9 of a white tile. So the target pixel
+would be somewhat unsaturated blue.
+.PP
+When you are scaling up or down by an integer, the results are
+simple. When scaling up, pixels get duplicated. When scaling down,
+pixels get thrown away. In either case, the colors in the target
+image are a subset of those in the source image.
+.PP
+When the scale factor is weirder than that, the target image can
+have colors that didn't exist in the original. For example, a red
+pixel next to a white pixel in the source might become a red pixel,
+a pink pixel, and a white pixel in the target.
+.PP
+This method tends to replicate what the human eye does as it moves
+closer to or further away from an image. It also tends to replicate
+what the human eye sees, when far enough away to make the pixelization
+disappear, if an image is not made of pixels and simply stretches
+or shrinks.
+
+.UN sampling
+.B Discrete Sampling
+.PP
+Discrete sampling is basically the same thing as pixel mixing except
+that, in the model described above, instead of averaging the colors of
+the tiles the cell covers, you pick the one color that covers the most
+area.
+.PP
+The result you see is that when you enlarge an image, pixels
+get duplicated and when you reduce an image, some pixels get discarded.
+.PP
+The advantage of this is that you end up with an image made from the
+same color palette as the original. Sometimes that's important.
+.PP
+The disadvantage is that it distorts the picture. If you scale up
+by 1.5 horizontally, for example, the even numbered input pixels are
+doubled in the output and the odd numbered ones are copied singly. If
+you have a bunch of one pixel wide lines in the source, you may find
+that some of them stretch to 2 pixels, others remain 1 pixel when you
+enlarge. When you reduce, you may find that some of the lines
+disappear completely.
+.PP
+You select discrete sampling with \fBpamscale\fP's \fB-nomix\fP
+option.
+.PP
+Actually, \fB-nomix\fP doesn't do exactly what I described above.
+It does the scaling in two passes - first horizontal, then vertical.
+This can produce slightly different results.
+.PP
+There is one common case in which one often finds it burdensome to
+have \fBpamscale\fP make up colors that weren't there originally:
+Where one is working with an image format such as GIF that has a
+limited number of possible colors per image. If you take a GIF with
+256 colors, convert it to PPM, scale by .625, and convert back to GIF,
+you will probably find that the reduced image has way more than 256
+colors, and therefore cannot be converted to GIF. One way to solve
+this problem is to do the reduction with discrete sampling instead of
+pixel mixing. Probably a better way is to do the pixel mixing, but
+then color quantize the result with \fBpnmquant\fP before converting
+to GIF.
+.PP
+When the scale factor is an integer (which means you're scaling
+up), discrete sampling and pixel mixing are identical -- output pixels
+are always just N copies of the input pixels. In this case, though,
+consider using \fBpamstretch\fP instead of \fBpamscale\fP to get the
+added pixels interpolated instead of just copied and thereby get a
+smoother enlargement.
+.PP
+\fBpamscale\fP's discrete sampling is faster than pixel mixing,
+but \fBpamenlarge\fP is faster still. \fBpamenlarge\fP works only
+on integer enlargements.
+.PP
+discrete sampling (\fB-nomix\fP) was new in Netpbm 9.24 (January
+2002).
+
+
+.UN resampling
+.B Resampling
+.PP
+Resampling assumes that the source image is a discrete sampling of some
+original continuous image. That is, it assumes there is some non-pixelized
+original image and each pixel of the source image is simply the color of
+that image at a particular point. Those points, naturally, are the
+intersections of a square grid.
+.PP
+The idea of resampling is just to compute that original image, then
+sample it at a different frequency (a grid of a different scale).
+.PP
+The problem, of course, is that sampling necessarily throws away the
+information you need to rebuild the original image. So we have to make
+a bunch of assumptions about the makeup of the original image.
+.PP
+You tell \fBpamscale\fP to use the resampling method by specifying
+the \fB-filter\fP option. The value of this option is the name of a
+function, from the set listed below.
+.PP
+\fBTo explain resampling, we are going to talk about a simple
+one dimensional scaling\fP -- scaling a single row of grayscale
+pixels horizontally. If you can understand that, you can easily
+understand how to do a whole image: Scale each of the rows of the
+image, then scale each of the resulting columns. And scale each of the
+color component planes separately.
+.PP
+As a first step in resampling, \fBpamscale\fP converts the source
+image, which is a set of discrete pixel values, into a continuous step
+function. A step function is a function whose graph is a staircase-y
+thing.
+.PP
+Now, we convolve the step function with a proper scaling of the
+filter function that you identified with \fB-filter\fP. If you don't
+know what the mathematical concept of convolution (convolving) is, you
+are officially lost. You cannot understand this explanation. The
+result of this convolution is the imaginary original continuous image
+we've been talking about.
+.PP
+Finally, we make target pixels by picking values from that function.
+.PP
+To understand what is going on, we use Fourier analysis:
+.PP
+The idea is that the only difference between our step function and
+the original continuous function (remember that we constructed the
+step function from the source image, which is itself a sampling of the
+original continuous function) is that the step function has a bunch of
+high frequency Fourier components added. If we could chop out all the
+higher frequency components of the step function, and know that
+they're all higher than any frequency in the original function, we'd
+have the original function back.
+.PP
+The resampling method \fIassumes\fP that the original function
+was sampled at a high enough frequency to form a perfect sampling. A
+perfect sampling is one from which you can recover exactly the
+original continuous function. The Nyquist theorem says that as long
+as your sample rate is at least twice the highest frequency in your
+original function, the sampling is perfect. So we \fIassume\fP
+that the image is a sampling of something whose highest frequency is
+half the sample rate (pixel resolution) or less. Given that, our
+filtering does in fact recover the original continuous image from the
+samples (pixels).
+.PP
+To chop out all the components above a certain frequency, we just
+multiply the Fourier transform of the step function by a rectangle
+function.
+.PP
+We could find the Fourier transform of the step function, multiply
+it by a rectangle function, and then Fourier transform the result
+back, but there's an easier way. Mathematicians tell us that
+multiplying in the frequency domain is equivalent to convolving in the
+time domain. That means multiplying the Fourier transform of F by a
+rectangle function R is the same as convolving F with the Fourier
+transform of R. It's a lot better to take the Fourier transform of
+R, and build it into \fBpamscale\fP than to have \fBpamscale\fP
+take the Fourier transform of the input image dynamically.
+.PP
+That leaves only one question: What \fIis\fP the Fourier
+transform of a rectangle function? Answer: sinc. Recall from
+math that sinc is defined as sinc(x) = sin(PI*x)/PI*x.
+.PP
+Hence, when you specify \fB-filter=sinc\fP, you are effectively
+passing the step function of the source image through a low pass
+frequency filter and recovering a good approximation of the original
+continuous image.
+
+.B Refiltering
+.PP
+There's another twist: If you simply sample the reconstructed
+original continuous image at the new sample rate, and that new sample
+rate isn't at least twice the highest frequency in the original
+continuous image, you won't get a perfect sampling. In fact, you'll
+get something with ugly aliasing in it. Note that this can't be a
+problem when you're scaling up (increasing the sample rate), because
+the fact that the old sample rate was above the Nyquist level means so
+is the new one. But when scaling down, it's a problem. Obviously,
+you have to give up image quality when scaling down, but aliasing is
+not the best way to do it. It's better just to remove high frequency
+components from the original continuous image before sampling, and
+then get a perfect sampling of that.
+.PP
+Therefore, \fBpamscale\fP filters out frequencies above half the
+new sample rate before picking the new samples.
+
+.B Approximations
+.PP
+Unfortunately, \fBpamscale\fP doesn't do the convolution
+precisely. Instead of evaluating the filter function at every point,
+it samples it -- assumes that it doesn't change any more often than
+the step function does. \fBpamscale\fP could actually do the true
+integration fairly easily. Since the filter functions are built into
+the program, the integrals of them could be too. Maybe someday it
+will.
+.PP
+There is one more complication with the Fourier analysis. sinc
+has nonzero values on out to infinity and minus infinity. That makes
+it hard to compute a convolution with it. So instead, there are
+filter functions that approximate sinc but are nonzero only within a
+manageable range. To get those, you multiply the sinc function by a
+\fIwindow function\fP, which you select with the \fB-window\fP
+option. The same holds for other filter functions that go on forever
+like sinc. By default, for a filter that needs a window function,
+the window function is the Blackman function.
+
+.B Filter Functions Besides Sinc
+.PP
+The math described above works only with sinc as the filter
+function. \fBpamscale\fP offers many other filter functions, though.
+Some of these approximate sinc and are faster to compute. For most of
+them, I have no idea of the mathematical explanation for them, but
+people do find they give pleasing results. They may not be based on
+resampling at all, but just exploit the convolution that is
+coincidentally part of a resampling calculation.
+.PP
+For some filter functions, you can tell just by looking at the
+convolution how they vary the resampling process from the perfect one
+based on sinc:
+.PP
+The impulse filter assumes that the original continuous image is in
+fact a step function -- the very one we computed as the first step in
+the resampling. This is mathematically equivalent to the discrete
+sampling method.
+.PP
+The box (rectangle) filter assumes the original image is a
+piecewise linear function. Its graph just looks like straight lines
+connecting the pixel values. This is mathematically equivalent to the
+pixel mixing method (but mixing brightness, not light intensity, so
+like \fBpamscale -linear\fP) when scaling down, and interpolation
+(ala \fBpamstretch\fP) when scaling up.
+
+.B Gamma
+.PP
+\fBpamscale\fP assumes the underlying continuous function is a
+function of brightness (as opposed to light intensity), and therefore
+does all this math using the gamma-adjusted numbers found in a PNM or
+PAM image. The \fB-linear\fP option is not available with resampling
+(it causes \fBpamscale\fP to fail), because it wouldn't be useful enough
+to justify the implementation effort.
+.PP
+Resampling (\fB-filter\fP) was new in Netpbm 10.20 (January 2004).
+
+.B The filter functions
+.PP
+Here is a list of the function names you can specify for the
+\fB-filter\fP option. For most of them, you're on your own to figure
+out just what the function is and what kind of scaling it does. These
+are common functions from mathematics.
+
+
+.TP
+point
+The graph of this is a single point at X=0, Y=1.
+
+.TP
+box
+The graph of this is a rectangle sitting on the X axis and centered
+on the Y axis with height 1 and base 1.
+
+.TP
+triangle
+The graph of this is an isosceles triangle sitting on the X axis
+and centered on the Y axis with height 1 and base 2.
+
+.TP
+quadratic
+.TP
+cubic
+.TP
+catrom
+.TP
+mitchell
+.TP
+gauss
+.TP
+sinc
+.TP
+bessel
+.TP
+hanning
+.TP
+hamming
+.TP
+blackman
+.TP
+kaiser
+.TP
+normal
+.TP
+hermite
+.TP
+lanczos
+Not documented
+
+
+
+.UN linear
+.SS Linear vs Gamma-adjusted
+.PP
+The pixel mixing scaling method described above involves intensities
+of pixels (more precisely, it involves individual intensities of
+primary color components of pixels). But the PNM and PNM-equivalent
+PAM image formats represent intensities with gamma-adjusted numbers
+that are not linearly proportional to intensity. So \fBpamscale\fP,
+by default, performs a calculation on each sample read from its input
+and each sample written to its output to convert between these
+gamma-adjusted numbers and internal intensity-proportional numbers.
+.PP
+Sometimes you are not working with true PNM or PAM images, but
+rather a variation in which the sample values are in fact directly
+proportional to intensity. If so, use the \fB-linear\fP option to
+tell \fBpamscale\fP this. \fBpamscale\fP then will skip the
+conversions.
+.PP
+The conversion takes time. In one experiment, it increased by a factor of
+10 the time required to reduce an image. And the difference between
+intensity-proportional values and gamma-adjusted values may be small enough
+that you would barely see a difference in the result if you just pretended
+that the gamma-adjusted values were in fact intensity-proportional. So just
+to save time, at the expense of some image quality, you can specify
+\fB-linear\fP even when you have true PPM input and expect true PPM output.
+.PP
+For the first 13 years of Netpbm's life, until Netpbm 10.20
+(January 2004), \fBpamscale\fP's predecessor \fBpnmscale\fP always
+treated the PPM samples as intensity-proportional even though they
+were not, and drew few complaints. So using \fB-linear\fP as a lie
+is a reasonable thing to do if speed is important to you. But if
+speed is important, you also should consider the \fB-nomix\fP option
+and \fBpnmscalefixed\fP.
+.PP
+Another technique to consider is to convert your PNM image to the
+linear variation with \fBpnmgamma\fP, run \fBpamscale\fP on it and
+other transformations that like linear PNM, and then convert it back
+to true PNM with \fBpnmgamma -ungamma\fP. \fBpnmgamma\fP is often
+faster than \fBpamscale\fP in doing the conversion.
+.PP
+With \fB-nomix\fP, \fB-linear\fP has no effect. That's because
+\fBpamscale\fP does not concern itself with the meaning of the sample
+values in this method; \fBpamscale\fP just copies numbers from its
+input to its output.
+
+
+.UN precision
+.SS Precision
+.PP
+\fBpamscale\fP uses floating point arithmetic internally. There
+is a speed cost associated with this. For some images, you can get
+the acceptable results (in fact, sometimes identical results) faster
+with \fBpnmscalefixed\fP, which uses fixed point arithmetic.
+\fBpnmscalefixed\fP may, however, distort your image a little. See
+the \fBpnmscalefixed\fP user manual for a complete discussion of the
+difference.
+
+.UN seealso
+.SH SEE ALSO
+.BR "pnmscalefixed" (1)\c
+\&,
+.BR "pamstretch" (1)\c
+\&,
+.BR "pamditherbw" (1)\c
+\&,
+.BR "pbmreduce" (1)\c
+\&,
+.BR "pbmpscale" (1)\c
+\&,
+.BR "pamenlarge" (1)\c
+\&,
+.BR "pnmsmooth" (1)\c
+\&,
+.BR "pamcut" (1)\c
+\&,
+.BR "pnmgamma" (1)\c
+\&,
+.BR "pnmscale" (1)\c
+\&,
+.BR "pnm" (5)\c
+\&,
+.BR "pam" (5)\c
+\&
+
+.UN history
+.SH HISTORY
+.PP
+\fBpamscale\fP was new in Netpbm 10.20 (January 2004). It was
+adapted from, and obsoleted, \fBpnmscale\fP. \fBpamscale\fP's
+primary difference from \fBpnmscale\fP is that it handles the PAM
+format and uses the "pam" facilities of the Netpbm programming
+library. But it also added the resampling class of scaling method.
+Furthermore, it properly does its pixel mixing arithmetic (by default)
+using intensity-proportional values instead of the gamma-adjusted
+values the \fBpnmscale\fP uses. To get the old \fBpnmscale\fP
+arithmetic, you can specify the \fB-linear\fP option.
+.PP
+The intensity proportional stuff came out of suggestions by \fIAdam M Costello\fP in January
+2004.
+.PP
+The resampling algorithms are mostly taken from code contributed by
+\fIMichael Reinelt\fP in December 2003.
+.PP
+The version of \fBpnmscale\fP from which \fBpamscale\fP was
+derived, itself evolved out of the original Pbmplus version of
+\fBpnmscale\fP by Jef Poskanzer (1989, 1991). But none of that
+original code remains.
+.SH DOCUMENT SOURCE
+This manual page was generated by the Netpbm tool 'makeman' from HTML
+source. The master documentation is at
+.IP
+.B http://netpbm.sourceforge.net/doc/pamscale.html
+.PP \ No newline at end of file