Digital Asset Management (DAM) Best Practice

I haven't noticed any articles discussing Digital Asset Management (DAM) best practice so I thought I'd offer my own insights...

Webcenter Content can be extended to offer Digital Asset Management (DAM) capability for the management of images and video. It works by taking an image or video and generating various reformatted versions, called renditions, during checkin. The set of renditions are stored in a zip file associated with the original content item and each rendition gets extracted for use when required. A "Renditions" page provides an overview of the set and contributors can choose specific renditions to use for their websites.

Standard components are added to both the Content Server and the InBound Refinery (IBR) to provide the DAM functionality. It also requires adding 3rd party conversion engines to process the renditions, such as ImageAlchemy, FlipFactory and ImageMagick, but 11g comes with OutsideIn. (Older versions (pre 11) of DAM had a dependency on ImageAlchemy that can be overcome here.) Each engine has their own language for instructing the transformation that the administrator will have to work out when configuring the renditions.

There are three required renditions for images: Web, Thumbnail and Preview. The administrator configures any number of extra renditions as desired. The rendition sets are configured in a standard .hda (formatted text) file located inside a DAM component on the IBR. The different rendition sets can be selected during checkin and the individual renditions can then be downloaded or selected for use in websites.

So that's an overview of how it works, but how should you work it? Well, firstly it is recommended that administrators create their own renditions file at ~/data/configuration/dam/extraRendition_definitions.hda to prevent upgrades from resetting it. Simply copy the component file to the new location, edit it and restart the IBR to apply changes.

Oracle suggests a rendition set for print, one for web and others for various other uses. My experience is that this is pretty useless. One of the defining purposes of a content management system is the reusability of content, so defining rendition sets for specific purposes seems counterproductive. If I check in an image for a specific purpose today, who's to say someone else needs it for a different purpose tomorrow? How will contributors even know which rendition set to pick, or what each rendition is for?

A better approach is to create a default set that includes the most common renditions that you might encounter. It would include a web-friendly size reduction, perhaps a print-suitable rescale, and a few mixed sizes that relate to various uses it might encounter, such as photogallery thumbnails, watermarks or portrait/landscape cropping. There might be a bit of guesswork here, maybe some refinements over time but it's handy for when a generic image might wind up in multiple uses.

One of the frustrating aspects of renditions for users is the reformatting of pre-designed images. Obviously if someone has taken the time to design a specific graphic they don't want the system to hack it into various sizes and treatments. Include a rendition set that performs no changes to the original image - simply copy the native file as the web rendition. This rendition set would be applied, for example, to webpage design elements such as backgrounds, icons or other design kibble.

Another commonly-encountered pitfall is where systems are configured to add unnecessary stickers, watermarks or edges to images. This lowers their reusability. It's better to use CSS or HTML layering techniques to augment an image. For example, don't create a rendition with rounded corners, it's better to overlay the rendition on the page with a transparent gif with coloured corners.

The names of the renditions are important because they appear in urls and they are also used as the labels to identify them. Names related to purpose are a bad idea, because purpose changes over time. Who knows what the "feature_wide" rendition will generate or where it is expected to be used? Instead, name the renditions with sizes and formats. For example, "jpg640x480" or "pngDark80x80" gives users a clue on what the rendition is and how to use it.

Contributors to SiteStudio websites can choose specific renditions to place on a web page but this functionality was not standard before 11g. There is a non-Oracle component floating around the interwebs to add that functionality to earlier versions, or just write one yourself - modify the renditions page to display buttons during a SiteStudio query and return a new docUrl value.

One of the more challenging problems is dealing with transparent images or images designed for light vs dark backgrounds. If a transparent background image is yellow for an assumed black background, it will be lost when placed on a white background. It might be feasible to offer dark and light renditions that invert the image where appropriate. The trick is identifying when to apply the inverse. This could be achieved by sniffing the image palette during the rendition creation (depending on the conversion engine) or with metadata that specifies the preferred background of light vs dark.

Passing in metadata to the rendition is possible because the IBR can parse IdocScript and read the items' metadata during the rendition generation process. This can be useful for applying watermarks or text, or for making decisions during the rendition generation.

When it comes time to call a rendition from a web page, a couple of IdocScript functions and services are provided that can retrieve renditions. The typical method is to use the GET_FILE service and request a specific rendition, but this extracts the file each time and wastes resources. The more useful method is the function <$docCreateRenditionPath(rendition,dDocName)$> which retrieves the static rendition from the filesystem, or generates it if it hasn't been extracted already. However there was a bug that caused the whole page output to be lost if the rendition is missing, so make sure you are using the latest version of ZipRenditionManagement component.

To force the Content Server to always have extracted static renditions available after checkin, use the config flag RenditionListExportedForStaticAcces and list all the desired renditions. Wildcards are accepted!

Finally, if the situation arises where a new rendition needs to be added to a set, older images will need to be resubmitted in order to acquire the new rendition. This can be done in bulk through the Repository Manager applet.