Last updated: 07 May 2007
Published in:
Managing your digital resources |
Tags:
business & community engagement |
delivery |
digital collections |
software |
It can be a daunting task choosing a system for managing an image collection - especially if you intend to use it to share your collection with colleagues or the wider world via the Web. As the companion paper to this indicates, there are a very wide variety of options (see Systems for Managing Digital Media Collections). You will probably find it useful to read that paper before you read this one.
Your choice of a system must be driven by your requirements and shaped by your own particular circumstances and constraints. While the perfect system may not exist, some will be much more suitable than others, so it's important that you choose well and that any compromises are made knowingly rather than through ignorance.
It can be difficult to know what to look for unless you've seen a few systems in action and understand what might be possible. Section 2 (below) describes functionality that is commonly (but by no means universally) provided by systems for managing images. As you read through this section, think about whether the functionality being described is essential, desirable, or not required for your particular collection. This might form the beginning of a checklist you could use when evaluating systems, or a more formal list of requirements in an Invitation To Tender (ITT). Section 3 of this paper raises several questions to think about when you're choosing a system.
JISC Digital Media has surveyed a range of image management software developers to gather specific information about their systems. Those who have responded so far are listed on our Image Management Software page.
This section describes some of the features you might look for in a system for managing images. This is grouped into features relating to: images (2.1); metadata (2.2); and delivery to users (2.3).
As we said in Systems for Managing Digital Media Collections, it can be useful to distinguish between systems that are image-centric (where a metadata record is attached to each and every image) or object-centric (where one or more images can be attached to an object record). Ideally you should choose a system whose orientation fits well with your purpose, although it can sometimes be useful or necessary to choose a different kind of system.
To give an example - although your images might be of pages from atlases, and so suit an object-centric approach, you might choose a system designed for handling separate images because it offers good zoom functionality, digital rights management technology, or perhaps e-commerce features. Or, to take another example, you might choose to use an image-centric system to help you manage some aspects of a digitisation project (e.g. digital capture and extraction of technical metadata) and then transfer the data into a collection management system which has object-related metadata and is more suited for delivery.
There are several different ways in which systems 'acquire' or 'ingest' digital images. Some systems - especially those distributed with digital cameras - will enable you to import images directly from a camera. A few systems take this a step further, enabling you to actually capture images from a scanner or a tethered camera from within the system itself.
More commonly, however, systems will assume you already have the digital images in folders on your computer, server or memory device. These can then be either copied into the system's preferred image folder or (much better) you can tell the system where to look and it will catalogue the images where they are. Sometimes systems don't even require you to actively point to files or folders - they will automatically scan specified folders and catalogue anything new they find there.
Of course, the approaches described above will only be relevant when the image management system takes the form of a program sitting on your computer. If you're using a system that is Web-based and hosted elsewhere, then you'll almost certainly have to actively up-load new images to the collection - and often individually rather than in batches.
Systems differ in their support for file formats, so if you're using anything beyond the common Web formats, GIF and JPEG, you'll need to make sure that the system you choose supports it.
TIFF is often used as a master image format because it does not compromise the data in the way the JPEG's compression does. However, as this comes at the expense of a much larger filesize, the TIFF is not always supported by systems - especially those systems that are Web-based. You might expect systems designed for the photographic market to have good support for TIFF, camera formats (RAW and DNG) and the Photoshop format (PSD), but other kinds of systems may not support these consistently.
You need to be aware that even if the system says it supports a particular format, some aspects of that format might not be well supported, such as higher bit-depth (i.e. more than 8-bits per channel), ICC colour profiles, or embedded metadata. If you are making use of any of these, you should check that the system supports them.
Support can be a particular issue for some of the newer file formats, such as PNG or JPEG2000. Although these formats have a lot to commend them, they are not always completely or consistently implemented. So if a system does support them (many will not), this support might not extend to all of their features (e.g. PNG transparency or JPEG2000 zooming).
Some systems provide much more image management functionality than simply recording a location, generating a thumbnail and storing some associated metadata. They might enable you to move, copy, or delete original files from within the system itself. They may provide the option of creating virtual folders for organising the images and then enable you to convert these into 'real' folders on your server or a disc. Or they might provide tools for automatically renaming your images. For some people these kind of features will be unnecessary or even confusing; for others they will offer useful support for an image workflow.
Many systems designed for managing images include image editing features (e.g. cropping, rotating, resizing, colour correction). Whether these are useful to you will depend on the nature and purpose of your collection and other software you have to hand. If you need to do sophisticated image correction, it will probably be preferable to use a dedicated programme like Photoshop or Gimp (indeed some systems enable you to automatically open an image within a separate editing program). But if you only need to make simple and occasional adjustments you may find that the editing tools provided by an image management system are more than sufficient.
One thing to check out is how any editing is applied to the image. Some systems will apply edits directly to the image as you make them - which makes it impossible to recover an earlier version if you change your mind. Some systems will create a copy, providing you with a level of version control. Other systems store details of the edits you make and only actually apply them to the image when it is exported or saved into a different size or format. These last two approaches (versioning or storing edits) can be very useful where the master is a JPEG image, since each time you resave a JPEG you are re-compressing (and further compromising) the image.
If you're using a system to manage your workflow, then versioning and auditing features (e.g. who edited the image) are worth looking out for. These can support your quality assurance (QA) processes, helping you to pick out where any errors may be being introduced.
One of the main reasons for using software to manage your images is to enable you to associate some metadata (catalogue information) to assist you and other users in the tasks of finding, understanding, managing, and using your images.
This is most commonly achieved through some sort of database. The database might take a relatively simple and 'flat' form (e.g. a single record per image). Or it could be much more complex, using, for example, a number of different tables of information which are related to form a kind of 'virtual' record for each image or object. There are also some other, less common, alternatives, such as storing the metadata in an XML encoding (similar to HTML Web encoding) or embedding the metadata within the image file itself. Although we cannot go into detail here about the various different database structures, this may be something to investigate or to talk with your IT support staff about.
Apart from the basic underlying database, you might also want to consider whether you need the cataloguing interface to be client-based (i.e. a separate program on your computer) or Web-browser-based. A client-based system typically offers more functionality and more control over the interface, but it must be loaded onto every machine and you will probably have to pay a fee for each copy installed. A browser-based cataloguing interface is typically not as efficient or flexible, but might enable you to add images to the collection from any location in the world.
Whatever 'system architecture' you settle for, you will need to think about how well it supports your data entry needs. Does it, for example, enable you to add, delete, hide, re-order, or rename catalogue fields? Can you create drop-down lists (or separate tables) to manage your keywords and other controlled vocabularies? Does it offer features that will speed-up the time-consuming task of adding metadata, such as templates, batch-editing, or global 'find and replace' options? Does it provide features that will support your workflow and quality assurance, such as auditing, a moderation process, spell-checking or data validation? Such features are often worth paying extra for.
If you intend your collection to 'interoperate' with other collections then you'll need to pay some attention to how well it supports appropriate metadata standards. Some systems will come out of their box with such support (especially collection management systems); others will often require a lot of customisation. For more information on metadata standards, see Metadata and Digital Images.
It's vital to pay special attention to the ease with which you can get your metadata in and out of the system. You may already have some metadata that you want to import, perhaps some records held in an earlier database or some metadata embedded within the image file itself. If this is the case, you'll need to investigate how easy it will be to bring this data into your new system (e.g. by importing comma-separated data or extracting metadata from the image files). Ideally your new system should support any imports or metadata extractions directly, but it is sometimes necessary to make use of additional software as an intermediary - especially where you are extracting metadata from the images themselves.
Once there is data in your system, you also need some means of exporting it. You will almost certainly need to move the images and metadata into another system within a few years time. But you may have cause to export your metadata well before then: perhaps to share it with other collections, or to embed it within your images for security or identification purposes. Many systems are now moving towards XML as a format for exchanging (importing and exporting) metadata. This is not yet standard, but it may be something to look out for when you're choosing a system.
Closely related to the ability to export metadata is the ability to generate useful reports and statistics. Do the systems you're looking at enable you to construct new reports easily yourself, or are you limited to standard forms and templates that come with the system?
We mentioned the data-entry/cataloguing interface above, but systems for managing and sharing images will often provide a separate interface for the "end-user". As with the cataloguing interface, this might take the form of a client-based program installed on the user's machine or a Web-browser-based interface accessed via an intranet or the Internet. It is not uncommon for systems to use a client interface for data entry and a browser interface for delivery to end users. Such an arrangement can offer the best of both worlds - a higher level of functionality and efficiency for the cataloguing and easier, more familiar access for the end user.
Whatever the configuration or technology is chosen, the user interface must effectively meet your users' requirements. It should offer flexibility and customisability, and conform to good usability and accessibility practices. For more information on interface design, usability and accessibility, please see: Graphical User Interface Design: Developing Usable and Accessible Collections.
You will need to pay particular attention to the search and retrieval features offered by the systems you're looking at. Can you search on all or most of the fields in your database? Is advanced searching possible (e.g. Boolean logic, "wildcards", "sounds-like" fuzzy searching or date range searching)? Are there any special search features offered, such as content based retrieval (based on colour and shape, etc). Can you browse the collection as well as search?
Sometimes the search functionality differs considerably between the cataloguing interface and the end-user interface - especially where a system uses client software for cataloguing and provides end-user delivery via a Web browser. It may be that the cataloguing interface enables you to conduct sophisticated searches, while the user interface simply presents Web galleries that can be browsed but not searched. You will need to make sure that both interfaces are going to meet your needs.
It will also be important to consider how well the images and metadata are displayed. Ideally you should able to customise the look and feel of the interface, choose the sizes of the images, and decide which metadata is displayed to cataloguers and users. Some systems will provide further functionality, enabling individual cataloguers or end users to personalise the way they view the data and enabling them to interact with it in certain ways (e.g. bookmark or annotate images). This level of interactivity is not common, but some readers may wish to look for it or include it in their brief to a system developer.
If you want to provide user access to larger images or master files, you will need to check how this is dealt with by the systems you're investigating. There may be a zoom facility, or an option to download the original image. If you're providing access to large images or files you may also need to think about the security implications and whether there are any network issues in delivering large amounts of data.
Security is often a concern for those who are building image collections and sharing them with others. Ideally, the system you choose should enable you to provide different levels of access and different views of the data according to particular user roles or profiles. It is common to have at least three roles (administrator, editor/moderator, user). Some systems are more sophisticated, enabling you to set different permissions at the level of an individual user or image, or connecting with institutional authentication systems.
If you are concerned about people misusing larger images you may also want to look out for digital rights management (DRM) technology, such as watermarking or the delivery of images via a protected interface. These technologies cannot guarantee that no one will take your images, but they can provide a deterrent and will minimise your risk.
Finally, if you want to share your data with other systems, you'll need to see how easily this can be done. It can be a real challenge to join up different systems in a seamless way, but some will enable their databases to be searched by other applications.
Another way to share data is to take advantage of a system's export facilities (as discussed above) or publishing options. Many systems will enable you to easily create CD-ROMs, slide shows, or Web galleries, or to dispatch images to an email address.
The remainder of this paper poses some questions to think about when you are choosing a system for managing an image collection.
Before you get too far in your search for a system, you will need to have answers to some of these questions:
Having established your needs and specific requirements, identified your stakeholders and resources, and considered your methodology, you are now ready to bring in those systems vendors or download those evaluation copies. Here are some questions you should ask about each of the systems you look at:
Your choice of a system for managing and delivering your collection is very important, so you need to take the time to carefully determine your needs and evaluate the options.
Bear in mind, though, that even with the best of care you will probably not find the "perfect" fit for your needs. You will need to make some informed compromises. However, if you make your choice without paying any attention, you run a real risk of being locked into something that is not only less than perfect, but will actually compromise your data and will fail your users.
Last updated: 07 May 2007
Published in:
Managing your digital resources |
Tags:
business & community engagement |
delivery |
digital collections |
software |
We provide a FREE enquiry service giving advice to the UK Further and Higher Education community.
You can ask us anything, typical questions include - "What formats should I use?" "How do I...?" "What tools can achieve the result I need?" "What is new and emerging?"
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++