Proxy Files As Functional Metadata: Their Changing Role And What It Means For the Future Of DAM

Introduction

This guest post is from Ralph Windsor, a senior partner in Digital Asset Management implementation consultants, Daydream.

Background

This article is about proxy files in DAM systems and how I see their role changing from practical necessity towards a specialised form of functional metadata. As I will explain, I believe this has implications for the future direction of Digital Asset Management and how (or indeed, if) users will interact with DAM systems as they mature and develop.

To appreciate how the role of proxies is changing, you need to be in agreement with the proposition that assets in DAM systems are composed of digital files + metadata, rather than a synonym for a digital file. My contention is that in DAM systems, metadata has equal status with a digital file, since without it, your chances of finding relevant media decline rapidly as the volume of material contained within increases. Note that finding assets, doesn’t just involve entering search queries, but also selecting or reviewing them to make a more informed decision about whether or not they are fit for your chosen purpose.

What Is A ‘Proxy File’?

For those who are unfamiliar with what proxy files are, the classic definition is a media element such as a preview that is provided to allow users to review files before accessing the original. Some similar terms you might hear include ‘derivative’ or ‘surrogate’ files. Those are not bad descriptions, but they can also refer to media that is created from an original for re-purposing (e.g. an RGB version of a CMYK file) rather than something you use as a direct substitute when viewing assets with a specific task in mind.

What Function Do Proxy Files Fulfil?

To answer this question, it is necessary to look at how the use of proxies has changed over the years since DAM systems first came into use around 20 years ago.

In the very early days of DAM, most end users of media assets users still preferred original, non-digital media like a transparencies for photos or tapes for audio or video. In that period, DAM systems were exclusively about proxy files and metadata because there either was no digital file or the size and available bandwidth made digital delivery impractical.

Moving forward a few years, more professional media asset buyers had internet access and were prepared to use a digital version because the quality of the digitised edition was better. Also, the shift from desktop apps or CD-ROM catalogues towards online websites was gathering pace. Bandwidth was the key limitation and the role of the proxy asset was to let you see what you were going to get before you commenced a potentially lengthy download.

These days, there often isn’t a non-digital original: the media has been captured or created and edited in an exclusively digital form. Downloading a JPEG of a few megabytes isn’t a big deal for most and many people will do that from their mobile phone without it being an issue – an idea which would have been unthinkable until fairly recently.

The benefits of the proxy as a means to leverage bandwidth more efficiently have become increasingly marginal and soon (if not now) you could potentially implement a DAM system using the original files for basic thumbnails and previews and many end users might not even notice. That might still be a somewhat contentious point, however, the underlying direction of DAM technology is clearly moving away from proxies being used purely to help users deal with bandwidth constraints.

The changing role of the proxy

Despite the trends I have described, anyone who is involved in implementing Digital Asset Management solutions at a practical level will be well aware that the number and range of proxy files has increased at a vociferous pace. It now seems that in many of the DAM systems I come into contact with, each core digital asset record practically has its own mini-DAM system dedicated to managing the multitude of associated proxy files that accompany it.

Based on a superficial analysis, this seems perverse. On the one hand, proxy files are not needed as much because you can often employ the original file to offer the user a representation at various sizes. On the other, DAM systems now use even more of them. In the remainder of the article, I will attempt to illustrate why I think this contradiction has arisen and what it means for those involved in making strategic decisions about Digital Asset Management implementations.

The proxy file as functional metadata

For the reasons discussed, I would argue that the role of the proxy file is changing and has become less about its historical function of overcoming delivery constraints and more a specialised form of non-text based metadata to support enhanced functionality in DAM systems.

I believe this might point towards a future role for DAM that concurs with the trends Naresh has discussed in many of his articles here on DAM News, especially the integration of DAM into other applications and the convergence of DAM with online content management technologies in general.

The following is a non-exhaustive list of new functions that still typically depend upon proxy files:

• Zooming images
• Multi-page previews
• Annotation
• Time based media navigation
• Timeline metadata
• Bypassing unconventional viewers
• Transformation preview

Zooming images

Many DAM systems now let you examine images and other files more closely using a ‘zoom’ control. To achieve this, they have to generate proxies at various sizes for each of the zoom levels. With HTML5 that need might begin to diminish and users will be able to zoom in/out of the original file but while those innovations might be round the corner, they’re not quite feasible yet for enterprise implementations where the target users are still using older browsers. So proxies at sets of sizes are still generally required to provide a working zoom function.

Multi page previews

