There has been a lot of back and forth on the internet regarding whether or not ProRes RAW is true RAW, or just ‘better ProRes’.
Let me try to shed some light onto the matter – note that this blog post does not contain any fancy images, that make reading it more appealing. However, it’s a fairly quick read and I hope it clarifies things for you, the dedicated reader. Also let me say one thing upfront: Yes, it is RAW.

The RAW people

So it appears, that in this world four types of RAW-believers exist:

1) Direct sensor read-out RAW – no filtering, no processing, just plain read outs. Everything else is not deemed ‘RAW’ for this group of people.

2) The ones for whom only uncompressed image data deserves the label ‘RAW’. ARRI RAW is such an example – it is being processed in the sense that it receives a tonal compression from 16 bit linear to 12 bit log.
However, the file format itself is uncompressed (hence bigger file sizes), so it does not require decompression upon reading it, but only a debayer pass. Anything further compressed (as in using a DCT) does not deserve the label “RAW” to this group of people.

3) The ones, that allow RAW data to be compressed (using a codec/DCT) and still carry the label ‘RAW’. This would apply to RED RAW, Sony RAW, and also ProRes RAW, as those formats first need to be decompressed, and then debayered. CinemaDNG *can* be compressed, but doesn’t necessarily have to be.

4) Something called “partially debayered RAW”. BRAW is the most prominent (if not only) format representing this category and there are the wildest discussions out there about whether it truly deserves to be called ‘RAW’.

I belong to the third group of people here.
As long as there’s mosaic data (Bayer pattern is only one form of mosaic) stored in the file, be it compressed or not, it’s still RAW for me (and most people, I might add).
Also check the ProRes RAW whitepaper here on those matters.

Other RAW formats

While none of us post people is dealing with raw sensor readouts (group #1), uncompressed RAW might be the truest form of them RAW formats, but it’s also not as easy to handle. And whether a ‘partially debayered’ RAW can still be seen as ‘RAW’, is very debatable.
However, lets consider that Blackmagic was facing a lawsuit from RED, because of them storing compressed RAW (in the form of Cinema DNGs) inside their cameras. As Blackmagic had no intention of paying royalties to RED, they worked around that patent by developing Blackmagic RAW.
It’s no secret, that BRAW is compressed. However, it’s safe to assume that if it stored actual RAW data, it would still be in conflict with RED’s patent, which it is quite obviously not.
That said, without knowing what’s actually inside BRAW (and that really only Blackmagic knows), it’s fairly pointless to discuss this format, so lets just not.
Contrary to that, we also know that Atomos is working together and paying royalties to RED, for Atomos to be able to record to ProRes RAW (as you can check here, here and here).
I highly highly doubt anybody would agree to pay royalties for being able to record a RAW format, if that format didn’t contain actual RAW data (and hence wouldn’t be subject to royalties in the first place).
So, apart from the technical side of things, this adds a strong financial perspective to it.

ProRes RAW in particular

For many people out there, the reason they think ProRes RAW isn’t ‘true RAW’ is based on the fact, that none of the PRR implementations present Kelvin, Tint and ISO parameters to change the debayer.
Yes, these kinds of parameters are quite common if you look at other RAW formats, such as RED, ARRI and Sony. However, they do not determine whether the format itself is actually RAW or not.
As stated above: As long as the file requires to be debayered, it is factually a RAW format, as it stores black and white – undebayered – image data. This is the case with ProRes RAW.
However, what do you need Kelvin, Tint and ISO controls for anyways?
Every ProRes RAW implementation uses Apple’s SDK to decode and debayer ProRes RAW.
This happens in floating point, which means, there is no clipping whatsoever going on. Your NLE of choice will have an incredible amount of image information to work with. So why not use the Kelvin, Tint and Gain controls, your NLE ships with? Yes, they are applied after the debayer.
So what?
Again, we’re dealing with floating point image information here. That’s plenty!
Whether you add 3 stops of exposure pre- or post debayer makes zero difference in terms of image quality, or dynamic range.

Up- and downsides of ProRes RAW

Any and every format has pros and cons. ProRes RAW is no different.
In terms of image quality, compression ratio and ease of use, it’s very much on par with RED, Sony and others. It does not convolute the workflow with side car files, zillions of debayering parameters and what not. Remember – it’s an Apple format – they tend to make things as simple and straight forward to use as possible.
It’s their thing, it’s what they do.
ProRes RAW is just the result of that. A simple to use, yet quality rich format.
The downside of that is two-fold.
First of all, it’s a perceptional downside:
No Kelvin-, Tint-, ISO-parameters? Not a RAW format!
Well, I hope I could clear that one up.
Second: A RED/Sony/ARRI RAW SDK ships with a huge number of parameters.
No matter which NLE I load the file into, by dialing in the same values for the SDK-given set of parameters, I can be sure to achieve the exact same image. If I set the whitebalance for my RED RAW file to 6000 Kelvin in
Assimilate SCRATCH, I can be sure that I’m getting the exact same image by setting the Kelvin slider to 6000 in Baselight, RedCine-X, or Resolve. That’s nice. However, to make this a valid argument, ask yourself two questions:
First question: How often do you need to load the same file into two applications and make it look the same by messing with the RAW parameters, really?
In reality, most often white balance, exposure and whatnot are already correctly set in-camera and there is not that much to tweak in the raw controls to begin with anyways. Also, most colorist prefer to dial in white balance using their color wheels – hence post debayer grading tools, instead of fiddling with RAW parameters.
Second question: Even if you do have to achieve the same look in two different aps – what is the easier thing here?
Dialing in a number of parameters, or would you in the end rather leave everything at its default and load a LUT or CDL, that carries the creative intent? Isn’t it then much better to not have to deal with a boatload of RAW parameters that can potentially get messed up, or misinterpreted?
Now this last point is very much subject to discussion and maybe even a matter of taste to some extent.
Like Windows vs. macOS, Mercedes vs. BMW or cats vs. dogs.
Some like to revel in debayering parameters, others like it simple and straight forward.
That’s alright. Both approaches are legit and serve their purpose.
And for the sake of my blog post: Both start with a file that contains RAW image data.