Image problems . . . and how to solve them

Image problems . . . and how to solve them

Electronic images are everywhere these days. The Web, corporate intranets, CD-ROM and other media have led to a boom in the sheer volume of digital images floating about in the ether. In many cases, access to these images is mission-critical, and careful archiving, storage and retrieval of them in a timely manner can make a significant difference to a company's competitive edge. Matthew JC. Powell looks at the options available for tracking digital assetsHow are your assets covered? Chances are you've got pretty good inventory controls, so you know where your stock is, how much of it you have, and how quickly you can get hold of it and send it to a customer. Your business depends on it, so you take care. For publishers, the images, documents and other electronic media types they handle are equally mission-critical, so publishers have known even from the dawn of time to keep a close eye on their digital assets.

But think about this: you may not think of yourself as a publisher, but if you're running a Web site with e-commerce, maybe a product catalogue and some colourful logos, chances are you're juggling hundreds of images or more. Presuming that your business will grow and so will the importance of your Web site, that library of images is going to expand rapidly and the efficient handling of those images is going to become more and more vital.

Congratulations, you're a publisher.

The problem for many companies which have suddenly and often inadvertently found themselves thrust into the brave new world of electronic publishing is that their libraries of digital images usually grow organically, without forward planning. Someone picks up a digital camera and takes a few snaps of products for use on the Web site, and they all have names like "Boxshot3.jpg" and so forth.

This is adequate while the Web site is a small operation with a small number of people running it, all of whom know pretty well what images are available and what they correspond to. But as companies put more emphasis on Web-based business, they tend to add people to those small teams. And as the Web sites grow in complexity, the number of images grows almost exponentially. Pretty soon, no one has a real handle on what all those file names mean, and no one's sure which shot goes with which product.

Or, to take another example, your marketing department probably has a library of digital images on hand which have been scanned for use in advertising. Perhaps they have sensible names, perhaps they don't. Depends on your bureau. What if one of your competitors suddenly advertises a product at a fantastic special price that's going to take sales away from you? How critical is it that you are able to get that image and adjust your advertising accordingly?

In this fairly extreme example, a digital media database would pay for itself in short order by preventing lost sales. In the Web example, the saving comes from more efficient use of time as staff are able to retrieve images quickly and efficiently instead of opening up thousands of thumbnails.

When you create a database to keep track of assets, a key feature in the design of that database is that its contents can be easily found. In the case of text-based assets, this is easy. When you're archiving a collection of digital images, video or even sound files, the ability to search content is rather less simple.

Image management databases, therefore, have tended to rely on keyword indexes for searching. The problem of this approach is obvious - the database only knows what a file contains if it is told explicitly at the time that the image is archived. For instance, let's say an image contains three ducks and a boat you photographed at Uncle Virgil's birthday party. Will someone be able to find it when they're looking for pictures of ducks if it's archived as "Virgil's party"? Probably not.

Also, since there isn't a single standard method for assigning these keywords, everyone who creates such a database essentially reinvents sliced bread. So while the creator of the database with Virgil's pics in it might have some idea how to find the ducks, someone else coming along will certainly fail to find the picture with the drakes in it that they liked so much. Eventually, there will be software that is able to intelligently understand the contents of image files and interpret searches along different criteria than arbitrary keywords.

Types of database

The two most common protocols for querying a database are Structured Query Language (SQL) and Open Database Connectivity (ODBC), a Microsoft standard. Both provide links between applications (such as database or spreadsheet software) and database engines such as Microsoft SQL Server, or Sybase and Oracle servers. SQL has been around for a while, but Microsoft is masking a big push towards getting acceptance for ODBC.

A relational database-management system (RDBMS) is at the core of most leading media database packages, including Canto's Cumulus and Luminous Media Manager. Relational databases are very useful for databases containing words and numbers, since these data types are easily contained within the database itself.

A media database, on the other hand, generally consists of thumbnail images which contain pointers to much larger images, often held on remote servers, CD jukeboxes and the like.

For this reason, the database may know very little about the content of any particular entry.

And relational architecture isn't the best way to handle extremely large amounts (we could be talking about terabytes) of image and video data, especially because SQL and other relational query techniques have no way of searching the content inside a multimedia file.

One possible alternative on the horizon is an object database, in which data are organised as hierarchies of related objects rather than as tables of rows and columns. A key advantage of an object-oriented database is that its structure, or schema, can easily be extended to include new data types.

