Digital Camera Home > Dealing with Space Junk

Dealing with Space Junk

By Mike Pasini, Editor
Imaging Resource Newsletter

"It isn't so much where to put everything you create . . . but finding it -- bringing it back up -- once it's filed away."

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 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 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.



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.

"You have a lot of options, ranging from exotic image analysis . . . to plain old exploitation of your operating system."

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 ( 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 ( 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 ( 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.