RAW Editing, Photoshop and Retouching: Why Workflows Get Complicated

Editing is several jobs that happen to share one photograph

A good RAW rendering, a careful portrait repair and a correct delivery file solve different problems. The first interprets the capture. The second changes a particular area or relationship in the image. The third prepares an accepted result for a destination. A workflow becomes confusing when all three are treated as one undifferentiated task called editing.

Specialist applications exist because these jobs have different controls and responsibilities. A RAW processor needs to understand supported camera data. A layered editor can isolate complex pixel work. A delivery system needs suitable dimensions, format, profile and accepted versions. One application may cover several stages well, but the photograph still passes through those conceptual boundaries.

This part explains how to decide where each stage belongs and how to keep revisions coherent. It is not another full tutorial on skin repair or a ranking of RAW processors. For those narrower tasks, read our natural skin retouching guide and the Lightroom Classic, Capture One and ON1 comparisons.

1. Camera sourceRetain the capture and establish the selected image identity.
2. RAW interpretationResolve supported-camera rendering, base tone, white balance and color.
3. Local treatmentRefine targeted areas and agree whether pixel retouching is needed.
4. Editable masterKeep layered or otherwise revisable work with its accepted base.
5. Destination outputRender, inspect and retain the approved delivery version.

RAW development begins before the photograph becomes a delivery image

A camera RAW file preserves capture information that a processor interprets into a visible image. The exact route depends on the camera format and processor. A thumbnail or operating-system preview is already an interpretation; displaying it does not establish that the viewer controls the underlying sensor-development pipeline.

At this stage, confirm support for the actual camera, file mode and application version. A supported model name can still leave questions about a newer compression mode or unusual capture setting. Test ordinary and difficult exposures from your own camera before making that processor the only route to a client deadline.

Work toward an intentional base rendering. Decide the overall tonal and color treatment before detailed pixel repairs depend on it. This does not require perfecting every output crop immediately. It does mean resolving a major white-balance change or strongly different interpretation before a retoucher builds hours of local work on the previous pixels.

Keep the source and adjustment record together in the preservation plan. Adobe documents several settings-storage locations. That storage choice affects recovery: the photograph can remain readable while the work needed to reproduce its accepted treatment is missing. Save a known checkpoint before handing a rendering to another worker.

Separate base tone, white balance and a chosen look

White balance addresses the interpretation of illumination and neutral relationships. Exposure and tone controls shape brightness and contrast. Color adjustments can address specific hues or build a deliberate look. These controls interact, but they do not all represent the same decision. A warmer creative grade should not be mistaken for proof that mixed lighting has been corrected.

For a wedding sequence, first group photographs whose lighting and capture conditions justify a shared starting point. Syncing a useful base can reduce repetitive setup. Then review the exceptions: a flash frame, a window-lit portrait, mixed reception lighting or a scene with an important bright fabric. A shared preset is a starting point, not acceptance of every frame.

Judge highlights and shadows with the source and the intended output in mind. A slider cannot promise recovery of detail that the capture did not retain. Likewise, an unattractive small preview does not prove a difficult RAW file is unusable. Make those decisions in a processor and view that supply the information needed.

Choose one base-treatment authority for the active version. If a photograph has one global grade in the RAW processor and another compensating grade in a later pixel editor, write down why. Otherwise, the next revision may remove one correction and expose the other. Clear ownership makes the edit easier to revise than a pile of individually plausible adjustments.

Local adjustments and portrait retouching answer different questions

A local mask can brighten a face, hold a sky or control a color region while preserving a parametric editing workflow. Pixel retouching can repair a specific mark, remove a distraction or build a composite. Some processors contain repair tools too. The boundary should be chosen by the task and reversibility required, not by a rule that every portrait must visit Photoshop.

Before retouching, agree on scope. Removing a temporary blemish, softening a glasses mark and changing permanent facial features are different requests. Skin smoothing is not automatically a required stage. Texture, lighting and identity belong to the photograph; indiscriminate smoothing can damage all three while making a close-up look superficially uniform.

Retain a way to revise local work independently. Adobe’s healing example uses a separate layer to keep repairs distinct. The broader production principle is to preserve the accepted base and organize changes so a later request can be addressed without rebuilding everything.

Do not copy geometry-dependent repairs blindly across a burst. An exposure treatment may transfer usefully between nearby frames, while a healing stroke can land on an eyelash or different skin contour after the head moves. Review each result at a useful scale and again as a complete photograph.

Decide what crosses into the external editor

