PAMTOGIF(1)

💖 pamtogif — the Pamtogif User Manual(1) 💖

okay bestie, gather round, because we're about to turn a Netpbm image into a GIF and honestly? iconic behavior.

---

✨ NAME ✨

pamtogif — convert a Netpbm image to a GIF image 🎀

---

🌸 SYNOPSIS 🌸

pamtogif

[-interlace]

[-sort]

[-mapfile=mapfile] [-transparent=[=]color]

[-alphacolor=color]

[-comment=text]

[-noclear]

[-nolzw]

[-aspect=fraction]

[-verbose] [netpbmfile]

okay so quick housekeeping before we dive in: every single option can be abbreviated to its shortest unique prefix. you can also use two hyphens instead of one if that's your vibe, and you can put either white space or an equals sign between an option name and its value. flexible queen behavior fr fr. 💅

---

🦋 DESCRIPTION 🦋

this program is part of Netpbm(1). 🤝

pamtogif reads a Netpbm image as input and produces a GIF file as output. that's the whole job. she does it, she does it well.

heads up bestie: this program creates only individual GIF images. if you wanna combine multiple GIF images into an animated GIF, you gotta use gifsicle — and no, that is not part of the Netpbm package. different girl, different house. 🏠

---

🎀 GIF87 vs GIF89 — the format tea ☕

pamtogif creates either an original GIF87 format GIF file, or the newer GIF89 format.

it creates GIF89 when the output needs to have features that were new with GIF89, to wit: transparency or comments. otherwise? it creates GIF87. periodt.

really old GIF readers conceivably could not recognize GIF89, so this matters, ngl. 😭

the output needs to have transparency when either the input has a transparency information or you specify the -transparent option. and it needs to have comments when you specify the -comment option. simple as that. ✨

---

🌈 the 256 color limit (yes, really)

pamtogif generates a GIF image with a single image block, which means the image cannot have more than 256 colors in it (it contains a single color map with a maximum size of 256).

if the image you want to convert has more colors than that — and ppmhist can tell you, she's the gossip — you can use pnmquant to reduce it to 256. or, if you're feeling fancy, use the more complex but faster method described under the -mapfile option. 💅

---

🫶 transparency info, explained

if your input image is a PAM with transparency information, pamtogif uses one entry in the GIF colormap specifically for the transparent pixels, so you can have at most 255 opaque colors. 😭

in contrast, if you use the -transparent option, one of the colors from the input becomes transparent, so the limit is still 256. slay, math.

pamtogif recognizes transparency information in the input by the tuple type being RGB_ALPHA, GRAYSCALE_ALPHA, or BLACKANDWHITE_ALPHA. this is the case for any image that has transparency information and was created by a Netpbm program that manipulates visual images. 👑

if, on the other hand, you have a PAM generated some other way, but you know the planes have the same meaning as implied by these tuple types, you can make pamtogif process the transparency information by changing the tuple type accordingly before you pass it to pamtogif. you can use pamstack to change the tuple type. main character problem-solving energy. 🧚

---

🗓️ the lore

pamtogif was new in Netpbm 10.37 (December 2006). in older Netpbm, use ppmtogif. that's the ancestry, bestie. 🎀

---

✨ OPTIONS ✨

okay so on top of the options that literally every libnetpbm-based program shares (most famously -quiet — go look at Common Options for the full rundown), pamtogif also knows these bad boys:

• -interlace — produces an interlaced GIF file. that's the whole thing 💅
• -sort — produces a GIF file with a color map sorted in a predictable order.

heads up bestie, this is not the sorted color map that's actually part of the GIF format itself. that other kind of sorted color map is the one where colors get ordered by how important they are, and the GIF header tells the viewer "yeah it's sorted like that." its whole purpose is letting the viewer get away with using fewer colors than the color map actually holds, for when it can't display all of them.

what this option gives you instead is a color map sorted by red value, then green, then blue. super useful when you're analyzing GIF images, especially ones made by two versions of the program, because it strips out some of the variability. 🦋

• -mapfile=mapfile — use the colors found in the file mapfile to build the colormap in the GIF file, instead of the colors from netpbmfile. mapfile can be any PPM file; literally the only thing that matters is the colors inside it. if the colors in netpbmfile don't match the ones in mapfile, pamtogif matches them to a "best match." you can get a much better result by running pnmremap to change the colors in the input to the ones in the map file. ✨

