File specs, captions, color management, and an image-asset system

Pixels vs DPI/PPI — why DPI is meaningless for screens

A digital image's true size is its pixel dimensions (e.g., 1920 × 1280 pixels).

DPI (dots per inch) and PPI (pixels per inch) are print concepts: they describe how densely a fixed number of pixels is packed onto paper. On a screen, the display's own pixel density is fixed, so the DPI tag embedded in a file has no effect on how large or sharp the image appears. A 72-DPI and a 3,000-DPI file of identical pixel dimensions display identically on the same monitor. The practical rule: for screen submission, specify pixels; ignore DPI. DPI matters only when you cross into print, where it interacts with physical output size (print size = pixel dimension ÷ DPI).

This is why a submission requirement phrased as "300 DPI" is, on its own, meaningless for a jury that reviews on screen — what they actually constrain is the pixel count and the file weight. When a portal lists a DPI figure alongside pixel dimensions, treat the pixel dimensions as the operative spec.

Jury/"jukebox" review systems (where works are projected or shown side-by-side on screen) historically standardized on the longest side as the controlling dimension. Illustrative, durable ranges (not a live rule):

• A common minimum floor is ~1,200 px on the longest side — below this, detail collapses when a juror zooms.
• A frequent target is 1,920 px on the longest side (matching HD review screens); some systems accept or request up to ~3,000 px or more so jurors can zoom into detail.
• Some current systems have removed maximum-pixel ceilings entirely and instead rely on a file-size cap, encouraging the highest-quality image the weight limit allows.

Because the longest side governs, orientation is handled automatically — a 1,920 px constraint applies to width for a landscape work and to height for a portrait work. Size by the long edge and the aspect ratio takes care of itself.

