+Background information: A WIM image is an independent directory tree in a WIM
+file. A WIM file may contain any number of separate images. WIM files are
+single-instancing with regards to file data, so a file is stored only one time
+in the entire WIM, regardless of how many images the file appears in.
+.PP
+\fISOURCE\fR specifies the location of the files to create the new WIM image
+from. If \fISOURCE\fR is a directory, the WIM image is captured from that
+directory (see \fBDIRECTORY CAPTURE (UNIX)\fR or \fBDIRECTORY CAPTURE
+(WINDOWS)\fR. Alternatively, if the \fB--source-list\fR option is specified,
+\fISOURCE\fR is interpreted as a file that itself provides a list of
+files and directories to include in the new WIM image. Still
+alternatively, only on UNIX-like systems, if \fISOURCE\fR is a
+regular file or block device, it is interpreted as an NTFS volume from
+which a WIM image is to be captured using libntfs-3g (see \fBNTFS VOLUME CAPTURE
+(UNIX)\fR.
+.PP
+\fIIMAGE_NAME\fR and \fIIMAGE_DESCRIPTION\fR specify the name and description to
+give the new WIM image. If \fIIMAGE_NAME\fR is not specified, it defaults to
+the base name (excluding path to parent directory) of \fISOURCE\fR, but if this
+name already exists in \fIWIMFILE\fR, a unique suffix is added. Otherwise,
+\fIIMAGE_NAME\fR must be either a name that does not already exist as an image in
+\fIWIMFILE\fR, or the empty string to create an image with no name. If
+\fIIMAGE_DESCRIPTION\fR is not specified, no description is given to the new
+image.
+.PP
+As a special case, if \fIWIMFILE\fR is "-", the \fB--pipable\fR option is
+assumed and the WIM file is written to standard output in a special pipable
+format. See the documentation for \fB--pipable\fR for more details.
+.SH DIRECTORY CAPTURE (UNIX)
+This section documents how \fB@IMAGEX_PROGNAME@\fR captures files from a
+directory tree on UNIX-like systems. See \fBDIRECTORY CAPTURE (WINDOWS)\fR for
+the corresponding documentation for Windows.
+.PP
+On UNIX-like systems, when \fISOURCE\fR specifies a directory or a symbolic link
+to a directory, the WIM image will be captured from the directory tree rooted at
+this directory. This directory can be on any type of filesystem, and mount
+points are followed recursively. However, it is important to keep in mind that
+the WIM format was designed for Windows, so it cannot store all possible
+metadata from filesystems used on UNIX-like systems. The main information that
+will \fInot\fR be stored is:
+.IP \[bu] 4
+UNIX file owners, groups, and modes. (Exception: see the \fB--unix-data\fR
+option.) As a result, file permissions will not be stored, and files that are
+neither regular files, directories, nor symbolic links, such as device files and
+FIFOs, cannot be captured.
+.IP \[bu]
+Extended attributes. This mainly includes extensions to the traditional UNIX
+security model, such as SELinux security labels, POSIX ACLs, and capabilities
+labels.
+.PP
+Notes: hard links and symbolic links are supported by the WIM format and
+\fIare\fR stored. (Symbolic links are turned into "native" Windows symbolic
+links via reparse points; this process is reversible, e.g. automatically by
+\fB@IMAGEX_PROGNAME@ apply\fR.) Timestamps are stored with 100 nanosecond
+granularity and include last modification time (mtime) and last access time
+(atime), but not last status change time (ctime).
+.SH NTFS VOLUME CAPTURE (UNIX)
+This section documents how \fB@IMAGEX_PROGNAME@\fR captures files directly from
+an NTFS volume image on UNIX-like systems. See \fBDIRECTORY CAPTURE
+(WINDOWS)\fR for the corresponding documentation for Windows.
+.PP
+On UNIX-like systems, a special image capture mode is entered when \fISOURCE\fR
+is a regular file or block device. In this mode, \fISOURCE\fR is assumed to be
+an NTFS volume or volume image, and wimlib will capture a WIM image containing a
+full contents of the NTFS volume, including NTFS-specific data. This is done
+using libntfs-3g.
+.PP
+Please note that the NTFS volume capture mode is \fInot\fR entered if
+\fISOURCE\fR is a directory, even if an NTFS filesystem is mounted on
+\fISOURCE\fR using ntfs-3g. You must specify the NTFS volume itself (and it
+must be unmounted, and you must have permission to read from it).
+.PP
+The NTFS volume capture mode attempts to capture as much data as
+possible, including:
+.IP \[bu] 4
+All data streams of all files, including the unnamed data stream as well as all
+named data streams.
+.IP \[bu]
+Reparse points, including symbolic links, junction points, and other reparse
+points.
+.IP \[bu]
+File and directory creation, access, and modification timestamps, using the
+native NTFS resolution of 100 nanoseconds.
+.IP \[bu]
+Windows security descriptors, including all components (owner, group, DACL, and
+SACL).
+.IP \[bu]
+DOS/Windows file attribute flags.
+.IP \[bu]
+All names of all files, including names in the Win32 namespace, DOS namespace,
+Win32+DOS namespace, and POSIX namespace. This includes hard links.
+.SH DIRECTORY CAPTURE (WINDOWS)
+On Windows, \fB@IMAGEX_PROGNAME@ capture\fR and \fB@IMAGEX_PROGNAME@ append\fR
+natively support Windows-specific and NTFS-specific data. They therefore act
+similarly to the corresponding commands of Microsoft's ImageX. For best
+results, the directory being captured should be on an NTFS volume and
+\fB@IMAGEX_PROGNAME@\fR should be run with Administrator privileges; however,
+non-NTFS filesystems and running without Administrator privileges are also
+supported.
+.PP
+On Windows, \fB@IMAGEX_PROGNAME@ capture\fR and \fB@IMAGEX_PROGNAME@ append\fR
+try to archive as much data and metadata as possible, including:
+.IP \[bu] 4
+All data streams of all files, unless running on a version of Windows prior to
+Vista, in which case named data streams (if supported by the source filesystem)
+will not be captured.
+.IP \[bu]
+Reparse points, including symbolic links, junction points, and other reparse
+points, if supported by the source filesystem. (Note: see \fB--rpfix\fR and
+\fB--norpfix\fR for documentation on exactly how absolute symbolic links and
+junctions are captured.)
+.IP \[bu]
+File and directory creation, access, and modification timestamps. These are
+stored with Windows NT's native timestamp resolution of 100 nanoseconds.
+.IP \[bu]
+Security descriptors, if supported by the source filesystem and \fB--no-acls\fR
+is not specified. However, beware that unless \fB--strict-acls\fR is specified,
+the security descriptors for individual files or directories may be omitted or
+only partially captured if the user does not have permission to read them, which
+can be a problem if \fB@IMAGEX_PROGNAME@\fR is run as a non-Administrator.
+.IP \[bu]
+File attributes, including hidden, sparse, compressed, encrypted, etc.
+Encrypted files will be stored in encrypted form rather than in plain text.
+Transparently compressed files will be read as uncompressed and stored subject
+to the WIM's own compression. There is no special handling for storing sparse
+files, but they are likely to compress to a small size.
+.IP \[bu]
+DOS names (8.3) names of files; however, the failure to read them is not
+considered an error condition.
+.IP \[bu]
+Hard links, if supported by the source filesystem.
+.PP
+Note: the capture process is reversible, since when \fB@IMAGEX_PROGNAME@
+apply\fR (on Windows) extracts the captured WIM image, it will extract all of
+the above information, at least to the extent supported by the destination
+filesystem. One exception is that since encrypted files are stored as
+unencrypted, their data will not be available if restored on a Windows system
+that does not have the decryption key.