Email: dev@concena.com       Twitter: @dbrucegrant

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

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">
    <require>org.nuxeo.ecm.platform.commandline.executor.service.defaultContrib</require>
    <extension target="org.nuxeo.ecm.platform.commandline.executor.service.CommandLineExecutorComponent”
                         point="command">
        <command name="identify" enabled="true">
            <commandLine>identify</commandLine>
            <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>

        :

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

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">
     <commandLine>convert</commandLine>
     <parameterString> #{inputFilePath}[0] jpg:- | convert - -resize #{targetWidth}x#{targetHeight} –depth
                                    #{targetDepth} #{outputFilePath}</parameterString>
     <installationDirective>You need to install ImageMagick</installationDirective>
</command>

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">
      <commandLine>stream</commandLine>
      <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>
<command/>

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">
            <logo>
                <path>/img/Custom-Logo-36x36.png</path>
                <previewPath>/img/Custom-Logo-36x36.png</previewPath>
                <width>32</width>
                <height>32</height>
                <title>alt</title>
            </logo>

              ...

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.

Nuxeo - Room for Improvement - Part 2

Given that I'm working with DAM at the moment thought I would critique the current (5.5) version and suggest a couple of areas where there is room for improvement!

When 5.5 was released the alignment and integration of DAM/DM was a notable achievement. There are as I found still differences under the cover. A simple, but surprising difference - when I added in a new icon to replace the standard nuxeo logo I used the new 5.5 styling service. This worked for everything but DAM which still uses pre-5.5 styling (at least as far as I can see). From an ease of branding perspective it would be great if these were aligned across all 5.5 products and not just DM.

More importantly, in investigating custom filtering widgets I noticed that the FilterActions.java class has hard-coded Asset document definitions. I found this because I wanted to split out office documents into true office documents and PDF files. Adding a file type PDF and making it show up in the filter requires some work (beyond the scope of this blog entry) but it will only work by customizing and overriding the FilterActions class. The current class has a static arraylist that limits DAM asset types to File, Picture, Video and Audio. It would be much more flexible if this list were dynamic; based either on contribution or (even better) by any type contribution that has the facet Asset!

[Added 2012.02.08] And a recent post to Nuxeo Answers makes me pine for already-integrated Adobe XMP support!

Anyways, some DAM food for thought.

>> Nuxeo - Room for Improvement - Part 1

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

Recent Entries Recent Entries

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