Daminion Update To Version 4.0

Last week, Daminion announced an upgrade to version 4.0 of their client/server desktop DAM solution.  As seems to be the convention currently, none of the updates are likely to have anyone falling off their chair in shock and amazement, but there are a decent number and some of their peers would make more of a fuss about these relatively minor changes than they have.  Here is the abridged list:

• Tag structure protected from unwanted changes during import
• Links between assets
• Italian localisation
• Performance enhancements
• Modifications to Daminion Server REST API

There is a full breakdown and some videos and screenshots on their blog post about the release (and they do look like real ones, rather than designer mock-ups).

“As you know, when Daminion imports images it reads the image metadata, saves it in the catalog and then displays it in the tag tree. This allows you to keep your database information synced with the metadata in imported files. But what if you want to import new stock images that may already contain large amounts of metadata that could easily mess up your existing tag structure? The new Daminion 4.0 version can mark all newly imported tags as Unapproved, so you can easily separate imported tags from your approved tag structure (taxonomy).” [Read More]

The main USP of Daminion is that it is low cost and runs internally on the type of studio network of Macs and PCs that you would typically get in a graphic production studio.  Obviously, this is more of a benefit for some kinds of users than others and a point often observed about this kind of product is that they frequently get used to feed assets to web-based DAMs that might not be responsive enough for production needs (or have direct access to all of the original files held on an internal server).  By contrast, if you need to make a logo available to thousands of users then this is more challenging with a product that is desktop-based and aimed at smaller studios.

One of the often stated benefits of SaaS applications is that they get updated more quickly than on-premise.  While Daminion’s high frequency release cycle demonstrates that this is not always true, part of the reason is the number of users involved in a given installation.  If you have a DAM with a small number of users, upgrades are less of an undertaking than those with more users and it’s easier to apply patches if bugs etc are found.  With SaaS or Cloud DAM, the vendor has to undertake a risk assessment and plan the upgrade with a good deal of care lest they end up being deluged with support calls if something breaks because it wasn’t picked up in testing.  This can make their release management headaches more of an issue than is widely understood (and obviously not something they are usually keen to talk openly about).

What these observations should highlight is that you can’t necessarily take all of the commonly held views about certain classes of products entirely at face-value, further, you might even have to consider the possibility of using more than one to synthesise a range of benefits that a single vendor alone cannot offer.  Evidently, cost is a big mitigating factor against following that route, but it is important to assess the needs of all your users first and look at products second.  One additional consideration that often seems to get ignored is that while there will be fewer heavier DAM users, they are also responsible for supplying most of the assets that everyone else will download, so it is essential to consider this in terms of a digital asset supply chain rather than a one-size fits all approach.

Share this Article: