Maybe someday I'll make this nicer, in the meanwhile, here it is for
others to modify and use in its current condition.

There are two tool sets mixed together here, one to create passive html
thumbnail pages of usually larger images for image review, using a
browser, the other to allow interactive culling or filing of images,
plus some self defense scripts for using the latter despite problems
due to unresolved massive memory leaks.

########################################################################
This first kit makes sheafs of html pages automatically that contain a
useful number of reduced size images of larger image files, for quick
review by the archive maintainer.  Run it, then bring up the "thumbs"
directory containing the results in your web browser, and review away,
html pageful by html pageful.  This being interpreted script code,
you need access to a Unix (I use FreeBSD on my Intel box; bye, Bill
Gates and all the problems your code causes) Korn shell (pdksh comes
with the FreeBSD distribution) to run, and to a Perl5 interpreter (one
also comes with the FreeBSD distribution, or can be downloaded from
numerous CPAN mirror sites).  Porting the ksh script to some other
scripting language should be easy, porting the Perl script to a
compiled language probably not so much fun.
########################################################################

dothumbs

  This Korn shell script is used as a driver to run thumbs.pl. It takes
  a list of local, one level deep source directory names, for the
  directories containing the source image data files, on the command
  line.  The output html script files always go to local directory
  thumbs (so it had better exist), but are named based in part on the
  input directory names (so keep those names short).  This script
  limits the number of thumbnails per html page generated to a quantity
  small enough (20) to support relatively fast local loading and
  perusing.

thumbs.pl

  This perl 5.x script builds individual html script pages based on the
  inputs it receives when called by dothumbs.  The "thumbnails" are rather
  large, too big probably for use in making index pages, though those pages
  would be a lot more useful using thumbnails this size.  Instead, these
  thumbnails are sized big enough so that the picture detail is usually
  obvious, but still several can fit on a screen window.

  Problem with this script: since defining both the height and width of
  the resulting thumbnail would alter the picture aspect ratio, only
  the height is specified.  For image files much wider than they are
  tall (single pixel row images to use for creating screen backdrops
  are the worst case), the result can be an image that gets magnified
  rather than reduced.  Since the built in image height is 200 pixels,
  a one pixel row high image will be magnified by 200 fold, consuming
  ridiculous amounts of memory and html page horizontal screen space.
  I used to know how to ask a JPEG or GIF file for its dimensions, the
  last time I wrote this code from scratch, so that I could check for
  this problem and limit the image in the other dimension if needed,
  but I've lost the trick since then.  Help is solicited in finding the
  information I need for fixing this problem, or in fixing WWW standard
  HTML 4.0 so that the height, width image size control functionality
  is supplemented by an even more useful maxheight, maxwidth aspect
  ratio preserving set of additional controls on image presentation.

########################################################################
This second kit brings up images one by one in a Tk requestor, with
buttons to control changing the source directory for images, moving the
current image data file to a new target directory, deleting the current
image data file, or just leaving the current file where it is.  The
display includes the image data file name and the source directory name
in informational labels.
########################################################################

spinswapinabox

  This innocuous Korn shell script just runs spinswap in an appropriately
  sized and parameterized color xterm window, in the processing background,
  but you want to put the window prominently in the foreground in your use
  of this kit.

spinswap

  This script runs a do-forever loop which pipes the normally
  interactive "top" program output run instead in batch mode through a
  filter, just to get the swap region memory use line , parse it, and
  put the parsed result out to the box provided by spinswapinabox.
  When all the right support is in place, the box then displays the
  percent of swap space in use and shifts the display to red when the
  in use percentage reaches 90%.  THIS IS A GREAT TIME TO PUSH THE DONE
  BUTTON ON THE Tk REQUESTER AND GET OUT OF reviewer.pl BEFORE YOUR
  COMPUTER CRASHES DEAD, DEAD, DEAD.

  Can you say "memory leak"?

reviewer.pl

Description: 

  This is the main script, in mixed perl-tk functionality, and is way,
  way cool, modulo a few more things to be done to make it really
  spiffy, and a GROSS, HORRIBLE MEMORY LEAK BUG.  If you don't need
  blinding speed, Tk is the _only_ way to implement a GUI tool.  Once
  learned a bit, Tk is simplicity itself to use as a GUI scripting
  language.  The Tk-embedded-in-Perl re-port from the usual Tcl based
  host scripting environment for Tk is a big joy to Perl fanciers who
  haven't taken the time to learn Tcl yet.

  The functionality provided is a row of source directory buttons, a
  row of target directory buttons, some extra buttons for "leave as is",
  "delete", and "Done" (reviewing), displays of the current source directory
  and source image file name, and a display of the current image or some
  excuse for why it isn't being displayed.

  Push a source directory button to (re-)build a list of image data
  files to be reviewed, then push move to <place>, leave as is, or
  delete buttons while the task remains fun.  It is perfectly OK to
  change source directories in the middle, or restart the current
  source directory from the front.  The one implication of having a
  captured list is that it can become stale.

  if you move some files into or out of the current source directory
  from outside the control of this tool, life will be nicer if you
  reacquire the list of files immediately thereafter.

