This Adobe Experience Manager (AEM) Assets feature replicates any changes you make to the asset metadata to the renditions of the asset.
When you change the metadata for an asset within AEM Assets or while uploading it, the changes are stored within the folder hierarchy defined for the asset.
For example, using the Asset editor, you can modify the Title property of the asset titled "Target" to "Target_1."
In this case, the AEM Assets saves the changes to the Title property in the dc:title parameter for the asset metadata stored in the asset hierarchy.
However, AEM Assets does not automatically propagate any metadata changes to the renditions of an asset.
The XMP writeback to renditions features lets you propagate the metadata changes to all or specific renditions of the asset. However, the changes are not stored under the metadata node in the asset hierarchy. Instead, this feature embeds the changes in the binary files for the renditions.
To enable the metadata changes to be propagated to the renditions of the asset when uploading it, modify the Adobe CQ DAM Rendition Maker configuration in Configuration Manager.
If you want the feature to propagate metadata changes to select renditions of the asset, add the name of the renditions to the XMP Writeback Process workflow step of DAM Metadata WriteBack workflow. By default, this step is configured with the original rendition.
For example, if you want the metadata changes to propagate to the renditions thumbnail.140.100.png and thumbnail.319.319.png:
The metadata changes are propagated to the renditions renditions thumbnail.140.100.png and thumbnail.319.319.png of the asset, and not the others.
For XMP writeback issues in 64 bit Linux, see How to enable XMP write-back on 64-bit RedHat Linux.
For more information about supported platforms, see XMP metadata write-back prerequisites.
AEM Assets supports both blacklist and whitelist filtering of properties/nodes for XMP metadata that is read from asset binaries and stored in JCR when assets are ingested.
Blacklist filtering lets you import all XMP metadata properties except the properties that are specified for exclusion. However, for asset types such as INDD files that have huge amounts of XMP metadata (for example 1000 nodes with 10,000 properties), the names of nodes to be filtered are not always known in advance. If blacklist filtering allows a large number of assets with numerous XMP metadata to be imported, the AEM instance/cluster can encounter stability issues, for example clogged observation queues.
Whitelist filtering of XMP metadata resolves this issue by letting you define the XMP properties to be imported. This way, other/unknown XMP properties are ignored. You can add some of these properties to the blacklist filter for backward compatibility.
Filtering works only for the properties derived from XMP sources in asset binaries. For the properties derived from non-XMP sources, such as EXIF and IPTC formats, the filtering does not work. For example, the date of asset creation is stored in property named CreateDate in EXIF TIFF. AEM stories this value in the metadata field named exif:DateTimeOriginal. As the source is a non-XMP source, filtering does not work on this property.
To filter out blacklisted XMP properties after applying whitelist filtering, specify them in the Blacklisted XML Names for XMP filtering box.
The Apply Blacklist to XMP Properties option is selected by default. In other words, blacklist filtering is enabled by default. To disable blacklist filtering, unselect the Apply Blacklist to XMP Properties option.