Introducing Image Processing as a Service
In an article that questions the traditional way to do things, DAM News Editor Ralph Windsor addresses the subject of image and media processing within a DAM system, and whether the time has come – for something that has always been viewed as one of a DAM’s core duties – to be delegated to specialist third-party service providers.
Using the analogy of ‘The Five Monkeys Experiment’, which observes the phenomenon of learned behaviour and inherited reluctance to change the status quo due to an historic ‘memory’ of past consequences, Ralph begins his piece by presenting an all too familiar dialogue concerning a supplier’s continuing failure to overcome a series of technical issues. In his scenario, a client requires a system that generates video and image previews. The service provider opts for a set of common open source tools and components such as FFMpeg and ImageMagick to get the job done, but soon realises that a set-and-forget type configuration is simply not going to cut it.
“What do you mean client X is reporting that all their thumbnails are blank? Oh yeah, colorspace, I didn’t think of that. Well not many people use CMYK these days anyway. Oh, we told them we would handle it and they say they’ve got 7,000 other images like it?” [Read More]
The re-invention of the wheel is a commonly perceived pitfall in software development circles, and DAM software providers are still seemingly making the same mistakes and attempting to spin too many cracked plates in order to provide the custom functionality that any given client requires.
Ralph continues by introducing the concept of outsourcing core functionality by using Platform-as-a-Service (PaaS) solutions:
“Outsourcing key infrastructure or core platform functionality has historically been frowned upon or generally overlooked by developers and product managers. Despite this, outsourcing and Platform-as-a-Service (PaaS) models are becoming ubiquitous across the entire Digital Asset Management supply chain.
This process started decades ago. In the 1990s, it was commonplace for DAM vendors to implement their own proprietary database. It is inconceivable that any vendor would do that now. Similarly, at one time, vendors would purchase physical servers and host on-line DAMs from private co-location facilities (or their own offices or even garages in a few cases).” [Read More]
Moving forward to a current view of the Digital Asset Supply Chain, Ralph explains how a modern DAM system is more akin to a hub or ‘control centre’, allowing seamless communication between both upstream and downstream nodes, many of which have already taken the form of tightly integrated third-party services responsible for such tasks as logging, security and system monitoring.
Continuing to focus on image and media processing functionality, the article explores the use of Image Processing as a Service (IPaaS), and how the conventional approach of cobbling together various disparate components is fraught with security and reliability issues, some of which are never fully resolved and subsequently form part of the ‘broken boilerplate’ that new client instances adopt.
“Building a robust image processing platform is like a long, complex game of whack-a-mole. Dealing with all the issues involved with properly maintaining and expanding it becomes a massive technical challenge. Image Processing as a Service (IPaaS) reduces the need to worry about legacy code, to make OS updates, or to mix and match media libraries.” [Read More]
Ralph’s advice concludes with a series of difficult questions that all DAM vendors should perhaps be asking themselves: should you adhere to ancient wisdom and continue to roll your own core functionality, even if it doesn’t work or has become a technical albatross? Is your product really ‘best of breed’? And by outsourcing your DAM’s image processing tasks, could you free up more resources to focus on the features that you’re really proud of?Share this Article: