readme_pf.txt

Photophile 0.2
September 12, 2002

Greg Ward
Anyhere Software, Unincorporated
Albany, California
[email protected]

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

[email protected]