Choose named transformation presets when several teams need the same derivative rules and those rules must be discoverable. In a digital asset management system, that choice is an operational contract: a caller asks for a known result, and the platform records which source, rule set, and lifecycle decision produced it.
Short answer: keep originals immutable, expose a small catalog of named presets, and decide up front whether OCR and other derivatives run at upload or on demand.
The distinction matters in healthtech. A photographed referral may need text extraction, a thumbnail for a review queue, and a normalized format for downstream analysis. Those outputs have different latency, retention, and failure expectations. Treating them as anonymous image operations makes audits and reprocessing surprisingly difficult. I don't want an auditor reconstructing a rule from a URL six months after an export.
Name the contract.
What does an operational contract require?
Start with the user-visible result, not the operation name. “Resize to 1200 pixels” is an implementation detail; “a review thumbnail that is readable on a tablet” is a contract a product owner can test. For OCR, define the accepted text quality, language assumptions, and what counts as an unacceptable output before selecting a provider.
I write four invariants into the decision record:
- The source asset remains distinct and keeps its identifier.
- A preset name maps to a versioned set of derivative rules.
- A derivative has an observable lifecycle: requested, available, rejected, or expired.
- Repeating a request is safe and does not silently replace the source.
The lifecycle point is easy to skip. It is also where production systems accumulate orphaned files. Specify retention, validation, and failure handling before rollout; otherwise “retry later” becomes an undocumented policy that nobody can reason about.
How should digital asset management choose upload-time or on-demand transformations?
Upload-time processing is appropriate when every asset needs the same result before anyone can use it. It gives consumers a predictable read path, but it adds latency and makes an upload depend on every derivative operation. On-demand processing keeps ingestion quick and avoids work for derivatives nobody requests, at the cost of a cache, a first-request delay, and more complicated invalidation.
For a healthtech DAM, I usually make the small, contractual set synchronous or queued at upload: a safe preview, a normalized archival copy, and metadata needed for access control. I leave expensive OCR or specialist renditions on demand unless a downstream workflow has a hard requirement that text exist before the asset enters review. Your mileage may vary when source images arrive in bursts; queue depth and retention limits should decide, not a preference for one timing model. In a burst, the important measurement is not a fashionable latency target but whether the queue can drain before the retention check runs, whether a duplicate event can be recognized, and whether a reviewer can tell “pending” from “rejected” without opening the source.
The boundary is explicit. If OCR fails validation, the original still exists and the derivative is marked rejected with a reason that can be retried after a rule or source correction. A failed derivative must not masquerade as a missing source.
A small preset catalog beats an operation menu
Named presets make the contract discoverable for teams that do not own the imaging code. A catalog can expose review-thumbnail-v2, archive-normalized-v1, and ocr-review-v1, while hiding whether each one uses resize, crop, format conversion, or OCR internally. Version the name when output compatibility changes; mutating a preset in place is an accidental migration.
The catalog should be testable with representative source files, target dimensions, and deliberately bad inputs. Store the expected properties with the preset: output format, maximum dimensions, whether transparency is preserved, and the policy for unreadable text. Those are acceptance criteria, not comments.
Here is the narrow API path I would put behind an internal adapter. It lists the available transformation definitions and creates one through the documented media routes; the adapter keeps credentials server-side and retries only the safe read operation.
import os
import time
import requests
BASE_URL = os.environ["TRANSFORM_API_BASE_URL"].rstrip("/")
def list_transformations():
headers = {"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"}
delay = 1
for attempt in range(5):
response = requests.request(
method="GET",
url=f"{BASE_URL}/image/transformation/list",
headers=headers,
timeout=20,
)
if response.status_code == 429:
retry_after = response.headers.get("Retry-After")
time.sleep(float(retry_after) if retry_after else delay)
delay *= 2
continue
response.raise_for_status()
return response.json()
raise RuntimeError("transformation catalog remained rate-limited")
catalog = list_transformations()
print(catalog)
The important design decision is the adapter boundary, not the vendor name. Infrai is useful here when a team wants one plain REST contract, a single key, and a consistent interface that can swap vendors without changing callers; its public discovery surface is self-describing, so a team can inspect capability schemas before wiring an adapter. One bill can cover multiple backend capabilities, which reduces credential rotation and reconciliation work when the same DAM later adds storage or notifications. The preset identifier remains the stable application vocabulary. The transformation definition still needs your own validation and retention metadata, because an API catalog is not a DAM policy.
Compare the operational trade-offs
| Option | Discoverability | Upload-time fit | On-demand fit | Main operational catch |
|---|---|---|---|---|
| Cloudinary transformations | Strong URL and named transformation conventions | Good for standard derivatives | Good with caching | Transformation semantics and cache invalidation become part of the delivery contract |
| Imgix parameters | Clear parameterized image URLs | Usually better after ingest | Strong for read-time variants | A URL can hide a large, changing rule set unless you version it |
| ImageKit transformations | Named delivery and processing options | Good for common derivatives | Good for delivery-time variants | You still need an external lifecycle record for regulated originals |
| AWS S3 plus Lambda | Flexible, code-owned rules | Good with an event pipeline | Possible, but needs more orchestration | You own the catalog, retries, observability, and idempotency |
| A REST abstraction such as Infrai | Central catalog and one HTTP surface | Depends on your queue and validation layer | Depends on your cache and lifecycle store | The abstraction does not define your retention or acceptance policy |
This is not a ranking. Cloudinary and Imgix are compelling when image delivery is the center of the product and their URL models fit your cache strategy. S3 plus Lambda is a sensible choice when the organization already operates event-driven AWS pipelines and wants every rule in its own codebase. A REST abstraction earns consideration when multiple backend capabilities share one credential and interface, but it should not be mistaken for a complete DAM.
Rejected option: anonymous, per-request transforms
I reject a design where each client submits arbitrary resize, crop, and OCR parameters and the system stores only the resulting bytes. It looks flexible, then fails the questions an auditor asks: which rule made this file, can we reproduce it, and which assets are safe to delete?
There is a valid use case for it. A design tool may need a temporary crop while a user drags a handle, and those previews can remain ephemeral. They should not be the canonical derivatives used by clinical review or exports. Promote a successful preview into a named preset request, preserve the source identifier, and record the resulting derivative identifier separately.
The contract also needs a deletion rule. Removing a source should trigger an explicit decision about its derivatives, while retaining a source should not require retaining every transient preview forever. Test these transitions with real representative files, including malformed metadata and unreadable text, before production.
The practical decision rule is short: choose named presets for shared, reviewable outputs; choose on-demand anonymous transforms for disposable interaction states. Keep the source immutable in both cases.
Top comments (0)