nbis-wrapper-js 0.0.1

package/libnbis/nbis_x86-64_linux/man/man1/rgb2ycc.1

@@ -0,0 +1,175 @@
+.\" @(#)rgb2ycc.1 2008/10/02 NIST
+.\" I Image Group
+.\" Craig Watson and Michael D. Garris
+.\"
+.TH RGB2YCC 1G "02 October 2008" "NIST" "NBIS Reference Manual"
+.SH NAME
+rgb2ycc \- converts a color RGB image to the YCbCr colorspace and
+downsamples component planes as specified.
+.SH SYNOPSIS
+.B rgb2ycc
+.I <outext>
+.I <image file>
+.br
+.RS
+[\fB-raw_in \fIw\fR,\fIh\fR,\fId\fR,[\fIppi\fR]
+.RS 3
+[\fB-nonintrlv\fR]]
+.RE
+[\fB-YCbCr \fIH0\fR,\fIV0\fR:\fIH1\fR,\fIV1\fR:\fIH2\fR,\fIV2\fR]
+
+.SH DESCRIPTION
+.B Rgb2ycc
+takes as input a file containing an uncompressed color RGB
+image.  Two possible input file formats are accepted, NIST IHead
+files and raw pixmap files.  If a raw pixmap file is to be converted,
+then its image attributes must be provided on the command line as well.
+Once read into memory, the RGB pixmap is converted to the YCbCr
+colorspace. The results are always written to a raw pixmap file
+because the NIST IHead file format only supports interleaved RGB images.
+
+The color components of RGB pixels in a raw pixmap file may
+be interleaved or non-interleaved.  By default, \fBrgb2ycc\fR
+assumes interleaved color pixels.  (See INTERLEAVE OPTIONS below.)
+
+If requested, \fBrgb2ycc\fR also conducts downsampling of the
+YCbCr component planes.  By default, this utility does no downsampling.
+Regardless of downsampling, the conversion from RGB to YCbCr and
+back to RGB will not result in the same exact image.  Some pixels
+values will be slightly perturbed due to the round-off of the
+floating point transformations that are applied.
+(See YCbCr OPTIONS below.)  
+
+.SH OPTIONS
+All switch names may be abbreviated; for example,
+\fB-raw_in\fR may be written \fB-r\fR.
+.TP
+.I <outext>
+the extension of the YCbCr output file.
+To construct the output filename, \fBrgb2ycc\fR takes the
+input filename and replaces its extension with the one
+specified here.
+.TP
+.I <image file>
+the input file, either an IHead file or raw pixmap file,
+containing the color RGB image to be converted.
+.TP
+\fB-raw_in \fIw\fR,\fIh\fR,\fId\fR,[\fIppi\fR]
+the attributes of the input image.  This option must
+be included on the command line if the input is a
+raw pixmap file.
+.br
+.RS
+.TP
+.I w
+the pixel width of the pixmap
+.TP
+.I h
+the pixel height of the pixmap
+.TP
+.I d
+the pixel depth of the pixmap
+.TP
+.I ppi
+the optional scan resolution of the image in integer units of
+pixels per inch.
+.RE
+.TP
+.B -nonintrlv
+specifies that the color components in an \fIinput\fR raw pixmap file
+image are non-interleaved and stored in separate component planes.
+(See INTERLEAVE OPTIONS below.)
+.TP
+\fB-YCbCr \fIH0\fR,\fIV0\fR:\fIH1\fR,\fIV1\fR:\fIH2\fR,\fIV2
+this option, if provided on the command line, directs \fBrgb2ycc\fR
+to conduct downsampling of the YCbCr component planes.
+If all the H,V factors are set to 1 then no downsampling is done;
+this is equivalent to ommiting the option.
+(See YCbCr Options below.)
+.TP
+\fB-version
+\fRPrint ANSI/NIST stardand and NBIS software version.
+
+.SH INTERLEAVE OPTIONS
+The color components of RGB pixels in a raw pixmap file may
+be interleaved or non-interleaved.  Color components are interleaved
+when a pixel's (R)ed, (G)reen, and (B)lue components are sequentially
+adjacent in the image byte stream, ie. RGBRGBRGB... .  If the color
+components are non-interleaved, then all (R)ed components in the
+image are sequentially adjacent in the image byte stream, followed
+by all (G)reen components, and then lastly followed by all (B)lue
+components.  Each complete sequence of color components is called
+a \fIplane\fR.  The utilities \fBintr2not\fR and \fBnot2intr\fR
+convert between interleaved and non-interleaved color components.
+By default, \fBrgb2ycc\fR assumes interleaved
+color components, and note that all color IHead images must be
+interleaved.
+
+.SH YCbCr OPTIONS
+\fBRgb2ycc\fR converts color RGB images to the YCbCr colorspace.
+A common compression technique for YCbCr images is to downsample
+the Cb & Cr component planes.
+\fBRgb2ycc\fR conducts a limited range of YCbCr
+downsampling schemes that are represented by a list of component
+plane factors.
+These factors together represent downsampling ratios relative to
+each other.  The comma-separated list of factor pairs correspond to
+the Y, Cb, and
+Cr component planes respectively.  The first value in a factor
+pair represents the downsampling of that particular component plane
+in the X-dimension, while the second represents the Y-dimension.
+Compression ratios for a particular component plane are calculated
+by dividing the maximum component factors in the list by the current
+component's factors.  These integer factors are limited
+between 1 and 4.  H,V factors all set to 1 represent
+no downsampling.  For complete details, \fBrgb2ycc\fR implements
+the downsampling and interleaving schemes described in the
+following reference:
+
+.RS
+W.B. Pennebaker and J.L. Mitchell, "JPEG: Still Image Compression
+Standard," Appendix A - "ISO DIS 10918-1 Requirements and Guidelines,"
+Van Nostrand Reinhold, NY, 1993, pp. A1-A4.
+.RE
+
+For example the option specification:
+
+.RS
+-YCbCr 4,4:2,2:1,1
+.RE
+
+directs \fBrgb2ycc\fR to not downsample the Y component plane
+(4,4 are the largest X and Y factors listed); the Cb component
+plane will be downsampled in X and Y by a factor of 2
+(maximum factors 4 divided by current factors 2); and the Cr component
+plane will be downsampled in X and Y by a factor of 4 (maximum factors 4
+divided by current factors 1).  Note that downsampling component
+planes is a form of \fIlossy\fR compression.
+The utility \fBycc2rgb\fR takes the YCbCr results and converts
+them back to the RGB colorspace.  If downsampling was applied
+to the YCbCr components, then the downsampled planes are
+up-sampled prior to conversion to RGB.  Note that even without
+dowsampling, the conversion from RGB to YCbCr and
+back to RGB will not result in the same exact image.  Some pixels
+values will be slightly perturbed due to the round-off of the
+floating point transformations that are applied.
+
+.SH EXAMPLES
+From \fItest/imgtools/execs/rgb2ycc/rgb2ycc.src\fR:
+.PP
+.RS
+.B % rgb2ycc ycc face.raw -r 768,1024,24 -Y 4,4:1,1:1,1
+.br
+converts an RGB face image in a raw pixmap file to the YCbCr
+colorspace and downsamples the Cb and Cr component planes
+by a factor of 4 in both dimensions.
+
+.SH SEE ALSO
+.BR cjpegl (1G),
+.BR dpyimage (1G),
+.BR intr2not (1G),
+.BR not2intr (1G),
+.BR ycc2rgb (1G)
+
+.SH AUTHOR
+NIST/ITL/DIV894/Image Group

