I’ve missed ProRes. I’m used to jumping between Mac and Windows, and I often say that once I’m in Adobe-land I can’t tell the difference. But a few months ago I switched to Windows permanently and the thing I miss most is ProRes.

Last week on the ProVideo Coalition Facebook page, a PVC reader posted a link to a new product offering the ability to encode ProRes on Windows. Krzysztof Karnicki had a simple question – is this for real? I was intrigued, but most of all I was excited – could this be the product I was looking for? Please let it be true…

There’s a lot to like about Apple’s ProRes family. There are just enough variations – from lower bandwidth proxy & LT versions, to higher-bandwidth 422 & HQ, and then the 4444 version with alpha channel support. It works at pretty much any resolution you’re likely to encounter, and most of all it’s commonly used in the production industry. In the 10 years since Apple launched ProRes, it’s something that has fulfilled a need and just worked.

While I am generally platform agnostic, there’s no denying that Mac and Windows each have their own strengths and weaknesses. And one of the more annoying problems with working on Windows machines is the lack of full ProRes support. Yes, Apple provide a ProRes decoder for Windows, but there hasn’t been any official way to encode ProRes files on Windows. Telestream offer ProRes encoding as a cloud-based service, but that’s not the same as rendering out of After Effects on your local machine.

Considering that the first version of ProRes was announced in 2007, this is a little surprising. And it’s not an uncommon question – ProRes is a fundamental part of many post workflows and it only takes a simple Google search to see how many Windows users are looking for some way of rendering ProRes. There have been previous attempts to get ProRes encoding working on Windows machines – you can do it using ffmpeg – but the results haven’t been as good as the real thing.

The lack of ProRes encoding on Windows is a common problem, especially for those who have switched from Macs to Windows and are trying to maintain their existing workflows. While there’s a lot of love out there for the Avid DNx codecs, they’re simply not as friendly as the ProRes family and it doesn’t appear to be as simple as just using DNx instead.

If you’re used to using ProRes, then the first encounter with a DNx codec can be surprising – why do you have to choose different versions depending on the resolution? Or frame rate? Why so many options? Does the i stand for interlaced, or just plain intimidation?

Compared to good old ProRes, the Avid DNx codecs are like kale smoothies. There’s a lot of people out there telling you how great they are, but the first time you try one it’s a shock to the system.

Last year I worked at a company that had purchased a product called “miraizon” – a product that rendered ProRes files on Windows machines. It was the first time I’d seen ProRes encoding on Windows, and I was a little surprised I hadn’t heard of it before. But I quickly noticed the problem – it simply wasn’t very good. Even by eye I could see blockiness, and I quickly discovered that it always encoded 8-bit files regardless of the settings in After Effects. When I looked up the company’s website to see if there were bug fixes or updates, I discovered they had closed down and miraizon was no longer supported.

But now there’s a new contender – simply called “Windows ProRes”. Thanks to Krzysztof on the ProVideo Coalition Facebook page, I headed over to the website and had a quick look. It seemed to offer everything I’d want, and they had discount pricing for the month of January. While my previous experience with miraizon left me skeptical, we purchased a couple of copies to see how it performed.

When I sent them an email, Arnold replied promptly and confirmed that yes – Windows ProRes is still in beta and no, this has not been officially licensed from Apple. The company only launched two weeks ago and the current product isn’t considered a “final” just yet.

Expectations

The thing I like about ProRes is that it just works. There’s not a lot to fiddle with. Testing a ProRes encoder is not like testing a camera, where there are knobs and menus to adjust and lots of competitors to measure against.

The basic test for Windows ProRes is to see if it works the same as ProRes does on a Mac. That’s about it.

Having been less than impressed by the miraizon product, which is no longer available, my main priority was to compare the encodes from a Mac with the same content encoded using Windows ProRes.

I opened After Effects on my Mac and put together a quick collection of footage from different jobs I’ve been working on. I set up a variety of ProRes renders – LT and 422 at “millions of colours”, 422HQ and 4444 at “trillions” of colours. Before I hit “render”, I saved.

Then I opened the same project on my Windows machine, and rendered exactly the same thing.

Before I even hit the “render” button I noticed something promising – when I opened up the project on my Windows machine I didn’t get an error message about missing output modules. It seemed as though After Effects on Windows was recognizing the ProRes items that I queued up on my Mac.

When checking the output modules the codec shows up as “Windows ProRes”, but all of the dialogue boxes and options appear to be the same as on a Mac.

This is worth emphasizing. I queued up the renders on my Mac, and opened the project on Windows. No errors. I wasn’t just rendering the same footage, I was rendering exactly the same render queue, with exactly the same render and output settings.

