Guide to BRAW Sidecar Metadata and Image Settings

For BRAW, treat the sidecar as the shared decode instruction file, not as the media. If you want ISO, white balance, tint, color space, and similar RAW image settings to follow the clip from one system to another, keep the matching .sidecar file next to the .braw file and move them together. If you want the original camera interpretation, remove or ignore the sidecar and let the application read the embedded metadata inside the BRAW file. That one rule solves most of the confusion. The sidecar is useful because it lets you change how the RAW file is interpreted without rewriting the original camera file. It's also easy to break because it depends on boring file management: same folder, matching clip, compatible software, and a team that understands whether the sidecar is authoritative or just someone’s local experiment.

What the BRAW sidecar actually does

Blackmagic RAW stores camera metadata inside the .braw file, and that embedded metadata includes the camera’s capture settings and enough image processing information for compatible software to decode the clip consistently. A sidecar adds an override layer, and when you change metadata or image processing values after capture, you can save those changes into a .sidecar file instead of writing them back into the original .braw. That distinction matters in post. The camera file remains the original camera negative. The sidecar becomes a portable set of RAW interpretation decisions.

A sidecar sits beside the source media as a separate set of RAW interpretation settings.

A BRAW sidecar can carry overrides and metadata such as:

ISO or gain interpretation
White balance temperature
Tint, especially green/magenta correction
Color space and gamma choices
Exposure, contrast, saturation, and related RAW image controls where supported
Iris, focus, and focal length metadata
Project name, take number, and other production metadata
Frame-by-frame metadata, which is important when lens data changes during a shot

The key word is interpretation. A sidecar doesn't give you new clipped highlight information, fix motion blur, or change the actual exposure that hit the sensor. It tells the decoder how to map the recorded BRAW data into an image. Blackmagic RAW isn't the same as a folder of untouched sensor photos. The camera handles part of the RAW processing, including the demosaic pipeline, and encodes it efficiently into the BRAW file. That's why the files are fast to decode compared with some traditional RAW image sequences, while still preserving useful control over ISO, white balance, tint, color science, and similar settings downstream.

Embedded metadata, sidecar metadata, and timeline grades are different layers

A lot of workflow mistakes happen because people call everything “metadata” or “the grade.” In BRAW work, it helps to separate three layers.

Embedded metadata, sidecar overrides, and project grade data act like separate layers over the same clip.

The first layer is embedded camera metadata. This lives inside the .braw file. It reflects how the camera was set at capture: ISO, white balance, tint, color science choices, lens information where available, timecode, clip information, and other camera-side values. If no sidecar exists, compatible software can use this embedded metadata as the starting point. The second layer is the sidecar. This is the portable override, and it can sit next to the .braw file and tell compatible software to use different RAW settings than the embedded defaults. Delete or move the sidecar away, and the clip can fall back to the original embedded metadata. The third layer is the NLE or grading application’s project data. A color grade in a Resolve timeline, an adjustment layer in Premiere, a LUT applied on an edit, or a color managed timeline transform isn't the same thing as a BRAW sidecar. Those choices usually live in the project file, database, XML, or rendered media unless you intentionally save RAW metadata changes into a sidecar or bake them into a new file. This is why two people can open the same .braw and see different images. One may be viewing camera metadata. One may have a sidecar override. One may have project-level Camera RAW settings. One may have a node tree or LUT on top. Before blaming color management, first identify which layer is changing the image.

Layer	Where it lives	Main effect	How it travels	Common trap
Embedded camera metadata	Inside the `.braw` file	Supplies the original camera interpretation, such as capture ISO, white balance, tint, lens data, timecode, and clip metadata	Always travels with the BRAW file	Assuming the embedded look is still active when a sidecar or project setting is overriding it
Sidecar metadata	In the matching `.sidecar` file next to the `.braw` file	Overrides RAW decode settings such as ISO, white balance, tint, color space, gamma, and supported production metadata	Travels only if the sidecar is copied and kept with the matching BRAW file	Treating the sidecar as a harmless temp file when it may change every downstream decode
NLE or grading project data	In the application project, database, XML, cache, or rendered derivative	Adds clip RAW settings, grades, LUTs, timeline color management, and export transforms	Travels through project exchange, database sharing, XML, AAF, EDL, or rendered files, depending on the workflow	Expecting project grades or timeline transforms to appear on another system just because the sidecar was copied