package/libnbis/nbis_x86-64_linux/man/man1/rwpics.1

@@ -0,0 +1,104 @@
+.\" @(#)rwpics.1 2008/10/02 NIST
+.\" I Image Group
+.\" G. T. Candela & Craig I. Watson
+.\"
+.TH RWPICS 1B "02 October 2008" "NIST" "NBIS Reference Manual"
+.SH NAME
+rwpics \- makes pictures of regional weights or gradients.
+.SH SYNOPSIS
+.B rwpics
+.I <rwfile_in[rwfile_in...]> <rws|eg|seg> <outpics_dir>
+.SH DESCRIPTION
+.B Rwpics
+reads a set of PCASYS "matrix" format files each of size 14 x 15.  The
+input files either should be a set of points in regional weights space
+(in particular, basepoints produced by the optimize regional weights
+command optrws), or they should be a set of estimated gradients of the
+activation error (also produced by optrws).  Makes a corresponding set
+of IHead format image files depicting the weights points or
+gradients; these image files can then be displayed using dpyimage.
+Rwpics can be used as a sanity check on whether optrws is
+working properly, and to help decide when the time has come that it is
+reasonable to stop an optrws run because further significant change of
+the weights seems unlikely.
+.SH OPTIONS
+.TP
+.I <rwfile_in[rwfile_in...]>
+The pcasys "matrix" format file(s) to be depicted.  Either they should
+each be a basepoint of the optrws optimization (point in
+regional weights space), or they should each be an estimated
+gradient, also produced by optrws.  In either case, they must
+be matrices of size 14 x 15, corresponding to the weights, each of
+which is associated with one 2 x 2 vector block of the 28 x 30
+pattern of orientation vectors. (Usually the output of \fBoptrws\fR.)
+.TP
+.I <rws|eg|seg>
+A code telling rwpics what kind of pictures to make:
+
+If rws ("regional weights"), the program makes a grayscale picture
+that is reasonable if the input file represents a set of regional
+weights, e.g. one of the bspt files produced by an optrws run.  To do
+so, it linearly maps absolute values of input values to gray tones,
+setting the mapping so that 0. maps to black and the maximum absolute
+value across all components of all input matrices, to white.  Absolute
+values are the reasonable thing to depict when examining a point in
+regional-weights space, since the sign of a regional weights has no
+effect on the PNN classifier.  (Optimization may sometimes cause some
+unimportant outer weights to be slightly negative.)  The mapping is
+adapted to the maximum absolute value across all input files, rather
+than being separately adapted for each input file; this is done so
+that the several resulting pictures can be examined side by side with
+the knowledge that all gray tones are on the same scale.
+
+If eg ("estimated gradient"), the program makes a grayscale picture
+that is reasonable if the input file represents an estimated gradient
+of the error function, e.g. one of the egrad files produced by an
+optrws run.  To do so, it affinely maps input values to gray tones,
+setting the mapping so that the minimum input value across all input
+files is mapped to white and the maximum input value, to black.
+
+If seg ("sign of estimated gradient"), the program makes a
+grayscale-binary (ie. 0 and 255 pixel values) picture that is
+reasonable if the input file represents an estimated gradient
+of the error function.  To do so, it maps negative values to white (255)
+and nonnegative values to black (0).  This is interesting because if
+the component of the estimated gradient (i.e., the estimated partial
+derivative) associated with a region is negative, that shows that the
+weight for this region should be increased (and will be increased by
+optrws).
+.TP
+.I <outpics_dir>
+The directory in which the program should produce its output files,
+which will be raster images in the NIST IHead format.  (The directory
+must already exist, i.e. rwpics does not produce it.) Each output
+file's name is produced by taking the last component of the
+corresponding input file and appending an underscore, then the
+rws|eg|seg code, then .pct (the standard IHEAD file suffix).  The
+output image files may be examined using the dpyimage command.
+.TP
+\fB-version
+\fRPrint ANSI/NIST stardand and NBIS software version.
+
+.SH EXAMPLE(S)
+From \fItest/pcasys/execs/rwpics/rwpics.src\fR:
+.PP
+.RS
+.B % rwpics ../optrws/optrws.bin rws rwpics
+.br
+Produces an image of the optimized regional weights, which
+can be converted to JPEG format using the \fBcjpegb\fR command.
+.PP
+.B % rwpics ../optrws/optdir/egrad_1.bin eg rwpics
+.br
+Produces an image of the estimated gradient, which
+can be converted to JPEG format using the \fBcjpegb\fR command.
+.PP
+.B % rwpics ../optrws/optdir/egrad_1.bin seg rwpics
+.br
+Produces an image of the sign of estimated gradient, which
+can be converted to JPEG format using the \fBcjpegb\fR command.
+.SH "SEE ALSO"
+dpyimage (1B), optrws (1B), cjpegb (1G)
+
+.SH AUTHOR
+NIST/ITL/DIV894/Image Group