This might seem like a little thing but it’s quite significant. It means that After Effects is not seeing the Windows ProRes codec any differently to the Apple one. It means you can queue up ProRes renders on a Windows machine and then open the project on a Mac without any problems, and vice versa.

Although I work on a Windows machine, our render farm is comprised of headless Mac Minis and so this is very important. If the Macs didn’t recognize the Windows ProRes codec as ProRes, then we wouldn’t be able to queue up ProRes renders on our desktop Windows machines and submit them remotely – the mac minis would open up the project but think the output module was missing. So this cross-platform transparency is very important, and a big tick for Windows ProRes.

As I said above – the most you can really ask for is that Windows ProRes works the same as Apple’s ProRes does on a Mac. So far, so good.

Comparisons

At first glance, the outputs from both machines looked identical. There was none of the blockiness or banding which was easily visible in the older miraizon product.

The file sizes were similar but not identical, and the data rates were too.

The next step was to stack the Windows renders on top of the Mac render and set the top layer to “difference”. If both layers were 100% identical then the result would be a perfectly black frame.

And that’s what it looked like to the eye – just black – so to emphasise any differences we need to boost them with the levels effect.

I added an adjustment layer with the levels effect and decreased the “input white” parameter until I started to see something. While this test demonstrates that the two files are not exactly identical, they are very very close. In order to make the differences clearly visible, I had to set the input white value to 4. What was also promising was that the differences – as minimal as they were – were more like an even noise, and not confined to edges or gradients.

While Windows ProRes is a beta product, this was enough for me to be satisfied with the purchase. But having been burned by miraizon, there were a few more things I wanted to try.

A great feature of ProRes is its support for bit depths greater than 8-bit. Because I had discovered that the miraizon encoder always appeared to output an 8-bit image, regardless of the settings in After Effects, I wanted to test Windows ProRes.

I have a simple test that I use to demonstrate the difference in bit depth to new users. I simply make a new comp and apply the “4 colour gradient” effect. Then I apply the “exposure” effect and darken the image down significantly: –10 stops is a good value. At this point, the display looks almost completely black. Then I duplicate the exposure effect and change the second one to +10 stops. This completely reverses the previous exposure effect, so the image should look the same as the default colour gradient.

But in 8-bit mode, the result is very visible artifacts. When working with 8-bit colour depth, the 0-255 range of each pixel isn’t enough to preserve image data through such a large adjustment. Darkening the image so significantly and then brightening it again results is very visible banding and blockiness.   If you do the same thing to footage, you end up with a heavily distorted and posterised look.

But as soon as you switch to 16 or 32 bit mode, these artifacts go away. The range of each pixel has now expanded from 256 levels to 65,556. This massive jump in fidelity is enough to completely preserve the original image through the -10 / +10 stop exposure process. In fact – if you compare the original 4 colour gradient with one that has been through the -10 / +10 stops adjustment, the results are identical. There is absolutely no difference at all.

In order to test whether Windows ProRes is really encoding 8,10 or 16 bit movies, I would render out clips with only the first exposure adjustment. Then I would import them and apply the second exposure adjustment and see what the result was.

With a lossless 16 bit file format, the end result is still identical to the source. As a control case I rendered out a frame of the 4 colour gradient with -10 stops exposure, using a 16 bit TIFF file format. When I re-imported the TIFF file, applied the exposure effect with +10 stops and compared it to the original gradient (using the same difference mode and adjustment layer mentioned before) there was no difference at all.

Unfortunately my first test with ProRes was disappointing. The renders out of After Effects were dark as expected – but after I reimported them, applying the exposure effect failed to reveal any information at all.  The black screen really was just that – pure black, with no hidden image.

ProRes is a lossy format, and only 10-bit as opposed to the full 16-bits that After Effects can work at. So perhaps I was asking too much of it.

I tried again using an 8 stops round-trip instead of 10, and this time I had more success. All of the renders – on both Mac and Windows – responded to the second exposure effect to reveal an image similar to the original 4 colour gradient.

As expected, the ProRes LT and ProRes 422 renders (which were rendered with the 8-bit “millions of colours” setting)  looked noisy and had extreme banding that showed the limits of doing such heavy processing with only 256 values available for each pixel. Interestingly, the LT and 422 renders looked visually the same.

The ProRes HQ and ProRes 4444 renders (using the “trillions of colours” setting) fared much better – but they still weren’t perfect. While there was much more detail than in the LT and 422 renders, there was still visible banding and blockiness. A 10-bit format provides 1024 values for each pixel – which is four times as much as the 256 levels of 8-bit images, but still a long way short of the 65,556 in a 16 bit format.

