Dealing
with Space Junk
By Mike Pasini, EditorImaging Resource Newsletter
 |
|
|
Out of the blue, in the middle of a front yard not very far from here, a hot
projectile burned itself into the grass with a thud. The neighbors who had heard
it whistle through the air gathered around but didn't recognize it. It didn't
look like anything any of them had ever seen before.
So they took it to the local institution of higher learning where an assortment of academically inclined specialists took a look at it and concluded it was indeed man-made. Man-made but from outer space. A piece of space junk, warped into an unrecognizable blob by re-entry, returned home.
What goes up must come down.
What Goes Down
Ask anybody who deals with digital images about space junk, though, and they'll tell you that the real problem is what goes down must come up.
It isn't so much where to put everything you create with a click of that digital shutter button, but finding it -- bringing it back up -- once it's filed away.
To do so, you need a system a little less random than that used by our unrecognizable blob from space.
The trick to designing a system that works for you, is to build one that frees you from ever having to think about it. So whether you are so organized you make everyone else nervous, or so disorganized you make them all crazy, we'll help you design a system you can live with.
You have a lot of options, ranging from exotic image analysis (currently in development) to plain old exploitation of your operating system (a staff favorite).
Image Analysis
If you happened to catch the Feb. 17 (2000) New York Times' Circuit section, you may have read about a new category of search software for images. But searching for images based on nothing more than their content is a tough nut to crack.
And, as the article by Lisa Guernsey pointed out, several companies are asking
themselves if end users wouldn't be satisfied with a more rudimentary image
retrieval scheme than one based on perfect matching. Searching for images with
specific colors or patterns, for example, rather than polar bears or basketballs.
AT&T is developing a product code-named Shoebox (whose screen shots you
can salivate over at http://www.uk.research.att.com/dart/shoebox
if you like). Images (polar bears, in fact) are analyzed for color, texture
and shape before being indexed by the program. A database search for images
with similar characteristics retrieves thumbnails of the matches. That's where
you, as the human observer, comes in, weeding out the fur coats from the polar
bears.
IBM has developed a technology it calls "Query By Image Content"
or QBIC that also analyzes colors and patterns to characterize images. Visit
http://wwwqbic.almaden.ibm.com
for an example of the technology at work on a stamp database.
It's no accident that these prototypes don't have betas or free downloads to play with. It's difficult stuff still on the drawing board. The engineers don't need to be reminded.
And while it would be terrific to see a program that could retrieve all the images of Nephew Lawrence you've ever taken, it's hard enough to identify them yourself. It isn't easy to recognize old Larry as Baby Lawrence, Kid Lawrence, Teen Lawrence (especially) and Collegian Lawrence, say. Front and rear. Side view. Haircut or not. Sunglasses, too. Halloween masks. You get the picture. This stuff has limits.
State-of-the-Art
But the problem of organizing images so you can find them has been with us
long enough to have a few well-known, reliable solutions. Not to mention its
own niche name: media asset management.
|
|
|
|
For the most part, the solutions have been developed for high-end customers
handling huge albums of images. A comfortable thought. But even early on, the
bright idea that consumers could really use something like this flashed in certain
minds at, say, Kodak, where Shoebox (no relation to AT&T's product) was
developed to catalog images.
When Kodak abandoned Shoebox, it graciously arranged to update its users at
no charge to Cumulus, Canto Software's cataloging software. Now at Version 5,
Cumulus can be purchased in a $99 single-user version (which is also sometimes
bundled with hardware), as well as the enterprise version installed in several
large publishing installations.
Cumulus (http://www.canto.com)
creates a database of thumbnails, each of which has a number of keywords assigned
to it. Manually. Which can be kind of tedious, but that's the way the database
game is played. To its credit, the program can be scripted and handles files
besides images (like Quark XPress documents).
A similar database scheme is employed by a new product on the scene, FotoStation.
Developed in Europe over the last two decades and employed by Hasselblad, FotoStation
(http://www.eroket.com)
also has a rich, high-end heritage whose polish can be appreciated in the single-user
version. It adds a number of handy image editing and printing functions that
distinguish it from the competition.
There is nothing, by the way, to prevent you from using your own database program
to track your images, just as you might your CDs or recipes or books. But somehow,
this option has always seemed to us a lot more trouble than it is worth.
There are also shareware programs for every platform that promise to do the
job.
And for those on the sort of limited budget that stumps even economic wizards
like Alan Greenspan, the free UGather from the University of Minnesota (http://upresent.umn.edu)
catalogs various multimedia files, building keywords from folder and file names.
We intend to use a few of these products over the next few weeks. We'll let
you know what happens. If they don't make it easy (fun even) to update your
database, they won't be much help when you ask them to find something.
All the features in the world don't mean much if the product makes you feel
like you're shoveling snow in winter and mowing the lawn in summer.
Roll Your Own
So how do you build a system that makes it easy to find your images and doesn't
make you feel like you're doing a chore?
Capitalize on the resources built into your system to begin with -- your file
system. You can't avoid your file system, so you may as well exploit it.
We used to have a standing offer (hereby retracted) of $100 to anyone whose
computer problem could not be unraveled by a clear understanding of the four
parts of a filename. Before being reincarnated, so to speak, as a lowly editor,
we'd thought of developing this into a game show, with Regis Philbin as a sort
of Ed McMahon walking around with a huge $100 check. But he was booked.
The four parts of a filename, should you ever need to know, are:
1. The volume name (e.g.: "C:\" or "Macintosh HD:")
2. The directory and sub-directories (if any) (e.g.: "DOS\" or "Documents:")
3. The root name (e.g.: "AUTOEXEC" or "Read Me")
4. The extension (e.g.: ".BAT" or ".txt")
This tends to be true for all operating systems, you'll notice, should you
have the misfortune to operate more than one of them. You will not be phased
by either "C:\DOS\AUTOEXEC.BAT" or "Macintosh HD:Documents:Read
Me.txt" ever again.
There are four parts to do four different things. Let's go through them.
The volume name tells us where the file can be found. The internal hard drive
(as in our example above), a Zip, a CD, some floppy. Logical device, physical
device.
The directory and sub-directories, together with the volume, give us the path
name of the file. The path name in our example is "C:\DOS\" or "Macintosh
HD:Documents:"
The root name is pretty much what we call a name, period. The basic name of
the file. Without the root name, we haven't got anything. Budget, image, or
email. More on that later.
And the extension is often our only clue to what the file is: .jpg for JPEG,
.tif for TIFF, .txt for an ASCII text file, etc. So we don't want to mangle
our extensions. Tread carefully here.
Those are the rules. But how do we play the game?
First, think about your images and the way you shoot. Do you shoot business
separately from pleasure? Do you shoot more than one event at a time, storing
them all together?
Then work out a naming system for your volumes. Give meaningful family names
to your external (and infinitely extendable) storage like floppies, Zip disks,
SyQuests and CDs. You might name the volumes by year or season or location or
client, depending on how you work.
These broad categories can, by using well-named directories and sub-directories
(or folders), be organized into smaller collections. Just don't overdo it. Remember,
you don't want to have to remember anything. A hierarchy of one or two levels
is deep enough, Jack Handy.
Fortunately you don't have to think much about the root name at all. Your camera
names each image. Let it -- and forget it (see, this forget-it system works).
Although I would be remiss not to mention that some software (like Cameraid)
will automatically rename all your images to the date and time, in a format
you describe. And if you find that useful, indulge.
So all you really have to think about -- er, design -- is a simple way to file
your images in folders.
An Example
Here's one scheme, but by no means the only way to do it. You will, like us,
prefer some variation.
Name your storage medium (let's just say it's a Zip disk) by the amount of
time it takes to fill it. If that's a year, name it "2000"; a month,
name it "2000.01" for January. A week? Get a CD-R drive.
On each disk (or disc) create folders named by date. Years, if you have the
space. Months within years is nice, too. Use numerals instead of names and they
will even sort conveniently for you. In fact, don't be too clever here. If there's
a chance of having two Januarys on the disk, use the year name, too (e.g.: "2000.01"
-- yes, even MS-DOS supports extensions in directory names).
Every disk enjoys the same arrangement, which reflects the calendar we all
know and love (and if you jot down important dates on your kitchen calendar,
save it: it's an index to your pictures).
Every directory enjoys the same arrangement, too. So if you're looking for
pictures from Christmas when Franz visited to celebrate the Millennium, you
already know the volume name (the disk labeled "1999"). And you know
you should be looking in the directory "1999.12/" or "1999/12/"
or "1999:12:" depending on syntax of your system. There's nothing
to remember.
In each directory named for the month, store directories by shoot number ("01
Labor Day" would be the shots you took on Labor Day, "02 Labor Day"
would be the second batch you took, if there was one, thus avoiding overwriting
file names). The numbers should have as many digits as shoots in your most active
month. If you do a hundred or so a month, that would be "001 SuperBowl".
If you're a weekend warrior, stick with "01 SuperBowl" just to impress
your friends.
This beats organizing strictly by event (there are a lot of Christmases) or
camera model (been there, and barely got back) or image type (what for).
But it is still merely how you set the table, not what you dish up. Dishing
up -- finding the shots you're looking for -- isn't simple.
A search of event names (like "Christmas" or "SuperBowl")
using nothing more than your operating system's file searching tools will list
every place (or volume) you need to look. And narrowing the search is the best
this system can do. Which is often good enough, considering it maintains itself.
But if you need to hone in more closely, you're ready for the next step up:
a database of the images themselves, indexed by keyword. Which means a little
time spent cataloging the images.
But then you'll be able to tell "Baby Lawrence" from space junk.
Before either of you go into orbit.
