Interesting comparison between Prores 4444 and other codecs

[David Newman]

Could somebody please explain what Cineform and Apple mean when they say QuickTime is 8-bit only?

What is the point of 12-bit ProRes 4444, if QuickTime is 8-bit only? http://bit.ly/127wUB

Sloppy/old implementations are 8-bit only, as the original specification didn't include alternative pixel formats, resulting every tool having to fallback to the 8-bit RGBA mode with that broken 1.8 gamma (at random times.) As QuickTime came to the PC later, more QT implementations on the PC support deep pixels than from QuickTime on the Mac. Tools like Autodesk Combustion and Adobe After Effects can support QuickTime at 16-bits per channel (format 'b64a') (I think Scratch just added it, also Nuke, but not Fusion -- EyeOn, catch up), whereas most tools on the Mac seems to be 8-bit only for QT sources. For the tech. side of things is bizarre that the Mac every made as a production suitable platform (Avid did it spite of QuickTime.) FCP has support for some deep formats, but only YUV formats like 'v210' (10-bit 4:2:2) and 'r4fl' (32-bit float, yuva 4:4:4:4.) While FCP has this 32-bit float, most of its filters don't support it, the product is shockingly unpredictable when it choose to deep modes (although rendering is stable.) Color doesn't support Quicktime at all, and accesses ProRES and others, only through an internal Apple API, bypassing QuickTime. There are very few post production solutions that reliably maintain deep pixel precision using compression, one reason why Stu Maschwitz's Rebels guide recommends uncompressed AE finishing, as DPX is mostly commonly 4:4:4 10-bit RGB. CineForm has fought this battle and won in places to allow for deep pixel compressed workflows, Adobe is good at supporting deep pixel API (beyond the 16-bit QuickTime support it has), FCP works, and many Windows tools are pretty good with QuickTime. With ProRES, CineForm and Avid DNxHD now proving compression and deeper color is compatible, we are seeing more tools improve there support, although slower than you want, although I doubt QuickTime Player will ever get there.

 

[Charles Angus]

Not sure what the benefits of tests are?
Who cares if with a composite mode set to difference show difference, it is what we see with out eyes in the end.

I did what i would think is a more practical test when ProRes first came out. in After Effects i did a split screen with Animation on one side and ProRes on the other with an adjustment layer cranking the levels and Saturation all over the place, I could not see a difference!

Also i believe Animation is 422 isnt it.

Mark

Hmm, that's interesting.

As an experiment, I took ProRes, 8-bit tga and 16-bit TIFF through the same pipeline (coming from an Apple UC 10-bit film scan) for a 3-minute short I edited and did VFX/colour.

I could definitely notice a difference in quality between the three when it came to grading.

 

[Evangelos Achillopoulos]

The main issue I have found in ProRes 4444 is the it legalizes the range to video... thats 64 - 940 instead of 0 -1023 so in all RGB footage, which is mostly full range, I'm loosing some of the low lights and almost all of the highlights...!

Because they are clipped...

The problem is big, when using cameras like Viper, Varicam 3700, F23 since these cameras are using the full range to represent what sensor is recording so when you batch capture or directly recording almost 2 stops are lost...

I hope that Apple fix that since its a big drawback...

 

[Thomas Berglund]

Thanks David! This is very interesting and educating.

I now see how this 8-bit only limitation makes my test quite useless

Back to square one.

It seems like Motion can export image sequences in 16-bit or 32-bit float though.

From Apples Motion 4 documentation:

When exporting a 16-bit or 32-bit float project, keep in mind that most file formats available for export do not support float—including QuickTime (8-bit only). OpenEXR is a float format. TIFF, PNG, and Adobe Photoshop files support the 16-bit integer format.

FCP has support for some deep formats, but only YUV formats like 'v210' (10-bit 4:2:2) and 'r4fl' (32-bit float, yuva 4:4:4:4.) While FCP has this 32-bit float, most of its filters don't support it, the product is shockingly unpredictable when it choose to deep modes (although rendering is stable.) Color doesn't support Quicktime at all, and accesses ProRES and others, only through an internal Apple API, bypassing QuickTime.

So, rather than fixing QuickTime, Apple bypasses the problem through an internal API. Interesting.

How would you check/confirm bit depth in an image?

 

[David Newman]

How would you check/confirm bit depth in an image?

Normally that is not so easy for end users to know, which is a problem we feel (in Prospect HD/4K under Premiere Pro we report the pixel depth in the display during the edit.) On the Mac we have to codec report as debug what pixel formats are being requested (so we can find out -- not be reported to the user yet.)

 

[Nick Shaw]

The main issue I have found in ProRes 4444 is the it legalizes the range to video... thats 64 - 940 instead of 0 -1023 so in all RGB footage, which is mostly full range, I'm loosing some of the low lights and almost all of the highlights...!

In what app are you experiencing this? In my testing of ProRes4x4 with Shake, I have converted full range 10 bit RGB to ProRes4x4 and it reads back in as full range, maintaining 10 bit granularity.

I have also passed that same clip (generated from Shake) through FCP, applying a minimal Gaussian blur (supports 32-bit float) and when I read the result back into Shake it is still full range, and has only lost a small amount of bit resolution and the colour values are very close to the originals. Basically granularity is still near as dammit 10 bit, and when the image is a linear ramp from 0 to 1023, only a few values come out with a one code value rounding error. Not yet done detailed analysis of colour fidelity.

 

[Evangelos Achillopoulos]

In what app are you experiencing this? In my testing of ProRes4x4 with Shake, I have converted full range 10 bit RGB to ProRes4x4 and it reads back in as full range, maintaining 10 bit granularity.

I have also passed that same clip (generated from Shake) through FCP, applying a minimal Gaussian blur (supports 32-bit float) and when I read the result back into Shake it is still full range, and has only lost a small amount of bit resolution and the colour values are very close to the originals. Basically granularity is still near as dammit 10 bit, and when the image is a linear ramp from 0 to 1023, only a few values come out with a one code value rounding error. Not yet done detailed analysis of colour fidelity.

I have a BMD HD pro PCIe 3 I used it with FCP7 to capture from my Viper... it was clipping it in video levels... its probably FCP7 thats legalizes everything... I will try the BMD capture app...

 

[Patrick Inhofer]

Not sure what the benefits of tests are?
Who cares if with a composite mode set to difference show difference, it is what we see with out eyes in the end.

I say: Our eyes are very poor judges of incremental deterioration in images. We usually know what an image is supposed to look like and our minds compensate. If not, who'd have a need for scopes?

One test I did of the SD variants of ProRes a few years ago was to output and recpature to DigiBeta. I went something like 4 generations of output/capture - figuring this would be the worst you could figure your deliverables would go through, say, for international versioning.

Then I took that N generation digitbeta, recaptured it, and cut it between the original. I also did some difference tests and looked on the scope. ProResHQ (SD variant, I'm talking about) held up well. And, I think, it was a good testing methodology reflecting real-world usage. In fact, DV dropped into an ProRes timeline held up surprisingly well (will I get kicked off of REDuser for mentioning NTSC DV?:001_cool

I'm not thrilled with the source footage used in the previously linked Codec Wars 2009 post. That's much too graphic-y an image. I've found it takes a range of footage - close-ups, wide shots, exterior nature (with fluttering leaves in the distance, please), interior - to get a good sense of how these codecs hold up. I've found in my testing a codec may hold up great, until you get to a particular shot where it breaks down.

Just some random thoughts on the subject...

- pi

 

[Chuck Z]

I tried to get in touch with the BitJazz guys and I never heard back from them either.

I hope they're still cranking along.

 

[J Davis]

edited my last comment as I was incorrect regarding YUV vs Y'Cb Cr

instead I have a question regarding prores4444

If you have a clip without an alpha saved to prores4444, is filespace still taken up for the alpha?

 

[Kwan Khan]

RED could use this technology in their workflow. It would be great to render out of REDCINE-X to Sheer lossless codecs. That would be a great workflow.

Agreed...

 

[J Davis]

Also I have noticed that when I take a prores4444 to Color something happens and according to the parade, Broadcast safe seems to be permanently on whether its checked or not.

When I take a prores422HQ to color I can get sub black and super white. Has anyone else seen this?

 

[Evangelos Achillopoulos]

Yehh I have seen that... Prores 444 clips 0 to 64 and 940 to 1023...

 

[J Davis]

I thought it was a bug in color, but you mentioned it in post 23, so the limit is within the codec itself? If so that sucks