Choosing a System for Managing your Image Collection
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.
- Common functionality
- Questions to ask when choosing a system
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).
Basic image orientation
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.
File format support
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.
Support for relevant metadata standards
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.
Getting your metadata in and out again
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?
Nature of the user interface
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.
Search and retrieval
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.
Display of images and metadata
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.
Interoperability with other systems
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:
Do I actually need to choose a system?
For most of us the answer will be an unequivocal "Yes!" While there are alternatives (careful file and folder naming, folder viewing options provided by operating systems, or embedded metadata), there are many advantages to employing a specialist system - as the features described in section 2 above indicate. However, in some cases the answer might be "No" or at least "Not yet". It may also be that someone else within your department or institution already has a suitable system or is about to buy one. Make some enquiries - you might save yourself a task and some money. You might also find there are some opportunities to share images as well as software.
What do I require from a system?
It is vital that you determine your requirements and always keep them in mind when you evaluate systems or talk to developers. The features in section 2 above and the different systems described in Systems for Managing Digital Media Collections should give you some idea of what to look for. But you will undoubtedly need to see a few systems before you finalise your list. In drawing up your list of requirements, try to avoid the extremes of overstating your needs (and so failing to find anything suitable), or understating them (and ending up with a system that just isn't up to the task). One useful way to do this is to divide the items on your list into features that you "absolutely must have" (essentials) and those that would be "nice to have but could be lived without" (desirables). Try to be as realistic as you can, but be prepared to shuffle the items between these categories when you get down to looking.
What are others in similar situations using?
Although everyone's situation is different, others will have made similar choices to yours. Try to identify these people - ask colleagues; post requests on relevant email lists. When you find them, phone, email, or better still visit them. Find out what system they're using and what features they like or dislike about the system. If they've had their system for some time they may also be aware of other products that could now do a better job. It's worth doing this sort of research for any sized system, but it's particularly important if you're looking for a large system requiring a lot of investment.
Who do I need to involve in this choice?
Unless you're buying or downloading a system to manage a personal collection of images there will usually be others who have a stake in your choice, such as users, cataloguers, funders, or IT support staff. Even with a personal system it might be wise to check out the security or systems implications with those who support your IT. Once you've identified any key stakeholders, it's important that you involve them in your research and decision-making. Consult with them over your list of requirements; invite them to system demos; give them evaluation copies to look at. If you're going to need them to contribute to your collection or you want to ensure they use it once it's in place, then it's crucial they feel a sense of ownership of the system.
What resources do I have?
Stakeholders are not just people you bring onside for political reasons - they may have considerable expertise that will help you in making your choice. Or there may be others within your institution or networks that can provide you with some help. JISC Digital Media can provide further help via its Helpdesk and Training programme. Other important resources you will obviously need to find are time and money - both of these are likely to be limited and so will constrain or direct your choice of a system.
How formal does the process need to be?
If you're looking for a large system - or you want to commission someone to develop one - you will probably need to prepare a formal 'Invitation To Tender' (ITT) or 'Request For Proposals' (RFP). You may also need to undertake European tendering if the system is going to be very large and expensive. JISC InfoNet has produced a useful InfoKit on procuring larger systems. However, even if it's a small system you're choosing for yourself or a small team it is important to formalise the process in some way. At the very least, jot down your key requirements and keep a record of the systems you've looked at and the functionality they offer - once you've seen several systems it can be surprisingly difficult to remember exactly which system offered which features.
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:
Does this system meet my requirements?
One of the first things to determine is how well the system fits with the requirements you've identified (essentials and desirables). Document your findings, but don't be too quick to dismiss anything that doesn't come up to scratch. You may discover that: (a) no system can meet your exact specification and you'll need to reconsider the essentials; (b) it might actually be fairly easy to customise a system to meet your requirements; (c) you might be able to complement the system with another system to address a particular need; or (d) the requirements you want might be on the list for the next upgrade - or you might be able to get them put onto that list!
How flexible is this system?
Your needs from a system are likely to change over time, so it's worth looking for a system that can accommodate some change. Can the system expand from a standalone version to a workgroup version if you decide later on to share the task of collection-building with others? Can you introduce security settings if you find you need tighter control over your resources or how people are accessing them? Can the system handle hundreds of users searching it at once if it becomes a runaway success? While it's impossible to anticipate all of your future needs, it's useful to have a system that will provide you with some flexibility and growth. Try not to limit yourself at the outset.
How future-proof is this system?
You will not only need to think about how your needs might change, but how the system you're looking at might change. This is difficult to predict without the aid of a crystal ball, but past performance may be some guide. Has the software company been around for some time and is it still growing? Is there a strong community contributing to the development of an open source system you're looking at? Is there a history of regular upgrades? Does the system seem to be keeping up with new standards as they come along? Is there a strong user group (composed of people like you) who are influencing the development of the system? It might be worth choosing a product with slightly less functionality than a competitor if it seems likely to have a more promising future.
How much will this system cost me?
As we've said above (in section 3.1) cost will be an important factor in your decision. However it's important that you don't just base this on the initial price tag. Many of the larger commercial systems come with support and upgrade packages, and it's often worthwhile taking these up. You may also need to take into account the costs of importing any existing data into the system and of training. All of these costs are reasonably easy to determine or estimate but are sometimes overlooked.
How much will this system really cost me?
However, there are also some less tangible costs you may want to consider. One of these might be delay. For example, if you need something quickly, you will probably not be able to afford a twelve-month delay while waiting for a bespoke system to be developed. Another important cost is the impact on workflow. If a cheap (or free) system requires you to spend a minute or two longer per record than another system, you may find it actually proves to be much more expensive over the longer term! An open source system might be free to download, but prove expensive to install and customise. An expensive bespoke system may prove even more costly when you need to employ someone to rewrite parts of it in five years time (as you probably will) or to move your data out of it in the future - as you almost certainly will for any system you currently choose!
Does this system compromise my data in any way?
You will be making a significant investment in creating digital images and metadata to accompany them. Over time this investment is likely to be worth much more than the system you've bought to deliver the data (in a very short time for some systems). You can reasonably expect to have to move to another delivery system within 5-10 years, but you're unlikely to want to re-create your images or metadata within this timeframe - you will want them to last much longer. So it's important that the system you choose doesn't force you to make too many compromises in terms of the quality of your images or your metadata. It's also vital that the system enables you to pull out your data again when you're ready to move on to the next system!
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.