Cinematography Mailing List - CML
    advanced

ARRICORE

Adam Wilt, 27 October 2025

In early October,  ARRI’s Chase Hagen invited me to test the ARRI 35 Xtreme and see if I could break the new ARRICORE codec, or at least see if I could find any glaring defects or deficiencies. What follows is the (mostly boring) results of that test.

Summary

ARRICORE renders images extremely close to ARRIRAW’s rendering, more closely than ARRI’s ProRes 4444 XQ rendering does. There are minor (infinitesimal) differences in color, visible on ‘scopes but not in pictures. Noise at and below the noise floor is slightly coarser in ARRICORE than in ARRIRAW, but the difference is not visible without extreme tonal-scale stretches.

ARRICORE has the same “Camera Raw” controls as ARRIRAW, and it responds identically to their manipulation.

Sample clips and a DaVinci Resolve project are available for download if you want to push the pictures around yourself.

(The downloads in this writeup are stored at MyAirBridge.com, which has a scary-looking page with two “I Agree” buttons that must be pressed before you can proceed. Don’t worry; it’s a legitimate file-transfer site that CML has been using for years.)

What is ARRICORE?

ARRICORE is an RGB codec designed to capture 18-bit linear data as 13-bit log. It takes up half the space as ARRIRAW while preserving the same workflow as ARRIRAW. Its data rate is comparable to ProRes 4444 and perhaps two-thirds that of ProRes 4444 XQ. This lower data rate increases the amount you can record on a given drive and allows faster high-speed capture for a given frame size, especially useful when combined with the Xtreme’s Sensor Overdrive mode, which is only available when recording in ARRICORE.

ARRI’S ARRICORE White Paper (PDF) says:

[T]he image from the sensor is debayered into an RGB image and then encoded by a proprietary process to an MXF-wrapped file. … Although ARRICORE is not a RAW format, it retains the essential post-production flexibility of ARRIRAW: ARRI’s Image SDK decodes the RGB Sensor Log image for a REVEAL workflow to enable changes in exposure, white balance, and color tint non-destructively after capture. … REVEAL color management and it’s look file (ARRI Look File 4), introduced with ALEXA 35, remains unchanged throughout the pipeline, ensuring visual and technical consistency from acquisition to post-production where ARRICORE replaces ARRIRAW. ARRICORE is also fully compatible with ARRI Textures… As with ProRes and ARRIRAW, the ARRI Textures are baked into the image.

Tests

ARRI asked me to try things I’d done before that caused codec conniptions: capturing clips that include spatially and/or temporally challenging material, and then stressing them in post to see what falls apart. To that end, Chase and I spent a day shooting various location exteriors, then a day in the studio shooting charts, slo-mo, and greenscreen material. I also had a few test-chart clips that Art Adams captured with another Xtreme.

I spent several days in a darkened room in Resolve, trying to tease out any significant differences between clips shot in ARRIRAW, ARRICORE, and ProRes 4444 XQ.

Both Xtremes were running software version 5.01.00, with the release version of ARRICORE. All images captured with ARRI Ensō primes. DaVinci Resolve versions 20.2.1 and 20.2.2 were used to decode the clips; these Resolve versions include the release version of the ARRI SDK that processes ARRICORE. 

All material was processed in ACEScct color using ACES 2.0, and output to Rec.709 BT 1886. I used an Apple M1 Max MacBook Pro, feeding a 4K monitor through a Blackmagic Design UltraStudio 4K mini.

Results

Most of what I did was a complete waste of time. I wasn’t able to detect any noticeable difference in clips recorded by ARRIRAW, ARRICORE and ProRes 4444 XQ when it comes to spatial detail rendering, sharpness, motion, sudden temporal changes (like illuminating the scene solely with Skypanels on “paparazzi” or “cop car” effects settings), or the like. Subtle sky gradients held up equally well to extreme contrast stretches in all three renderings. Colors didn’t shift; tonal scales remained the same; highlights were handled identically. Foliage blowing in the wind, ripples in the Columbia river, PDX airport at dusk: there’s nothing in the clips that betrays the codecs in which they were recorded. 

BehrensWoods

PDX.jpg

Comparing location shots was complicated by the variability of the scenes. The wind speed, or the light, or the position of the sun would change during the 35+ seconds it took to flip the camera between the different codecs (going between ARRIRAW and ARRICORE requires a reboot), and those changes swamped any codec-related differences I might possibly have seen while pixel-peeping the pictures. 

In the studio, we weren’t sufficiently careful with reflections: the black levels on the left side of the chart array varied based on where we stood. Note the central, non-reflective black chip in the ChromaDuMonde remains the same on all three waveforms:

Charts.gif

While the extents of the colors on the vectorscope are different (sadly not visible in the GIF above, but you can see 'em in the Resolve project), those envelopes varied frame-by-frame within the clips about as much as the variance between the clips. The central “fuzzball” on the ‘scope does shift slightly between renderings, but there is nothing I can see changing in the picture (aside from those left-side shadows) when I play these clips in a loop.

Underexposing the charts by 4 stops and fixing ‘em in post showed no visible differences. Overexposing by 7 stops and fixing in post showed a slight difference in color balance on the WFM between the ProRes rendering and the other two (the ProRes goes a bit magenta in the grays; this matches the fuzzball’s magenta leanings in the ProRes vectorscope), but ‘CORE and ‘RAW matched each other very closely.

ARRICORE has the same controls as ARRIRAW in the “Camera Raw” controls: color temperature from 2000 K to 11000 K, tint from -12 to +12, and exposure from EI 160 to EI 6400. Pushing those controls around affected both ‘CORE and ‘RAW identically.

As to the greenscreen clips, well, I’m not Bob Kertesz and I don’t play him on TV. We used a green fabric backdrop complete with wrinkles, and I shot blowing hair and tinsel at 24 fps with a 180º shutter, like any idiot would.  ;-)  The simple keys I pulled with Resolve’s 3D Keyer might suffice for a mid-market weatherman’s broadcast… maybe.

