ProRes transcode in cct?

Discussions - Using ACES Post (DI, Edit, Mastering)
#1

Hi everyone,

For a low budget web series I am shooting on a Komodo and BMPCC 6K camera. To save on disk space, we would shoot raw and then transcode the footage to ProRes masters, downscaling to HD and discarding the raw files. This to avoid the sensor crop on the Red and because I dislike the internal BMPCC compression and I can transcode it to a ProRes444 master.

I want to use an Aces workflow and I need some feedback on the following:

I was thinking that it could maybe be an idea to transcode the raw files directly into an Aces cct ProRes master, instead of their designated manufacturers gamut/log encoding.

I know that you are not supposed to write a file in Aces cct, but could someone expand on why not? And why this would be a bad idea?

I haven’t tested it yet, but rendering the raw files to exr linear sequences wouldn’t gain as much disk space as a ProRes would and this is very hard to defend to producers.

Thanks
Pieter

#2

Hi Pieter,

I can’t give you a proper explanation on why not to use ACEScct apart from storing log data in EXRs shouldn’t be done, only linear data.

I don’t see any issue creating native camera log format ProRes files from your cameras.
ACES is designed to take those in and work with them in a working space like ACEScct or ACEScg. This is what makes ACES so powerful. As long as the manufacturer has provided the IDT you can work with the material. So if you’re on a budget do this:

RED:
Transcode to ProRes in RedWideGamut/Log3G10. ACES has an IDT for this.
Maybe it’s even possible to just record proxies along with the R3D in ProRes 444. Not sure if that codec is selectable though. But I know proxies are always recorded in log with IPP2. If it works you save time transcoding and have free backup files should a raw file corrupt.

BMPCC 6K:
Tricky as Blackmagic doesn’t provide IDT’s but handles the raw files behind the scenes with Resolves own ACES implementation.
Easy to convert to another space however like Alexa LogC or even RWG/Log3G10 again. I think they even added the Alexa LogC as a read option in the raw settings when you open your BRAW files in Resolve.

Hope this helps!

Shebbe

#3

Hi Shebbe,

Thanks for the reply.

The reason I’m asking is I don’t see any difference to making a bmd log prores to to an aces cct prores technically.

Why I would be leaning towards making an aces prores is that once you have gone through the idt proces, everything is in the same space with the same log encoding. With bmd for example, I also fear for continuity towards the future as they don’t publish anything. If I now find the idt that works for my intended end result, either by resolve ingest or a ctl from the generator on this site, that one may not be available anymore in the future. For archival purposes I would much rather have an aces cct than a bmd log file.

#4

I totally get your point on BMD’s side of things. But just keep in mind that
ACEScct is a working colorspace not one to store data in. If ACES ever evolves to a point where cct becomes legacy you run into the same issue. It’s not an IDT in that regard.

RWG/Log3g10 won’t change in the near future and neither will Alexa Wide Gamut/LogC so it just makes sense to go for those encodings instead. It’s what they’re designed for. ACEScct is designed to just work in for colorgrading etc.

Working in ACES wil always be the same. It doesn’t matter if you encode RED + BMD to one or the other.
The source data/quality won’t change. You can’t suddenly have “the alexa look” because you went from BMD to Alexa to ACES output 709. It will be the same as going directly or going from cct.

What’s holding you back from just setting your project BRAW to Alexa? It’s also super similar to BMDs log encoding but at least available as IDT everywhere.

2020-12-24 17_09_32-Window
2020-12-24 17_09_32-Window1046×499 36 KB

Can’t think of an easier way to go about it. Just make an HD timeline, dump all clips in and render individual clips to ProRes. But feel free to experiment I guess if you have the time :slight_smile:

Cheers.

#5

Using AWG / LogC as an intermediate encoding can cause issues due to the fact that the LogC curve varies with EI. You need to be certain that the same variant of the curve gets used for encoding and decoding, and you do not get to select the EI variant (or even see which one is being auto-selected under the hood) in all applications. So you can get round-trip mismatches.

#6

Hmm, thanks for pointing that out @nick .
What’s your take on creating intermediates in ACEScct in Pieter’s situation?
Would love to hear some other perspectives/opinions.

#7

I didn’t know you could debayer the braw directly to awgrgb logc, thanks for pointing that out, I’ll give it a try

#8

I would have to test to look for potential issues. But something I can say is that ACEScct was not designed to be stored in an integer format like ProRes. It was designed as a transient working format for processing in a grading system at 32-bit float or higher precision. So it is quite possible that rendering it to ProRes could cause harmful quantisation.

But like I said, I would have to test to make a truly informed comment.