CentOS 7.0 - man page for pnmtojpeg (centos section 0)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section
Select Man Page Set:      
apropos Keyword Search (sections above)
Pnmtojpeg User Manual(0)						 Pnmtojpeg User Manual(0)

       pnmtojpeg - convert PNM image to a JFIF ('JPEG') image

       pnmtojpeg [-exif=filespec] [-quality=n] [{-grayscale|-greyscale}] [-density=nxn[dpi,dpcm]]
       [-optimize|-optimise]  [-rgb]   [-progressive]	[-comment=text]   [-dct={int|fast|float}]
       [-arithmetic]   [-restart=n]  [-smooth=n]  [-maxmemory=n]  [-verbose]  [-baseline]  [-qta-
       bles=filespec] [-qslots=n[,...]]  [-sample=HxV[,...]]  [-scans=filespec] [-tracelevel=N]


       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.

       This program is part of Netpbm(1)

       pnmtojpeg converts the named PBM, PGM, or PPM image file, or the standard input if no file
       is named, to a JFIF file on the standard output.

       pnmtojpeg  uses	the Independent JPEG Group's JPEG library to create the output file.  See
       http://www.ijg.org <http://www.ijg.org>	 for information on the library.

       'JFIF' is the correct name for the image format commonly known as 'JPEG.' Strictly  speak-
       ing,  JPEG is a method of compression.  The image format using JPEG compression that is by
       far the most common is JFIF.  There is also a subformat of TIFF that  uses  JPEG  compres-

       EXIF  is an image format that is a subformat of JFIF (to wit, a JFIF file that contains an
       EXIF header as an APP1 marker).	pnmtojpeg creates an EXIF  image  when	you  specify  the
       -exif option.

       The basic options are:

	      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, includ-
	      ing 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  jpegtopnm,  then transform it, then convert it back to JFIF with pnmto-
	      jpeg, and you don't know whether or not it includes an EXIF header.  jpegtopnm cre-
	      ates an EXIF file containing 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
	      contents of the APP1 marker, not counting the length field,  that  constitutes  the
	      EXIF header.

	      Scale  quantization  tables to adjust image quality.  n is 0 (worst) to 100 (best);
	      default is 75.  Below about 25 can produce images some interpreters won't  be  able
	      to interpret.  See below for more info.



       -rgb   These  options  determine  the color space used in the JFIF output.  -grayscale (or
	      -greyscale) means to create a gray scale JFIF, converting from color PPM	input  if
	      necessary.  -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 val-
	      ues) 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 con-
	      vert the RGB inputs 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.

	      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
	      horizontal density; the 2nd number is the vertical density.  Each may be any  inte-
	      ger  from 1 to 65535.  The unit specifier is dpi for dots per inch or dpcm for dots
	      per centimeter.  If you don't specify the units, the density information goes  into
	      the  JFIF explicitly stating "density unspecified" (also interpreted as "unknown").
	      This may seem pointless, but note that even without specifying the units, the  den-
	      sity  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
	      converts 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
	      resulting 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  -den-
	      sity 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.

	       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.

	      Create a progressive JPEG file (see below).

	      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 qual-
       ity setting (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 reasonable 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.)

       -quality=100 generates a quantization table of all 1's, minimizing loss in  the	quantiza-
       tion step (but there is still information loss in subsampling, as well as roundoff error).
       This setting is mainly of interest 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
       library, 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,	because  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-qual-
       ity  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 total 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)

       Options for advanced users:

	      Use integer DCT method (default).

	      Use fast integer DCT (less accurate).

	      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.

	      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  the	JPEG  FAQ
	      <http://www.faqs.org/faqs/jpeg-faq>  ,  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

	      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
	      (either 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 mes-
	      sage, 'Sorry, there are legal restrictions on arithmetic coding' or 'Sorry,  arith-
	      metic coding not supported,' this is the problem.

	      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.

	      Smooth the input image to eliminate dithering noise.  n, ranging	from  1  to  100,
	      indicates the strength of smoothing.  0 (the default) means no smoothing.

	      Set  a  limit  for amount of memory to use in processing large images.  Value is in
	      thousands of bytes, or millions of bytes if you append M to the number.  For  exam-
	      ple,  -max=4m  selects 4,000,000 bytes.  If pnmtojpeg needs more space, it will use
	      temporary files.

	      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
       resynchronize after a transmission error.  Without restart markers, any damage to  a  com-
       pressed	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 recom-
       mend -restart=1 for images that will be transmitted across  unreliable  networks  such  as

       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.

       Options for wizards:

	      Force baseline-compatible quantization tables to be generated.  This clamps quanti-
	      zation  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.)

	      Use the quantization tables given in the specified text file.

	      Select which quantization table to use for each color component.

	      Set JPEG sampling factors for each color component.

	      Use the scan script given in the specified text file.  See below for information on
	      scan scripts.

	      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 wiz-
       ard.doc that comes with the Independent JPEG Group's JPEG library.

       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

       When you compress with JPEG, you lose information -- i.e. the resulting image has somewhat
       lower quality than the original.  This is a characteristic of JPEG itself, not any partic-
       ular  program.	So if you do the usual Netpbm thing and convert from JFIF to PNM, manipu-
       late, then convert back to JFIF, you will lose quality.	The more you do it, the more  you
       lose.   Drawings  (charts,  cartoons,  line  drawings,  and such with few colors and sharp
       edges) suffer the most.

       To avoid this, you can use a compressed image format other than JPEG.   PNG  and  JPEG2000
       are good choices, and Netpbm contains converters for those.

       If  you need to use JFIF on a drawing, you should experiment with pnmtojpeg's -quality and
       -smooth options to get a satisfactory conversion.  -smooth 10 or so is often helpful.

       Because of the loss, you should do all the manipulation you have to do  on  the	image  in
       some other format and convert to JFIF as the last step.	And if you can keep a copy in the
       original format, so much the better.

       The -optimize option to pnmtojpeg is worth using when you are making a 'final' version for
       posting	or  archiving.	 It's  also a win when you are using low quality settings to make
       very small JFIF files; the percentage improvement is often a lot more than it is on larger
       files.	(At  present,  -optimize mode is automatically in effect when you generate a pro-
       gressive JPEG file).

       You can do flipping and rotating transformations losslessly  with  the  program	jpegtran,
       which  is packaged with the Independent Jpeg Group's JPEG library.  jpegtran exercises its
       intimate knowledge of the way JPEG works to do the transformation  without  ever  actually
       decompressing the image.

       Another program, cjpeg, is similar.  cjpeg is
       maintained  by  the Independent JPEG Group and packaged with the JPEG library which pnmto-
       jpeg uses for all its JPEG work.  Because of that, you may expect it to exploit more  cur-
       rent  JPEG  features.   Also, since you have to have the library to run pnmtojpeg, but not
       vice versa, cjpeg may be more commonly available.

       On the other hand, cjpeg does not use the NetPBM libraries to process its  input,  as  all
       the NetPBM tools such as pnmtojpeg do.  This means it is less likely to be consistent with
       all the other programs that deal with the NetPBM formats.  Also,  the  command  syntax  of
       pnmtojpeg is consistent with that of the other Netpbm tools, unlike cjpeg.

       Use  the -scan option to specify a scan script.	Or use the -progressive option to specify
       a particular built-in scan script.

       Just what a scan script is, and the basic format of the scan script file,  is  covered  in
       the  wizard.doc	file  that  comes  with  the Independent JPEG Group's JPEG library.  Scan
       scripts are same for pnmtojpeg as the are for cjpeg.

       This section contains additional information that isn't, but probably should be,  in  that

       First,  there are many restrictions on what is a valid scan script.  The JPEG library, and
       thus pnmtojpeg, checks thoroughly for any lack of compliance with these restrictions,  but
       does little to tell you how the script fails to comply.	The messages are very general and
       sometimes untrue.

       To start with, the entries for the DC coefficient must come before any entries for the  AC
       coefficients.   The  DC	coefficient  is  Coefficient 0; all the other coefficients are AC
       coefficients.  So in an entry for the DC coefficient, the two numbers after the colon must
       be 0 and 0.  In an entry for AC coefficients, the first number after the colon must not be

       In a DC entry, the color components must be in increasing order.  E.g. '0,2,1' before  the
       colon is wrong.	So is '0,0,0'.

       In  an entry for an AC coefficient, you must specify only one color component.  I.e. there
       can be only one number before the colon.

       In the first entry for a particular coefficient for a particular color component, the 'Ah'
       value  must be zero, but the Al value can be any valid bit number.  In subsequent entries,
       Ah must be the Al value from the previous entry (for that coefficient for that color  com-
       ponent), and the Al value must be one less than the Ah value.

       The  script  must  ultimately  specify at least some of the DC coefficient for every color
       component.  Otherwise, you get the error message 'Script does not transmit all the  data.'
       You need not specify all of the bits of the DC coefficient, or any of the AC coefficients.

       There  is  a  standard option in building the JPEG library to omit scan script capability.
       If for some reason your library was built with this option, you get the message 'Requested
       feature was omitted at compile time.'

	      If  this	environment  variable is set, its value is the default memory limit.  The
	      value is specified as described for the -maxmemory option.  An explicit  -maxmemory
	      option overrides any JPEGMEM.

       jpegtopnm(1)  ,	pnm(1)	, cjpeg man page, djpeg man page, jpegtran man page, rdjpgcom man
       page, wrjpgcom man page

       Wallace, Gregory K.  'The JPEG Still Picture Compression Standard', Communications of  the
       ACM, April 1991 (vol. 34, no. 4), pp. 30-44.

       pnmtojpeg  and  this manual were derived in large part from cjpeg, by the Independent JPEG
       Group.  The program is otherwise by Bryan Henderson on March 07, 2000.

netpbm documentation			  23 April 2007 		 Pnmtojpeg User Manual(0)

All times are GMT -4. The time now is 05:58 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password

Not a Forum Member?
Forgot Password?