Email:       Twitter: @dbrucegrant

Entries with tag <em>dam</em>.

Nuxeo DAM UI Improvements

The newest version of Nuxeo DAM in the fastrack release has made some improvements over its predecessors. A rundown of some of the UI improvements that I think make DAM a better product:

  • Overall a more refined interface and more well-aligned with the DM interface
  • The ability to replace/update an underlying attached asset file
  • Ability to easily switch between DAM and DM views of the asset (although it would be nice if this were configurable out of the box to be turned off, to support users with DAM UI only access)
  • It's now much more obvious which asset is selected in the UI (the previous CSS had very poor contrast)
  • Selection/deselection of assets (for bulk activities) is now much simpler with the addition of the selection checkbox on each displayed asset
  • Exposing tagging for DAM assets brings the UI up to snuff with DM
  • The Bulk Import button is a welcome addition for users with small digital assets, but for any industrial strength use of DAM with serious size assets a browser-based bulk import is not practical (or desirable)
  • In my opinion the presentation of metadata (and elimination of tabs across the top of the asset) makes for a cleaner interface

So, what's missing from the new UI (or at least what could be improved)

  • Addition of a hierarchical, dynamic filtering model (e.g., have a backend metadata model with related attributes, like Company A, has Brand B and C, Brand B has models D, E, and F, Brand C has models E and G; each level of selection narrows the shown assets but preserves hierarchical relationships)
  • Addition of XMP metadata (common for all Adobe assets)
  • Annotation improvements (very general but there is so much to be done to make this functionality more useful)
  • Ability to collapse right and left panels for more screen real estate

While the Nuxeo DAM UI is moving forward the backend components aren't moving with the same velocity. If you have big assets, multiple color spaces, multi-layer images, then you'll appreciate the gaps in speed and functional coverage. I will itemize some of these issues in a future blog entry.

What's your experience with Nuxeo DAM?

Comment on Nuxeo Tech Report 4 - DAM

Studio and UI configurability enhancements in Nuxeo DAM are welcome improvements. Making more of the interface more easily configurable with help more quickly meet customer requirements.

Unfortunately, I think Nuxeo has missed the mark when it comes to DAM performance. While DM has certain performance requirements, they pale in comparison to DAM. The average Nuxeo DM document (with attachments) is orders of magnitude smaller than a typically DAM asset. In this case I am talking about the use of DAM for high resolution images, graphics, and video.

There are challenges storing, rendering, and presenting all of these large files. Hardware (RAM, disk speed, CPU) is an extremely important part of the equation, but equally so are the underlying libraries that extract metadata, render lower resolution images, and stream video. Nuxeo's own code, wrapped around these libraries is also an important (and sometimes limiting) factor.

I believe that for Nuxeo DAM to be useful (in a marketing firm for example) there needs to be significant work on performance and scalability of DAM.

That's my two cents, albeit based though on real life experience with DAM. Anybody else have similar experience with DAM and handling of large digital assets?

Leveraging ImageMagick with Nuxeo

Until recently I never really appreciated the value and power of ImageMagick. This is one slick piece of software (or collection of image transformation tools).

The base integration with Nuxeo is good, but there is still plenty of opportunity to improve. The need for speed (and flexibility) becomes very evident when dealing with 250MB images, TIF images, IPTC/EXIF/XMP metadata, and with images that have a CMYK color space.

Quick Fix...

ImageMagick is integrated with Nuxeo, or more accurately loosely bound to, via a series of command line calls that perform the image-related magic.  Nuxeo expects to find the ImageMagick tools on the system path, while the loose binding comes by way of a contribution that associates Nuxeo command names with ImageMagick commands and parameters. Part of the default Nuxeo contribution is shown below…

<?xml version="1.0"?>
<component name="org.nuxeo.ecm.platform.picture.commandline.imagemagick">
    <extension target="org.nuxeo.ecm.platform.commandline.executor.service.CommandLineExecutorComponent”
        <command name="identify" enabled="true">
            <parameterString> -ping -format '%m %w %h %z' #{inputFilePath}</parameterString>
            <winParameterString> -ping -format "%m %w %h %z" #{inputFilePath}</winParameterString>
            <installationDirective>You need to install ImageMagic.</installationDirective>


       <command name="resizer" enabled="true">
          <parameterString>-flatten -resize #{targetWidth}x#{targetHeight} -depth #{targetDepth} #{inputFilePath}[0]
          <installationDirective>You need to install ImageMagic.</installationDirective>

I included this chunk of code because it demonstrates an issue with ImageMagick and the flexibility of Nuxeo (and ImageMagick) to address the issue.

In the example, the Nuxeo “resizer” command gets tied to the ImageMagick “convert” command. If the input picture is a TIF file then resizer will convert the image to a JPG and resize as required. This causes a problem when the TIF image has layers/masks. Unfortunately, converting from TIF to JPEG and resizing at the same time results in the loss of layers/masks in the resulting JPEG image – not so good.

