Raw vs. Transcodes?

resolve
colorcorrection
Tags: #<Tag:0x00007f3c6113ad40> #<Tag:0x00007f3c6113aa98>

(Gray Marshall) #1

Hi all.

In the wilds of lower-budget filmmaking, I’m hearing from various colorist who are giving ACES “a try”, and some of their issues. In almost all cases they are working in Resolve (12.5 mostly) and they are using transcoded footage, either XAVC, DNxHR or DNxHD, or DPX. While they tend to try to maintain the tone curve of the original footage (F55 footage will be XAVC codec with an S-Log 2 tone curve, R3D will be transcoded into DPX files with a RedLogFilm curve), all the original camera meta is stripped.

So, my question is: Do ACES implementations (especially Resolve) prefer to work with Camera Raw files to accurately utilize the IDT or are properly transcoded files fine to work with (we can get into “properly transcoded” later)?

Thanks for your time & opinions.


(MichaelKeelin) #2

Hey Robert. I am exactly the person you describe. I’ve been using ACES on Resolve 12.5 - mainly with F55 footage straight from the camera (slog3) as xavc MXFs (ie bypassing the raw). It works nicely for me- particularly when there is other cameras such as gopro, BMPCC and phantom drone footage involved (as is on the current job I’m on today).


(Peter) #3

Of course you always want to work with RAW footage if available and if the machine has the power to play it in realtime. Apart from that Log-Footage is fine if it has at least 10bits. That and the correct IDT brings you to ACES AP0. Although with less data compared to RAW. But it works in practise

I want to indicate again that the SLog3-IDT in Resolve is NOT correct for SGamut.cine. It seems to be SGamut3 only.

Peter


(Walter Arrighetti) #4

Hi guys.
First of all there is no problem at all working with camera-native file formats in ACES. In fact, this is the preferred way to do because you don’t touch your original files (and all camera-specific metadata are retained).

If the file has Bayern pattern layout internally, you may want to do other considerations.
Usually one transcodes the camera-native files at the beginning if either:

  • software products used long down the chain have trouble supporting or playing back those native formats, or
  • the demosaicing algorithm available further downstream may not be as accurate as the one you have at the beginning, or
  • one simply can’t do assumptions on other demosaicing tools available.

Said that, as said above, the best thing is usually to work with raw files. The color-correction / editing / compositing / finishing software will internally do the conversion to ACES2065-1 by applying the Input Transforms as first step.

The storage of files in ACES colorimetry, however, should never be demanded to DPX format; the elective file format is OpenEXR and ACES2065-1 colorspace, plus additional stuff as per SMPTE Standard ST2065-4, which software applications should, in the near future, honor in (semi-)automatic way.
There’s also a specific MXF wrapping of the above OpenEXR frames (as per SMPTE Standard ST2065-5), in order to have a clip-wrapped single file instead of a files-per-frame sequence. But I think vendor suppor for this “ACES MXF” is still lagging behind today.

As a last note, the conversion of today’s camera-native files/colorimetries into ACES2065-1, i.e. to the AP0 gamut, if stored correctly in an ACES-compiant file (read above about EXRs and ST2065-4) does not reduce the quality of the image, for mainly two reasons.

  • ACES-compliant encoding uses 16bit/channel depth and is linear, which is equal or higher than any other cameras;
  • AP0 primaries are wider than any other camera primaries (except for Arri RGB WideGamut’s, but the larger gamut peak outside of AP0 mostly spans imaginary colors).

Again, demosaicing algorithm can be the game-changer for native-cavera versus early ACES2065-1 conversion.