The point of this test was to see if there was a clear difference between the way the Windows ProRes encoder deals with 8-bit data from After Effects, as compared to 16-bit.  This corresponds to choosing “millions” or “trillions” of colours in the output module. Clearly there is a differemce, and so the Windows ProRes codecs are working as expected.

Even with the additional bit depth, the HQ and 4444 examples didn’t look that great, so I did the same test on a Mac to see if Apple’s codecs performed differently.

The results for the LT and 422 versions rendered on a Mac were visually indistinguishable from the Windows ProRes versions, but the ProRes HQ looked noticeably different.

The Mac version also displayed visible banding, but in a different and less blocky way. Generally, the Windows and Mac renders were very similar even with these artificially challenging tests, but it was the only time that the Windows ProRes result looked visibly different to the Mac equivalent.   While this doesn’t mean either is better than the other, it does serve as a reminder that the Windows and Mac ProRes results aren’t identical, and that in difficult circumstances these differences are more pronounced.

When I repeated the process yet again using a -4 / +4 stops round trip, the results were encouraging. Again, the ProRes LT and 422 @ “millions” displayed the 8-bit limitations with extensive banding and blockiness on both Mac and Windows machines. But this time, the ProRes HQ and 4444 renders @ “trillions” survived the aggressive processing to be visually indistinguishable from the original gradient.  In the same way that the LT and 422 renders looked the same visually, the 422HQ and 4444 renders also looked the same to the eye.

While this demonstrates that the Windows ProRes encoders are true 10-bit when given sources that higher than 8-bit, it also suggests that the ProRes 4444 codec is 10-bit as well – otherwise there would have been a visible difference between the 422HQ render and the 4444 render.  Apparently, the 4444 version of ProRes has the ability to do 12-bit RGB encoding, but there are no settings within After Effects to control this – on Mac or Windows.  So if it’s true then either the capability is not supported by After Effects, or the Windows ProRes encoder, or both.

By this stage I had satisfied my main concerns with the product. I was very happy with the quality of the renders when compared to the same renders from a Mac. I was satisfied that the HQ and 4444 variations of the codec used 10-bits when fed with 16-bit data, and I was relieved that After Effects treated the Windows ProRes codec in the same way as the Apple version, so that renders on one OS can be queued up and opened on the other OS without errors.

But.

Arnold was quite open about this being a beta product, and happily shared a few known bugs. He said there are some issues with alpha channel tearing when rendering 4K with ProRes 4444, that unusual aspect ratios can cause problems, as can rendering 6K images – the largest size currently supported.

As I was working through my tests, I noticed a few anomalies with file sizes. All of my initial tests had been with “real” footage – and as expected the different variations of ProRes codec rendered to different files sizes. The ProRes LT codec was the smallest, then ProRes 422, then ProRes 422HQ, with ProRes 4444 being the largest. As noted earlier, the files sizes were pretty close to the same clips rendered on a Mac.

But once I started rendering out the 4 colour gradients with different exposure adjustments, this changed. The 4 colour gradient with a -10 stops adjustment looked almost black, but the LT file was suddenly larger than the ProRes 422HQ file. More renders revealed more anomalies with the files sizes of ProRes LT and 422 renders. It appears that while regular footage encodes as expected, more extreme footage and artificial test patterns produce inconsistent results.

The same files rendered on a Mac did not show these anomalies – suggesting that this is an issue for the Windows ProRes team to look at.

With the file size differences piquing my interest, I decided to try encoding another batch of normal footage to see how the file sizes differed between the Mac and Windows versions.

This time, I queued up my outputs on my Windows machine and hit render, then a few seconds later I heard the distinctive sheep-bleat announcing a failed render. It appeared that the ProRes 422HQ output had failed, without any clear indication of why. I re-queued it and re-rendered, and it failed again. I tried lots of different things – restarting, rebooting, different file names, different destinations, but both the 422HQ and 4444 encodes consistently failed on exactly the same frame every time.

The interesting thing was that the renders would only fail if I rendered the entire composition. If I rendered a shorter version – eg ten frames before the ‘voodoo’ frame, then it would work. If I changed the “voodoo” frame even slightly, it would work. But somehow, the combination of a specific type of image and its location in the timeline combined to trip up the encoder. This was pretty interesting, so I reduced the project down to just the incriminating items, confirmed again that it would always consistently fail on exactly the same frame, and then zipped everything up and emailed it to Arnold for his diagnosis.

Conclusions

Windows ProRes is a beta product, and it has a few quirks. But in ordinary usage the product works exactly as you would expect- and it does it better than the only alternative I’ve seen  before – the now defunct miraizon.

