Photophile 0.2
	September 12, 2002

	Greg Ward
	Anyhere Software, Unincorporated
	Albany, California
	gward@lmi.net

Since I don't have any documentation or help screens going, yet, I thought
I'd give a quick introduction for people who are willing to help me out
with some alpha testing.

Photophile is an image browser and cataloging application.  I
started developing it in Spring of 2001, under the newly released
Mac OS X, which combines the best of Unix and Mac together into a
reasonably seamless whole.  The first 2-3 months were spent on
system-independent C and C++ libraries, including a database manager,
cache manager, thumbnail manager, and image processing library.
Subsequent work has focused on the GUI development and getting the
darned thing to do what I want.

Photophile works on local files only, and is not internet savvy at
this time.  It reads and writes JPEG, TIFF, and Radiance-RGBE
(often called HDR for "high dynamic range") image formats.

Here is a brief list of goals I had in developing this software:

1.   Track image files rather than managing their location or storage.
2.   Subject, time-line, keyword, owner, and album indexing.
3.   Fast, interactive response for browsing directories or catalogs.
4.   Read and interpret the Exif header information on digital camera images.
5.   Facilities to create and view high dynamic-range images.
6.   Accurate color reproduction.
7.   Automated web page and photo album assembly.
8.   Displayable and editable image information.
9.   Drag and drop functionality.
10.  User-defined database fields.
11.  Direct connection to digital photo printing services.
12.  Portable across platforms (Mac, Unix, Windows).

Of these goals, I'd say I've covered 1-6 pretty well, and I have
web pages going (goal 7) but not printed albums.  Goal 8 is done,
and drag and drop (goal 9) is working, except for dragging to the trash.
However, some basic functions like printing are still not working at this
point.  Despite its incomplete state, Photophile is quite functional
as an image display, browsing, and cataloging tool, and you can
always write out pictures in TIFF format and pass them to other
programs (like Preview) that can print them adequately.  I could
easily add direct support of PostScript printers, but I want to do
it properly with the Print Manager, and that's more work.

Portability across platforms is something I'm addressing by
enlisting the help of a friend who can tolerate Windows.  He
has said he would give it a shot, and he's extremely capable,
but I don't think he quite knows yet what he's getting into.
All the library code is portable, and has been compiled under
Windows and Linux already, but some of it is a bit tricky to 
understand and apply in a GUI...  As for Linux, I'm going to
tackle this much later on an "as time permits" basis, which 
is how I've had to approach this entire project.

The current version of the browser, which I'm calling 0.1
without any real reason for doing so, contains the following
set of capabilities and features.  Some of these were
secondary goals I originally intended, and some are cool
things that came along as I developed the program:

o    Tracks image files as they are moved from one location to
	another by recording all previously known whereabouts
	and keeping a list of directory migrations.  From the
	user's perspective, the program only asks for
	help every once in a while to in find an image.
	The rest of the time, it just seems to know.
o    Image data is never modified by the program.  The user must
	explicitly write out a new file if they wish to change
	an image or write out the displayed pixels.  The image
	is displayed according to field values in its database
	record, including orientation, cropping, red-eye removal, etc.
o    All thumbnails from all catalogs are cached together
	in a thumbnail directory with 6 320x320 thumbnails
	per JPEG contact sheet.  This provides for large
	thumbnail views (previews) even when the original
	images are not present on the system, while reducing
	the storage to the equivalent size of individually
	stored 160x120 thumbnails.
o    When smaller thumbnails are displayed in the browser,
	the preview size is instantly accessible with an
	option-click of the mouse over the thumb.  Other
	information about the image, such as capture date,
	title, keywords, etc., is also displayed in this
	"detail view."
o    Thumbnail images are associated with image files by the
	original file size and a fast hash on the raw file bytes.
	This allows multiple copies of the same file
	to share thumbnails, and avoids regenerating
	thumbnails of images that have been seen before
	but not cataloged.
