{ "content": [ { "type": "text", "text": "# pnmtojpeg (man)\n\n## NAME\n\npnmtojpeg - convert PNM image to a JFIF (\"JPEG\") image\n\n## SYNOPSIS\n\npnmtojpeg [-exif=filespec] [-quality=n] [{-grayscale|-greyscale}] [-density=nxn[dpi,dpcm]]\n[-optimize|-optimise] [-rgb] [-progressive] [-comment=text] [-dct={int|fast|float}] [-arith‐\nmetic] [-restart=n] [-smooth=n] [-maxmemory=n] [-verbose] [-baseline] [-qtables=filespec]\n[-qslots=n[,...]] [-sample=HxV[,...]] [-scans=filespec] [-tracelevel=N]\nfilename\nMinimum unique abbreviation of option is acceptable. You may use double hyphens instead of\nsingle hyphen to denote options. You may use white space in place of the equals sign to sep‐\narate an option name from its value.\n\n## DESCRIPTION\n\nThis program is part of Netpbm(1).\n\n## TLDR\n\n> Convert a PNM image file to the JPEG/JFIF/EXIF image format.\n\n- Read a PNM image as input and produce a JPEG/JFIF/EXIF image as output:\n `pnmtojpeg {{path/to/file.pnm}} > {{path/to/file.jpg}}`\n- Display version:\n `pnmtojpeg -version`\n\n*Source: tldr-pages*\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **OPTIONS** (27 subsections)\n- **EXAMPLES**\n- **JPEG LOSS** (1 subsections)\n- **OTHER PROGRAMS**\n- **SCAN SCRIPTS**\n- **ENVIRONMENT**\n- **SEE ALSO**\n- **AUTHOR**\n- **DOCUMENT SOURCE**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "pnmtojpeg", "section": "", "mode": "man", "summary": "pnmtojpeg - convert PNM image to a JFIF (\"JPEG\") image", "synopsis": "pnmtojpeg [-exif=filespec] [-quality=n] [{-grayscale|-greyscale}] [-density=nxn[dpi,dpcm]]\n[-optimize|-optimise] [-rgb] [-progressive] [-comment=text] [-dct={int|fast|float}] [-arith‐\nmetic] [-restart=n] [-smooth=n] [-maxmemory=n] [-verbose] [-baseline] [-qtables=filespec]\n[-qslots=n[,...]] [-sample=HxV[,...]] [-scans=filespec] [-tracelevel=N]\nfilename\nMinimum unique abbreviation of option is acceptable. You may use double hyphens instead of\nsingle hyphen to denote options. You may use white space in place of the equals sign to sep‐\narate an option name from its value.", "tldr_summary": "Convert a PNM image file to the JPEG/JFIF/EXIF image format.", "tldr_examples": [ { "description": "Read a PNM image as input and produce a JPEG/JFIF/EXIF image as output", "command": "pnmtojpeg {{path/to/file.pnm}} > {{path/to/file.jpg}}" }, { "description": "Display version", "command": "pnmtojpeg -version" } ], "tldr_source": "official", "flags": [ { "flag": "", "long": null, "arg": null, "description": "This option specifies that the output image is to be EXIF (a subformat of JFIF), i.e. it will have an EXIF header as a JFIF APP1 marker. The contents of that marker are the contents of the specified file. The special value - means to read the EXIF header contents from standard input. It is invalid to specify standard input for both the EXIF header and the input image. The EXIF file starts with a two byte field which is the length of the file, including the length field, in pure binary, most significant byte first. The special value of zero for the length field means there is to be no EXIF header, i.e. the same as no -exif option. This is useful for when you convert a file from JFIF to PNM using jpeg‐ topnm, then transform it, then convert it back to JFIF with pnmtojpeg, and you don't know whether or not it includes an EXIF header. jpegtopnm creates an EXIF file con‐ taining nothing but two bytes of zero when the input JFIF file has no EXIF header. Thus, you can transfer any EXIF header from the input JFIF to the output JFIF without worrying about whether an EXIF header actually exists. The contents of the EXIF file after the length field are the exact byte for byte con‐ tents of the APP1 marker, not counting the length field, that constitutes the EXIF header." }, { "flag": "", "long": null, "arg": null, "description": "Scale quantization tables to adjust image quality. n is 0 (worst) to 100 (best); de‐ fault is 75. Below about 25 can produce images some interpreters won't be able to in‐ terpret. See below for more info." }, { "flag": "", "long": null, "arg": null, "description": "" }, { "flag": "", "long": null, "arg": null, "description": "" }, { "flag": "", "long": null, "arg": null, "description": "-greyscale) means to create a gray scale JFIF, converting from color PPM input if nec‐ essary. -rgb means to create an RGB JFIF, and the program fails if the input is not PPM. If you specify neither, The output file is in YCbCr format if the input is PPM, and grayscale format if the input is PBM or PGM. YCbCr format (a color is represented by an intensity value and two chrominance values) usually compresses much better than RGB (a color is represented by one red, one green, and one blue value). RGB is rare. But you may be able to convert between JFIF and PPM faster with RGB, since it's the same color space PPM uses. The testimg.ppm file that comes with Netpbm is 2.3 times larger with the -rgb option than with the YCbCr default, and in one experiment pnmtojpeg took 16% more CPU time to convert it. The extra CPU time probably indicates that processing of all the extra compressed data consumed all the CPU time saved by not having to convert the RGB in‐ puts to YCbCr. Grayscale format takes up a lot less space and takes less time to create and process than the color formats, even if the image contains nothing but black, white, and gray. The -rgb option was added in Netpbm 10.11 in October 2002." }, { "flag": "", "long": null, "arg": null, "description": "This option determines the density (aka resolution) information recorded in the JFIF output image. It does not affect the raster in any way; it just tells whoever reads the JFIF how to interpret the raster. The density value takes the form xxy followed by an optional unit specifier of dpi or dpcm. Examples: 1x1, 3x2, 300x300dpi, 100x200dpcm. The first number is the horizon‐ tal density; the 2nd number is the vertical density. Each may be any integer from 1 to 65535. The unit specifier is dpi for dots per inch or dpcm for dots per centime‐ ter. If you don't specify the units, the density information goes into the JFIF ex‐ plicitly stating \"density unspecified\" (also interpreted as \"unknown\"). This may seem pointless, but note that even without specifying the units, the density numbers tell the aspect ratio of the pixels. E.g. 1x1 tells you the pixels are square. 3x2 tells you the pixels are vertical rectangles. Note that if you specify different horizontal and vertical densities, the resulting JFIF image is not a true representation of the input PNM image, because pnmtojpeg con‐ verts the raster pixel-for-pixel and the pixels of a PNM image are defined to be square. Thus, if you start with a square PNM image and specify -density=3x2, the re‐ sulting JFIF image is a horizontally squashed version of the original. However, it is common to use an input image which is a slight variation on PNM rather than true PNM such that the pixels are not square. In that case, the appropriate -density option yields a faithful reproduction of the input pseudo-PNM image. The default is 1x1 in unspecified units. Before Netpbm 10.15 (April 2003), this option did not exist and the pnmtojpeg always created a JFIF with a density of 1x1 in unspecified units." }, { "flag": "", "long": null, "arg": null, "description": "Perform optimization of entropy encoding parameters. Without this, pnmtojpeg uses default encoding parameters. -optimize usually makes the JFIF file a little smaller, but pnmtojpeg runs somewhat slower and needs much more memory. Image quality and speed of decompression are unaffected by -optimize." }, { "flag": "", "long": null, "arg": null, "description": "Create a progressive JPEG file (see below)." }, { "flag": "", "long": null, "arg": null, "description": "Include a comment marker in the JFIF output, with comment text text. Without this option, there are no comment markers in the output. The -quality option lets you trade off compressed file size against quality of the recon‐ structed image: the higher the quality setting, the larger the JFIF file, and the closer the output image will be to the original input. Normally you want to use the lowest quality set‐ ting (smallest file) that decompresses into something visually indistinguishable from the original image. For this purpose the quality setting should be between 50 and 95 for reason‐ able results; the default of 75 is often about right. If you see defects at -quality=75, then go up 5 or 10 counts at a time until you are happy with the output image. (The optimal setting will vary from one image to another.)" }, { "flag": "", "long": null, "arg": null, "description": "step (but there is still information loss in subsampling, as well as roundoff error). This setting is of interest mainly for experimental purposes. Quality values above about 95 are not recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality. In the other direction, quality values below 50 will produce very small files of low image quality. Settings around 5 to 10 might be useful in preparing an index of a large image li‐ brary, for example. Try -quality=2 (or so) for some amusing Cubist effects. (Note: quality values below about 25 generate 2-byte quantization tables, which are considered optional in the JFIF standard. pnmtojpeg emits a warning message when you give such a quality value, be‐ cause some other JFIF programs may be unable to decode the resulting file. Use -baseline if you need to ensure compatibility at low quality values.) The -progressive option creates a \"progressive JPEG\" file. In this type of JFIF file, the data is stored in multiple scans of increasing quality. If the file is being transmitted over a slow communications link, the decoder can use the first scan to display a low-quality image very quickly, and can then improve the display with each subsequent scan. The final image is exactly equivalent to a standard JFIF file of the same quality setting, and the to‐ tal file size is about the same -- often a little smaller. Caution: progressive JPEG is not yet widely implemented, so many decoders will be unable to view a progressive JPEG file at all. If you're trying to control the quality/file size tradeoff, you might consider the JPEG2000 format instead. See pamtojpeg2k(1)." }, { "flag": "", "long": null, "arg": null, "description": "Use integer DCT method (default)." }, { "flag": "", "long": null, "arg": null, "description": "Use fast integer DCT (less accurate)." }, { "flag": "", "long": null, "arg": null, "description": "Use floating-point DCT method. The float method is very slightly more accurate than the int method, but is much slower unless your machine has very fast floating-point hardware. Also note that results of the floating-point method may vary slightly across machines, while the integer methods should give the same results everywhere. The fast integer method is much less accurate than the other two." }, { "flag": "", "long": null, "arg": null, "description": "Use arithmetic coding. Default is Huffman encoding. Arithmetic coding tends to get you a smaller result. You may need patent licenses to use this option. According to \u001b]8;;http://www.faqs.org/faqs/jpeg-faq\u001b\\the JPEG FAQ\u001b]8;;\u001b\\ , This method is covered by patents owned by IBM, AT&T, and Mitsubishi. The author of the FAQ recommends against using arithmetic coding (and therefore this option) because the space savings is not great enough to justify the legal hassles. Most JPEG libraries, including any distributed by the Independent JPEG Group since about 1998 are not capable of arithmetic encoding. pnmtojpeg uses a JPEG library (ei‐ ther bound to it when the pnmtojpeg executable was built or accessed on your system at run time) to do the JPEG encoding. If pnmtojpeg terminates with the message, \"Sorry, there are legal restrictions on arithmetic coding\" or \"Sorry, arithmetic coding not supported,\" this is the problem." }, { "flag": "", "long": null, "arg": null, "description": "Emit a JPEG restart marker every n MCU rows, or every n MCU blocks if you append B to the number. -restart 0 (the default) means no restart markers." }, { "flag": "", "long": null, "arg": null, "description": "Smooth the input image to eliminate dithering noise. n, ranging from 1 to 100, indi‐ cates the strength of smoothing. 0 (the default) means no smoothing." }, { "flag": "", "long": null, "arg": null, "description": "Set a limit for amount of memory to use in processing large images. Value is in thou‐ sands of bytes, or millions of bytes if you append M to the number. For example, -max=4m selects 4,000,000 bytes. If pnmtojpeg needs more space, it will use temporary files." }, { "flag": "", "long": null, "arg": null, "description": "Print to the Standard Error file messages about the conversion process. This can be helpful in debugging problems. The -restart option tells pnmtojpeg to insert extra markers that allow a JPEG decoder to re‐ synchronize after a transmission error. Without restart markers, any damage to a compressed file will usually ruin the image from the point of the error to the end of the image; with restart markers, the damage is usually confined to the portion of the image up to the next restart marker. Of course, the restart markers occupy extra space. We recommend -restart=1 for images that will be transmitted across unreliable networks such as Usenet. The -smooth option filters the input to eliminate fine-scale noise. This is often useful when converting dithered images to JFIF: a moderate smoothing factor of 10 to 50 gets rid of dithering patterns in the input file, resulting in a smaller JFIF file and a better-looking image. Too large a smoothing factor will visibly blur the image, however." }, { "flag": "", "long": null, "arg": null, "description": "Force baseline-compatible quantization tables to be generated. This clamps quantiza‐ tion values to 8 bits even at low quality settings. (This switch is poorly named, since it does not ensure that the output is actually baseline JPEG. For example, you can use -baseline and -progressive together.)" }, { "flag": "", "long": null, "arg": null, "description": "Use the quantization tables given in the specified text file." }, { "flag": "", "long": null, "arg": null, "description": "Select which quantization table to use for each color component." }, { "flag": "", "long": null, "arg": null, "description": "Set JPEG sampling factors for each color component." }, { "flag": "", "long": null, "arg": null, "description": "Use the scan script given in the specified text file. See below for information on scan scripts." }, { "flag": "", "long": null, "arg": null, "description": "This sets the level of debug tracing the program outputs as it runs. 0 means none, and is the default. This level primarily controls tracing of the JPEG library, and you can get some pretty interesting information about the compression process. The \"wizard\" options are intended for experimentation with JPEG. If you don't know what you are doing, don't use them. These switches are documented further in the file wizard.doc that comes with the Independent JPEG Group's JPEG library." } ], "examples": [ "This example compresses the PPM file foo.ppm with a quality factor of 60 and saves the output", "as foo.jpg:", "pnmtojpeg -quality=60 foo.ppm > foo.jpg", "Here's a more typical example. It converts from BMP to JFIF:", "cat foo.bmp | bmptoppm | pnmtojpeg > foo.jpg" ], "see_also": [ { "name": "jpegtopnm", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/jpegtopnm/1/json" }, { "name": "pnm", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/pnm/1/json" } ], "section_outline": [ { "name": "NAME", "lines": 3, "subsections": [] }, { "name": "SYNOPSIS", "lines": 13, "subsections": [] }, { "name": "DESCRIPTION", "lines": 17, "subsections": [] }, { "name": "OPTIONS", "lines": 4, "subsections": [ { "name": "Basic Options", "lines": 1 }, { "name": "-exif=_", "lines": 21 }, { "name": "-quality=_", "lines": 5 }, { "name": "-grayscale", "lines": 1 }, { "name": "-greyscale", "lines": 1 }, { "name": "-rgb -grayscale", "lines": 24 }, { "name": "-density=_", "lines": 29 }, { "name": "-optimize", "lines": 6 }, { "name": "-progressive", "lines": 2 }, { "name": "-comment=_", "lines": 15 }, { "name": "-quality=100", "lines": 27 }, { "name": "Advanced options", "lines": 1 }, { "name": "-dct=int", "lines": 3 }, { "name": "-dct=fast", "lines": 3 }, { "name": "-dct=float", "lines": 7 }, { "name": "-arithmetic", "lines": 17 }, { "name": "-restart=_", "lines": 4 }, { "name": "-smooth=_", "lines": 4 }, { "name": "-maxmemory=_", "lines": 6 }, { "name": "-verbose", "lines": 17 }, { "name": "Wizard Options", "lines": 1 }, { "name": "-baseline", "lines": 6 }, { "name": "-qtables=_", "lines": 3 }, { "name": "-qslots=n[,...]", "lines": 3 }, { "name": "-sample=_", "lines": 3 }, { "name": "-scans=_", "lines": 4 }, { "name": "-tracelevel=_", "lines": 11 } ] }, { "name": "EXAMPLES", "lines": 12, "subsections": [] }, { "name": "JPEG LOSS", "lines": 11, "subsections": [ { "name": "-smooth -smooth 10", "lines": 16 } ] }, { "name": "OTHER PROGRAMS", "lines": 11, "subsections": [] }, { "name": "SCAN SCRIPTS", "lines": 40, "subsections": [] }, { "name": "ENVIRONMENT", "lines": 8, "subsections": [] }, { "name": "SEE ALSO", "lines": 8, "subsections": [] }, { "name": "AUTHOR", "lines": 3, "subsections": [] }, { "name": "DOCUMENT SOURCE", "lines": 6, "subsections": [] } ], "sections": { "NAME": { "content": "pnmtojpeg - convert PNM image to a JFIF (\"JPEG\") image\n\n", "subsections": [] }, "SYNOPSIS": { "content": "pnmtojpeg [-exif=filespec] [-quality=n] [{-grayscale|-greyscale}] [-density=nxn[dpi,dpcm]]\n[-optimize|-optimise] [-rgb] [-progressive] [-comment=text] [-dct={int|fast|float}] [-arith‐\nmetic] [-restart=n] [-smooth=n] [-maxmemory=n] [-verbose] [-baseline] [-qtables=filespec]\n[-qslots=n[,...]] [-sample=HxV[,...]] [-scans=filespec] [-tracelevel=N]\n\nfilename\n\nMinimum unique abbreviation of option is acceptable. You may use double hyphens instead of\nsingle hyphen to denote options. You may use white space in place of the equals sign to sep‐\narate an option name from its value.\n\n\n", "subsections": [] }, "DESCRIPTION": { "content": "This program is part of Netpbm(1).\n\npnmtojpeg converts the named PBM, PGM, or PPM image file, or the standard input if no file is\nnamed, to a JFIF file on the standard output.\n\npnmtojpeg uses the Independent JPEG Group's JPEG library to create the output file. See\n\u001b]8;;http://www.ijg.org\u001b\\http://www.ijg.org\u001b]8;;\u001b\\ for information on the library.\n\n\"JFIF\" is the correct name for the image format commonly known as \"JPEG.\" Strictly speaking,\nJPEG is a method of compression. The image format using JPEG compression that is by far the\nmost common is JFIF. There is also a subformat of TIFF that uses JPEG compression.\n\nEXIF is an image format that is a subformat of JFIF (to wit, a JFIF file that contains an\nEXIF header as an APP1 marker). pnmtojpeg creates an EXIF image when you specify the -exif\noption.\n\n", "subsections": [] }, "OPTIONS": { "content": "In addition to the options common to all programs based on libnetpbm (most notably -quiet,\nsee \u001b]8;;index.html#commonoptions\u001b\\ Common Options\u001b]8;;\u001b\\ ), pnmtojpeg recognizes the following command line options:\n\n", "subsections": [ { "name": "Basic Options", "content": "" }, { "name": "-exif=_", "content": "This option specifies that the output image is to be EXIF (a subformat of JFIF), i.e.\nit will have an EXIF header as a JFIF APP1 marker. The contents of that marker are\nthe contents of the specified file. The special value - means to read the EXIF header\ncontents from standard input. It is invalid to specify standard input for both the\nEXIF header and the input image.\n\nThe EXIF file starts with a two byte field which is the length of the file, including\nthe length field, in pure binary, most significant byte first. The special value of\nzero for the length field means there is to be no EXIF header, i.e. the same as no\n-exif option. This is useful for when you convert a file from JFIF to PNM using jpeg‐\ntopnm, then transform it, then convert it back to JFIF with pnmtojpeg, and you don't\nknow whether or not it includes an EXIF header. jpegtopnm creates an EXIF file con‐\ntaining nothing but two bytes of zero when the input JFIF file has no EXIF header.\nThus, you can transfer any EXIF header from the input JFIF to the output JFIF without\nworrying about whether an EXIF header actually exists.\n\nThe contents of the EXIF file after the length field are the exact byte for byte con‐\ntents of the APP1 marker, not counting the length field, that constitutes the EXIF\nheader.\n\n" }, { "name": "-quality=_", "content": "Scale quantization tables to adjust image quality. n is 0 (worst) to 100 (best); de‐\nfault is 75. Below about 25 can produce images some interpreters won't be able to in‐\nterpret. See below for more info.\n\n" }, { "name": "-grayscale", "content": "" }, { "name": "-greyscale", "content": "" }, { "name": "-rgb -grayscale", "content": "-greyscale) means to create a gray scale JFIF, converting from color PPM input if nec‐\nessary. -rgb means to create an RGB JFIF, and the program fails if the input is not\nPPM.\n\nIf you specify neither, The output file is in YCbCr format if the input is PPM, and\ngrayscale format if the input is PBM or PGM.\n\nYCbCr format (a color is represented by an intensity value and two chrominance values)\nusually compresses much better than RGB (a color is represented by one red, one green,\nand one blue value). RGB is rare. But you may be able to convert between JFIF and\nPPM faster with RGB, since it's the same color space PPM uses.\n\nThe testimg.ppm file that comes with Netpbm is 2.3 times larger with the -rgb option\nthan with the YCbCr default, and in one experiment pnmtojpeg took 16% more CPU time to\nconvert it. The extra CPU time probably indicates that processing of all the extra\ncompressed data consumed all the CPU time saved by not having to convert the RGB in‐\nputs to YCbCr.\n\nGrayscale format takes up a lot less space and takes less time to create and process\nthan the color formats, even if the image contains nothing but black, white, and gray.\n\nThe -rgb option was added in Netpbm 10.11 in October 2002.\n\n" }, { "name": "-density=_", "content": "This option determines the density (aka resolution) information recorded in the JFIF\noutput image. It does not affect the raster in any way; it just tells whoever reads\nthe JFIF how to interpret the raster.\n\nThe density value takes the form xxy followed by an optional unit specifier of dpi or\ndpcm. Examples: 1x1, 3x2, 300x300dpi, 100x200dpcm. The first number is the horizon‐\ntal density; the 2nd number is the vertical density. Each may be any integer from 1\nto 65535. The unit specifier is dpi for dots per inch or dpcm for dots per centime‐\nter. If you don't specify the units, the density information goes into the JFIF ex‐\nplicitly stating \"density unspecified\" (also interpreted as \"unknown\"). This may seem\npointless, but note that even without specifying the units, the density numbers tell\nthe aspect ratio of the pixels. E.g. 1x1 tells you the pixels are square. 3x2 tells\nyou the pixels are vertical rectangles.\n\nNote that if you specify different horizontal and vertical densities, the resulting\nJFIF image is not a true representation of the input PNM image, because pnmtojpeg con‐\nverts the raster pixel-for-pixel and the pixels of a PNM image are defined to be\nsquare. Thus, if you start with a square PNM image and specify -density=3x2, the re‐\nsulting JFIF image is a horizontally squashed version of the original. However, it is\ncommon to use an input image which is a slight variation on PNM rather than true PNM\nsuch that the pixels are not square. In that case, the appropriate -density option\nyields a faithful reproduction of the input pseudo-PNM image.\n\nThe default is 1x1 in unspecified units.\n\nBefore Netpbm 10.15 (April 2003), this option did not exist and the pnmtojpeg always\ncreated a JFIF with a density of 1x1 in unspecified units.\n\n" }, { "name": "-optimize", "content": "Perform optimization of entropy encoding parameters. Without this, pnmtojpeg uses\ndefault encoding parameters. -optimize usually makes the JFIF file a little smaller,\nbut pnmtojpeg runs somewhat slower and needs much more memory. Image quality and\nspeed of decompression are unaffected by -optimize.\n\n" }, { "name": "-progressive", "content": "Create a progressive JPEG file (see below).\n" }, { "name": "-comment=_", "content": "Include a comment marker in the JFIF output, with comment text text.\n\nWithout this option, there are no comment markers in the output.\n\n\n\nThe -quality option lets you trade off compressed file size against quality of the recon‐\nstructed image: the higher the quality setting, the larger the JFIF file, and the closer the\noutput image will be to the original input. Normally you want to use the lowest quality set‐\nting (smallest file) that decompresses into something visually indistinguishable from the\noriginal image. For this purpose the quality setting should be between 50 and 95 for reason‐\nable results; the default of 75 is often about right. If you see defects at -quality=75,\nthen go up 5 or 10 counts at a time until you are happy with the output image. (The optimal\nsetting will vary from one image to another.)\n" }, { "name": "-quality=100", "content": "step (but there is still information loss in subsampling, as well as roundoff error). This\nsetting is of interest mainly for experimental purposes. Quality values above about 95 are\nnot recommended for normal use; the compressed file size goes up dramatically for hardly any\ngain in output image quality.\n\nIn the other direction, quality values below 50 will produce very small files of low image\nquality. Settings around 5 to 10 might be useful in preparing an index of a large image li‐\nbrary, for example. Try -quality=2 (or so) for some amusing Cubist effects. (Note: quality\nvalues below about 25 generate 2-byte quantization tables, which are considered optional in\nthe JFIF standard. pnmtojpeg emits a warning message when you give such a quality value, be‐\ncause some other JFIF programs may be unable to decode the resulting file. Use -baseline if\nyou need to ensure compatibility at low quality values.)\n\nThe -progressive option creates a \"progressive JPEG\" file. In this type of JFIF file, the\ndata is stored in multiple scans of increasing quality. If the file is being transmitted\nover a slow communications link, the decoder can use the first scan to display a low-quality\nimage very quickly, and can then improve the display with each subsequent scan. The final\nimage is exactly equivalent to a standard JFIF file of the same quality setting, and the to‐\ntal file size is about the same -- often a little smaller.\n\nCaution: progressive JPEG is not yet widely implemented, so many decoders will be unable to\nview a progressive JPEG file at all.\n\nIf you're trying to control the quality/file size tradeoff, you might consider the JPEG2000\nformat instead. See pamtojpeg2k(1).\n\n" }, { "name": "Advanced options", "content": "" }, { "name": "-dct=int", "content": "Use integer DCT method (default).\n\n" }, { "name": "-dct=fast", "content": "Use fast integer DCT (less accurate).\n\n" }, { "name": "-dct=float", "content": "Use floating-point DCT method. The float method is very slightly more accurate than\nthe int method, but is much slower unless your machine has very fast floating-point\nhardware. Also note that results of the floating-point method may vary slightly\nacross machines, while the integer methods should give the same results everywhere.\nThe fast integer method is much less accurate than the other two.\n\n" }, { "name": "-arithmetic", "content": "Use arithmetic coding. Default is Huffman encoding. Arithmetic coding tends to get\nyou a smaller result.\n\nYou may need patent licenses to use this option. According to \u001b]8;;http://www.faqs.org/faqs/jpeg-faq\u001b\\the JPEG FAQ\u001b]8;;\u001b\\ , This\nmethod is covered by patents owned by IBM, AT&T, and Mitsubishi.\n\nThe author of the FAQ recommends against using arithmetic coding (and therefore this\noption) because the space savings is not great enough to justify the legal hassles.\n\nMost JPEG libraries, including any distributed by the Independent JPEG Group since\nabout 1998 are not capable of arithmetic encoding. pnmtojpeg uses a JPEG library (ei‐\nther bound to it when the pnmtojpeg executable was built or accessed on your system at\nrun time) to do the JPEG encoding. If pnmtojpeg terminates with the message, \"Sorry,\nthere are legal restrictions on arithmetic coding\" or \"Sorry, arithmetic coding not\nsupported,\" this is the problem.\n\n" }, { "name": "-restart=_", "content": "Emit a JPEG restart marker every n MCU rows, or every n MCU blocks if you append B to\nthe number. -restart 0 (the default) means no restart markers.\n\n" }, { "name": "-smooth=_", "content": "Smooth the input image to eliminate dithering noise. n, ranging from 1 to 100, indi‐\ncates the strength of smoothing. 0 (the default) means no smoothing.\n\n" }, { "name": "-maxmemory=_", "content": "Set a limit for amount of memory to use in processing large images. Value is in thou‐\nsands of bytes, or millions of bytes if you append M to the number. For example,\n-max=4m selects 4,000,000 bytes. If pnmtojpeg needs more space, it will use temporary\nfiles.\n\n" }, { "name": "-verbose", "content": "Print to the Standard Error file messages about the conversion process. This can be\nhelpful in debugging problems.\n\n\nThe -restart option tells pnmtojpeg to insert extra markers that allow a JPEG decoder to re‐\nsynchronize after a transmission error. Without restart markers, any damage to a compressed\nfile will usually ruin the image from the point of the error to the end of the image; with\nrestart markers, the damage is usually confined to the portion of the image up to the next\nrestart marker. Of course, the restart markers occupy extra space. We recommend -restart=1\nfor images that will be transmitted across unreliable networks such as Usenet.\n\nThe -smooth option filters the input to eliminate fine-scale noise. This is often useful\nwhen converting dithered images to JFIF: a moderate smoothing factor of 10 to 50 gets rid of\ndithering patterns in the input file, resulting in a smaller JFIF file and a better-looking\nimage. Too large a smoothing factor will visibly blur the image, however.\n\n" }, { "name": "Wizard Options", "content": "" }, { "name": "-baseline", "content": "Force baseline-compatible quantization tables to be generated. This clamps quantiza‐\ntion values to 8 bits even at low quality settings. (This switch is poorly named,\nsince it does not ensure that the output is actually baseline JPEG. For example, you\ncan use -baseline and -progressive together.)\n\n" }, { "name": "-qtables=_", "content": "Use the quantization tables given in the specified text file.\n\n" }, { "name": "-qslots=n[,...]", "content": "Select which quantization table to use for each color component.\n\n" }, { "name": "-sample=_", "content": "Set JPEG sampling factors for each color component.\n\n" }, { "name": "-scans=_", "content": "Use the scan script given in the specified text file. See below for information on\nscan scripts.\n\n" }, { "name": "-tracelevel=_", "content": "This sets the level of debug tracing the program outputs as it runs. 0 means none,\nand is the default. This level primarily controls tracing of the JPEG library, and\nyou can get some pretty interesting information about the compression process.\n\n\n\nThe \"wizard\" options are intended for experimentation with JPEG. If you don't know what you\nare doing, don't use them. These switches are documented further in the file wizard.doc that\ncomes with the Independent JPEG Group's JPEG library.\n\n" } ] }, "EXAMPLES": { "content": "This example compresses the PPM file foo.ppm with a quality factor of 60 and saves the output\nas foo.jpg:\n\npnmtojpeg -quality=60 foo.ppm > foo.jpg\n\n\nHere's a more typical example. It converts from BMP to JFIF:\n\ncat foo.bmp | bmptoppm | pnmtojpeg > foo.jpg\n\n\n", "subsections": [] }, "JPEG LOSS": { "content": "When you compress with JPEG, you lose information -- i.e. the resulting image has somewhat\nlower quality than the original. This is a characteristic of JPEG itself, not any particular\nprogram. So if you do the usual Netpbm thing and convert from JFIF to PNM, manipulate, then\nconvert back to JFIF, you will lose quality. The more you do it, the more you lose. Draw‐\nings (charts, cartoons, line drawings, and such with few colors and sharp edges) suffer the\nmost.\n\nTo avoid this, you can use a compressed image format other than JPEG. PNG and JPEG2000 are\ngood choices, and Netpbm contains converters for those.\n\nIf you need to use JFIF on a drawing, you should experiment with pnmtojpeg's -quality and", "subsections": [ { "name": "-smooth -smooth 10", "content": "Because of the loss, you should do all the manipulation you have to do on the image in some\nother format and convert to JFIF as the last step. And if you can keep a copy in the origi‐\nnal format, so much the better.\n\nThe -optimize option to pnmtojpeg is worth using when you are making a \"final\" version for\nposting or archiving. It's also a win when you are using low quality settings to make very\nsmall JFIF files; the percentage improvement is often a lot more than it is on larger files.\n(At present, -optimize mode is automatically in effect when you generate a progressive JPEG\nfile).\n\nYou can do flipping and rotating transformations losslessly with the program jpegtran, which\nis packaged with the Independent Jpeg Group's JPEG library. jpegtran exercises its intimate\nknowledge of the way JPEG works to do the transformation without ever actually decompressing\nthe image.\n\n" } ] }, "OTHER PROGRAMS": { "content": "Another program, cjpeg, is similar. cjpeg is maintained by the Independent JPEG Group and\npackaged with the JPEG library which pnmtojpeg uses for all its JPEG work. Because of that,\nyou may expect it to exploit more current JPEG features. Also, since you have to have the\nlibrary to run pnmtojpeg, but not vice versa, cjpeg may be more commonly available.\n\nOn the other hand, cjpeg does not use the NetPBM libraries to process its input, as all the\nNetPBM tools such as pnmtojpeg do. This means it is less likely to be consistent with all\nthe other programs that deal with the NetPBM formats. Also, the command syntax of pnmtojpeg\nis consistent with that of the other Netpbm tools, unlike cjpeg.\n\n", "subsections": [] }, "SCAN SCRIPTS": { "content": "Use the -scan option to specify a scan script. Or use the -progressive option to specify a\nparticular built-in scan script.\n\nJust what a scan script is, and the basic format of the scan script file, is covered in the\nwizard.doc file that comes with the Independent JPEG Group's JPEG library. Scan scripts are\nsame for pnmtojpeg as the are for cjpeg.\n\nThis section contains additional information that isn't, but probably should be, in that doc‐\nument.\n\nFirst, there are many restrictions on what is a valid scan script. The JPEG library, and\nthus pnmtojpeg, checks thoroughly for any lack of compliance with these restrictions, but\ndoes little to tell you how the script fails to comply. The messages are very general and\nsometimes untrue.\n\nTo start with, the entries for the DC coefficient must come before any entries for the AC co‐\nefficients. The DC coefficient is Coefficient 0; all the other coefficients are AC coeffi‐\ncients. So in an entry for the DC coefficient, the two numbers after the colon must be 0 and\n0. In an entry for AC coefficients, the first number after the colon must not be 0.\n\nIn a DC entry, the color components must be in increasing order. E.g. \"0,2,1\" before the\ncolon is wrong. So is \"0,0,0\".\n\nIn an entry for an AC coefficient, you must specify only one color component. I.e. there can\nbe only one number before the colon.\n\nIn the first entry for a particular coefficient for a particular color component, the \"Ah\"\nvalue must be zero, but the Al value can be any valid bit number. In subsequent entries, Ah\nmust be the Al value from the previous entry (for that coefficient for that color component),\nand the Al value must be one less than the Ah value.\n\nThe script must ultimately specify at least some of the DC coefficient for every color compo‐\nnent. Otherwise, you get the error message \"Script does not transmit all the data.\" You\nneed not specify all of the bits of the DC coefficient, or any of the AC coefficients.\n\nThere is a standard option in building the JPEG library to omit scan script capability. If\nfor some reason your library was built with this option, you get the message \"Requested fea‐\nture was omitted at compile time.\"\n\n", "subsections": [] }, "ENVIRONMENT": { "content": "JPEGMEM\nIf this environment variable is set, its value is the default memory limit. The value\nis specified as described for the -maxmemory option. An explicit -maxmemory option\noverrides any JPEGMEM.\n\n\n\n", "subsections": [] }, "SEE ALSO": { "content": "jpegtopnm(1), pnm(1), cjpeg man page, djpeg man page, jpegtran man page, rdjpgcom man page,\nwrjpgcom man page\n\nWallace, Gregory K. \"The JPEG Still Picture Compression Standard\", Communications of the\nACM, April 1991 (vol. 34, no. 4), pp. 30-44.\n\n\n", "subsections": [] }, "AUTHOR": { "content": "pnmtojpeg and this manual were derived in large part from cjpeg, by the Independent JPEG\nGroup. The program is otherwise by Bryan Henderson on March 07, 2000.\n", "subsections": [] }, "DOCUMENT SOURCE": { "content": "This manual page was generated by the Netpbm tool 'makeman' from HTML source. The master\ndocumentation is at\n\nhttp://netpbm.sourceforge.net/doc/pnmtojpeg.html\n\nnetpbm documentation 23 April 2007 Pnmtojpeg User Manual(1)", "subsections": [] } } } }