For a company that only launched two weeks ago, this is a very promising product. It’s already changed the way I work and solved some basic workflow issues that I’ve had since switching to Windows last year. Just being able to queue up a ProRes render on my Windows machine has made my life easier, and considering the investment we’ve made in our mac mini render farm, this benefit alone is worth us paying for before we even consider desktop rendering (after we switched to Windows last year, we’ve still needed a desktop Mac to queue up ProRes encodes for our render farm).

ProRes is a great codec family and it isn’t going away any time soon. Windows ProRes is a product that is filling a very obvious gap in the market, and although the beta has a few quirks the product is very impressive for a company that only launched two weeks ago.

I don’t think our spare Mac is going away any time soon, and we’ll probably need to have it as a backup until some of the quirks in the Windows ProRes beta are sorted out. But already this has dramatically changed our workflow and made the switch to Windows that much easier.

As the Windows ProRes team move the product out of beta and fix some of their issues, I’ll post updates in the future.

Update – 3rd Feb

Some of our readers have reported problems trying to install the Windows ProRes product:

I sent a quick email to the support address, and received the following reply from Arnold:

“There have been about 5 cases, out of hundreds, where it didn’t immediately show up in their programs.  We try and diagnose the program first by asking them to make sure it’s installed correctly and then double checking whether they have Quicktime installed.  Reinstalling Quicktime fixed it for a couple people and reinstalling the specific Adobe program fixed it for one so far.  It’s impossible for us to diagnose what could be wrong on their end of the setup process so we have just been asking them to try these options.  There’s only one open case now where the guy still hasn’t gotten it to show up but we’re waiting on his response now.  I don’t think that in any of these cases it’s a larger scale bug on our end.”

Update – 4th Feb

It seems that encoding ProRes on Windows is something lots of people are interested in, as there have been more comments and feedback on this article than everything else I have previously written for the PVC, combined.

A number of people have pointed out some inaccuracies regarding ProRes and bit depth.  James (commenting below) is correct that I had not read the Apple ProRes white paper, because I didn’t know there was one.  The white paper makes for a good read and clarifies issues such as data rate and bit-depth.  As an After Effects compositor, I generally only think in terms of working with After Effects – which offers 8 and 16 bit depth but not 10 or 12, and when rendering the options are only “millions” or “trillions” of colours.  When I rendered to ProRes LT and 422, I deliberately had After Effects working at 16-bit depth, but I set the output module to 8-bits by setting it to “millions of colours”.

But many more people have commented on the fact that this is an unauthorised implementation of Apple technology.  The ProRes white paper even addresses unauthorised products at the very start, before they even get into the technical details, and warns:

“Using any unauthorized implementation (like the FFmpeg and derivative implementations) may lead to decoding errors, performance degradation, incompatibility, and instability.”

The fact that Windows ProRes is unauthorised isn’t something that I focussed on, but evidently it is important to many people.  It isn’t something I have a strong personal opinion about, and I would hope that it’s clear that I am an animator and not a lawyer.  But despite my own personal ambivalence towards the topic, there are a few points I can add.

Firstly, Windows ProRes has always been open that their product is unauthorised.  When I specifically asked them , Arnold responded:

“All I can say is we’re all Apple fans and own a ton of Apple products in addition to previously being a Mac-only post house.  Apple has chosen to focus on their consumer market, leaving most of their professional market in the dark.  From the end of Final Cut Pro to discontinuation of their Mac Pro Towers, they have put many high-end visual professionals in a bind.  ProRes became a standard years ago and Windows ProRes is simply meant as a compatibility bridge for those looking to use latest high-end hardware without having to force their clients learn something new.” – Windows ProRes

Secondly, an unauthorised implementation of ProRes is not illegal.  It’s actually quite common for standards in the IT industry to have unauthorised versions.  SAMBA is an “unauthorised” implementation of the  Windows SMB protocol, and is so prevalent that even some IT professionals don’t realise they’re different.  WINE is an unauthorised implementation of the Win32 API, and there are unauthorised implementations of file systems like NTFS.  But perhaps one of the most prevalent examples is AMD, who have been manufacturing chips that use the Intel x86 instruction set for decades.

Creating an unauthorised implementation of another company’s protocols is nothing new to the IT industry, and someone on this page suggests that the PC itself owes its history to such a process – citing this old article which discusses the “clean room” approach.

So Apple have a generic warning against using unauthorised ProRes codecs, and Windows ProRes are quite open about being an unauthorised implementation.  If there was an alternative, authorised way of rendering to ProRes on Windows directly out of After Effects, then perhaps the discussion may be different.  But right now, there isn’t, and if Apple were really serious about getting people to stop using unauthorised ProRes codecs, they should start by releasing their own, official Apple ProRes codec for Windows.