the mapfile file is not a palette file bestie — it's just an image whose colors you want to use. the order of colors in the GIF palette has nothing to do with where they appear in the mapfile image, and duplicate colors in the image are irrelevant. 🎀

the map file's depth has to match the number of color components in the input (and psst, that's not necessarily the same as the input's depth — the input might have a transparency plane on top of everything else). if your map file doesn't match, or might not match, run your input through pnmremap using that same map file so it does. 😭

you can use -mapfile to speed up conversion of an image where you already have a map file from earlier processing. for example, it's super common to start with an image that has more than 256 colors and remap its colors down to a set of 256 so that pamgtogif can convert it (a GIF can only hold 256 colors — and pamtogif without -mapfile fails on any image that has more than that) using pnmquant. when you do this, pnmquant generates a palette for the color quantization, and then pamtogif generates an identical palette from the quantized image. so you can save computation by generating the palette just once:

$ pnmcolormap 256 myimage.ppm >/tmp/colormap.ppm
$ pamtogif myimage.ppm -mapfile=/tmp/colormap.ppm >output.gif

• -transparent=color — pamtogif marks the color you name as transparent in the GIF image. 👻

if you don't specify -transparent, pamtogif doesn't mark any color transparent (except as indicated by the transparency information already in the input file).

specify the color (color) the way it's described for the argument of the pnm_parsecolor() library routine.

if the color you specify isn't present in the image, pamtogif instead picks the color in the image that's closest to the one you named. closeness = a Cartesian distance between colors in RGB space. if multiple colors are equidistant, pamtogif just chooses one of them arbitrarily. shrug 🙈

however, if you prefix your color spec with "=", like -transparent==red, then only the exact color you specify will be transparent. if that color doesn't show up in the image, there will be no transparency at all. pamtogif issues an information message when that happens.

when you specify -transparent, pamtogif ignores any explicit transparency info (the "alpha channel") in the input image. 💀

• -alphacolor=color — this specifies the foreground color for transparent pixels. a viewer might use that foreground color for a transparent pixel if it chooses not to let another color "show through." the default is black. ⭐

this only applies to pixels that are transparent in the GIF because they're transparent in the Netpbm input. if a GIF pixel is transparent because of the -transparent option, then the foreground color is whatever color that option indicated.