Submission portals cap individual file weight to keep uploads fast and review responsive. A 5 MB-per-image ceiling is a long-standing, representative value (illustrative, not a live rule); some systems double the limit when print-quality images are needed, and gallery email submissions often sit in a 2–5 MB band. The mental model worth having (a CaFÉ coordinator's "box" metaphor): the file-size cap is a fixed box; within it you fit the largest pixel dimensions that will fit under the weight limit. You trade pixel dimensions against JPEG compression to land under the ceiling.

Format selection — JPEG, TIFF, PNG, pdf

• JPEG is the near-universal delivery/submission format for photographic images of artwork: small, broadly compatible, and the only format some portals accept. It uses lossy compression (Discrete Cosine Transform on 8×8 pixel blocks), discarding high-frequency detail. Appropriate for final output; inappropriate as a working/master format.
• TIFF is the standard archival/master and prepress format: lossless (or uncompressed), preserving every pixel, supporting 16-bit depth and layers. Files are large (a master can be tens of MB to multiple GB). Use for masters and for print houses that request it. Many portals do not accept TIFF for upload.
• PNG is lossless and excels at sharp-edged graphics, text, line art, screenshots, and images needing transparency. For continuous-tone photographs of artwork it offers no quality advantage over a high-quality JPEG at far larger size, but it is a valid lossless intermediate. Some portals accept it; others do not.
• PDF is page-oriented: appropriate for multi-page documents, proposals, artist books, or vector layouts, and PDF/A is a preservation-grade variant. It is generally not the vehicle for individual artwork images in a jukebox review, and some portals explicitly reject multi-page PDFs as work samples.

JPEG quality is a slider (often 1–100, or Photoshop's 0–12). The durable guidance:

• Quality ~75–85 (or Photoshop 8–10) is the practical sweet spot for web/submission photos: visually near-lossless with large size savings. The maximum setting is effectively visually lossless at ~10% of an uncompressed raster's size.
• Below ~60, artifacts become visible: blocking (the 8×8 grid showing in smooth gradients like skies and skin), ringing/mosquito noise (halos around sharp edges and text), and banding in gradients.
• Generation loss is cumulative: every re-save of a JPEG re-runs lossy compression on already-degraded data. After a few re-saves, blocking and blurring compound. The rule: never edit and re-save in JPEG repeatedly. Edit the master (TIFF/PSD/raw), and export to JPEG once, as the final step.

Once lossy compression discards data, it is gone — no upscaler restores the original information (AI tools synthesize plausible detail, they do not recover it). A lossless master (TIFF, PNG, PSD, or the raw capture) is the only source from which you can re-derive any future format, size, or color space without compounding loss. This is the foundation of the master-derivative model in Section 5.

Beyond the full/overall view, documentation conventions distinguish:

• Detail shots — close crops showing surface, texture, brushwork, or a passage of the work. Jukebox systems frequently request "one overall + one detail" per work.
• Installation shots — the work shown in situ (on a wall, in a room), giving scale and spatial context, essential for installation, sculpture, and site-specific work.
• For time-based media (video, sound, performance), the still image is a representative frame or still, and the work list carries runtime rather than physical dimensions.

Each shot type should be captioned and named so the reviewer knows whether they are seeing the whole work, a detail, or an installation view (the framing/shooting of these is capture craft, out of scope here).

Highest-leverage insightA DPI figure on its own tells a screen jury nothing; pixel dimensions and file-size ceilings are what actually govern how the work is seen.

What an ICC profile is

An ICC profile (International Color Consortium standard; .icc/.icm) is a data file that defines what the numeric RGB (or CMYK) values in an image actually mean in terms of visible color — it maps a device's or color space's values to a reference. Color-management systems use profiles to reconcile differences among camera, monitor, and printer so a color can be predicted across devices. Without a profile, an application must guess (it usually assumes sRGB), and color "drifts."

These are color spaces (gamuts) of increasing size:

• sRGB — the smallest of the three; the de facto standard for the web, screens, and most consumer devices. It was proposed by Hewlett-Packard's Michael Stokes and Ricardo Motta with Microsoft's Matthew Anderson and Srinivasan Chandrasekar in "A Standard Default Color Space for the Internet – sRGB" (Nov. 5, 1996), and formalized by the International Electrotechnical Commission as IEC 61966-2-1:1999 ("Default RGB colour space – sRGB").

• Adobe RGB (1998) — a wider space with extra reach in cyans/greens; it "occupies roughly 40% more volume than the sRGB color space" and encompasses slightly more than 50% of all visible colors specified by the CIE. Historically favored for print workflows feeding wide-gamut inkjet printers.

• ProPhoto RGB — very wide, encompassing essentially all colors a camera can capture (and some no device can display); an excellent editing/working space but unsuitable for direct delivery.

Must be used at 16-bit to avoid banding.

Most applications that view images (browsers, OS previews, social platforms, juror viewers) are not reliably color-managed: they ignore the embedded profile and render values as if they were sRGB. An Adobe RGB or ProPhoto RGB file dropped into such an app appears dull and desaturated because its wider-gamut numbers are misinterpreted in a small space. Therefore the durable delivery rule: edit wide, deliver in sRGB with the profile embedded. Convert to sRGB as the final export step for any web/screen submission. Wide-gamut files should be "kept in a cage" and never released into non-color-managed contexts.

Always embed the ICC profile on export. An embedded profile tells any color-managed recipient how to interpret the numbers; a file without one forces a guess. Embedding sRGB adds negligible weight and is the single most reliable safeguard against color drift.

• Assign Profile changes the interpretation of the existing numbers without changing them — it re-labels what the values mean, so the on-screen appearance can shift dramatically. Use only when a file is missing a profile or carries the wrong one, to attach the correct interpretation.
• Convert to Profile recalculates the numbers to preserve appearance as closely as possible in the destination space. Use this for normal output (e.g., wide-gamut working space → sRGB for web; or → a printer/paper profile). Converting from a small space into a larger one does not add saturation; only converting down can clip the most saturated colors.

The mantra: in color management you "change the numbers to stay the same" (Convert), versus "keep the numbers, change the look" (Assign).

Monitor calibration — the foundation

Every color decision is made by eye on a monitor; if that monitor is uncalibrated, every edit is based on a false reference and may look wrong everywhere else. Monitors vary by panel, age, and manufacturing, and they drift over time. The durable practice:

• Use a hardware calibrator (colorimeter/spectrophotometer) that measures actual output and builds a correction ICC profile — software "eyeball" calibration is only marginally better than nothing because you are using uncalibrated eyes to judge an uncalibrated screen.
• Typical targets: D65 white point, ~100–120 cd/m² luminance for screen-oriented work; D50 better matches print-evaluation viewing. A web-and-print compromise is D65 at moderate luminance plus soft proofing.

• Recalibrate periodically (commonly every 2–4 weeks) as displays age. Never judge color on a phone screen.

• 8-bit = 256 levels per channel (~16.7M colors). Adequate for final delivery files.

• 16-bit = vastly more levels, giving headroom for large tonal/color edits without banding (visible steps in gradients). The rule: edit in 16-bit (especially in wide-gamut spaces), then export 8-bit JPEGs for delivery. Masters should be retained at 16-bit where the capture supports it.

A gamut is the range of colors a space or device can reproduce. When converting from a larger gamut to a smaller one (e.g., to a printer), out-of-gamut colors must be remapped, governed by a rendering intent. Two matter for images:

• Perceptual — compresses the entire gamut proportionally so relationships between colors are preserved; nothing is hard-clipped but everything shifts slightly. Best for images with many out-of-gamut/saturated colors.
• Relative Colorimetric — keeps in-gamut colors exact and clips only out-of-gamut colors to the nearest reproducible value. Best when most colors are already in gamut. (Saturation and Absolute Colorimetric intents exist but serve graphics and proofing, not photographic reproduction.)

There is no universally "better" intent; choose per image, ideally using a soft-proof gamut warning.

Soft-proofing simulates on your calibrated screen how an image will look when converted to a specific output profile (a given printer/paper). You select the output ICC profile, choose a rendering intent, and enable "simulate paper & ink" to preview the (duller) paper white and reduced black density. A gamut warning flags colors the output cannot reproduce, so you can adjust before committing. Soft-proofing is how you reconcile screen and print before wasting materials.

Screens are additive RGB; most presses are subtractive CMYK. Offset/commercial print requires conversion to a CMYK space, ideally using the specific ICC profile for the target press/paper (often supplied by the print house) rather than a generic CMYK. The basic workflow: edit in a wide RGB working space at 16-bit, soft-proof to the output profile, then convert with the appropriate rendering intent. Fine-art inkjet printing is often driven from RGB with paper-specific profiles. (Deep prepress is its own discipline; the durable point is use the output device's actual profile and soft-proof first.)

Highest-leverage insightColour only survives a journey between devices when a profile travels with the file — an unmanaged image is not neutral, it is unpredictable.

Why naming is infrastructure

A filename is the smallest unit of an archive's findability. Good names are simultaneously machine-sortable (they order correctly in any file browser, script, or database) and human-readable (a person can identify the file without opening it). Consistency here is what keeps a body of work navigable over years and across systems.

• No spaces. Spaces break URLs, command lines, and some systems (rendering as %20). Separate elements with underscores _ and words within an element with hyphens -.
• Use only safe characters: letters A–Z a–z, digits 0–9, hyphen, underscore. Avoid reserved/special characters (/ \ : * ? " < > | & # %. ,; ' [ ] { }) — many are reserved by operating systems and several portals reject filenames containing them or extra dots.
• Lowercase by default — case is not preserved consistently across systems and case-based word separation (camelCase) is hard to search.
• ISO 8601 dates: YYYY-MM-DD (or YYYYMMDD). This is the one date format that sorts chronologically when sorted alphabetically, and avoids regional MM/DD vs DD/MM ambiguity. Use numerals only; never spell months.
• Leading zeros for any sequence: 001, 002 … 010 … 100. Without padding, file2 sorts after file10 because numerals are read as characters, not values. Pad to the maximum count you anticipate.
• Controlled vocabulary: maintain a documented list of the abbreviations/codes you use (media, view types, etc.) so they are applied consistently.
• Keep names reasonably short (a ~30-character target is common) while staying descriptive.
• Most important element first: lead with whatever you most often sort or group by (artist, then title/work-ID, then view, then version).

A widely used pattern is artist_title_year_view_version. Illustrative example (not a live rule):

lastname-firstname_work-title_2024_v01_detail-02.tif

Components: artist (lastname-firstname), work title (hyphenated), four-digit year, version (v01), and view/sequence (detail-02). For a master vs derivative you might encode size: ..._master.tif, ..._sub2000.jpg, ..._web1200.jpg, ..._thumb.jpg. The exact schema is tailorable; what matters is that it is documented and applied consistently.

Track versions inside the filename with a zero-padded version token (v01, v02) or an ISO date, appended consistently at the end. This makes the most current version unambiguous and preserves earlier states. Decide one convention (version number or date) and commit to it.

The filename should key directly to the work list / caption entry — ideally the file carries the same work-ID or title token used in the annotated work list, so a reviewer (or future cataloguer) can match image to record instantly. A common professional setup numbers images to a printed/PDF work list (Image 01 → caption 01), with the filename echoing that ID. This mapping is what lets a jury reconcile "which file is which work" without ambiguity.

Folder structure

Mirror the naming logic in folders: a stable top-level structure (e.g., by year, then by work, with sub-folders for master/ and derivatives/) keeps masters separated from outputs and prevents accidental edits to masters. Include a top-level README documenting the naming convention, codes, and folder logic so the system survives hand-off and the passage of time.

Renaming files after they enter a system can destroy provenance — it breaks links between images and their catalog records, embedded references, and any external citations, and can orphan files. The discipline: settle the convention before mass-naming, rename via documented batch tools if at all, and never casually rename archival masters. Non-descriptive system IDs (stable numeric strings linked to external metadata) are deliberately used in large archives precisely because they never need to change.

The caption (museum term: tombstone, for its bare-facts resemblance to a gravestone inscription) is the factual identity block of a work. Complete, correctly ordered captions matter for three durable reasons:

1. Disqualification risk — open calls frequently require specific fields and reject incomplete entries.
2. Professionalism — sloppy or missing data signals an unprepared artist.
3. Future cataloguing — complete data is what lets a registrar, gallery, or archive ingest the work cleanly years later.

A tombstone gives only the essential facts; a longer interpretive "chat" or didactic label is separate and out of scope here.

The conventional field set, in roughly the conventional order:

1. Artist name — given in full. For anonymous work, "Artist unknown."
2. Title — conventionally italicized. Render the artist's own capitalization/punctuation.
3. Year/date of creation — usually the completion year; a span (2019–2021) for work made over time; c. / circa for approximate historical dates; "ongoing" for durational pieces.
4. Medium/materials — for mixed media, list in descending order of physical/conceptual significance.
5. Dimensions — see convention below; runtime for time-based media (e.g., "14 min. loop").
6. Edition/AP information — for editioned work (see below).
7. Credit line — collection, donor, or "Courtesy of the artist."
8. Copyright — e.g., © 2024 Artist Name; distinguish copyright in the artwork from copyright in the photograph.
9. Photographer credit — "Photograph: Name," where required.
10. Location/installation context — collection and city, or installation site.
11. Inventory/accession number — the catalog ID linking to the work's record.

Highest-leverage insightNaming is decided once and paid for daily: a convention chosen carelessly is felt on every deadline for years afterwards.

Treating 'Untitled'

"Untitled" is a legitimate title and appears constantly in contemporary art (often Untitled in italics, or "Ohne Titel"/"O.T."). Two durable conventions:

1. When an artist intends the work to be called Untitled, render it as such, and disambiguate multiples by appending a series name or number (e.g., Untitled #21, or Untitled (FS 245))
2. For cataloging retrieval, assign a unique inventory number to each untitled piece so they can be told apart.

Formal cataloging standards (Getty's CDWA and CCO) go further: do not use the word "Untitled" unless the creator intended it — for a genuinely untitled work, construct a descriptive title (e.g., "Abstract Composition," "Ceramic Bowl") so the work is findable, while indexing work type and subject in their own controlled fields.

• Order: Height × Width × Depth. This is the cross-disciplinary standard in art cataloging and publishing (AAE, CAA's Art Bulletin, museum practice). Height precedes width; depth is given third only when applicable (sculpture, relief, objects).
• Measure the work itself — the outer dimensions of the canvas/paper/object — excluding the frame unless the frame is integral to the work.
• Metric vs imperial: convention varies by institution and region; publishing practice often gives inches with centimeters in parentheses, e.g., 57 × 46 × 3 in. (144.8 × 116.8 × 7.6 cm). Provide both where the audience is mixed; follow the institution's stated unit otherwise.
• "Dimensions variable" for installation or work whose size changes with each install; runtime (minutes/seconds) replaces physical dimensions for video/sound/performance.

For prints, photographs, cast sculpture, and other multiples, the caption states the edition. Numbering is written as a fraction: 13/18 means the 13th impression of an edition of 18. Standard proof notations (durable across printmaking):

• A/P (or E.A.) — Artist's Proof; held by the artist, outside the numbered edition, conventionally up to ~10% of the edition size.
• P/P — Printer's Proof.
• B.A.T. (bon à tirer, "good to pull") — the approved reference print; one only, usually retained by the studio.
• T/P — Trial Proof; H.C. (hors commerce) — not for sale; C/P — Cancellation Proof.

The edition size is a public commitment: once set, producing more of the same edition undermines collectors and reputation. Editioned records should also capture paper vs image size and any variant (color, embellishment).

The annotated work list is the master index that ties each caption to its image file(s). Best practice: number each work, give each image a filename carrying that work-ID/title token, and ensure every overall, detail, and installation image points back to one caption entry. This one-to-one mapping is what lets reviewers, registrars, and your future self reconcile file ↔ work without guesswork — and it is the bridge between the caption (this section) and the embedded metadata.

Formal cataloging crosswalk (VRA core, CDWA, Dublin core, CCO)

The caption fields above map directly onto the cultural-heritage metadata standards that museums, libraries, and visual-resource collections use — worth knowing because they are stable and interoperable:

• VRA Core 4.0 (Visual Resources Association) describes images and the works they represent across three record types — Work, Image, Collection — using elements including agent, title, date, location, material, measurements, worktype, technique, stylePeriod, culturalContext, inscription, stateEdition, subject, rights, source. A recommended minimal Work record = Work Type, Title, Agent, Location, Date.
• CDWA (Categories for the Description of Works of Art), run by the J. Paul Getty Trust with the College Art Association — first edition published 1994 (editors Murtha Baca and Patricia Harpring), latest revised edition 2024 — comprises 532 categories and subcategories, of which a small core subset is the minimum to identify a work: Catalog Level, Object/Work Type, Classification, Title or Name, Measurements, Materials & Techniques, Creator (Description/Identity/Role), Creation Date, Subject, Current Location, and Repository Numbers.
• Dublin Core is the lightweight 15-element lingua franca that everything crosswalks to: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights.
• CCO (Cataloging Cultural Objects) is a data content standard — it gives the rules for how to fill those fields (term choice, syntax, title construction) — as distinct from data structure standards like VRA Core/CDWA/Dublin Core, which define what fields exist.

An artist need not catalog to museum depth, but aligning a personal work list to these field names future-proofs the archive and eases any eventual hand-off to an institution.

Highest-leverage insightThe caption is what lets a work be cited correctly by someone who was not there, so a complete tombstone is a claim about provenance, not a formality.

The master-derivative model

The organizing principle of a durable image-asset system: preserve exactly one untouched, high-resolution master per work; generate every other version from that master; never edit the master destructively. This mirrors archival practice, which distinguishes the archival/preservation master (highest quality, lossless, minimal adjustment, optimized for longevity and repurposing) from derivative/access files (compressed, resized, output-specific). Masters are written rarely and protected; derivatives are regenerated freely.

A master should be the best, most repurposable version you can hold:

• Lossless format — TIFF is the archival standard (uncompressed or lossless-compressed); PSD/raw are acceptable working masters. Avoid JPEG masters.
• Full resolution — the native pixel dimensions of the capture or scan; never downsized.
• 16-bit depth where the source supports it, for editing headroom without banding.
• Wide-gamut working space (e.g., ProPhoto RGB or Adobe RGB) so future wider-gamut outputs can draw on colors a small space would have clipped.
• Embedded ICC profile so the master's color is unambiguous.

TIFF's standing as a preservation format is reflected in its status among the formats libraries and archives (e.g., Library of Congress's sustainability/recommended-formats work) treat as preferred for still images, on criteria like open disclosure, wide adoption, and transparency.

From the one master, export a consistent ladder of derivatives, each purpose-built (illustrative tiers, tailorable):

• Print-resolution — full or near-full resolution, often TIFF or maximum-quality JPEG, in the output's color profile, for catalogs and reproduction.
• Submission-resolution — JPEG, longest side ~1,920–3,000 px, sRGB, under the portal's weight ceiling.
• Web-resolution — JPEG, longest side ~1,200–2,048 px, sRGB, quality ~75–85, for site and email.
• Thumbnail — a few hundred pixels, for contact sheets and indexes.
• Social — sized to the platform (e.g., long edge ~1,080–2,048 px), sRGB.

Each tier is regenerated from the master, never from another derivative — re-deriving from an already-compressed, already-downsized, already-sRGB file compounds quality loss and locks in a narrowed gamut.

Generate derivatives consistently and repeatably using export presets or batch actions (e.g., Lightroom export presets, Photoshop actions/Image Processor). Build one preset per tier (long-edge dimension, color-space conversion to sRGB, quality, output sharpening for screen vs paper, filename token, metadata handling) and reuse it. Multi-batch export can emit several tiers from one selection in a single pass. Presets enforce uniform sizing, color, naming, and sharpening across a whole body of work and eliminate hand-set errors. Because editing in Lightroom/raw is non-destructive (adjustments are stored as instructions, not baked into the file), quality is determined only at export.

Keep edits non-destructive: work from raw/TIFF with adjustments stored as metadata/instructions (Lightroom catalog, XMP sidecars) or as adjustment layers (PSD), so the master's pixels are never overwritten. This guarantees you can revisit and re-export at any time without having degraded the source.

Metadata embedding (IPTC/XMP) so captions travel

Embed the caption/identity data inside the file using the IPTC Photo Metadata Standard, carried technically via XMP — Adobe's Extensible Metadata Platform, introduced in 2001 and standardized as ISO 16684-1 (first published 2012, revised 2019); the older IIM/"IPTC headers" format persists for compatibility. Key IPTC fields map directly to caption elements: Creator, Copyright Notice, Credit Line, Source, Description/Caption, Title/Object Name, Date Created, Keywords, Rights Usage Terms. Embedding means the caption, authorship, and rights travel with the image wherever it goes, supporting attribution and discoverability (search engines read certain IPTC fields).

Two cautions: embed metadata into the master and let it propagate to derivatives on export; and beware that some content-management/social systems strip metadata on upload — keep your own embedded copies intact regardless.

Protect the masters (and the catalog) with the 3-2-1 backup rule — a phrase coined by photographer Peter Krogh in The DAM Book: Digital Asset Management for Photographers (O'Reilly Media); as Backblaze notes, Krogh "didn't invent the idea… but he did distill it down to what we now refer to as the 3-2-1 rule":

• 3 copies of the data (the working copy plus two backups),
• On 2 different media/storage types,
• With 1 copy off-site (geographically separate — cloud or a drive stored elsewhere).

This eliminates single points of failure: a drive failure, theft, fire, or ransomware cannot take all three at once. Modern extensions (3-2-1-1-0: add one immutable/air-gapped copy and verify zero recovery errors) strengthen it against ransomware, but 3-2-1 remains the durable baseline. The discipline only works if backups are tested — an unverified backup is a false sense of security. Treat the master archive plus the work list/metadata as the irreplaceable assets to protect.

Every derivative is a lossy, narrowed descendant: smaller pixels, JPEG compression, and (usually) sRGB clipping. Re-deriving from it inherits and compounds all of those losses and can never recover the master's resolution, bit depth, or gamut. The master is the single source of truth; all tiers flow from it. This is why the model is a hub-and-spoke (master → each derivative) and never a chain (master → derivative → smaller derivative).

Highest-leverage insightOne untouched master per work is what keeps every future derivative possible; a derivative made from a derivative loses what cannot be recovered.

Stage 1 — Establish the system once (before the next submission).

1. For each work, create and store one lossless 16-bit TIFF master at full resolution in a wide-gamut space with an embedded profile.
2. Set up a documented filename convention (artist_title_year_view_version, lowercase, ISO dates, zero-padded) and a folder structure separating master/ from derivatives/, with a README.
3. Calibrate your monitor with a hardware device; recalibrate on a schedule.
4. Build the annotated work list with complete tombstone fields and embed the data as IPTC/XMP in each master.

Stage 2 — Produce derivatives per opportunity

5. Build export presets for each tier (submission, web, print, thumbnail, social), each converting to sRGB + embedded profile for screen tiers and applying tier-appropriate sharpening.
6. Regenerate every derivative from the master, never from another derivative.
7. Read each portal's current spec and pick the preset that fits; size by the longest pixel edge and stay under the file-size ceiling; ignore DPI for screen.

Stage 3 — Protect and maintain

8. Implement 3-2-1 backups (3 copies, 2 media, 1 off-site) covering masters + work list + catalog; test restores.
9. Re-export derivatives whenever specs change — cheap, because the master is intact.

Thresholds that change the approach

• If a portal requests print-quality/large files, switch to the print-res preset (full resolution, higher weight ceiling) rather than the submission preset.
• If you move into commercial/offset print, add CMYK conversion using the print house's supplied ICC profile and soft-proof first.
• If you begin selling editions, add edition/AP fields to the work list and embed rights terms in IPTC.

• If your archive grows past easy manual management, adopt non-descriptive stable IDs linked to an external catalog so filenames never need to change.

• No live numbers Every pixel dimension, file-size cap, and format-acceptance rule cited here is illustrative of durable conventions, not a current portal requirement. Specific portals change their specs; always read the live technical page for any given call before exporting.

• Plural, tailorable approaches. Ranges (e.g., 1,200–3,000 px; quality 75–85; metric vs imperial; ProPhoto vs Adobe RGB working space) are presented as options to adapt to context, not single correct answers. Working-space choice in particular is debated among professionals; the one near-universal agreement is deliver in sRGB with the profile embedded.
• Out of scope by design. Photographic capture craft — lighting, camera setup, shooting — belongs to photographing work to submission standard, and so does choosing and sequencing work samples.
• Standards evolve. Metadata standards (IPTC, VRA Core, Dublin Core) and backup conventions (3-2-1 → 3-2-1-1-0) are periodically revised; the field names and principles given here are stable, but consult the maintaining bodies for the current version.
• Terminology note. Some communities now use "primary" instead of "master" for the preservation file; the concept is identical.

Highest-leverage insightSet the system up once, before the next deadline, because none of it can be assembled under submission pressure.