The Professional Photographer’s Guide to Ratings, Color Labels and Photo Culling

Give each signal one job

Consider a photograph that is technically strong, needs a distracting object retouched, and has been requested for an album. Those are three different facts. If green means both “ready” and “client chose it,” marking the request green can hide unfinished work. If five stars means both “best picture” and “print order,” a change in taste can accidentally change an order list.

A practical system separates four questions. Preference: how strongly do you want to retain this frame within its context? Production state: what action is needed next? Purpose: which specific output or selection includes it? Description: what is in the photograph? Ratings, labels, collections and descriptive metadata can support those questions, but their exact storage and behavior depend on the application.

Stars record relative preference

Use them to distinguish candidates from stronger selections within a defined job. A rating is a decision with context, not an objective measurement of photographic quality.

Labels record a small workflow vocabulary

Use a label for an actionable state such as Needs inspection or Ready for editing. Display its name alongside the color so the meaning survives a monochrome printout or a colleague's different color perception.

Collections record membership

A photograph may belong to Ceremony, Editing selection and Album candidates simultaneously. Membership is useful when several purposes overlap or when you need to retain a named selection.

Descriptions and keywords record subject information

Names, subjects and locations help retrieval. They should not become improvised substitutes for production approvals or proof that an order was placed.

This is a proposed studio policy, not a universal standard or a description of every application's controls. Some programs provide additional flags and custom fields. Choose the smallest system that expresses your actual decisions. If a field has no distinct question to answer, leave it unused rather than maintaining it for its own sake.

Write a selection policy before assigning thousands of marks

Start with a short written key stored with the job. Include its version, who can change decisions, and whether ratings apply to the whole archive or only within one assignment. A three-star frame in a complete wedding story may be essential documentary coverage even if it would not enter a landscape portfolio. Comparing those stars across unrelated jobs without context creates false precision.

The following example gives stars one stable meaning: suitability for the photographer's editing selection. It intentionally leaves the top value for exceptional work without requiring every assignment to contain one. It also leaves zero available for photographs that have not received a rating. No number in this example means that a file may be deleted.

Then define labels independently in your written studio key. For example, Yellow / Needs inspection asks for a closer technical review; Red / Retouch question records an unresolved production issue; Green / Ready for editing means the source and handoff have passed your checks. A label is usually a single value, so do not rely on it to hold several simultaneous facts. Put overlapping purposes into collections and retain detailed questions in an accompanying job record.

Write down prohibited interpretations too: green does not mean client approval; one star does not authorize disposal; a collection called Album candidates is not a final album order. This small effort prevents the most costly errors, which often arise from a plausible interpretation rather than a broken shortcut.

Follow three photographs through two review rounds

Here is a hypothetical portrait assignment with three invented file identifiers. The example describes a decision record, not a measured test or a Lightbox Pro screen. All three originals remain preserved. During the first round, the photographer prefers A, is uncertain about B's focus, and retains C as a useful alternate. During comparison, B proves to have the best expression at the required output size; A has a small retouching question.

PreferenceStars can change after comparison.

Next actionA named label records the current task.

PurposeCollections preserve distinct selections.

The ledger explains why B changed without claiming that the earlier decision was an error. It records new evidence. If a client later asks for C in an album, add C to the appropriate album-request record; do not promote its editing-preference score merely to make a filter find it. Revisit its production readiness separately.

You do not need to transcribe every rating change into a spreadsheet. Preserve meaningful milestones: the policy, the dated handoff selection, outstanding exceptions and final output correspondence. The level of history should match the consequences of a mistake. A portfolio experiment and a paid print order need different records.

Run a culling session with a clear stopping point

1. Confirm the review population. Identify the job, source folders and expected sequences. Check active filters, hidden items and the current collection before assuming you are viewing every photograph.
2. Set the policy for this session. Open the job's rating key. If another editor is involved, agree whether they are making independent recommendations or changing the authoritative selection.
3. Make a broad first pass. Record candidates and obvious questions. Avoid repeatedly adjusting three adjacent star values before you have seen the whole sequence.
4. Compare competing frames. Review expression, timing, coverage and relevant detail. A needs-inspection label keeps uncertainty visible without forcing a premature rejection. See how to judge sharpness when technical detail is decisive.
5. Resolve the exception queue. Inspect dark previews in an appropriate processor, compare alternates and document any remaining retouching questions. A smaller shortlist is not finished while critical uncertainties are hidden in a forgotten label.
6. Lock a named handoff. Create an explicit selection such as Editing handoff v1. Record its date, count and any excluded exceptions. Clear irrelevant filters and verify representative identities before sending the files onward.

Do not confuse a convenient working filter with a fixed deliverable. “Four stars and above” changes whenever a rating changes. A named selection can make a milestone explicit, but check whether your application stores fixed membership or a live rule. For the distinction between a rule, collection and physical folder, read catalogs, folders and collections.

Marking a candidate is reversible; deleting the original may not be. Keep disposal outside the culling pass. A separate retention decision should consider backup coverage, contractual obligations, useful alternates and how the job can be recovered. This guide's example policy deliberately provides no automatic “delete low stars” instruction.

Find the decisions a filter hides

A filter can make work appear complete by removing the evidence that remains. Suppose a reviewer uses a four-star filter to prepare the editing set. Three unrated photographs from a second camera are absent, so the displayed count cannot show that they were never reviewed. A count describes the visible result of a query, not necessarily completion of the job.

