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
anyone is aware of additional camera RAW types besides ARRI & RED that premiere can debayer to camera log?
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.
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.
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:
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.
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.
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 .
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.
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?
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.
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
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.
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.