Workflow
Running print and web from one asset library
Most publications that do both ended up with two libraries by accident. The print operation had one first, the web operation built its own because the print one could not serve pages fast enough, and now the same photograph exists in both…
Consolidating is worth doing, and it is not a matter of merging the two. It is a matter of separating masters from derivatives properly, which is the thing neither library was doing.
The requirements genuinely differ
Print wants the largest file available, in a colour space intended for ink, at a size fixed when the page is laid out. It wants it once, and it does not care how long the request takes.
The web wants a small file, in a colour space intended for screens, at whichever of several sizes the layout asks for, delivered in milliseconds, thousands of times.
These are not two versions of the same requirement. Trying to satisfy both from one stored file produces either print quality at web speed — which is slow and expensive — or web quality in print, which is visibly bad.
One master, generated derivatives
The resolution is the standard one and it is worth stating plainly because so many libraries fail to implement it.
The library stores one master per photograph: highest available resolution, unmodified, in a preservation format. Nobody uses the master directly.
Everything anyone actually touches is a derivative generated from the master: the print-resolution export in the right colour space, the several web sizes, the thumbnail, the social crop. Derivatives are produced on demand or on ingest, cached, and discarded and regenerated freely.
The essential property is that no derivative is ever the only copy. A derivative can be deleted at any time without loss, which is what makes it safe to generate as many as the workflows need.
Colour, which is where it goes wrong
Colour management is the single most common source of print-and-web trouble, and it is entirely mechanical.
Keep the master in a wide working colour space with its profile embedded. Convert to the print profile when generating the print derivative, and to the screen profile when generating the web derivative. Convert once, at generation, from the master — never from another derivative.
The failure mode is converting a web derivative for print or the reverse, which produces colours that are wrong in a way that survives every subsequent correction. Because each individual step looks reasonable, this is usually diagnosed as a printer problem.
Cropping once, using everywhere
The crop is the other point where two workflows diverge unnecessarily.
Store a focal point on the master — the coordinates of what the picture is actually of. Every automated crop then keeps that point in frame: the 16:9 hero, the square card, the tall mobile placement, the print cutout.
Store named crops for the cases automation cannot handle. A picture editor's considered crop is an editorial decision and should be recorded as a property of the asset, available to both print and web, rather than made twice by two people.
This is the change that most reduces duplicate work, and it is cheap: a focal point takes one click at ingest.
One caption, one rights record
The reason to consolidate is not storage. It is that a photograph currently has two captions, two credit lines and two rights notes, and they disagree.
After consolidation, a caption is written once, against the asset, and both outputs draw from it. A correction is made once and propagates. A rights restriction — editorial only, licence expiring, territory limited — is recorded once and is visible to everybody who retrieves the image, including the person on the web side who would otherwise never have seen the contract.
That last point is the strongest argument for the whole exercise. Most licence breaches we see come from one side of a publication using a frame the other side licensed, under terms it had no way of knowing about.
Serving at web speed
The objection to a single library is always performance, and it is answerable.
The web does not read from the library. It reads from a cache or a delivery network that the library populates. Derivatives are generated when the asset is published or first requested, then served from the edge like any static file.
The library is then a system of record, not a serving system, and its performance characteristics stop mattering. This is what makes the print requirements — large files, slow queries, deep metadata — harmless to the site.
What to do first
Do not attempt a merge. Pick the library with better metadata, establish it as the system of record, and make the other one a consumer of derivatives generated from it. Then reconcile the assets that exist in both, one batch at a time, keeping the better master and the better caption.
The reconciliation is where the real work is, because it is editorial rather than technical, and because it surfaces every disagreement between the two records. That is the value: those disagreements are already published.
Conclusion
One master, many generated derivatives, one caption, one rights record, a focal point set once, colour converted from the master rather than between derivatives, and a cache between the library and the site. Print and web have genuinely different output requirements and exactly the same source requirements, and every problem with running both comes from confusing the two.