How changes propagate into the NLE

In the clean version of the workflow, the NLE or grading application loads a BRAW clip, checks for a matching sidecar next to it, applies the sidecar metadata if present, and otherwise uses the embedded camera metadata. Blackmagic’s SDK is designed so applications can decode BRAW consistently across platforms, and software using that SDK can read the same RAW settings. DaVinci Resolve is the reference environment for most BRAW workflows. On the Media page and Color page, Resolve can read BRAW metadata, expose RAW controls, and let you choose how clips are decoded. Depending on project setup, you may be decoding from camera metadata, project settings, or clip-specific settings. If you make clip-level RAW adjustments and need those decisions to travel outside the Resolve project, you need to save or generate sidecar metadata rather than assuming the Resolve database will communicate those choices to another workstation. The general propagation path looks like this:

The .braw file contains embedded capture metadata.
A matching .sidecar file placed beside it can override that metadata.
The NLE reads the BRAW through native support or a Blackmagic RAW SDK-based component.
The decoded image updates according to the active RAW settings.
Any grading, LUTs, timeline color management, or export transforms happen after that decode stage.

The last point is important because sidecar settings happen early, and they affect the image before normal grading operations. If the editor adds a creative LUT on top of a clip, that LUT isn't automatically part of the sidecar. If the colorist changes the BRAW white balance from 4300K to 5600K and saves that as sidecar metadata, that can travel with the clip. Applications may cache metadata. If your team edits a sidecar while an NLE already has the clip open, the image may not update instantly. Some tools need a relink, refresh, project reopen, media cache clear, or application restart before they re-read the adjacent sidecar. Don't assume a live folder update equals a live picture update in every NLE. Make an obvious temporary change, such as a large white balance shift, then reopen or refresh the clip on another machine. If the picture changes before you apply any timeline grade, the application is reading the sidecar. If it doesn't, the application is probably using embedded metadata, cached metadata, project-level decode settings, or a different copy of the media.

When sidecar edits are non-destructive

Sidecar edits are non-destructive when they remain as external metadata overrides, and in that state, you haven't altered the original .braw file. You can remove the sidecar and return to the original embedded metadata. You can create a different sidecar and reinterpret the clip another way. You can send the same OCN to finishing with or without the editorial sidecar, depending on the conform plan. This is a common use case for sidecars:

Normalizing dailies or editorial viewing without modifying camera originals
Correcting an obviously wrong camera white balance for the offline edit
Passing a camera RAW starting point from DIT to editorial
Keeping clip metadata consistent across Resolve systems
Letting a colorist see the intended decode while preserving freedom to reset

The non-destructive benefit is only real if the sidecar remains separate and clearly managed. If one team member overwrites a sidecar in a shared folder, everyone else may inherit that new interpretation. That's still non-destructive to the .braw, but it can disrupt the team. In a collaborative workflow, don't treat sidecars like invisible temp files. Treat them like source-adjacent metadata. They may affect every thumbnail, proxy transcode, review export, conform, and finishing session that reads from that folder.

When settings become baked

BRAW sidecar settings become baked when your team renders, transcodes, or writes the image into a new file in a way that no longer preserves RAW control. If you transcode BRAW to ProRes, DNxHR, H.264, H.265, or another non-RAW editing format, the derivative file will bake in the current RAW interpretation. The transcoded file won't carry the same RAW flexibility. You can still color correct it, but you're grading pixels that a specific ISO, white balance, tint, color space, and transform already decoded.

Transcoding turns flexible RAW interpretation settings into fixed pixels in a new derivative file.

There's also a BRAW-specific bake path. Blackmagic’s SDK documentation describes a trim operation that can create a new .braw file that incorporates sidecar changes into that newly created BRAW. That's different from changing the original camera file. The original remains untouched, but the new BRAW has those metadata decisions incorporated. Common bake points include:

Creating editorial proxies or dailies from BRAW
Rendering review files
Exporting VFX pulls to EXR, ProRes, or image sequences
Creating a trimmed BRAW file with sidecar changes incorporated
Archiving only the transcodes and not the original .braw plus sidecar

For editorial, this is often fine because proxies are supposed to be lightweight viewing and cutting files. But the team needs to know which RAW interpretation your team used when it created those proxies. If the DIT changes the sidecar after your team generates proxies, the original BRAW may now decode differently than the existing proxies. That can make the conform look “wrong” even though your team created both files correctly at different times.

ISO, white balance, tint, and color space aren't all the same kind of decision

The sidecar can carry multiple image settings, but they don't have the same creative or technical weight. ISO in BRAW is a decode interpretation of gain. It's useful for adjusting image brightness and highlight placement within the RAW processing model, but it can't recover data that was clipped at capture. In post, changing ISO is a good first-stage RAW adjustment when the shot was exposed with enough sensor information intact. White balance is often the most forgiving and useful sidecar correction. If a camera was set to tungsten in daylight or left at a previous scene’s setting, changing BRAW white balance in post can produce a much cleaner starting point than pushing color wheels later. This is one practical reason for keeping RAW control through the edit and into finishing. Tint handles the green/magenta axis. It's especially useful for fluorescent, LED, mixed-source, and practical lighting environments where Kelvin alone doesn't correct the color cast. Tint corrections in the RAW stage can make downstream grading easier because the image enters the grade in a more balanced state. Color space and gamma choices define the working interpretation of the image. Some productions want a fast video-style look for editorial. Others want log-style viewing that preserves grading flexibility. There's no universal correct setting. The right choice depends on whether the sidecar is meant for editorial viewing, dailies, VFX plates, or final grade preparation. That's the decision to make early: is the sidecar carrying a viewing intent or a finishing starting point? Those aren't always the same thing.

How to manage sidecars across teams

A reliable team workflow starts by deciding who is allowed to create or change sidecars. If everyone can write them, no one knows which image interpretation is official. For most productions, sidecar authority should sit with the DIT, post supervisor, lead assistant editor, or color department, depending on when your team makes the correction. The file management rule is simple: keep each sidecar with its matching BRAW clip whenever the sidecar is meant to travel. If your team clones camera cards, clone the sidecars too. If your team moves media into a shared storage structure, move the sidecars into the same clip folders. If editorial receives only proxies, document whether your team generated those proxies from camera metadata or sidecar-adjusted metadata.

When media moves to shared storage, each sidecar should stay beside its matching clip.

Useful naming and storage habits include:

Keep the .braw and matching .sidecar adjacent unless your pipeline has a tested alternative.
Avoid renaming BRAW files after your team has created sidecars.
Preserve original camera folder structure during ingest when possible.
Archive sidecars with the OCN, not only with project files.
If you replace a sidecar, keep the previous version somewhere traceable.

Make sidecars boring and predictable. A sidecar is small, but it can change the image every downstream department sees. Versioning is especially important when dailies, editorial, and color are moving at different speeds. Imagine editorial starts cutting with proxies that your team made from the camera’s original 3200K metadata. Later, the DIT creates sidecars that correct the scene to 5600K. When the colorist conforms back to BRAW, the raw clips now open warmer or cooler than the offline references. Nobody did anything malicious. The metadata changed after your team made the proxies. To avoid that, record which sidecar version your team used for each major output: dailies, editorial proxies, VFX pulls, turnovers, and final conform. If your team issues a new sidecar, say what changed and whether your team should regenerate previous transcodes.

Sidecars in proxy and offline workflows

Offline workflows introduce another layer of confusion because editors may never touch the BRAW directly. They may cut H.264, H.265, ProRes Proxy, DNxHR LB, or camera-generated HD proxies while the original BRAW stays on shared storage or nearline. If your team generated the proxy from BRAW, it reflects whatever RAW interpretation was active at the time of transcode. That could be embedded camera metadata, project RAW defaults, clip-level adjustments, or sidecar metadata. Once your team makes the proxy, later sidecar changes don't magically update the proxy’s pixels, so your team has to regenerate the proxy if the viewing transform matters. This is why your team should generate dailies and proxies after setting the intended BRAW decode. The team should know whether editorial is seeing:

Camera-original BRAW metadata
DIT-adjusted sidecar metadata
A Resolve project-level Camera RAW setting
A dailies LUT or color managed transform on top of the RAW decode
A combination of RAW metadata and creative grade

For conform, the finishing system needs the original .braw media and the intended sidecars if those sidecars represent approved RAW adjustments. If the colorist prefers to start from embedded camera metadata, then you should exclude or disable the sidecars intentionally, not lose them accidentally.

Common failure modes

Most BRAW sidecar problems are normal post problems with small files and unclear ownership. The failures usually fall into a few buckets:

Your team didn't copy the sidecar with the .braw.
Someone renamed the clip and the sidecar no longer matches.
The project is set to override camera metadata with project RAW settings.
A receiving application doesn't support the same BRAW SDK behavior or version.
A render baked the sidecar look into a derivative file, but the team expected RAW flexibility later.

When the image doesn't match, isolate the decode before touching the grade. Open the BRAW with no timeline effects, no LUT, no color nodes, and known Camera RAW settings. Then test with and without the sidecar, and if the image changes, the sidecar is active. If it doesn't, look at project decode settings, cache behavior, plugin support, or file placement.

The decision that keeps the workflow sane

Use sidecars when you need portable, non-destructive RAW interpretation changes. Don't use them as an untracked place for creative grades, temporary experiments, or private fixes on shared media. For a small team, the rule can be as simple as: the sidecar next to the BRAW is the approved starting point unless the handoff says otherwise, while for a larger production, sidecars need versioning, ownership, and clear turnover notes. Either way, the sidecar shouldn't be a mystery file that may or may not matter. If you're sending BRAW to editorial, include the sidecars only if editorial should see those RAW adjustments. If you're sending BRAW to color, include the sidecars if they represent approved technical corrections or intended starting points. If you're archiving the show, keep the original .braw, the final approved sidecars, and notes describing where those sidecars were used. BRAW workflows can keep the camera original and the decode decisions separate. The tradeoff is that your team has to manage both. When your team manages them well, sidecars let you fix metadata-level image settings, keep the OCN untouched, and move consistent RAW interpretation between systems. When your team manages them casually, they become the tiny files that explain why the same shot looks different on every machine.

FAQ

A BRAW sidecar can override RAW interpretation metadata such as ISO, white balance, tint, color space, gamma, exposure-related controls, and some production or lens metadata where supported. It doesn't change the original sensor capture or restore clipped highlights. It tells compatible software how to decode the existing.braw file.

The most common reasons are that one system is reading a sidecar and the other isn't, project-level Camera RAW settings are overriding clip metadata, cached metadata hasn't refreshed, or a LUT, grade, or color management transform is being applied differently. Test the clip with no grade or LUT, then compare it with and without the sidecar present.

They're non-destructive as long as they remain external metadata overrides. The original.braw file isn't rewritten, and the sidecar can be removed or replaced. The changes become baked when you render, transcode, create proxies, export plates, or create a new BRAW file that incorporates the sidecar changes.

No. A proxy reflects the RAW interpretation that was active when the proxy was generated. If a sidecar is changed later, existing ProRes, DNxHR, H.264, H.265, or other proxy files won't update automatically. They must be regenerated if the new RAW interpretation needs to appear in editorial.

Yes, if they represent approved technical corrections or intended decode settings. Archive the original.braw files, the relevant.sidecar files, and notes describing which sidecar versions were used for dailies, proxies, VFX pulls, turnovers, or final conform. This helps future users understand why a clip decodes a certain way.

Keep the.braw file and its matching.sidecar file adjacent in the same managed folder, then have editors work from that shared location instead of making private media copies. Aspect lets remote editors mount one shared cloud filespace, which helps the team preserve the intended folder structure and sidecar pairing.