keying

ARRI’s Chase Hagen stands in for a mid-market TV weatherman

But the key point (pun intended) was that I stank equally badly with all three formats: codec quality wasn’t a differentiating or discernable factor in the resulting awfulness.

Noise in the deep shadows

But that doesn’t mean that ‘CORE and ‘RAW are identical. 

I took segments of the clips from the “paparazzi” tests when all lights were off:

Unstretched-CORE

I strung them together and boosted gamma so that the bottom 4% of the tonal scale, including its noise, expanded to about 70% (in Rec.709 terms):

Stretch-RAW.jpg

ARRIRAW

Stretch-CORE.jpg

ARRICORE

Stretch-ProRes.jpg

ProRes 4444 XQ

In ARRICORE’s deepest shadows I see a slight magenta tint, a coarsening of the “grain” pattern, and a minor loss of tonal discrimination.

Note that these images, downsampled more than 5x from the originals, greatly reduce the amplitude of the noise. Here’s a pixel-for-pixel crop from the upper grayscale of the ChromaDuMonde chart:

Noise.jpg

(If you’re playing along at home, this is the “Strobing shadows gamma” timeline.)

I also tried a linear stretch of the shadows using a custom luma curve (“Strobing shadows stretch” timeline), with a brightness inversion at the high end to make the slate readable. Please download StretchedShadows.mov (931 MB) to see it. (As it’s all about noise, it does not work as an H.265 streaming clip: it winds up twice the size of the ProRes original, and looks far worse; the characteristic noise patterns are converted into nasty DCT compression artifacts.)

For a slightly more realistic example, I took one of my location shots:

CamasNormal.jpg

This was purposefully exposed so that the shaded window on the house at the lower left was buried in ARRI’s viewfinder false-color purple: the “noise floor”. I then pulled up the gamma in Resolve to reveal details in the shadows:

CamasStretched.jpg

Download the rendered comparison: Scenic Shadow Stretch.mov (638 MB).

ARRICORE’s low-level noise is less isomorphic than ARRIRAW’s: there are faint horizontal striations, somewhat reminiscent of analog tape noise. ARRI mentions this in the SUP 5.0.1 release notes (PDF):

In comparison to ARRIRAW, ARRICORE recordings currently have slightly increased noise with a horizontal pattern when shooting at EI 6400 or when shooting at lower EIs and then increasing the image brightness in post.

But it’s a minor difference, and unless you’re digging detail out of the noise floor as in these example, it’s not something that’s likely to have any impact on your images.

The Wringer

ARRI’s Art Adams has a (sadly discontinued) DSC Labs Wringer chart showing zone plates of contrasting colors, cunningly contrived to cause camera, codec, and compression conniptions:

Wringer.jpg

He captured it with the Xtreme and kindly provided the clips, and this commentary:

At first, I just looked at color differences in Resolve. The difference between ProRes and the other formats is much more noticeable on the vectorscope where ProRes’s magenta skews more saturated. There’s also a significant shift in orange on the CIE 1931 display in ProRes.

Also, looking at the CIE display, ARRIRAW shows a greater variety of color at the outside edges of the “blob” than ARRICORE, where the ARRICORE “blob” has harder edges, but at least the color doesn’t shift like it does in ProRes.

I do see that slight magenta saturation in ProRes: it’s barely visible when A/Bing the clips. The ‘scope changes look like this:

WringerScopes.gif

I should note that when I render ARRIRAW to ProRes 4444 XQ in Resolve, the resulting clips are much closer to the ARRIRAW rendering than the in-camera ProRes clips are.

Art also mentioned differencing the clips to see errors. I’ve done that (and the Resolve project has several places where clips are stacked in difference mode), but unless the clips stacked are identically captured, without even the tiniest shift in position, the misalignment causes visible errors on anything with high spatial frequencies, like sharp edges. Random noise also generates visible differences. Thus I’m loath to use differencing as a definitive test.

I normally use differencing to winkle out errors when recompressing a clip: the source and output clips are identical, right down to the sensor noise, other than the extra stage of compression. Here, even two clips shot one after the other in perfectly locked-down registration will have different, randomly-distributed sensor noise, and as that’s where ‘RAW and ‘CORE appear to vary, it’s hard to separate differences due to the codecs from differences that occur from being being distinctly-captured clips.

That the differences between ‘RAW and ‘CORE are so small as to make differencing distinct frames unhelpful is itself an indication of how closely both formats render a scene.

A Note About Performance

On an M1 Mac mini (not a powerhouse machine) running Resolve, UHD ProRes plays at 24 fps, ARRIRAW at 10.5 fps and ARRICORE at 12.5 fps. On an M1 Max MacBook Pro, all play back easily at 24fps. Activity monitor shows that the CPU isn't being meaningfully stressed on either machine; it's the GPU doing the heavy lifting, as this history plot shows:

GPU

Camera Originals

You can download the source clips here (162 GB). The clips are contained in a DaVinci Resolve 20.2.2 project archive with timelines for most of the source clips and renders discussed.

Clips labeled “S. O.” were captured in Sensor Overdrive mode. Some test-chart clips are insufficiently focused; the focus puller involved has been sternly disciplined and may never work in this town again. :-)

Disclaimer / Disclosure

ARRI’s Art Adams and Chase Hagen invited me to perform these tests, but they did not compensate me for doing so or have any input into what I could or could not look at. The conclusions I drew are my own. Feel free to download the project archive and come to your own conclusions.


Copyright © CML. All rights reserved.