package/libnbis/nbis_x86-64_linux/man/man1/sd_rfmt.1

@@ -0,0 +1,88 @@
+.\" @(#)sd_rfmt.1 2008/10/02 NIST
+.\" I Image Group
+.\" Craig Watson and Michael D. Garris
+.\"
+.TH SD_RFMT 1G "02 October 2008" "NIST" "NBIS Reference Manual"
+.SH NAME
+sd_rfmt \- takes images from NIST Special Databases 4, 9, 10, 14,
+and 18 and reformats the compressed data to work with the
+decompressors \fBdjpegl\fR and \fBdwsq\fR.
+
+.SH SYNOPSIS
+.B sd_rfmt
+.I <SD #>
+.I<outext>
+.I <image file>
+.RS 8
+SD list = {4,9,10,14,18}
+
+.SH DESCRIPTION
+.B Sd_rfmt
+reformats images compressed with the old JPEGLSD and WSQ14
+compression, on NIST Special Databases 4, 9, 10, 18 (JPEGLSD) and
+14 (WSQ14), so the images can be decompressed with the new
+commands \fBdjpegl\fR and \fBdwsq\fR.
+
+When JPEGLSD was used to compress images on NIST Special
+Databases (4, 9, 10, 18) the NIST IHEAD header was used to store
+the data for the JPEGLSD compression.  In the new versions
+\fBcjpegl\fR and \fBdjpegl\fR the full JPEG format is used
+not the IHEAD header.
+
+The WSQ14 compression used on SD14 has problems with ordering
+of the data in the compressed file.  \fBSd_rfmt\fR simply reorders
+the data to comply with the format specified in the
+FBI's Criminal Justice Information Services (CJIS) document,
+"WSQ Gray-scale Fingerprint Compressions Specification," Dec. 1997.
+This is the only fingerprint compression format accepted by the
+FBI IAFIS system.  \fBNOTE: The method for selecting the quantization
+amount was refined after the release of SD14 so the data loss in
+the reconstructed image may be more than seen when using the new versions
+cwsq and dwsq.\fR
+
+.SH OPTIONS
+.TP
+.I <SD #>
+Specify that the input image is from NIST Special Database #.
+.TP
+.I <outext>
+the extension of the reformatted output file.
+�To construct the output filename, \fBsd_rfmt\fR takes the
+input filename and replaces its extension with the one
+specified here.
+.TP
+.I <image file>
+the compressed input file to be reformatted.
+.TP
+\fB-version
+\fRPrint ANSI/NIST stardand and NBIS software version.
+
+.SH EXAMPLES
+From \fItest/imgtools/execs/sd_rfmt/sd_rfmt.src\fR:
+.RS
+.PP
+.br
+.B % sd_rfmt 7 jpl sd09.old
+.br
+.B % sd_rfmt 10 jpl sd10.old
+.br
+.B % sd_rfmt 14 wsq sd14.old
+.br
+.B % sd_rfmt 18 jpl sd18.old
+.br
+Convert the special database images to the correct
+formatted compressed files (JPEGL and WSQ).  User
+could use \fBrdjpgcom\fR and \fBrdwsqcom\fR to read the
+NISTCOM comment that is written in the reformatted output file.
+After reformatting the new file can be decompressed with
+\fBdjpegl\fR or \fBdwsq\fR.
+
+.SH SEE ALSO
+.BR djpegl (1G),
+.BR dwsq (1G),
+.BR dpyimage (1G),
+.BR rdjpgcom (1G),
+.BR rdwsqcom (1G)
+
+.SH AUTHOR
+NIST/ITL/DIV894/Image Group

