Cutsio Blog

RED RMD Sidecar Workflow: Why Premiere RAW Settings Do Not Always Follow R3D Files to DaVinci Resolve

Why RED RMD sidecar settings created in Premiere Pro may not transfer correctly when R3D files are moved to DaVinci Resolve, and how to ensure the dailies look is preserved across NLEs.

Why do RED RAW settings from Premiere Pro not always transfer to DaVinci Resolve?

RED RMD sidecar files created or modified in Adobe Premiere Pro should be tested before they are handed to DaVinci Resolve, because each application can expose RED SDK settings, sidecar paths, and defaults differently. The safest workflow is to create the approved look in a RED-native or DIT-managed tool, keep the RMD sidecar with the R3D media, and verify the same clip visually in both applications before the editorial handoff.

The RMD file is the master metadata sidecar for RED R3D clips. It contains all RAW parameter overrides — ISO, white balance, color science version, look file reference, and CDL values. When you adjust RED RAW settings in Premiere Pro's Source Settings panel, those changes are written to the RMD sidecar. When the same R3D file is opened in DaVinci Resolve, Resolve reads its own RED SDK instance and may apply a different interpretation of the RMD data.

This is not a bug in either application — it is a consequence of each NLE integrating the RED SDK independently, with different defaults, different SDK versions, and different approaches to metadata handling.

Working with raw camera footage? Check out How to Build a Searchable Library From ARRIRAW, RED R3D, and ProRes Footage.

For more DaVinci Resolve tips, read our guide on DaVinci Resolve AI Tools for Colorists and Editors.

What specifically goes wrong when RMD files move between Premiere and Resolve?

There are four practical failure modes to test when RMD metadata transfers between Premiere Pro and DaVinci Resolve.

| Failure Mode | Symptom | Root Cause |

| :--- | :--- | :--- |

| Color science mismatch | Clip looks different in Resolve than it did in Premiere | Different RED SDK versions between applications |

| Look file not applied | Creative look differs between applications | The referenced look file or sidecar path is not available on the receiving system |

| ISO/white balance reset | RAW settings return to camera defaults in Resolve | The receiving application is not using the expected RMD settings |

| IPP2 pipeline difference | Clip looks contrastier or flatter than expected | Premiere and Resolve apply IPP2 transform differently |

The most common failure is the color science version mismatch. If Premiere Pro is running RED SDK 8.2 and DaVinci Resolve is running RED SDK 8.0, the same RMD file with the same color science setting may produce visibly different debayer results. The color science version is specified in the RMD, but each SDK version may contain bug fixes or rendering changes that affect the output.

How do you ensure consistent RED RAW settings across Premiere and Resolve?

The recommended workflow uses REDCINE-X PRO as the authoritative metadata tool, not Premiere Pro's Source Settings.

Step 1: Create the look in REDCINE-X PRO or the production's DIT metadata tool. Apply all RAW settings — ISO, white balance, color science version, look files, and CDL values — and save the RMD file. This keeps the approved look outside a single NLE project file.

Step 2: Keep the RMD with the R3D, and embed metadata only if your DIT tool and finishing vendor approve that workflow. Embedded metadata can reduce sidecar loss, but it does not remove the need to test the receiving application's RED SDK behavior.

Step 3: Verify in both applications. Open the same R3D file in both Premiere Pro and DaVinci Resolve. Compare the image visually. If the images match, the metadata is being read consistently. If they do not match, check that both applications are running the same RED SDK version.

Step 4: Lock the SDK versions. Document which RED SDK version each application is running. If the production involves NLE handoffs, ensure both the sending and receiving teams are using the same SDK versions.

| Workflow | RMD Reliability | Complexity | Recommended? |

| :--- | :--- | :--- | :--- |

| REDCINE-X PRO + embedded RMD | Highest | Medium | Yes |

| Silverstack metadata management | High | Low | Yes |

| Premiere Source Settings + exported RMD | Medium | Low | Use with caution |

| Resolve direct R3D import | High (if Resolve is sole NLE) | Low | Yes for Resolve-only |

| Manual matching by eye | Low | High | Last resort |

How does Cutsio help with the RMD handoff problem?

Cutsio does not decode R3D files or apply embedded RMD settings to review streams. Use a ProRes review file rendered with the approved production look, and keep the complete R3D/RMD package as the conform source. On Enterprise, a supported R3D original can be attached to the ProRes asset for download.

The Cutsio workflow for cross-NLE consistency:

1. DIT offloads cards and manages RMD metadata in Silverstack or REDCINE-X PRO
2. RMD metadata is embedded into the R3D file headers
3. The DIT renders look-approved ProRes review files and uploads them to Cutsio
4. Cutsio streams and visually indexes the ProRes files
5. The director and DP review the footage with the correct look applied
6. When the picture is locked, the online editor retrieves the original R3D/RMD package from the archive or attached Enterprise asset
7. The R3D files and their approved metadata package remain available for conform
8. The conform NLE — whether Premiere or Resolve — is checked against the approved dailies reference

The key principle: the RMD metadata is approved at the DIT stage and not casually modified afterward. Both the review stream and the conform source should be checked against the same visual reference.

What is the best practice for documenting the dailies look for the colorist?

Even with consistent RMD metadata, the colorist should have an independent reference for the dailies look. Create a "look reference package" that includes:

1. The original RMD file (exported from REDCINE-X PRO)
2. A reference still frame or video export showing the approved dailies look
3. A note documenting which RED SDK version was used for the dailies
4. The color science version (RED Color 4, IPP2, etc.)
5. Any CDL values or look file references used

The DIT-approved ProRes file in Cutsio can serve as a visual reference. The colorist compares the grade to that review file to verify the match.

FAQ

Can I use the same RMD file in both Premiere and Resolve without modification?

In most cases, yes — the RMD file format is standardized by RED. However, SDK version differences may cause the same RMD data to render differently. Always verify the visual match between applications rather than assuming the RMD will produce identical results.

Does embedding RMD metadata into the R3D file affect the original sensor data?

No. RMD metadata is stored in the R3D file header, separate from the sensor data. Embedding metadata does not modify or degrade the original sensor data. The process is non-destructive.

Which RED SDK version should I use for cross-NLE consistency?

Use the same RED SDK version in both Premiere and Resolve. Check the RED SDK version in each application's About or Version information. If the versions differ, update the application with the older SDK to match the newer one.

Does Cutsio apply RMD metadata to the review stream?

No. Cutsio does not decode R3D or apply RMD settings. Render a ProRes review file with the approved look in REDCINE-X PRO, Resolve, or the dailies system, then upload that file for review and indexing.

What should I do if the RMD metadata is lost during transfer?

If RMD metadata is lost, the R3D file reverts to the in-camera metadata defaults. The dailies look saved in the RMD is unrecoverable unless a backup copy of the RMD file exists. Always save backup copies of RMD files alongside the R3D media.