There is a workaround, and that involves splitting the resizer command into two parts. Luckily both Nuxeo and ImageMagick are fine with using pipe-lined commands. So, what I split the single default resizer command into a conversion and then a re-size. I overrode the existing contribution with the following….

<command name="resizer" enabled="true">
     <parameterString> #{inputFilePath}[0] jpg:- | convert - -resize #{targetWidth}x#{targetHeight} –depth
                                    #{targetDepth} #{outputFilePath}</parameterString>
     <installationDirective>You need to install ImageMagick</installationDirective>

In the new “resizer” the input file first gets converted to a JPEG file (represented by the -), which is then piped into a convert command to resize the JPEG as required. This may cause slightly more work, but TIF files now get converted and resized as expected.

Resolving the TIF conversion issue with a simple contribution is a fairly simple solution.

One or the Other...

Unfortunately, not all fixes are so straight forward. The “CropAndResize” command is used by the tiling service to facilitate annotations. Crop and resize issues a pipelined ImageMagick command (stream | convert … see below) that takes an input stream and converts the image to a specified size using a given color map. Problem is – the color map is hardcoded as RGB – which is an issue for any image in a CMYK color space.

<command name="cropAndResize" enabled="true">
      <parameterString> -map rgb -storage-type char -extract #{tileWidth}x#{tileHeight}+#{offsetX}+#{offsetY}
                                    #{inputFilePath} - | convert -depth 8 -size #{tileWidth}x#{tileHeight} -resize
                                    #{targetWidth}x#{targetHeight}! rgb:- #{outputFilePath} </parameterString>
      <installationDirective>You need to install ImageMagic.</installationDirective>

The –map rgb in the cropAndResize command can be changed to –map cmyk (and the piped output changed to cmyk:-) … and CMYK images will now appear properly for annotations. However, RGB images are no longer tiled correctly. In this case programmatic changes are required to determine the color space of the image being processed and then to pass the appropriate color map value to cropAndResize as a parameter.  Getting the color space could be part of an existing Identify command (where all image objects are picked up) or it could be done in a separate process using “identify –format %[colorspace] filename.tif” (although this will incur extra processing costs).

To make this work the image tiling package and imaging core package need to be modified.

Big Image Efficiencies... next time

Finally, when it comes to dealing with big files in Nuxeo (100MB+) there is room for improvement. I haven’t yet walked through the whole process but I have watched the number of temp files that get created during the ingestion process. At first blush it appears that there is an opportunity to make this more efficient – which is really important for large files! However, I will have to dig into this another time.

Branding DM and DAM

I really like what's happening with themes and styling in DM. Creating custom look and feel has become much easier in the latest release. With pages, flavors, and CSS styling comes a flexibility that henceforth did not exist in DM. Styling has become another configuration item, rather than a mystical journey into big and ugly XML file requiring a modicum of magic to get the result you wanted.

I was a saddened a bit to see this new approach hadn't propagated through to DAM. When I went to perform a comparatively simple branding task in a Nuxeo deployment with DAM and DM I found the 'flavor' extension point only applied to DM... So the following XML, which I thought would change the logo in all places only showed up in the DM UI.

    <extension target="org.nuxeo.theme.styling.service" point="flavors">
        <flavor name="mybranding" extends="default">


To get the logo to change in DAM I had to revert back to pre-5.5 approach. Easy enough change once you realize what's going on, but slightly confusing at first when your logo insists on not changing.

I know this will eventually be rationalized. I just hope it's sooner than later.

While I'm on my DAM Soapbox

Subtitle: Nuxeo - Room for Improvement - Part 3

The DAM UI is built for the consumer of Digital Assets. As a search-centric UI, I think Nuxeo has done a great job making the interface usable and practical. If you need to find an asset then you have great tools at hand.

If you are a digital asset contributor then you will more than likely work in both the DM and DAM interfaces. Because the DAM UI is search-centric the flexibiliy and power of the DM interface is almost completely hidden.

There is another group of users that sit between consumers and contributors. I call them reviewers and approvers - often not the originators of content or necessarily the end consumer. They have special needs that demand additional rights. It would be nice if this group could live in the DAM UI and complete there tasks.

Some of the DM functionality that is important for the DAM interface:

1. Workflow - probably a topic worthy of discussion on it's own, however, the focus for now would be BATCH workflow and BATCH approval - simliar to Batch Edit! When a new project has 400 assets imported they could be reviewed and approved in BATCH mode from within the DAM UI.

2. Publishing - a natural extension of the DM interface, but the ability for DAM users to initate publishing (in BATCH) of selected assets

3. Setting Alerts - if you work with assets on a campaign and somebody updates 30 key renderings then you would like to know. Again, for the DAM-only consumer it would be great to have this ability in the DAM UI.

Of course there are more but that's all i have time for at the moment.

Showing 1 - 5 of 7 results.
Items per Page 5
of 2

Recent Entries Recent Entries

RSS (Opens New Window)
Showing 1 - 5 of 15 results.
of 3