export const meta = { title: "ARRI LogC3 vs LogC4: Pipeline Differences Explained", description: "Learn how LogC3 and LogC4 differ in exposure mapping, LUT/CDL behavior, Resolve and ACES support, and how to keep mixed ARRI projects consistent from dailies to final color.", tldr: "Decode by camera science: LogC3 uses AWG3 with higher mid-gray placement, LogC4 uses REVEAL/AWG4 with lower mid-gray for more highlight range. Pick a LogC4, LogC3, or ACES base; in Resolve 18.0.1+/ACES 1.3, output labeled transforms and space-matched looks.", slug: "arri-logc3-vs-logc4-pipeline-differences-explained", publishedAt: "2026-09-11", readingTime: 9, thumbnail: "https://cdn.aspectlabs.dev/blog/arri-logc3-vs-logc4-pipeline-differences-explained/cover-49bed5d5e5d8.png", authors: ["edison"], primaryTopic: "camera-workflows", topics: ["camera-workflows"], tags: ["arri"], faq: [ { "question": "Can I use a LogC3 LUT on LogC4 footage if it looks acceptable?", "answer": "You shouldn't treat a LogC3 LUT as valid for LogC4 footage. LogC3 and LogC4 use different tone mapping and different wide gamut color spaces, so the LUT will interpret exposure and color incorrectly. It may look usable on some shots, but it can create mismatched contrast, skin tone shifts, and highlight behavior later in the grade." }, { "question": "Why does LogC4 look darker than LogC3 before a transform?", "answer": "LogC4 places middle gray lower in the signal than LogC3 to leave more room for highlight latitude from newer ARRI sensors. That darker midtone appearance is normal when viewed without the correct transform. It doesn't automatically mean the image was underexposed." }, { "question": "Do CDLs transfer safely between LogC3 and LogC4?", "answer": "CDLs can be transferred technically, but they aren't visually neutral across LogC3 and LogC4. The same slope, offset, power, and saturation values can produce different results because the log curves and color primaries differ. For mixed projects, apply source-specific CDLs in the space where they were created, or normalize all sources into a common working space before applying shared CDLs." }, { "question": "What Resolve version supports ARRI LogC4?", "answer": "DaVinci Resolve Studio added native ARRI LogC4 support starting with version 18.0.1. Current Resolve Studio builds are preferable for active productions, especially when using color management, CST nodes, or ACES workflows. If LogC4 and ARRI Wide Gamut 4 aren't available as explicit input options, don't substitute LogC3." }, { "question": "How should a mixed LogC3 and LogC4 project be organized?", "answer": "Identify every source as LogC3/AWG3, LogC4/AWG4, ACES, or display-referred before dailies. Then transform each source into one agreed working space before applying shared creative LUTs, CDLs, trims, and output transforms. LUTs should be named by input and output, and dailies notes should record the decode path, LUTs, CDLs, and display transform used for each camera source." }, { "question": "How can we keep LogC3 and LogC4 decode decisions attached to the media through dailies, VFX, and conform?", "answer": "Treat the color pipeline as asset metadata, not tribal knowledge. Aspect lets teams keep notes such as LogC3/AWG3, LogC4/AWG4, LUT version, CDL space, and dailies transform alongside the file using custom metadata." } ], } If a project contains both LogC3 and LogC4, make the color encoding decision before dailies. Treat LogC4 as a different camera color pipeline, not as “newer LogC3.” The safest rule is simple: identify each source as [LogC3/AWG3 or LogC4/AWG4](https://www.arri.com/en/learn-help/learn-help-camera-system/image-science/log-c), transform it into one agreed working space, and only then apply shared creative looks, CDLs, trims, and output transforms. That sounds obvious, but this is where mixed ARRI shows get messy. A LogC3 LUT may load on LogC4 footage, and a CDL may appear to “work.” A Rec.709 dailies file may look close enough in editorial, but then the online turns up with mismatched contrast, skin tone shifts, clipped-looking highlights, or a show LUT that only behaves on half the camera package. LogC3 and LogC4 are both ARRI Log C encodings, but they're built for different sensor generations and different color science. LogC3 belongs to the ALEV3-era ARRI Wide Gamut 3 pipeline. LogC4 belongs to the REVEAL pipeline with ARRI Wide Gamut 4, introduced with ALEXA 35 and also used by ALEXA 265. Once you understand that split, most pipeline decisions become much easier. ## Why LogC4 isn't a drop-in replacement for LogC3 LogC3 was designed around the original ALEXA sensor family and has been in use since 2011. It became the default way to think about ARRI log footage for a lot of post teams: LogC3 footage comes in flat and desaturated, a LogC3-to-Rec.709 LUT or color managed transform brings it into view, and CDLs or show LUTs are built around that response. LogC4 was designed for the increased dynamic range of the ALEV4 sensor. To make room for that range, the exposure mapping changes. [Middle gray sits lower](https://www.youtube.com/watch?v=da3I_vMLRwc) in the LogC4 signal than many LogC3 users expect. In broad terms, LogC3 places 18% gray around the familiar upper-30% signal range, while LogC4 places it closer to the high-20% range. That lower placement isn't an error or an underexposure warning. It's how LogC4 allocates more code space for highlight latitude. The visible result is that a LogC4 image doesn't look like a LogC3 image when viewed without the correct transform. It will usually look darker in the midtones, with highlight behavior that doesn't match LogC3 display assumptions. If someone drops a LogC3 viewing LUT on LogC4 footage, the first impression may be “thin,” “dark,” “off,” or “not matching the Mini LF.” The camera didn't necessarily shoot it wrong. The display pipeline is probably wrong. The gamut changes too. LogC3 is paired with ARRI Wide Gamut 3, while LogC4 is paired with ARRI Wide Gamut 4. AWG4 isn't just a relabel, and it's part of REVEAL color science, alongside updated debayering and color processing. So the mismatch is both tonal and chromatic. That's why the input label matters. “ARRI Log” isn't enough. “ALEXA” isn't enough. The pipeline needs to know whether the media is LogC3/AWG3 or LogC4/AWG4. ## Cameras and formats set the starting point The camera model and recording format determine what you're likely to receive, but there are a few traps. ALEXA 35 and ALEXA 265 can [output LogC4 over SDI](https://www.arri.com/resource/blob/359512/89ebcfa98c2523a8f8deaf0e2d73a1c6/arri-mixing-arri-logc3-and-logc4-on-set-guideline-data.pdf). Earlier cameras such as ALEXA Mini LF, ALEXA LF, ALEXA Mini, AMIRA, and earlier ALEXA bodies output LogC3 over SDI. For recorded media, the picture is slightly more flexible because post can process ARRIRAW from older cameras through REVEAL. That means your team can debayer legacy ARRIRAW into LogC4/AWG4, even though those same cameras couldn't have output LogC4 on set. ARRICORE, introduced with ALEXA 35 Xtreme, is already RGB processed in-camera rather than raw, but it retains REVEAL pipeline flexibility and delivers RGB LogC4 image data to supported software. Aspect streams bytes to your Finder or NLE, so an assistant can open large ARRIRAW or LogC4 camera originals without waiting for a full download. The file starts working from the cloud while source media stays in one shared place. In mixed jobs, the common sources usually fall into these buckets: - ALEXA 35, ALEXA 35 Xtreme, or ALEXA 265 recorded or monitored as LogC4/AWG4. - ALEXA Mini LF, ALEXA LF, ALEXA Mini, AMIRA, SXT, or older ALEXA material recorded or monitored as LogC3/AWG3. - Legacy ARRIRAW processed through the older LogC3 path or through REVEAL as LogC4/AWG4. - Dailies, transcodes, or EXRs that may no longer clearly expose the original camera encoding unless your team preserves metadata and notes. The takeaway is that you can't always infer the color pipeline from the body alone once raw processing enters the picture. The dailies colorist, assistant editor, and finishing colorist need the actual decode path, not just the camera report. ## LUTs need the input they were built for Most LogC3/LogC4 mistakes are LUT mistakes. A LUT isn't a general “ARRI look,” and it expects a specific input encoding and produces a specific output encoding. If the input is wrong, the result is wrong even if it looks subjectively acceptable on a few shots. A LogC3-to-Rec.709 LUT expects LogC3/AWG3. If you feed it LogC4/AWG4, it will apply the wrong tone curve and wrong gamut mapping. Because LogC4 middle gray is lower, the transform won't place exposure where the LUT designer expected. Saturated colors can also move unpredictably because AWG3 and AWG4 are different spaces. A LogC4-to-Rec.709 LUT expects LogC4/AWG4. If you feed it LogC3/AWG3, you get the inverse problem: midtones, contrast, and color separation are being interpreted through the wrong model. Creative LUTs need the same discipline. A show LUT may contain two different ideas at once: a technical transform from camera log to display, plus a creative look. If that LUT was built for LogC3, it isn't automatically valid for LogC4. If it was built for LogC4, it isn't automatically valid for LogC3. ARRI’s newer look workflow makes this distinction explicit. For ALEXA 35, ALEXA 35 Xtreme, and ALEXA 265, ARRI Look File 4 workflows use LogC4-based look material. A creative modification transform for these cameras should be a [LogC4-to-LogC4 3D LUT](https://www.arri.com/en/learn-help/learn-help-camera-system/image-science/look-files), and ARRI Color Management or a display rendering transform should handle the display transform separately. Older ALF-2 look workflows for previous ALEXA and AMIRA cameras are based on LogC3, and a 3D LUT used there commonly has the Rec.709 transform baked in. That separation matters in post. A log-to-log creative LUT is easier to reuse across SDR and HDR because it doesn't bake the display conversion into the look. A log-to-Rec.709 LUT is useful for monitoring or editorial review, but it's harder to repurpose because the technical output transform and the creative intent are glued together. ## CDLs are portable, but not neutral CDLs travel well through production because they're simple: [slope, offset, power](https://www.arri.com/en/learn-help/learn-help-camera-system/image-science/vfx-faq), and saturation. That simplicity can make them feel safer than LUTs, but they're still not color-space agnostic. If you apply a CDL in LogC3, it doesn't have the same visual effect when you apply it directly to LogC4. The code values are mapped differently, middle gray is in a different place, and the primaries are different. A small offset that felt right in LogC3 can move a LogC4 image differently, especially around lower midtones. Saturation also interacts with the working gamut, so the same saturation value may not match perceptually. For mixed projects, decide where CDLs live. If the CDL is a camera-side or dailies-side trim, keep it attached to the source encoding it was created against. If the CDL is part of the shared creative grade, transform all sources into the common working space first, then apply the CDL. Don't apply one CDL to mixed LogC3 and LogC4 clips upstream of their input transforms and expect a match. A useful convention is to name CDL folders or ALE columns by input family: LogC3 CDLs, LogC4 CDLs, or Working Space CDLs. That avoids the classic conform question: “Was this CDL made before or after the LogC4 transform?” ## Resolve and ACES support DaVinci Resolve Studio has native ARRI LogC4 support starting with version 18.0.1. If you're on an earlier Resolve build, you shouldn't assume that color management, CST nodes, or ACES input transforms will correctly identify LogC4/AWG4. Upgrade rather than building a fragile workaround, especially if the show is already mixed LogC3 and LogC4. In Resolve, the clean setup depends on whether you're using DaVinci color management, ACES, or a manual node pipeline. The important part is the same in all three: assign the right input transform per clip. Common Resolve choices look like this: - For LogC3 media, use ARRI Wide Gamut 3 with LogC3 as the input. - For LogC4 media, use ARRI Wide Gamut 4 with LogC4 as the input. - For ARRIRAW, confirm the decode settings instead of assuming the clip is LogC3 because it came from an older camera. - For EXR plates in ACES2065-1, treat them as ACES, then convert to the working space required by the show LUT or grade. - For Rec.709 editorial references, don't use the reference file to infer the original log encoding. ACES support depends on the ACES implementation available in the software, not just the word “ACES” in a project setting. Use an ACES version or OCIO configuration that includes the ARRI LogC4/AWG4 input transform. In Resolve workflows, that generally means using current Resolve Studio builds with [ACES 1.3 support](https://www.arri.com/en/learn-help/learn-help-camera-system/image-science/color-faq) and the LogC4/AWG4 IDT exposed. If the only ARRI choices available are older LogC3/AWG3 transforms, that setup isn't sufficient for LogC4. [ARRI’s LogC4 specification](https://www.arri.com/resource/blob/278790/f3318e8c9c65617d8c5ca3f8b3e32051/2023-05-arri-logc4-specification-data.pdf) includes conversion information for ACES2065-1, and ARRI’s own mixed workflow guidance covers Resolve Studio and Baselight sample setups. For production, your team needs to make the transform chain explicit: camera encoding in, working/rendering space through, delivery space out. ## Choosing the common working space For a mixed LogC3/LogC4 job, decide where the show look, dailies, VFX pulls, and final grade need to agree. | Working choice | Best fit | LogC3 handling | LogC4 handling | Main tradeoff | |---|---|---|---|---| | LogC4/AWG4 or REVEAL-based pipeline | New shows led by ALEXA 35, ALEXA 35 Xtreme, or ALEXA 265 | Transform LogC3/AWG3 material into the chosen LogC4 or REVEAL working environment | Keep LogC4/AWG4 material in its native camera pipeline before shared looks | Existing LogC3 show LUTs and CDLs may need rebuilding or conversion | | LogC3/AWG3 legacy pipeline | Returning series, archival-heavy jobs, or shows with an established LogC3 show LUT | Keep LogC3/AWG3 material in the established show pipeline | Transform LogC4/AWG4 material into the LogC3/AWG3 working environment before shared looks | Consistency with the legacy look takes priority over a native LogC4 pipeline | | Scene-referred managed pipeline | VFX-heavy shows, ACES workflows, Resolve color management, or multi-camera projects | Assign ARRI Wide Gamut 3 and LogC3 as the clip input transform | Assign ARRI Wide Gamut 4 and LogC4 as the clip input transform | Every department needs compatible color management with LogC4 support | There are three common approaches: - Normalize everything into LogC4/AWG4 or a REVEAL-based pipeline. - Normalize everything into LogC3/AWG3 because the show LUT and legacy workflow are already built there. - Normalize everything into a scene-referred color managed space, such as ACES or Resolve color management, and keep camera-specific input transforms at the clip level. For new shows led by ALEXA 35 or ALEXA 265, a LogC4/AWG4 or color managed pipeline usually makes the most sense. You preserve the intent of the newer camera system, and you avoid forcing LogC4 material through older LogC3 assumptions. If older ARRI cameras are supplementary, transform their material into the chosen LogC4 or scene-referred working environment. For returning series, archival-heavy projects, or shows with an established LogC3 show LUT, the decision can be different. If the whole creative pipeline is built around a proven LogC3 LUT, and ALEXA 35 is only a small part of the package, you may choose to transform LogC4 sources into the older working environment for consistency. That can be valid, but it should be a deliberate compromise. For VFX-heavy jobs, ACES or another scene-referred managed workflow often reduces ambiguity because plates, CG, EXRs, and camera originals can be tagged with explicit input transforms. The risk is version drift. If editorial, VFX, and color aren't using compatible ACES configurations, LogC4 may be interpreted differently or not available at all. ## On-set monitoring with mixed ARRI cameras The on-set version of the problem is simple: an ALEXA 35 can output LogC4, while a Mini LF can output LogC3. If both feeds go into the same LUT box or monitor LUT without source-aware transforms, the LUT box or monitor interprets one of them incorrectly. The DIT or color pipeline lead should decide whether your team will monitor in a common log space before the display transform, or whether each camera gets its own camera-to-display path that matches visually at the monitor. Either can work, but what doesn't work is pretending that one LogC3 show LUT is equally valid for a LogC4 SDI feed. For live monitoring, keep the labels painfully clear. Name LUTs with input and output, not just the show name. “ShowLook_LogC4_to_709” and “ShowLook_LogC3_to_709” are much harder to misuse than “ShowLook_v12.” If a LUT is only the creative component, name it as log-to-log and document the separate display transform. This also protects dailies. If the on-set look is baked into editorial transcodes, the dailies team needs to know whether the on-set pipeline generated that look from LogC3 or LogC4 and whether the source OCN should later be transformed the same way. ## Editorial and dailies need metadata, not guesses Editors usually don't want to think about LogC curves, and they shouldn't have to. But editorial can easily inherit color ambiguity if your dailies team generates dailies without clear naming and metadata. A good dailies package should tell post what happened to each source. Did the dailies team transform LogC4 to Rec.709 with an ARRI display transform? Did the dailies team apply a show LUT? Did the dailies team apply CDLs before or after the camera transform? Did the dailies team render proxies from ARRIRAW using LogC3 or REVEAL LogC4 decode settings? Aspect lets teams add custom metadata to assets, so decode notes, LUT versions, and CDL status stay attached to the media. The finishing team isn't guessing from filenames when the conform relinks to originals. This is especially important when editorial cuts proxies for weeks before online. The conform will relink to original camera files, not to the flattened editorial viewing file. If the finishing team only sees “ARRI” in the notes, they have to reverse engineer decisions that the team should have carried forward from day one. Media handling still matters too, and ARRI’s guidance is clear that your team should copy original camera media with checksum verification rather than simple Finder, Explorer, or basic command-line copies. That isn't specific to LogC4, but mixed color workflows make bad turnovers more expensive. Losing sidecar files, camera reports, LUT versions, or dailies notes can be just as damaging as losing picture metadata. ## Failure modes that show up late Most LogC3/LogC4 pipeline errors are visible early if your team looks at the right comparison. They become expensive when they hide behind acceptable-looking dailies. The usual problems are easy to recognize: - LogC4 footage looks too dark or oddly compressed because the pipeline applied a LogC3 transform. - A show LUT works on one camera but not the other because it includes a baked camera-to-display transform. - CDLs from set don't match in final color because the team applied them in a different space than the one dailies used. - Dailies and final color decode ARRIRAW from a legacy camera differently. - Teams use Rec.709 proxies as color references without the LUT, CDL, and transform path that created them. When one of these appears, resist the urge to “fix” it shot by shot first. Check the input transform and decode path. If the source encoding is wrong, every downstream correction is compensating for a pipeline error. ## A clean mixed LogC3 and LogC4 handoff The cleanest mixed ARRI workflow is explicit. Your team identifies every clip as LogC3/AWG3, LogC4/AWG4, ACES, or display-referred, labels every LUT by expected input and output, ties every CDL to the space where it was created, and checks Resolve, ACES, Baselight, VFX, and dailies systems for real LogC4 support before the show depends on them. For Resolve, use Studio 18.0.1 or later for native LogC4 work, and preferably a current build on active productions. For ACES, use an implementation or OCIO configuration that includes ARRI LogC4/AWG4 support, commonly ACES 1.3-era configurations in current grading tools. If LogC4 isn't available as an input transform, don't substitute LogC3 and move on. Make the decision early: either bring LogC3 material forward into a LogC4 or scene-referred pipeline, or bring LogC4 material into an established LogC3 pipeline for a specific legacy reason. Your team can manage both. What breaks shows is mixing the two without admitting they're different.