Digital Asset Management Value Chains – Asset Manipulation
Earlier this week, we introduced the concept of Digital Asset Management Value Chains to describe how DAM may develop in the future. We will examine how this might operate in practice with reference to activities that end users may carry when using a DAM system.
The first topic is Asset Manipulation – specifically alterations or derivations of the source digital file. This can encompass a range of different needs from more straightforward tasks like generating proxies (thumbnails, previews etc) through to more advanced functions where a copy of the modified asset is used for production purposes rather than the digital original that was ingested.
One area where most DAM system suppliers know they cannot generally deliver cost-effective solutions themselves is media encoding and processing. Few develop their own components for this task, the majority will use existing products provided by other ancillary vendors or popular open source projects such as ImageMagick, FFMPEG etc. There are some who specialise in this area already and either choose to selectively integrate with more popular platforms or by acting as an OEM partner for those willing to pay them. For example, there are a few component vendors who will offer to turn SharePoint into a DAM system for you and also offer their manipulation tools for several DAM vendors too.
Our expectation is that if DAM Value Chains acquire momentum, a number of DAM system vendors might decide to operate in a similar fashion and make use of the expertise they have acquired getting their applications to work with the a multitude of processing tools and custom AJAX interfaces by offering their services to others.
A further potential area for asset manipulation might be direct integration with software tools that have an existing market reputation in a given media type. For example, Photoshop is the image manipulation tool that a major section of users are already familiar with – especially within the DAM market.
At present, while they might have bought a couple of vendors with an interest in DAM, Adobe don’t appear to have fully grasped the opportunity that DAM systems could not only offer for products like Photoshop but also that technology itself could be a server-side provider of value to third party applications. Many DAM developers either already have (or are busy now) re-building simplified image management tools to expand the scope and capability of their products to meet demand from end users for the ability to do this without the need for a third party application (such as Photoshop).
You can use the basic features of some DAM tools to enable users to do cropping, format conversions, sharpness adjustments etc In around 80% of cases, that is sufficient. Going from the other direction, it is true that you can integrate many DAM systems directly within Photoshop so you may never need to leave it to find assets. Those are great for image professionals and graphic designers etc who spend all day using it, but the reason why many DAM end users want basic image manipulation is so they don’t need to roll out graphics apps across the whole business for everyone who just wants to resize a photo.
It seems to me that if Adobe controlled both the client and server sides then many DAM developers would very willingly drop any hand-rolled image manipulation front-ends they might have been painstakingly assembling and switch into one that a major player with the dominant image/photo software industry brand was offering instead. I’m aware they offer their Creative Cloud product, but it appears to fall between two stools, serious image/photo people prefer desktop apps because of the performance problems working continuously over the internet; casual users don’t need such an advanced array of tools. Both those scenarios might changes in the future with end users getting more sophisticated and internet connectivity becoming quick enough for pros to be able to do serious work over it, but it remains to be seen whether Adobe (or someone else) might be able to cover both ends of the spectrum successfully.
These sort of examples seem likely to be repeated across most of the main types of media asset that DAM systems currently are required to manage. Where there is an established industry leader in a given asset type, they have an opportunity to leverage that momentum via DAM value chains. Where they don’t do anything with the opportunity, someone else who may decide to specialise in it may enter instead – they might come from DAM, or maybe from another related sector.
In either case, they are likely to find a number of eager customers in the form of DAM developers who are looking for someone else to solve the asset manipulation problem (both client and server-side) so they can go off and worry about one of the multitude of other functional areas they have to provide to their end users. As we talked about in the original article, it might not just be DAM software developers either.
Share this Article:
The thing I’ve always found funny (and frustrating) about the built-in image editing tools most DAMs offer is that while they are intended to allow “self service” by DAM users who don’t use or know Photoshop, they are modeled after the tools in Photoshop. If I’m not a Photoshop user, why do you expect me to know how Photoshop does things?
Great points made in this article. While there are some DAMs that continue to use their own imaged-editing algorithms (after all these years), no DAM vendor can keep pace with the development communities behind the various open libraries. This is one reason it’s so important that a DAM be based on a service-oriented architecture (SOA) that permits it to leverage the best of the rest of the world.