Message-Id: <199901192138.OAA33780@dns.ccit.arizona.edu> Date: Wed, 20 Jan 1999 10:37:35 +1300 From: Richard Knuckey <mailto:rknuckey@TECHNICHE.CO.NZ> Subject: Re: Image management To: mailto:IMAGELIB@LISTSERV.ARIZONA.EDU
Commercial Image Databases tend to be skewed to serving specific markets, and very very few are any good for a more general market such as long-term archiving and photo-bank. Most Image Database packages on the market are designed as Pre-press automation tools. They key off automatic features of images such as file name, file type, size, resolution and colourspace.If you're really lucky they will let you assign keywords that you can search for.
They fall down because there is an assumption that the primary user is looking for an image that they know exists in the collection. If you don't know what image you are looking for, but are after candidate images for a project, then they are pretty useless.
To cover our needs (product shot library) we developed our own system, running on UNIX, using CGI's talking to a SQL database (in this case MySQL). ImageMagick was used for format conversion and creating previews and positionals. Other code was written to extract information about scans in various formats (ie image size, colour depth)
The database is fully searchable. They key difference is that we don't use keywords. Instead each image has a number of attributes that the operator importing the image has to full out. These attributes are not concrete, but are designed to remind the operator of the kind of information we need associated with an image. For the Product shot database this is things like brand and model number. Each image also has a sentance long description of what is in the picture. This description is where the key to success lies--instead of trying to extract fuzzy information from the picture like dominant colour, the operator types in what the picture is. ie. "Red Stapler on blue background".
Any text associated with an image, ie all the text from the attributes and the description is indexed against the image.
The primary interface for searching for images is the full text search. if I want a picture of a Red Stapler, I simply search for "+red +stapler". The search engine uses infoseek style modifiers, an implicite OR with no operator, + for "must include" terms, and "-" for must not include terms. +red +stapler" is the logical equivalent for "red AND stapler" but is easier to humans to grok.
You can see the Image Database at <http://image.techniche.co.nz>. It is currenly being developed to be more generic.
It's intended user base is in two areas. The first are marketing and general office staff searching for images to use in flyers, promotions and catalogues. They generaly use underspec'd PC's and have no idea of the Technical aspects of images. The second are pre-press operators who need to check images for technical useability.
There are workflows desgined around the Image Database to automate image use etc. that I won't go into here.
There are commerical engines that are similar to the Image Database, such as the system from Cascade Systems in England. --------------------------------------------------------------------------- Richard Knuckey mailto:rknuckey@techniche.co.nz Technology Manager DDI +649 573 5923 Techniche, a division of Blue Star Print Group Limited Fax +649 573 1803