Post-production begins when the capture team hands over the source files and current shot record.
It ends when the studio has released the correct final files under the current job policy.
The process can include:
- Source-file verification
- Shot-row mapping
- Selection
- Retouching
- Internal quality control
- Client proofing
- Requested changes
- Approval
- Output generation
- Manifest
- Final-file release
- Retention decision
The studio can use different software at each stage.
The important part is that the current file, requirement, version, owner, and decision remain identifiable.
Define the handoff from capture
The capture handoff should identify:
- Job
- Capture date
- Source location
- Source copies verified under the studio's policy
- Shot-list version
- Completed rows
- Missing rows
- Substitutions
- Approved deviations
- Client decisions needed
- Next owner
Do not rely on a camera-card folder and a message such as:
Shoot is done.
The post-production team needs the current production context.
Keep source protection in the studio's own storage policy
The studio should define how it verifies source files before clearing camera media, moving files, handing work to an external editor, or deleting a temporary copy.
The correct backup and retention method depends on the studio's infrastructure, agreement, risk, and insurance.
Lenso does not manage camera-card ingest or backup verification.
Do not use this article as a substitute for a real data-protection policy.
Map files to the current shot rows
A source file can keep its camera-native or ingest name.
The working record still needs to map it to:
- Product or SKU
- Variant
- View or asset
- Capture or source reference
- Shot-list row
- Current selection state
Do not require every source file to contain every identifier in the filename.
The mapping can live in ingest metadata, a catalog, a contact sheet, a shot-list table, or another current production system.
The final client-facing delivery name can be applied later.
Make selection status explicit
Use current labels such as:
- Not reviewed
- Selected for retouching
- Alternate
- Rejected
- Client selection needed
- Question for studio
The exact labels belong to the studio's process.
A selected capture is not automatically client approved, purchased, final, or released.
In per-photo billing, a client selection can be part of a purchase path.
Keep that distinction visible.
Prepare the retouching handoff
For every selected capture or group, provide:
- Shot-row reference
- Style-guide reference
- Job-specific retouching instruction
- Product-truth boundary
- Approved visual reference
- Current output
- Known limitation
- Required review file
- Expected final filename
Do not route work by a universal retouching tier unless the studio has defined and agreed that tier.
Use the actual treatment dimensions.
The Retouching Checklist covers the working self-check and internal handoff.
Decide the handoff unit
A post-production team can work by:
- file;
- product;
- variant set;
- setup;
- release batch.
Use the unit that lets the studio identify what is included, what remains open, who owns it, which requirement applies, and when it is ready for the next stage.
Do not send an incomplete random subset when the next reviewer needs to assess a complete product set.
Run a retoucher self-check
Before internal QC, the maker reviews:
- Current instruction
- Product truth
- Cleanup
- Color
- Geometry
- Edges
- Shadow and reflection
- Composite disclosure
- Output
- Review filename
- Known limitation
The self-check does not replace internal QC.
It records the maker's handoff.
Run internal QC at the stage the job needs
Internal QC can happen before client proofing, before final release, or at both points.
A proofing-stage gate can check:
- Required review set
- Product identity
- Version
- Preview quality
- Obvious technical issue
- Current requested action
A release-stage gate can check:
- Final export
- Delivery filename
- Manifest
- File count
- Access
- Actual download
Do not publish `QC must always happen before every client sees any file` as a universal rule.
Some jobs deliberately use early creative review before full final QC.
State what the client is reviewing.
Create a named proof version
A review file or set should identify:
- Proof or set
- Version
- Date
- Products or assets
- Preview limitation
- Requested action
When the work changes materially, create a new visible version.
Do not keep comments from an earlier file attached to a later file without clear history.
Route client feedback
Keep separate:
- Comment
- Selection
- Request changes
- Revision
- Reshoot
- Client decision needed
- Approve
The current product labels and client agreement control the operational and commercial path.
A requested change can return the work to retouching.
A new requirement can return the job to planning or capture.
Do not hide new scope inside a normal revision status.
Generate destination outputs after the current decision
A studio can create destination-specific files from an approved source or master when the creative and technical requirements support it.
Do not assume every destination output is a crop of the same file.
Some destinations can require a different product view, background, composition, model or prop treatment, visible product quantity, creative concept, metadata, or upload path.
Use the destination matrix in the multi-channel article.
Keep source, proof, and final filenames distinct
Source reference
The stored or capture name used inside production.
Proof name
The client-review name and version.
Delivery name
The final client-facing name.
These names can differ.
The mapping must remain reliable.
Avoid:
- final
- final2
- final-new
- final-final
as the only version information.
Build the delivery set from the current record
Before release, confirm:
- Every required output is present or has an accepted exception
- Only current final files are included
- Every delivery name maps to the product and view
- The manifest matches the files
- The release policy is satisfied
- The recipient is correct
- The actual download works
A ZIP is a package. It is not the delivery record by itself.
Apply a retention decision after release
The studio's retention policy should distinguish:
- Source files
- Working files
- Proofs
- Final files
- Manifests
- Brief and shot-list versions
- Client-access links
Do not publish a universal retention period.
The agreement, subscription, storage, privacy policy, recovery needs, and legal obligations can affect the decision.
Archiving a Lenso project changes the project state and can revoke client access.
It does not necessarily delete every file.
Copyable post-production handoff
- CAPTURE HANDOFF
- Job:
- Capture date:
- Source location:
- Source verification:
- Shot-list version:
- Completed rows:
- Missing rows:
- Substitutions:
- Deviations:
- Next owner:
- SELECTION
- Product or SKU:
- Variant:
- View or asset:
- Source reference:
- Selection state:
- Selected by:
- Date:
- RETOUCHING
- Instruction:
- Style-guide reference:
- Product-truth boundary:
- Visual reference:
- Known limitation:
- Review output:
- Delivery output:
- MAKER SELF-CHECK
- Current instruction:
- Product truth:
- Color:
- Geometry:
- Edges:
- Shadow or reflection:
- Composite:
- Output:
- Question:
- INTERNAL QC
- Review unit:
- Requirement versions:
- Disposition:
- Issue:
- Owner:
- Evidence:
- Resolved:
- CLIENT REVIEW
- Proof or set:
- Version:
- Client action:
- Comments:
- Requested changes:
- Approval:
- Decision maker:
- EXPORT AND DELIVERY
- Destination:
- Current source:
- Output:
- Delivery filename:
- Manifest:
- Release policy:
- Recipient:
- Download tested:
- RETENTION
- Source-file decision:
- Working-file decision:
- Proof decision:
- Final-file decision:
- Access decision:
- Review date:
How this fits in Lenso
Lenso can keep the current job brief, product and shot rows, references, proof versions, comments, decisions, optional invoice, final files, and manifest context connected.
Lenso does not ingest cards, manage raw backups, cull, retouch, or automatically inspect images.
The studio can keep source and working files in its current storage and editing tools.
Questions
Does post-production begin with culling?
It begins with a verified capture handoff. Selection or culling is one early stage.
Should source files be renamed?
Not necessarily. A reliable mapping to the shot record can be enough.
Must internal QC happen before proofing?
The studio should define the review stage. Early creative proofing can happen before final release QC.
Should every channel output come from one master?
Only when the creative and technical requirements permit it.
Does final-file release end retention?
No. Retention is a separate policy decision.