A feature of some systems is enabling multi-page previews. This is mostly for print assets like PDF or InDesign files, but as with large files, more end users want to look at multiple pages of a document oriented assets before getting it to their local machine and finding it’s not what they were after (or sometimes just to check a fact direct from the DAM system). Proxies are generated for each of the pages, again, often at different sizes to allow users to zoom any page also.

Annotation

There is a whole industry now developing around providing end users with the means to make comments and add mark-up to a representation of an asset to augment text comments. Solutions exist which are PDF based but in many cases they use proxies to deliver this functionality in a way that is more directly accessible via a browser.

Time based media navigation

This is obviously only relevant for audio and video, but I increasingly speak to end users who want visual representations such as stills of videos at key points on the timeline to enable them to navigate more easily. Bookmarking frames, chapter navigation and other shortcuts are becoming more important. All these need a still image, or possibly a short dynamic segment of the chosen frame in a proxy format that will display properly in a browser.

Timeline metadata and media manipulation

Often, simply playing back a video or audio file isn’t sufficient any longer. Users want advanced functionality such as to be able to cross reference narrative with frames so they can ‘search’ for key phrases that might be spoken or otherwise used. Similarly, the range of media manipulation requirements is expanding rapidly. In the case of video, that often means being able to set up EDLs and quick edits direct from the DAM.

Bypassing unconventional viewers

Another area of expansion for proxies is avoiding the need for end users to install some kind of obscure third party web plug-in. PDFs are one of the obvious examples that lead users to hesitate before clicking on them, but there are others like 3D or CAD files also. I’ve seen proxy files being used here to let end users get a quick visual of media and bypass the need to launch some unconventional viewer plug-in or resource intensive third party application until they absolutely need to.

Transformation preview

The last area is using proxies to illustrate the effects some kind of transformation, for example, flipping or rotating media like images. Users want the speed and convenience of a proxy file before they commit to the operation and get the file to find it’s not what they wanted. In more than a few cases, a DAM system is being viewed as realistic alternative to the deployment of bitmap editing software for users with basic needs.

Proxies And The Assimilation of DAM Technology

I have seen the developers of DAM systems use a multitude of clever or esoteric techniques to leverage proxy files to deliver the advanced functionality of the type described. These make great ‘war stories’ for them to share with like minded friends and colleagues. Having been a developer myself in the past, I don’t doubt the level of effort, skill and ingenuity required to get them working. But, they are all essentially hacks that point towards an assimilation process going on within the Digital Asset Management industry as it integrates with other technologies.

It is clear (to me) that end users want to remain within a single application and to reduce the friction generated as a result of moving between different software products. If you’re doing a task on a computer, a big factor that disrupts your ability to retain continuity and keep focussed on the job at hand is when you need to move between software and re-orientate yourself about how program x works compared with web application y. This is the case, even if you are highly familiar with all the systems involved.

Many of the proxy file innovations I have described are designed to make it easier for you to avoid doing that, just as the proxy file was used originally to deal with a delivery constraint, now this conceptual device is being employed to cope with functional limitations. The force of momentum will eventually gather pace to remove those constraints, as happened with bandwidth.

Ultimately (as with delivery) it will become easier and more feasible to work directly with the actual original file from within the same system. All this points towards a key questions that Naresh has talked about in his posts on DAM News many times: will DAM systems become the primary interface to control other applications or will other competing technologies be the ‘go to’ solution for users and DAM systems sit behind them in support?

Conclusion

I will leave it for others to assess how closely most users are going to want to interact directly with DAM systems in the future. It may well be that (as Naresh has said) the industry will fragment to cope with the ever expanding scope of user requirements.

At this point in time, I do have to note that they are not the hub or launching point from which users initiate tasks, but fulfil more of a utility function which they access to carry out a task which is usually search and selection related. It is also true that some of the innovations I have described might also change end user’s perceptions of DAM systems and what they are capable of too.

If you are involved in the strategic decisions about what DAM solution to use and the direction it needs to go in, this is a critical issue you cannot ignore. At some stage, either your DAM system will need to become a supporting player behind your wider digital media production strategy, or it will be the core point of delivery where users will carry out most tasks from. The decision about which it is will have a profound effect upon what product choices you make and also drive the implementation objectives you decide to prioritise.

 

About the author

Ralph Windsor is a senior partner in Digital Asset Management Implementation Consultants, Daydream and has worked in the DAM industry for 18 years as a developer, project manager and now consultant.  Daydream were the original developers of the FocusOPEN open source .NET DAM system.

Web: http://www.daydream.co.uk

Twitter: @daydreamuk

LinkedIn: http://uk.linkedin.com/in/daydream

 

Share this Article: