xloadimage.1

speech signal process tools

as the foreground color, replicate the image, and overlay
"another.image" onto it at coordinate (10,10):
.sp
.ti +5
xloadimage -foreground red my.image -at 10,10 another.image
.PP
To center the rectangular region from 10 to 110 along the X axis and
from 10 to the height of the image along the Y axis:
.sp
.ti +5
xloadimage -center -clip 10,10,100,0 my.image
.PP
To double the size of an image:
.sp
.ti +5
xloadimage -zoom 200 my.image
.PP
To halve the size of an image:
.sp
.ti +5
xloadimage -zoom 50 my.image
.PP
To brighten a dark image:
.sp
.ti +5
xloadimage -brighten 150 my.image
.PP
To darken a bright image:
.sp
.ti +5
xloadimage -brighten 50 my.image
.SH HINTS FOR GOOD IMAGE DISPLAYS
Since images are likely to come from a variety of sources, they may be
in a variety of aspect ratios which may not be supported by your
display.  The \fI-xzoom\fR and \fI-yzoom\fR options can be used to
change the aspect ratio of an image before display.  If you use these
options, it is recommended that you increase the size of one of the
dimensions instead of shrinking the other, since shrinking looses
detail.  For instance, many GIF images have an X:Y ratio of about 2:1.
You can correct this for viewing on a 1:1 display with either
\fI-xzoom 50\fR or \fI-yzoom 200\fR (reduce X axis to 50% of its size
and expand Y axis to 200% of its size, respectively) but the latter
should be used so no detail is lost in the conversion.
.PP
When merging images, the first image loaded is used to determine the
depth of the merged image.  This becomes a problem if the first image
is monochrome and other images are color, since the other images will
be dithered to monochrome before merging.  You can get around this
behavior by using the \fI-geometry\fR option to specify the size of
the destination image -- this will force \fIxloadimage\fR to use the
default depth of the display instead of 1.  The standard behavior
might be modified in the future if it becomes a problem.
.PP
You can perform image processing on a small portion of an image by
loading the image more than once and using the \fI-at\fR and
\fI-clip\fR options.  Load the image, then load it again and clip,
position, and process the second.  To brighten a 100x100 rectangular
portion of an image located at (50,50), for instance, you could type:
.sp
.ti +5
xloadimage my.image -at 50,50 -clip 50,50,100,100 -brighten 150 my.image
.PP
One common use of \fIxloadimage\fR is to load images onto the root
window.  Unfortunately there is no agreed-upon method of freeing some
root window resources, such as colormap entries, nor is there a way to
modify the root window colormap without confusing most window
managers.  For this reason, \fIxloadimage\fR will not allow the
loading of images onto the root window if it cannot allocate shared
colors from the root window's colormap.  I suggest the avoidance of
multiple color image loads onto the root window, as these eat up root
window shareable colormap entries.  If you wish to have a slideshow,
use the \fI-slideshow\fP or \fI-prog_slideshow\fP option, possibly
together with \fI-fullscreen\fP.
.PP
One common complaint is that \fIxloadimage\fR does not have a
\fI-reverse\fR function for inverting monochrome images.  In fact,
this function is a special-case of the foreground and background
coloring options.  To invert an image with a black foreground and
white background (which is standard), use \fI-foreground white
-background black\fR.  This will work on both color and monochrome
displays.
.SH PATHS AND EXTENSIONS
The file ~/.xloadimagerc (and optionally a system-wide file) defines
the path and default extensions that \fIxloadimage\fR will use when
looking for images.  This file can have two statements: "path=" and
"extension=" (the equals signs must follow the word with no spaces
between).  Everything following the "path=" keyword will be prepended
to the supplied image name if the supplied name does not specify an
existing file.  The paths will be searched in the order they are
specified.  Everything following the "extension=" keyword will be
appended to the supplied image name if the supplied name does not
specify an existing file.  As with paths, these extensions will be
searched in the order they are given.  Comments are any portion of a
line following a hash-mark (#).
.PP
The following is a sample ~/.xloadimagerc file:
.PP
.nf
  # paths to look for images in
  path= /usr/local/images
        /home/usr1/guest/madd/images
        /usr/include/X11/bitmaps

  # default extensions for images; .Z is automatic; scanned in order
  extension= .csun .msun .sun .face .xbm .bm
.fi
.PP
Versions of \fIxloadimage\fR prior to version 01, patchlevel 03 would
load the system-wide file (if any), followed by the user's file.  This
behavior made it difficult for the user to configure her environment
if she didn't want the default.  Newer versions will ignore the
system-wide file if a personal configuration file exists.
.SH IMAGE TYPES
.PP
\fIXloadimage\fR currently supports the following image types:
.sp
.nf
  Faces Project images
  GIF images
  Portable Bitmap (PBM) images
  Sun monochrome rasterfiles
  Sun color RGB rasterfiles
  X10 bitmap files
  X11 bitmap files
  X pixmap files
  G3 FAX images
.fi
.PP
Normal, compact, and raw PBM images are supported.  Both standard and
run-length encoded Sun rasterfiles are supported.  Any image whose
name ends in .Z is assumed to be a compressed image and will be
filtered through "uncompress".
.SH AUTHOR
.nf
Jim Frost
Saber Software
[e-mail]
.fi
.PP
Other contributing people include Barry Shein ([e-mail]), Kirk
Johnson ([e-mail]), Mark Snitily (zok![e-mail]),
W. David Higgins ([e-mail]), and Dave Nelson
([e-mail]).  The \fInext_slide\fP program and
\fI-prog_slideshow\fP option are by Rod Johnson, Entropic Research
Laboratory ([e-mail]).
.SH FILES
.nf
.in +5
xloadimage              - the image loader and viewer
xsetbg                  - pseudonym which quietly sets the background
xview                   - pseudonym which views in a window
next_slide		- program to trigger advance to next slide
/usr/lib/X11/Xloadimage - default system-wide configuration file
~/.xloadimagerc         - user's personal configuration file
.in -5
.fi
.SH COPYRIGHT
Copyright (c) 1989, 1990 Jim Frost and others.
.PP
\fIXloadimage\fR is copywritten material with a very loose copyright
allowing unlimited modification and distribution if the copyright
notices are left intact.  Various portions are copywritten by various
people, but all use a modification of the MIT copyright notice.
Please check the source for complete copyright information.  The
intent is to keep the source free, not to stifle its distribution, so
please write to me if you have any questions.
.SH BUGS
Zooming dithered images, especially downwards, is UGLY.
.PP
Images can come in a variety of aspect ratios.  \fIXloadimage\fR cannot
detect what aspect ratio the particular image being loaded has, nor
the aspect ratio of the destination display, so images with differing
aspect ratios from the destination display will appear distorted.  See
\fIHINTS FOR GOOD IMAGE DISPLAYS\fR for more information.
.PP
The GIF format allows more than one image to be stored in a single GIF
file, but \fIxloadimage\fR will only display the first.
.PP
Only PseudoColor, GrayScale, StaticColor, and StaticGray visuals are
supported.  These are the most common visuals so this isn't usually a
problem.
.PP
You cannot load an image onto the root window if the default visual is
not supported by \fIxloadimage\fR.
.PP
One of the pseudonyms for \fIxloadimage\fR, \fIxview\fR, is the same
name as Sun uses for their SunView-under-X package.  This will be
confusing if you're one of those poor souls who has to use Sun's
XView.
.PP
Some window managers do not correctly handle window size requests.  In
particular, many versions of the twm window manager use
the MaxSize hint instead of the PSize hint, causing images which
are larger than the screen to display in a window larger than the
screen, something which is normally avoided.  Some versions of twm
also ignore the MaxSize argument's real function, to limit the maximum
size of the window, and allow the window to be resized larger than the
image.  If this happens, \fIxloadimage\fR merely places the image in
the upper-left corner of the window and uses the zero-value'ed pixel
for any space which is not covered by the image.  This behavior is
less-than-graceful but so are window managers which are cruel enough
to ignore such details.
.PP
The order in which operations are performed on an image is independent
of the order in which they were specified on the command line.
Wherever possible I tried to order operations in such a way as to look
the best possible (zooming before dithering, for instance) or to
increase speed (zooming downward before compressing, for instance).