Build a closing sweep that asks different questions from the shortlist filter. Show the full job without preference restrictions; inspect the beginning and end of each source sequence; check unrated items and unresolved labels; then return to the final selection. If your software has no distinct reviewed flag, use a documented coverage process rather than treating zero as proof of rejection.

Another trap is assigning a mark to more photographs than intended. A focused image, a selected group and the visible set can differ. Before a batch change, confirm the selected count and inspect the target. Afterward, verify several members and one nonmember. If the change was wrong, use the application's supported Undo while the context is clear; do not scatter compensating edits whose scope you cannot reconstruct.

When a label changes the active filtered set, the photograph may disappear immediately. That can be correct query behavior rather than data loss. Return to an unfiltered view and locate the stable file identity before repeating the action. Repeatedly pressing a shortcut without understanding the current selection can spread the mistake to the next image.

Carry meaning between people and applications

A colored mark is not an interchange agreement. In Adobe's XMP Basic namespace, xmp:Rating permits −1 for rejected and 0 through 5, with 0 representing unrated. xmp:Label is text. A program's colored square therefore does not establish a universal red/green vocabulary, and a local catalog rating does not prove that any XMP was written. These XMP values do not establish that Lightbox Pro implements every value or writes them to files.

The IPTC Photo Metadata User Guide also cautions that rating rationale varies. Send the meaning with the marks. A recipient who sees “three stars” still needs to know whether that means a reserve, an editing candidate or a final selection.

For a human handoff, provide a short key, the assignment identifier, a dated selection name, an expected count and stable file identifiers. Explain how to report an ambiguous filename. Two camera cards may both contain IMG_0001, so a bare filename can be insufficient. Use the job and source-relative path or another agreed unique identity. Do not silently rename an already-shared selection without updating its correspondence record.

For an application handoff, test a disposable sample in both directions before relying on a large transfer. Change one rating and one label, save using the actual application's supported workflow, and reopen the sample in the destination. Inspect the values and their meanings. Confirm where they lived: embedded metadata, sidecar, exchange file or private database. Then check whether the destination can return a change without overwriting newer decisions.

Choose one authority for each stage. If the catalog owns selection and the editor owns processing recipes, record that division. A more recent filesystem timestamp alone does not prove that a competing rating is the intended one. When edits conflict, retain both records and resolve them by the agreed policy rather than blindly choosing “newest.”

Use the verified Lightbox Pro tools within that policy

The reviewed Lightbox Pro development build supports local star ratings, color labels, filtering and nested catalog sets. Those tools can separate preference, a compact task vocabulary and overlapping selections. Light Table compares one to six explicit selections with linked or independent viewing. The Loupe provides detail inspection while identifying the available pixel evidence. See the comparison guide for the actual controls.

Committed photographs can be reviewed while import continues in build 60. That improves the opportunity to begin selection, but an early visible subset is not proof that the whole job has arrived. Check the final import outcome before declaring coverage complete. Imported-entry counts and ready offline-preview counts describe different stages.

Keep exchange expectations precise. Supported imported descriptions, keywords and custom text are currently read-only, filename search is implemented, and general XMP/IPTC writeback is not established. Do not expect a local label change to appear automatically in an external RAW editor. Transfer Copy copies originals; it does not translate private selection semantics or turn preview edits into finished proofs.

Likewise, a photographer's local Album candidates set is not a synchronized client order. Hosted private galleries, returned client choices and a completed album designer are not established in this reviewed source. Use your verified external approval process and an explicit return record, then reconcile it by identity. The album workflow guide explains how to keep selection and production approval distinct.

Repair an inconsistent archive without destroying its history

When an older library contains several competing rating systems, begin by documenting what you can establish. Which photographer used the marks? Do old delivery folders or contact sheets show their meaning? Are client orders recorded elsewhere? Unknown is a valid status. Guessing that red meant reject can erase a useful interpretation that later evidence would resolve.

Keep a protected copy of the catalog and relevant metadata before normalizing anything. Work on a bounded job, not the whole archive at once. Write a mapping table from old meaning to new meaning, including an unresolved category. Preserve original values in an independent record when the application offers no verified history. Do not describe a color-to-color conversion as semantic preservation unless the underlying definitions match.

After a pilot conversion, reconcile selection counts and inspect individual photographs from every mapped group. Check items carrying several purposes, low-rated images that were delivered, and images with no marks. A mathematically complete mapping can still be editorially wrong. Retain the pilot's evidence and the original catalog before expanding the operation.

Legacy catalog imports deserve particular care: the supported Lightbox Pro importer retains native label assignments but does not reconstruct original custom label names and colors. Retain any old legend alongside the catalog. The legacy preservation guide covers the wider evidence you should keep.

Test whether the system survives a real handoff

Before the next paid assignment, use a small backed-up sample containing an unrated image, several rating values, two task labels, overlapping collections and a duplicate filename from a different source folder. Ask a colleague—or return after a short break—to find the final editing selection and the unresolved technical question using only the written key.

Then save, close and reopen the actual catalog. Verify that the values and collection membership persist. Test the exact supported file handoff you intend to use, and confirm what does and does not arrive in the receiving application. Keep a brief acceptance record with application versions and sample identities. This is a proposed test for your workflow, not a claim that every combination has been tested by Lightbox Pro.

The useful outcome is practical: a reviewer can distinguish an unseen frame from a reviewed reserve, an editing selection from a print request, and a ready file from an unresolved question. When those distinctions remain legible after reopening and handoff, the marks are doing useful work.