The receiving editor may open the camera source through a compatible RAW component, receive a rendered pixel file or work with a Smart Object whose content retains a particular editing route. These options preserve different kinds of flexibility. A menu command that opens Photoshop does not, by itself, prove that every adjustment remains separate and editable there.

Lightroom Classic’s external-editing preferences expose format, color space and bit-depth choices. Choose those settings for the actual retouching brief and receiving system. A demanding master can warrant more tonal precision and a larger file than a small proof. The same preset need not serve every boundary.

Capture One’s external-editing workflow processes an image before the external editor receives a new variant. That is a controlled handoff of an appearance, not a universal translation of all RAW controls. Preserve the original processing record so a later base-render revision remains possible.

Run one complete round trip before sending the selected batch. Confirm where the new file is created, whether it appears in the catalog, which layers survive, and how the saved result is reopened. A receiving editor can support TIFF while interpreting a particular layered file differently from the sender. Record a known-good route and its settings.

Layers preserve decisions only if their structure stays understandable

A layered master can retain local repairs, masks, text, composites and color treatments separately. That is useful when a client asks for a limited revision. It also creates a document whose structure needs care. Ten unnamed layers with conflicting global grades may be technically editable and operationally difficult to trust.

Name layers or groups by responsibility: cleanup, skin-tone correction, background repair or output-specific treatment. Preserve the base that the work was built on. Keep major compositing decisions separated from simple finishing where practical. Another person should be able to identify the accepted version without toggling every layer at random.

Be explicit about what nondestructive means in this document. A mask can be revised; a flattened replacement cannot reveal the original content it overwrote unless a source survives elsewhere. A Smart Object can retain useful content and processing relationships, but its behavior depends on the object and supported application. The label alone is not a universal editing guarantee.

Test the master in the environment that will receive it. Save, close and reopen it before treating the job as complete. Check the intended rendering and the particular controls the recipient must change. Keep a compatible flattened reference when it helps communicate appearance, while retaining the real editable master separately.

A revision shows why the base-render checkpoint matters

Consider an illustrative wedding portrait chosen for a large print. The photographer approves a warm base rendering and asks a retoucher to remove a temporary spot and a distracting background object. The retoucher returns an editable master. Later, the couple prefers a cooler treatment and a tighter crop. This is a hypothetical dependency problem, not a Lightbox Pro customer case.

The crop may be straightforward if enough source detail remains and the repair falls inside the new framing. The cooler treatment needs more care. Changing the RAW interpretation and exporting a new base does not automatically update repairs whose pixels were sampled from the earlier rendering. Replacing a lower layer can reveal mismatched color, edges or tonal transitions.

First decide whether the revision can be made appropriately in the current master. If it needs a new RAW interpretation, create and identify that base, then inspect the dependent work against it. Some repairs may remain usable; others may need revision. Preserve the earlier accepted master until the new version passes review.

Now imagine the same photograph is also in a delivered gallery and an album proof. Those outputs should refer to the intended accepted revision, not simply the newest file timestamp. Record whether the change applies to the print only or to every destination. An output-specific crop should not silently become the universal version of the photograph.

The practical improvement is to settle expensive dependencies earlier. Agree on the general treatment before detailed repair where possible. Ask for a small representative retouch before commissioning a full batch. Keep the requested decision attached to each proof. These steps reduce avoidable rework without claiming a measured number of hours saved.

Resolution, file format and sharpening belong to the destination

A large editable master and a client download solve different needs. The master preserves revision potential. The download should meet the promised delivery specification with suitable compatibility and size. A print file must also meet the actual lab’s requirements. Do not export every destination from a previously downsized proof simply because it is easy to find.

Use pixel dimensions to assess available detail. A metadata resolution number does not invent additional captured information. Calculate the pixels required for the intended print dimensions and chosen print density, then consider crop and lab guidance. If an enlargement process is used, retain that fact and inspect the result; a larger file is not evidence of newly captured detail.

Capture One’s output documentation distinguishes rendered formats from camera sources. Choose JPEG, TIFF or another accepted format around the recipient’s requirements rather than a generic hierarchy in which the largest extension is always best. Layers, transparency, bit depth and compression have different compatibility implications.

Apply destination sharpening as an output decision, then inspect at the intended dimensions. Sharpening that appears crisp in a small gallery can produce halos in another use. Preserve an accepted master without forcing every later derivative to inherit the exact same resizing and sharpening treatment.

Color management connects the stages without making them identical

Keep the working profile and output profile explicit. Embed the appropriate profile where the destination expects it, and follow the recipient’s instructions for conversion. A wide-gamut retouching master and an sRGB web derivative can both be correct for their roles. They should not be confused when files return to the catalog.