package/libnbis/nbis_x86-64_linux/man/man1/stackms.1

@@ -0,0 +1,68 @@
+.\" @(#)stackms.1 2008/10/02 NIST
+.\" I Image Group
+.\" G. T. Candela & Craig I. Watson
+.\"
+.TH STACKMS 1B "02 October 2008" "NIST" "NBIS Reference Manual"
+.SH NAME
+stackms \- stacks PCASYS formatted matrix files together.
+.SH SYNOPSIS
+.B stackms
+.I <matrixfile_in[matrixfile_in...]> <matrixfile_out>
+.I <matrixfile_out_desc> <ascii_outfile messages>
+.SH DESCRIPTION
+.B Stackms
+stacks together several PCASYS "matrix" files: produces a file whose
+matrix has, as its rows, the rows of all the input matrices. All input
+matrices must have the same second dimension.  (The standard "cat"
+(catenate files) command is insufficient for proper stacking of matrix
+files, since the files contain header information and not just the
+rows of entries.)
+.SH OPTIONS
+.TP
+.I <matrixfile_in[matrixfile_in...]>
+The matrix files to be read.  (Can be ascii or binary, and they don't
+all have to have the same ascii/binary setting.)  All must have the
+same second dimension.
+.TP
+.I <matrixfile_out>
+The matrix file to be written.  Its rows will be the rows of all the
+input matrices.
+.TP
+.I <matrixfile_out_desc>
+A string to be written into the output matrix file as its description
+string; must contain no embedded newline characters.  If it contains
+spaces, tabs, or shell metacharacters that are not to be expanded,
+then it should be quoted.  To leave the description empty, use '' (two
+single quote marks, i.e. a single\-quoted empty string).  To let
+stackms make the description (stating that the file was made by
+stackms, and listing the names of the input files), use \- (hyphen).
+.TP
+.I <ascii_outfile>
+If y, stackms makes an ascii output file; if n, it makes a binary
+output file.  Binary is recommended, unless the output file must be
+portable across different byte orders or floating\-point formats.
+.TP
+.I <messages>
+If y, stackms writes a progress message to the standard output each
+time it is about to start reading a new input file; if n, no messages.
+.TP
+\fB-version
+\fRPrint ANSI/NIST stardand and NBIS software version.
+
+.SH EXAMPLE(S)
+From \fItest/pcasys/execs/stackms/stackms.src\fR:
+.PP
+.RS
+.B % stackms ../meancov/fv1.men ../meancov/fv2.men tst.men - n y
+.br 
+Combines the mean files \fIfv1.men\fR and \fIfv2.men\fR into
+a single file.  This is only and example, the \fBcmbmcs\fR should
+be used to combine mean files.  The mean files were used to preserve
+disk space.  The \fBstackms\fR in practice is used to combine feature
+vector files (ie. where one wants to stack the data in the files).
+.SH "SEE ALSO"
+asc2bin (1B), bin2asc (1B)
+
+
+.SH AUTHOR
+NIST/ITL/DIV894/Image Group

