Street Photography Magazine

The decision to implement image database

software has significant consequences. Once

you have settled for a particular product,

switching to another almost always involves a

lot of effort and the risk of losing valuable

image data. System architectures often

contain idiosyncrasies that can make life very

difficult should you decide to migrate your

data. Different manufacturers use very

different approaches to file import and

management, so it is essential to find out how

a particular product works before you commit

your digital photo collection to storage using

a particular brand of software.

Image Viewer vs. Database

Until quite recently, you needed a whole

arsenal of tools to manage and optimize your

digital images, including a viewer, a RAW

converter, an image editor and probably also

a database. Nowadays, strict differentiation

between the individual components of such

a system is largely passé. Most image viewers

now have built-in thumbnail caching

functionality, even if it is not as powerful as

that included with most dedicated image

database products.

In the endless bid to win new customers,

software manufacturers continue to include

an increasing number of features in their

products, which makes them more powerful,

but also more complex. Incorrect matching of

thumbnails to images is a problem that is

unknown in the world of image viewers – a

thumbnail is rendered from the current state

of the image file, and nothing can really go

wrong. Although serious problems are rare,

database thumbnail caches are nevertheless

more suscpetible to false mapping errors.

In spite of their similar feature sets, image

viewers often do better than unwieldy

database programs at pre-sorting large

collections of images. It is often using

programs like Nikon’s ViewNX 2or the popular

Photo Mechanic to sort and pre-select your

images before importing them. An image

viewer is simply more agile if you need to do

a lot of copying, moving and deleting before

you start work in earnest. Once you are sure

that there are not going to be too many

significant changes to the content of your

collection, it is time to import your image data

or synchronize it with your database.

File Import

One thing a image database doesn’t do is

import the actual files to data fields, as this

would make it unfeasibly large. It is possible

to use BLOb (Binary Large Object) technology

to save image files directly to a database, but

managing and searching the huge amounts

of data that this creates is slow and clumsy.

Most database software imports links to the

files it manages using one of two basic

approaches:

Import links, copy images to onboard

file system:This approach involves copying

all the image files to a new folder and

renaming them. The database program is

then the only software that can access the

new folder. This approach is used by pixafe,

which is based on the IBM DB2 architecture.

Renaming files and removing unwanted file

extensions ensures that the database itself is

the only program that can read (and alter) the

results. Among our test candidates, Cumulus

and Aperture use this approach, although both

also enable the user to use links to existing

folder structures if desired.

This type of system is great for preserving

data integrity but also has disadvantages.

Data import usually destroys the original

folder structure, so you have to decide which

is the lesser of two evils: either keeping a

parallel set of image files in your conventional

file system (which means you need twice as

much disk space and have to keep both

collections up to date), or crossing your

fingers and deleting your source folder

once you have committed your precious

images to the potential vagaries of a particular

manufacturer’s software.

If you take the latter route, you can only do

what the software manufacturer wants with

your data, and it is no longer possible to take

a quick look at the source file system to check

whether everything is shipshape. If you are a

home user, we only recommend this

approach if you are prepared to keep a

separate copy of your files for safety’s sake.

This is also a practical approach if you only

want to import some of your images for the

duration of a particular project or to organize

them for sale. In such cases, the amount of

administrative work you have to do will

remain manageable.

Committing to a database also makes it

much more difficult to switch to a different

system later on, as you can never be sure that

a proprietary database will be capable of

exporting clearly structured data that is

readable to other software. The success of

such an export maneuver depends on the

degree to which a database writes its own

management data to the metadata of the

Image Database Software | File Import

File Import and Management

An image browser without caching

functionality has to re-read the image

data and recreate the thumbnail every

time it is accessed. This makes previews

slower, but guarantees that they show the

current version of the image.