Known Problems:

  1) Have I mentioned the MEMORY LEAK?  Due to problems which may not
  be my fault (see comments in the code about workarounds already
  tried), the program chews up at least the image size's worth of
  memory with every picture displayed.  I have a quarter of a gigabyte
  of swap space on the machine where I run this program, so I can
  survive this at all.  Others may not be so fortunate.  Even with my
  setup, it doesn't take much over a quarter hour of intensive image
  sorting to use all the swap space up.  I'd _love_ to have a fix for
  this.

  In partial compensation for this MEMORY LEAK problem, reviewer.pl is
  currently set up to work from an input directory list to a list of
  hidden (Unix style) output directories with the same names preceeded
  by a ".", so that when reviewer.pl is exited and re-entered, progress
  on shredding out a directory is preserved: one uses the "move to
  <itself>" button in place of the "leave as is" button to move image
  files from the visible directory to its hidden shadow directory so as
  not to have to go back through the set of "left as is" files in the
  next pass.

  The current work-around for the MEMORY LEAK, then, is to sort through
  images for a while, keeping a weather eye on the swap space consumed
  window you've set running, and when the 90% limit is reached, press
  the "Done" button on reviewer.pl's requestor, get out of the program
  completely, and re-start the program from the command line.  I could
  probably explain that in real English if I weren't about to do a face
  fault into the keyboard from exhaustion.

  2) The current level of CPAN JPEG image display support in Perl5-tk8
  is behind the current level of JPEG encodings in use in commonly seen
  files, so some perfectly valid images report problems about invalid
  JPEG internal encoding tags, to the command line window where the
  reviewer.pl program was started (which you should therefore keep
  visible too), and the previous image remains displayed.  WORKAROUND:
  Just push the file aside ("leave as is", "move to <itself>", or add
  some dedicated "move to problems" directory/button) and handle these
  few images by hand with a browser or other tool.

To Do list:

  1) KEEP THE TOOL ENTIRELY ON THE SCREEN.  Change the image display
  widget from a label to a scrollable canvas, and freeze the maximum
  size of the canvas, so that images don't end up overflowing the
  screen size and thus hiding the entire screen including all the
  controls for panning to see the rest of the image; OR, display the
  image scaled to fit a limited sized label so that very large images
  are displayed in "very large thumbnail" mode instead of full sized.
  Keep the scroll bars somewhere on the control panel side, independent
  of the image frame, to avoid pathological situations where a scroll
  bar control widget becomes itself inaccessible.

  2) PARAMETERIZE THE TOOL.  Accept the list of ordinary directory
  names from the command line (or as an input list when called
  internally, see below) and build the control panel from this
  information instead of from stuff hard wired in the program, AND
  change the display for these buttons from pack to grid style so that
  they can be laid out in multiple columns; the current implementation
  is running off the screen.  It may be that these control buttons need
  to be in a scrollable canvas or some such themselves, but the human
  interface done this way would be fairly hostile.  Think harder about
  better ways to do this: trade image size for control panel size?  A
  solution that scaled nicely to ridiculously large numbers of
  directories would be "really nice", and possibly variant solutions
  based on the number of source and target directories would be even
  nicer, so that the simple case is user friendly, and the nearly out
  of control case is possible at all.

  3) UPDATE THE JPEG SUPPORT.  The version of JPEG support pulled in is
  a "release" level behind the current one, because the maintainer of
  the JPEG support hasn't finished the port to the current perl-tk
  release level.  This may or may not be related to the MEMORY LEAK
  problem.  Doing this may involve completing the JPEG support upgrade
  "myself", an ugly choice since my Perl skills haven't come close to
  reaching that level of guruhood yet.

  4) OBJECTIFY THE TOOL.  This tool should exist as a library module,
  so that it can be called in to support larger Perl5 or perl-tk
  programs.  To do this, I need to better understand Perl modules and
  Perl objects, something which has been on my to do list for a couple
  of years now anyway.

  5) IMPROVE THE REVIEW ORDER.  Since this tool for me is mostly a
  culling tool, arguably the biggest image files should be reviewed
  first.  That way, if enough disk space is recovered tossing big files,
  to meet some goal, it may not be necessary to slog through the whole
  image list.  Sorting the image files by size (optionally?) would help
  facilitate this work.  PRO: Big files can be tossed early.  CON: Lots
  of little files could accumulate to consume the same or other scarce
  resources if the user gets lazy.