Use a controlled comparison when checking a mismatch. Confirm the exact version, profile, display environment, crop and scale before changing color sliders. A client’s phone, an unmanaged preview and a calibrated editing display are not interchangeable proofing conditions. Explain what the client is approving and reserve critical print decisions for a suitable proofing route.

For a lab handoff, ask for current requirements instead of reusing a remembered preset from another supplier. The lab may specify a profile, dimensions, format, naming or sharpening responsibility. Test a representative image when color or material is important to the assignment. Retain the accepted output alongside the requirements used to create it.

Keep color responsibility singular at each stage. If both an application and another output component perform an unintended conversion, the result can depart from the approved master. A clear export preset and a checked delivered file are more useful than assuming that a correct working preview guarantees a correct print.

Keep the necessary specialist; remove the unnecessary round trip

Ask whether a task actually requires another application. A restrained local adjustment within a capable RAW processor may be enough for an ordinary delivery. A composite, difficult repair or detailed client revision may justify a layered editor. The right boundary depends on the photograph and brief, not a fixed number of programs.

Keep the path short for routine frames and explicit for exceptions. In an illustrative editing set of 180 photographs, perhaps 12 need additional local retouching. That is a proposed example, not a typical rate. Sending all 180 through a pixel editor without a purpose would create masters to manage rather than useful work. Mark the exceptional set and explain why it exists.

Reuse presets for stable technical decisions while retaining visual judgment. Naming, destination folders and known profile settings can be repeatable. Whether a face looks natural or an important highlight has been handled appropriately requires inspection. Automation should reduce mechanical setup without hiding quality control.

Consolidation is successful when the same accepted result becomes easier to produce, revise and retain. If a single environment cannot meet a specialist requirement, a documented handoff may be the better design. An integrated interface is valuable only when the underlying image pipeline and production records are dependable.

The exact Lightbox Pro boundary in reviewed build 65

Lightbox Pro’s current selection tools can help decide which frames deserve development and which need closer inspection. The native Loupe and Light Table support that review, with detail status distinguishing verified raster source detail from system RAW detail-unverified and reduced previews. Seeing a RAW photograph in the catalog does not establish app-controlled sensor development.

Reviewed development build 0.1.2 (65) has catalog-stored crop/rotation, Light, Levels, Color Balance and Duotone preview adjustments. These operate on a prepared RGB rendering. They are not camera-calibrated RAW white balance, a completed highlight-recovery pipeline, selective portrait repair or advanced skin smoothing.

The internal raster encoder now has a tested output policy for a 20-field photographic metadata subset, with explicit catalog overrides, clearing, omission and conflict read-back checks. GPS, device serials, MakerNotes, arbitrary XMP, embedded previews and stale pixel tags are excluded from that subset. This is bounded internal implementation, not a completed export interface with end-user output review or a protected publication workflow.

For this article’s RAW-to-retouch-to-delivery route, use a validated external processor and editor. Hosted proofing and an album designer also remain future capabilities. Lightbox Pro’s long-term connected-workspace ambition should be judged separately from the current build’s useful catalog, comparison and preview work.

A production-ready photograph has a recoverable chain

• The selected capture can be resolved to one available source.
• The accepted base treatment and its processing record are retained.
• Local repairs have a clear brief and revisable master where required.
• Each destination receives the intended version, crop, dimensions and profile.
• A representative master and delivered output have been reopened and checked.
• Sources, editing records and accepted results are backed up together.

A connected workflow does not need to hide the difference between sensor data, pixels and production approval. It should make those transitions easier to understand. Once the responsibilities are clear, you can keep the specialists that improve the photograph and simplify the handoffs that add work without adding value.

Sources and verification

Official references reviewed 21 October 2026. Prices, service terms, versions and supported systems can change. Application statements use Lightbox Pro development build 0.1.2 (65), source 3f3e29f11e2ae18a2d93cc2337c16e6fc6172550. Native test results are recorded engineering evidence rather than tests rerun on this Windows website workstation.

• Adobe: external editing preferences, format, bit depth and color space
• Capture One: external editing and the distinction between processing and opening
• Adobe: reversible healing work on a separate layer
• Adobe: Camera Raw settings and storage locations
• Capture One: processing and output file formats

Zippi Technologies is the developer of Lightbox Pro, independently of the other companies named. Product references do not imply affiliation or endorsement. Current local features, unfinished development and future ambitions have different acceptance requirements.