Debayering to log in Premiere

I’m working on a guide for using Premiere Pro to debayer camera RAW into ACES2065-1 via OCIOv2. I have been able to verify that this works with ARRI and RED cameras, meaning that Premiere can debayer these into their camera log color spaces (i.e. LogC and IPP2 respectively).

I have also found that Premiere cannot read BRAW files (BlackMagic camera RAW), and that it reads in DNG files in Rec.709/BT.1886 with no option to view in log.

I’m wondering if

  1. anyone is aware of additional camera RAW types besides ARRI & RED that premiere can debayer to camera log?
  2. where I can get a sample file of that camera RAW to verify? Specifically I’m thinking of sample camera RAW files for Cannon, Sony, Panasonic.

thanks!

Hi Derek,

I am not really using that workflow, but as far as I know, Premiere can debayer SonyRAW to Slog2 and Slog3. As well as Rec709 I think. How do you implement OCIO in Premiere?

I could shoot something for you in SonyRAW from a F5 if thats useful for you. :slight_smile:

Yes please. That would be wonderful.

EDIT: Fixed link
Here’s my write-up on the process:

The TLDR; is that the After Effects OCIO plugin works in Premiere too.

Hey Derek,

Braw doesn’t work out of the box but Blackmagic offers the software that enables metadata access in Premiere Pro the same way you’d handle R3D. From there you could directly decode to AP0/Lin if you’d want without OCIO plugin. You can find it in the download section here.

And if you want to extend support for .braw to After Effects there is a paid third-party solution.

For cDNG this is not possible unfortunately so you’d have to handle it through Resolve.

Can’t comment on other raw formats as I have no experience with them.

I say this but I haven’t verified if this works properly. You might want to check if it includes chromatic adaptation.

Thanks that’s great to know!

Here’s where I’ve gotten so far:

Broadly speaking Premiere is a great software for editing, but is limited in it’s ability to debayer camera RAW files. Premiere can not properly debayer the following. For these Resolve will need to be used, which can debayer all camera RAW formats (with the exception of ProRes RAW).

Black Magic (.BRAW) - Cannot read at all.
CinemaDNG - Reads in Rec.709 only
ProRes 4444 - Reads in Rec.709 only

That said, Premiere can debayer camera RAW files from:

ARRI (.ari)
RED (.R3D)
Canon (.CRM)
ProRes RAW (.mov)
MXF (a container format that supports many cameras including Sony, Panasonic, ARRI, etc.)

Note that for MXF files, by default Premiere reads these in as Rec.709. You can however right-click the media and go to Source Settings where you can select the camera log space.

Cool, so I see that in the Effects Controls for the BRAW I can set:

  • Color Space: AP0
  • gamma: linear

and have it in ACES2065-1 without the need for OCIO at all.

Are you sure about this? They moved source settings to the same Master Clip Effects section location as with other raw formats since some major version a while ago. The ARRI file is also automatically set to LogC but maybe that depends on what is set in the camera?
This is what I see with ARRIRAW in .mxf.
image

Maybe it’s still different with other .mxf files? This is the only ones I’ve worked with.
I don’t really understand ‘raw’ .mxf anyways because the file itself is just a ProRes 4444XQ but the ‘raw’ part is just the access to a Colorspace Transform and WB tool?

I also see that setting it to Rec.709 will include the LUT used in the camera which you can’t turn off. Interesting fact but not that relevant for your document :slight_smile: .

One thing worth mentioning regarding Adobe software is, at least on Windows and since 2020 (or 2021, not sure) versions, exporting without “use maximum depth” checkbox turned on (or “use trillions of colors” in AE) always gives 8 bit data, no matter what encoding format is chosen. And also there is offset shift into magenta. But this only happens if there are some changes in the image or if the export is in different (from source) format. Otherwise the frames are just copied without re-encoding and the bug is not presented.

Another thing is Adobe software incorrectly displays (and renders) ProRes files from Alexa camera. It applies some kind of a wrong matrix. I’m not sure. This is a very typical case when I work with editors or clean up artists who use Adobe software. While it’s easy to avoid getting 8-bit data from them just by telling them to turn on one checkbox, the only way to deal with incorrect colors of Alexa ProRes is to re-encode the files using non-Adobe software and only then send the files to clean up artists.

Have no idea if that was fixed in the recent versions though.

Thanks for mentioning this. I think I’ve made a post on their forums about this once. From what I remember is that most Arri ProRes files are encoded with BT. 601 and Adobe doesn’t handle them correctly on Apple computers. I discovered this when a mac created proxies and I saw the difference on Windows. The appearance of the originals in Premiere matched that from Resolve on the same machine.
I assume mac doesn’t convert this to it’s Rec.709 timeline while on Win it does. Exporting in ProRes or other common formats will tag it as Rec.709 so the shift will persist once it’s there.


Haven’t experienced an offset shift issue though but perhaps this has gone unnoticed so far.

This is still present in the current versions.

@meleshkevich & @Shebbe

I think so. Here’s what I found:

Camera OS Effect Controls Source Settings
Sony WinOS YES NO
Sony macOS NO YES
ARRI Prores WinOS NO NO (reads in but no means to change color space)
ARRI Prores macOS NO NO (reads in but no means to change color space)
ARRI RAW WinOS NO NO (does not read at all)
ARRI RAW macOS NO NO (does not read at all)

Sony footage from here:
https://sonycine.com/testfootage/

Seems the Sony MXF varies on the OS on how it behaves. Do you know if Sony RAW is always in generic containers like MXF or Prores or does it have it’s own RAW format too?

ARRI from here: Camera Sample Footage

I see that they have MXF Prores and MXF ARRIRAW. The above is for ARRIRAW. MXF Prores does not work (i.e. there is no way to change it if it isn’t in log already)

Yikes! Well this workflow is for **in:**RAW camera log out: AP0 EXR so does that mean there will be a magenta shift?

Do you mean Prores 4444 or ProresRAW? Again, yikes!

I dunno, the more I dig into this the more it seems that Premiere is error prone, inconsistent, and overly complicated and kludged together… at least in regards to color management and debayering. I understand the motivation of editors wanting to stay in the familiar territory of Premiere. But if it so easy to mess up the master in Premiere… I wonder if it may be better to only present the solid Resolve workflow? Thoughts?

1 Like

Adobe said somewhere that they will support OCIO 2.0 at some point.
Until then I would use tools that work…like Resolve.

I don’t remember if I tested EXRs, but the shift (and 8 bit data) was definitely presented in dpx, h264 and prores exports. Actually, I tested this with many formats and options and the shift and 8 bit data were always there. The only thing I don’t remember if I checked this with EXRs or not.

I mean ProRes 4444. I wasn’t talking strictly regarding the workflow discussion above, I just wanted to add a few details to keep in mind during any rendering operations with Adobe software.

Silly me, I checked the wrong .mxf when inspecting with MediaInfo :slight_smile:

Now about compatibility…
Sony X-OCN .mxf → decodes to log, access through Source Effect Controls
ARRIRAW .mxf → decodes to log, access through Source Effect Controls

I don’t know why you are finding that they don’t work or need access through Source Settings by rightclick. Are you making sure the latest Premiere Pro is installed on both test machines?

On the appearance side of things…


Premiere does not match Resolve for X-OCN .mxf.
Maybe because it doesn’t fully take in the metadata?

The other flaw is setting it to Rec.709 doesn’t look like the color space gets converted along with it, only gamma. I did see it appear on a couple frames but it bugged out and now it stays like this.

Premiere Pro

Resolve with a CST (without tonemapping) which roughly matches the thumbnail on the download site.

I haven’t checked fully yet with ARRIRAW .mxf files but I think that running VFX prep through Premiere Pro is just asking for issues. I also realized that both raw formats have abysmal performance in Premiere Pro compared to playback in Resolve so I’d never use it like that anyway. Especially since adding OCIO plugin in Premiere to the mix makes it even worse. No GPU acceleration too.

The only downside in using Resolve is that the free version has a resolution limit but the software is just 300 dollars for lifetime which is a steal for people being able to afford a subscription for Adobe :wink:

Interesting! Do you remember where they said this?
I always felt like they were too proud of their current ways or scared of change but now that the people using Substance really needed this maybe they see the light for their other software too.

1 Like

My Mac has v22.2 which is the current version. But really I think we are all in agreement that this is the least of the problems! As you say,

That’s a great point with the Adobe subscription! Also the resolution limit is UHD which is pretty great for free!

Yes, I found the link. Here it is:

quote:"
Adobe
Adobe is currently working to implement an ACES workflow inside an OpenColor IO v2 wrapper for its tools most often used in production pipelines: Photoshop, After Effects and Premiere Pro. Lars Borg, a SMPTE Fellow and one of the developers of ACES, is a core leader in Adobe’s color team who is leading the charge. His colleague Patrick Palmer, Principal Product Manager for Professional Video, notes that the ability to support ACES in OCIO v2 without a 3D LUT is a significant step forward to driving broad-scale support for ACES, and that the improved GPU renderer in OCIO v2 is a critical area that will drive adoption.
"

2 Likes