# Processing, delivery and bulk ingest Verified 2026-09 against and . ## Processing profiles A processing profile is attached to a folder tree and runs on ingest, producing the renditions that tree needs. Define one per meaningful class of asset rather than one per folder: - **Web imagery** — the rendition sizes the front end requests, plus a thumbnail. - **Documents** — a page-one preview image and a thumbnail. - **Video** — poster frame and the encodes the player supports. - **Print / source files** — thumbnail only; the original is the deliverable. Points that catch people out: - A profile applies to assets uploaded *after* it is attached. Existing assets need explicit reprocessing, which is a long job on a large tree — validate on a sample folder first. - More renditions is not free: each is storage, processing time and something to invalidate. Dynamic Media derives sizes on the fly, so static renditions are for cases it cannot serve. - Changing a profile does not retroactively change delivered URLs for already-processed assets. ## Smart crops Smart crops come from Dynamic Media image profiles. Define the ratios the design system actually uses — typically three or four (16:9, 1:1, 4:5, and a wide hero) — not one per breakpoint, because a responsive image picks a *size* within a ratio, not a new ratio. Check the automatic crop on a sample of real assets: faces and product edges are where it goes wrong, and those are corrected per asset in the UI. ## Delivery URL forms | Consumer | URL form | Notes | |---|---|---| | Sites page | Core Image component with Dynamic Media enabled | Emits responsive `srcset` and picks format per browser | | Headless, composed screen | `_dynamicUrl` on the image field in GraphQL | Web-optimized, CDN-cacheable; returned with the content in one call | | Headless, by asset id | Dynamic Media delivery API, `/adobe/assets/{id}/as/.` with size and format parameters | Use when the consumer has the id but not the fragment | | Exact original bytes | `_publishUrl` / original rendition | Downloads, print, anything re-encoding would damage | Because the CDN caches these aggressively, a replaced asset must yield a new URL. Use the platform's versioned delivery URLs; a hand-rolled `?v=` query parameter fragments the cache without guaranteeing freshness. ## Bulk Import Bulk Import ingests from cloud storage — Azure Blob, Amazon S3, Google Cloud Storage or Dropbox — and is the supported route for volume. A run that goes well looks like this: 1. Design the target folder structure; attach metadata profiles and processing profiles to it. 2. Stage the binaries in the source bucket in a layout that maps to that structure. 3. Supply metadata alongside the binaries in the same pass, so assets arrive complete. 4. Import a sample of a few hundred assets. Verify: folder placement, metadata populated, renditions generated, delivery URL works, search finds them by the intended facets. 5. Only then run the full import, and re-verify the same six things on a sample of the result. Importing binaries first and "doing metadata later" turns into a second migration project over a much larger collection. ## Asset Compute workers Asset Compute is a microservice, deployed through App Builder, that produces renditions the platform cannot. Legitimate cases: a brand watermark with exact placement rules, a PDF preview with specific rendering settings, a thumbnail for a proprietary 3D or CAD format. Shape of a worker: ```js 'use strict'; const { worker } = require('@adobe/asset-compute-sdk'); exports.main = worker(async (source, rendition, params) => { // source.path — the downloaded original // rendition.path — write the output here // rendition.instructions — the parameters from the processing profile await transform(source.path, rendition.path, rendition.instructions); }); ``` Before writing one, confirm a processing profile or Dynamic Media cannot already do it — a worker is code to deploy, monitor and upgrade for the life of the DAM.