o    Interactive browser speed is maintained for digital
	camera images by displaying their Exif thumbnails
	while the higher resolution thumbnails are being
	generated.  The only noticeable delay in looking
	through directories is the time spent generating
	hash values and reading the Exif information,
	which takes about a tenth of a second per image,
	independent of image size and resolution.  Thumbnails
	of images that have already been cataloged display instantly.
o    Large image catalogs don't seem to cause any problems
	for the browser.  I have a database indexing over 7000
	digital camera images.  It takes about 1.5 seconds
	to load on start-up, and all 7000 records can
	be pulled up in the browser in under 4 seconds.
	Keyword searches are too quick to time.
o    Image records use cut and paste with tab-separated
	fields, which may be edited in a text editor or
	spreadsheet program.  Importing and exporting
	records and catalogs to text files is supported
	directly by the browser, facilitating database
	manipulation and conversion.
o    Entering new images into a catalog is quick and easy.  You
	simply look them up on your file system (or CD-ROM),
	click "Add" and specify a subject (defaults to the
	parent directory's name).  I can add a set of 100
	images in about 2 minutes, including keyword entries.
o   High dynamic-range images may be built up from multiple
	(i.e., bracketed) exposures.  My Olympus C-3040 will take
	5 shots in 1.5 seconds, separated by 1 f-stop each.  (I
	wish it were more.)  I get the JPEG files, select them in
	Photophile, then pull down the "Make HDR..." item under
	the File menu.  It asks me if I want to use the response
	function it computed previously for the C-3040 or create
	a new one, and if I want it to automatically align my
	exposures (usually a good idea, even with a tripod).  After
	about a minute, I'm looking at a tone-mapped display of a
	high dynamic-range image, which I can write out in Radiance
	RGBE or TIFF (float or LogLuv) format.  I can interactively
	go up and down on my displayed exposure, try out different
	tone-mapping options, and write out the displayed image in
	a low dynamic-range format such as JPEG or TIFF 24-bit RGB
	if I like.
o    Cropping and red-eye removal are recent additions, which make
	the displayed images more pleasing.  The rectangles to crop
	and apply red-eye removal in are stored in fields in the
	database, so nothing is lost and (almost) no additional
	storage is required. 
o    The catalog record information takes up around 512 bytes/image,
	depending on field settings, and another 15 Kbytes/image
	or so for thumbnail storage in the separate thumbnail
	cache.  My 7000 record database takes 2.5 Mbytes, plus
	about 100 Mbytes for all the associated thumbnails.
	Considering this DB represents over 5 Gbytes of
	image data, that seems quite reasonable (2%) in terms
	of local storage, and the DB fraction is only 0.05% of
	the total.  Since the thumbnails are stored in a cache, a user
	who is short on disk space can specify a suitably small limit
	and avoid even this expense.  This may be important for
	laptop computers, which often have small internal disks.  Since
	laptops are ideal for handling digital camera data in terms
	of their portability, I consider this an important issue.
o    Memory management is handled within a user-adjustable limit in
	Photophile.  It doesn't depend on virtual memory for image
	and thumbnail caching, which tends to cause system-wide
	swapping and delays.  Instead, a low-level cache manager
	frees memory as needed based on LRU and the time requirements
	for restoring or regenerating the sub-classed object.  The
	result is snappy thumbnail and image display within a fixed
	memory footprint.
o    The image processing library uses a C/C++ plug-in architecture,
	which is designed to make it easy to add support for various
	formats.  As soon as I get some time, I intend to link to
	the QuickTime library to leverage all of the image formats Apple
	supports.  I needed to support TIFF directly to get the LogLuv
	stuff to work properly, and floating point images are not
	supported at all by Quicktime, so there was a need to develop
	my own library.  Fortunately, most of the code for this
	was already laying about in one form or another.

I'm sure I'll think of more to say and more to add soon enough, but that's
about all I can come up with at the moment.  The program continues to
evolve daily, and I welcome bug reports and suggestions from everyone.

Enjoy!
-Greg

gward@lmi.net