A little further, just over the horizon, an even more powerful technology is growing closer to fruition that combines the flexibility of relational databases and the power of object-database architectures.

It's called, unsurprisingly, the object-relational database, and so far it's used by only one program, Bulldog, from the Bulldog Group. At present, this product is not distributed in Australia.

Then, of course, there's the Web. It's becoming almost a boilerplate in articles like this one that at some point you say "and of course the Web changes everything". The widespread adoption and use of the Web means that image stores do not need to be held on local servers, but can reside in central servers which can be accessed remotely. Conversely, image libraries held on a number of widespread local servers can be accessed remotely as if they were in a central location.

In response, many vendors are rapidly re-engineering their server software so that Web browsers can be used as clients. In some cases, this means that the software has the ability to dynamically generate HTML documents from query searches.

Time is money

Management of digital assets is a young market, but a growing one. The text, image and multimedia archives a publisher needs to keep track of can only grow. More important from a growth perspective is the fact that, thanks to the Web and the dawning age of e-commerce, more and more businesses are finding themselves becoming publishers. The time is ripe for smart resellers to get in "on the ground" of this emerging market and devise methods for your customers to manage the large and growing volumes of digital information they need to be available at a moment's notice.

It's a simple "time is money" proposition. If you have clients creating and trying to handle large libraries of digital information, this should be a no-brainer.

Alchemy: turning digital media into goldDeveloped by Information Management Resources (IMR) as a document archiving solution specifically for use with writable CD-ROM media, Alchemy has matured to a full-blown digital asset management solution which works with magneto-optical disks, jaz cartridges and others.

Australian distributor SCSI Corporation initially sold Alchemy as an adjunct to its main business of large-scale storage solutions such as CD jukeboxes, but now supports the full range of Alchemy functionality, and has established it as the pre-eminent software in its category.

As well as whatever storage hardware you purchase, Alchemy comes with four main software components: Alchemy itself, Datagrabber, Scan2CD and CAD2CD.

Alchemy Gold 5 consists of two applications: Alchemy Build and Alchemy Search. Alchemy build is used by those in the organisation responsible for creating document archives. Alchemy Search is a 32-bit Windows client for read-only access to the databases created with Alchemy Build. It includes viewers for over 250 different media types, including images, word processor files, spreadsheets and various different database reports. Using an optional Web publishing module, it is also possible to publish Alchemy databases on a Web server for viewing by any HTML browser - useful in mixed-platform environments.

Scan2CD is an optional "front end" to Alchemy which controls scanning, OCR, indexing and transfer to the Alchemy database. It includes support for over 100 different SCSI-based scanners. Datagrabber is the high-volume companion to Scan2CD, and allows the end user to create templates for indexing documents, and then parses the content of scanned documents into those templates.

Other features

CAD2CD is also optional, and adds the capability to view, index and search CAD files in DWG or DXF formats.

Robert Ek, managing director of SCSI Corporation, told ARN that Alchemy is an ideal alternative to archiving documents on paper, since up to 100,000 pages of paper can be stored on a single CD-ROM. With a CD-ROM jukebox, that means that many millions of pages can be accessed almost instantly over a network without the need for large filing cabinets.

And because the documents cannot be altered once they are archived, Ek claims, Alchemy-archived documents are acceptable as legal evidence in most states of Australia as if they were originals.

The Australian Stock Exchange is one of Alchemy's biggest customers in Australia, having set up a totally automated nightly procedure to process over 300 reports through datagrabber into a database. In the morning, the reports are available for staff to search, display and reprint, without the risk of misplacing important documents on the way to the photocopier. Once a month the database is written to a CD and put into a networked CD-ROM tower. According to SCSI Corporation, the ASX has saved in printing costs and the cost of maintaining its previous microfiche archive system. There have also been improvements in in-house productivity and response time to customer queries.

Hardware requirements for Alchemy are a "reasonable" PC running Windows 95/98 or NT; a large hard drive for creating databases; a scanner for OCR and image capture; and some kind of writable archiving media such as CD-R, CD-RW, jaz or magneto-optical disk.

RRP is $6301 RRP. Alchemy is available from:

SCSI Corporation Tel (02) 9894 6033

Follow Us

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.


Brand Post

Show Comments