package/libnbis/nbis_x86-64_linux/man/man1/txt2an2k.1

@@ -0,0 +1,130 @@
+.\" @(#)txt2an2k.1 2008/10/02 NIST
+.\" I Image Group
+.\" Michael D. Garris
+.\"
+.TH TXT2AN2K 1F "02 October 2008" "NIST" "NBIS Reference Manual"
+.SH NAME
+txt2an2k \- Converts a formatted text file into an ANSI/NIST 2007 file.
+.SH SYNOPSIS
+.B txt2an2k
+.I <fmttext in>
+.I <ansi_nist out>
+.SH DESCRIPTION
+.B Txt2an2k
+parses a specially formatted text file representing the contents of
+an ANSI/NIST-ITL 1-2007 file, and writes its contents to a new file
+in the standard compliant format.  This utility when used in
+conjunction with \fBan2k2txt\fR enables changes to be interactively
+made to an ANSI/NIST file using a simple text editor.
+
+.SH OPTIONS
+.TP
+.I <fmttext in>
+the formatted text file to be converted
+.TP
+.I <ansi_nist out>
+the output ANSI/NIST file
+.TP
+\fB-version
+\fRPrint ANSI/NIST stardand and NBIS software version.
+
+.SH INPUT FORMAT
+Every line in the input text represents a single information
+item for the ANSI/NIST file.  These lines are formatted as
+follows:
+.PP
+.RS
+\fIr.f.s.i \fR[\fIt.n\fR]=\fIvalue{US}
+.TP
+.I r.f.s.i
+references the information item with
+.RS
+.TP
+.I r
+the item's positional \fIr\fRecord index in the file
+.TP
+.I f
+the item's positional \fIf\fRield index in the record
+.TP
+.I s
+the item's positional \fIs\fRubfield index in the field
+.TP
+.I i
+the item's positional \fIi\fRtem index in the subfield
+.PP
+Note that all indices start at 1.
+.RE
+.TP
+.I t.n
+references the Record Type and Field ID from
+the standard.
+.RS
+.TP
+.I t
+the record's \fIt\fRype
+.TP
+.I n
+the field's ID \fIn\fRumber
+.RE
+.TP
+.I value
+is the textual content of the information item, unless
+the information item contains binary image data, in which case,
+the value is the name of an external file containing the binary data.
+.TP
+.I {US}
+is the non-printable ASCII character 0x1F.  This separator character
+is one of 4 used in the standard.  In VIM, this non-printable
+character may be entered using the ^v command and entering the
+decimal code "31".  In Emacs, this non-printable character may
+be entered using the ^q command and entering the octal code "037".
+
+.RE
+.RE
+\fBExample Input Lines
+.PP
+.RS
+1.5.1.1 [1.005]=19990708\(bu
+.PP
+This is the information item corresponding to the Date (DAT) field
+in the standard.
+It is the 5th field in a Type-1 record, and the Type-1 record is
+always the first record in the ANSI/NIST file; therefore, its record
+index is 1, its field index is 5, its subfield index is 1, and its
+item index is 1.  The value of this information item represents the date
+of July 8, 1999.  The '\(bu' at the end of the line represents the
+non-printable {US} character.
+
+1.3.4.1 [1.003]=14\(bu
+.PP
+This information item is part of the File Content (CNT) field.
+The CNT field is the 3rd field in a Type-1 record, so this
+information item's record index is 1 and its field index is 3.
+This information item is in the 4th subfield of the CNT field, and
+has an item index of 1; therefore, its value 14 signifies that the
+4th record (the subfield index) in this ANSI/NIST file is a Type-14
+record.
+
+4.14.1.1 [14.999]=fld_2_14.tmp\(bu
+.PP
+This information item corresponds to an Image Data field of a
+Type-14 record.  This field always has numeric ID 999 and is
+always the last field in the image record.  This Type-14 record
+is the 4th record in this ANSI/NIST file, so the Image Data information
+item has record index 4, and it is in the 14th field (field index 14)
+in the record.  This information item in the ANSI/NIST file contains
+binary pixel data, so the input value "fld_2_14.tmp" references an
+external filename from which \fBtxt2an2k\fR reads the item's binary
+data.
+
+.SH EXAMPLES
+From \fItest/an2k/execs/txt2an2k/txt2an2k.src\fR:
+.PP
+.RS
+.B % txt2an2k ../an2k2txt/nist.fmt nist.an2
+.SH SEE ALSO
+.BR an2k2txt (1F),
+.BR an2ktool (1F)
+
+.SH AUTHOR
+NIST/ITL/DIV894/Image Group

package/libnbis/nbis_x86-64_linux/man/man1/wrjpgcom.1

@@ -0,0 +1,107 @@
+.TH WRJPGCOM 1H "02 October 2008" "IJG" "NFIS Reference Manual"
+.SH NAME
+wrjpgcom \- insert text comments into a JPEG file
+.SH SYNOPSIS
+.B wrjpgcom
+[
+.B \-replace
+]
+[
+.BI \-comment " text"
+]
+[
+.BI \-cfile " name"
+]
+[
+.I filename
+]
+.LP
+.SH DESCRIPTION
+.LP
+.B wrjpgcom
+reads the named JPEG/JFIF file, or the standard input if no file is named,
+and generates a new JPEG/JFIF file on standard output.  A comment block is
+added to the file.
+.PP
+The JPEG standard allows "comment" (COM) blocks to occur within a JPEG file.
+Although the standard doesn't actually define what COM blocks are for, they
+are widely used to hold user-supplied text strings.  This lets you add
+annotations, titles, index terms, etc to your JPEG files, and later retrieve
+them as text.  COM blocks do not interfere with the image stored in the JPEG
+file.  The maximum size of a COM block is 64K, but you can have as many of
+them as you like in one JPEG file.
+.PP
+.B wrjpgcom
+adds a COM block, containing text you provide, to a JPEG file.
+Ordinarily, the COM block is added after any existing COM blocks; but you
+can delete the old COM blocks if you wish.
+.SH OPTIONS
+Switch names may be abbreviated, and are not case sensitive.
+.TP
+.B \-replace
+Delete any existing COM blocks from the file.
+.TP
+.BI \-comment " text"
+Supply text for new COM block on command line.
+.TP
+.BI \-cfile " name"
+Read text for new COM block from named file.
+.PP
+If you have only one line of comment text to add, you can provide it on the
+command line with
+.BR \-comment .
+The comment text must be surrounded with quotes so that it is treated as a
+single argument.  Longer comments can be read from a text file.
+.PP
+If you give neither
+.B \-comment
+nor
+.BR \-cfile ,
+then
+.B wrjpgcom
+will read the comment text from standard input.  (In this case an input image
+file name MUST be supplied, so that the source JPEG file comes from somewhere
+else.)  You can enter multiple lines, up to 64KB worth.  Type an end-of-file
+indicator (usually control-D) to terminate the comment text entry.
+.PP
+.B wrjpgcom
+will not add a COM block if the provided comment string is empty.  Therefore
+\fB\-replace \-comment ""\fR can be used to delete all COM blocks from a file.
+.TP
+\fB-version
+\fRPrint ANSI/NIST stardand and NBIS software version.
+
+.SH EXAMPLES
+.LP
+Add a short comment to in.jpg, producing out.jpg:
+.IP
+.B wrjpgcom \-c
+\fI"View of my back yard" in.jpg
+.B >
+.I out.jpg
+.PP
+Attach a long comment previously stored in comment.txt:
+.IP
+.B wrjpgcom
+.I in.jpg
+.B <
+.I comment.txt
+.B >
+.I out.jpg
+.PP
+or equivalently
+.IP
+.B wrjpgcom
+.B -cfile
+.I comment.txt
+.B <
+.I in.jpg
+.B >
+.I out.jpg
+.SH SEE ALSO
+.BR cjpeg (1H),
+.BR djpeg (1H),
+.BR jpegtran (1H),
+.BR rdjpgcom (1H)
+.SH AUTHOR
+Independent JPEG Group