ngl, in GIF all transparent pixels share the same foreground color (there's only one single entry in the GIF colormap for transparent pixels). 💜

specify the color (color) the way it's described for the argument of the pnm_parsecolor() library routine.

• -comment=text — include a comment in the GIF output, with the comment text text. 🎀

without this option, there are no comments in the output, periodt.

heads up: in a command shell you'll have to put quotation marks around text if it contains characters (like a space) that would make the shell think it's multiple arguments:

$ pamtogif -comment "this is a comment" <xxx.ppm >xxx.gif

• -noclear — causes the output to contain no GIF clear codes. 🔥

okay so context: in GIF, the stream defines codes that represent strings of pixels as it goes along. the stream has definitions of codes mixed in with the references to those codes that describe the image's pixels. GIF specifies a maximum number of codes that can be defined; once the stream has defined that many, it can either just keep using those for the rest of the image, or include a clear code — which deletes all the string codes so the stream can start over defining new ones. 🌈

by far the most common choice is the clear code. this usually makes a smaller stream, because the set of pixel strings that occur in an image varies across different parts of the image. hardly any GIF encoders produce streams that skip the clear code.

but it is conceivable that a stream could be smaller without the clear code, since it saves the stream having to redefine the same string codes over and over. it could even dodge a thrashing situation where the stream keeps defining a set of strings that never get used again before the maximum is reached. 👑

the default is to use the clear codes.

this option was new in Netpbm 10.82 (March 2018). before that, the program always used the clear codes.

• -nolzw — this one is mainly of historical interest, because it involves use of a patent that's now expired. 💀

this option causes the GIF output (and therefore pamtogif) not to use LZW (Lempel-Ziv) compression. the result: the image file is bigger, and back before the patent expired, no royalties would be owed to the patent holder on LZW. peep the LICENSE section below.

LZW is a method for combining the information from multiple pixels into a single GIF code. with the -nolzw option, pamtogif creates one GIF code per pixel, so it's doing no compression at all and not using LZW. but any GIF decoder — whether it uses an LZW decompressor or not — will correctly decode this uncompressed format. an LZW decompressor would just see it as a particular case of LZW compression.

lowkey important: if someone uses an LZW decompressor (like the one in giftopnm, or pretty much any graphics display program) to process the output of pamtogif -nolzw, then they're using the LZW patent. but the patent holder expressed far less interest in enforcing the patent on decoding than on encoding. 🙈

• -aspect=fraction — this is the aspect ratio of the image's pixels. its only effect is to record that info in the GIF for whatever ends up interpreting the GIF. note that this GIF feature is hardly ever used, and most GIF decoders just ignore this info and assume pixels are square. 🫶

pixels in a Netpbm image don't have aspect ratios; there's always a one-one correspondence between GIF pixels and Netpbm pixels.

the aspect ratio is the quotient of width divided by height. GIF allows aspect ratios from 0.25 (1:4) to 4 (4:1) in increments of 1/64. pamtogif implements a natural extension of GIF that allows an aspect ratio up to 4 14/64. if you specify anything outside this range, pamtogif fails. pamtogif rounds the fraction to the nearest 1/64. ✨

the default is square (1.0).

this option was new in Netpbm 10.38 (March 2007). before that, the pixels were always square.

• -verbose — causes pamtogif to display information about the conversion process and about the image it produces. 👀

---

👀 SEE ALSO 👀

giftopnm(1), pnmremap(1), ppmtogif(1),

gifsicle http://www.lcdf.org/gifsicle , pnm(1), pam(1). 🌸

✨ HISTORY ✨

okay so gather round bestie, because pamtogif has lore 💖

pamtogif was new in Netpbm 10.37 (December 2006). It replaced ppmtogif, which had been out here creating GIF images for Pbmplus/Netpbm users since 1989. iconic behavior, honestly 👑

The main outward change in the conversion from ppmtogif to pamtogif was that pamtogif was able to use transparency information ("alpha channel") in PAM input, whereas with ppmtogif, one had to supply the transparency mask in a separate pseudo-PGM image (via the -alpha option). glow-up fr fr ✨

Jef Poskanzer wrote ppmtogif in 1989, and it has always been a cornerstone of Pbmplus/Netpbm because GIF is such a popular image format. Jef based the LZW encoding on GIFENCOD by David Rowley <mgardi@watdcsu.waterloo.edu>. Jef included GIFENCOD's GIFCOMPR.C file pretty much whole. Rowley, in turn, adapted the LZW compression code from classic Unix compress, which used techniques described in IEEE Computer, June 1984. the way this is basically a family tree of code 😭💀

Jef's ppmtogif notably lacked the ability to use a transparency mask with it. You could create transparent pixels in a GIF, but only with the -transparent option, which allowed one to specify that all pixels of a certain color in the input were to be transparent. Bryan Henderson added the -alpha option in July 2001 so you could supply a mask image that indicates exactly which pixels are to be transparent, and those pixels could have the same color as other opaque ones. periodt 💅

Bryan Henderson added another significant piece of code and function in October 2001: the ability to generate a GIF without using the LZW patent -- an uncompressed GIF. This was very important to many people at the time because the GIF patent was still in force, and this allowed them to make an image that any GIF viewer could display, royalty-free. Bryan adapted code from the Independent JPEG Group's djpeg for that. that's actually so real of him 🫶

There is no code in pamtogif from Jef's original, but Jef may still hold copyright over it because of the way in which it evolved. Virtually all of the code in pamtogif was written by Bryan Henderson and contributed to the public domain. public domain queen 🌈

---

🎀 LICENSE 🎀

If you use pamtogif without the -nolzw option, you are using a patent on the LZW compression method which is owned by Unisys. The patent has expired (in 2003 in the US and in 2004 elsewhere), so it doesn't matter. While the patent was in force, most people who used pamtogif and similar programs did so without a license from Unisys to do so. Unisys typically asked $5000 for a license for trivial use of the patent. Unisys never enforced the patent against trivial users. damn, the drama 💀

Rumor has it that IBM also owns or owned a patent covering pamtogif. 👀

A replacement for the GIF format that never required any patents to use is the PNG format. PNG stays winning, no cap 💖

---

📚 DOCUMENT SOURCE 📚

This manual page was generated by the Netpbm tool 'makeman' from HTML source. The master documentation is at

http://netpbm.sourceforge.net/doc/pamtogif.html

---

and that's the whole vibe, bestie 🦋 this was netpbm documentation, dated 09 June 2021 — the Pamtogif User Manual(1) — so go forth and make GIFs, you absolute main character 👑💖