Canon 7D (H264) –> Compression –> Compare (part 3)
After the two last parts I got a little fed up by always seeing my color bar image. So I thought why not continue testing with some footage that I shot with my Canon 7D. I also got a chance to get some test clips from the Arri Alexa (PR444) shot on a parking lot of a film production company. Some more formats may follow if needed.
The idea is:
I shoot footage myself (7D) or receive it (Alexa) for a job. Then I work with it in Autodesk flame, The Foundry’s Nuke or the new Final Cut (FCP-X) for example.
I finished commercials shot on the 7D and the Alexa mixed with stock footage which was shot on 35mm – all directly on flame. Still my normal workflow is Alexa LogC material will be graded (Lustre/DaVinci/Baselight) and then I work with it as DPX files (in sRGB) in Nuke and Flame. 7D material is for additional elements such as little greenscreen background elements or clouds or whatnot – but not as a real A camera.
What I want to know is:
I view and select 7D clips and Alexa footage directly on a MAC with quicktimeX and may even use it directly inside of Nuke and Flame. Maybe even with FCP-X and Motion… because I have them installed.
Can I work in all these tools and see the same colors and luminance. Or do I expect shifts? Yes, I do…
Let’s get started with the Canon 7D material.
I use a long clip that I shot out of the window in the evening sky and recorded some moving clouds.
The screenshot above is captured from QuicktimeX in full screen mode.
The first comparison I made was to see if the 7D (H264) clips looks the same in QuicktimeX and the old Quicktime 7 on OS/X Lion. And they don’t. The difference is very subtle, but show some funny details.
the QuicktimeX image is more reddish and shows some fine noise or grain.
The Quicktime 7 image is slightly more blue-/greenish and less reddish and it lacks the noise.
Therefore it looks a bit more blurry. Although the overall sharpness is not affected.
Screenshot from Quicktime 7. Viewed in Nuke and push the exposure up to see more details.
Screenshot from Quicktime X (QTx).
But in general I think it is okay to say that the two images are matching. That’s why I concentrate again only on QtX and leave Quicktime 7 out, because it is an outdated tool.
The next program is Nuke. As this clip is shot with the picture style „ Standard“ and the camera is set to sRGB for photos, I assume that the H264 movies are also recorded in sRGB. But of this I am not sure but I would like to know.
Set the read node to sRGB and view the image inside of Nuke. The image is darker and the colors are less vibrant than in QuicktimeX. To compare the results I make screenshots of the QuicktimeX player window and load these .PNG files into Nuke.
Which result is now the right one? Is quicktime already lifting the gamma automatically? Is there a colorspace conversion happening? Is the Canon file really encoded with the sRGB curve, does the quicktime importer in Nuke on OS/X works correctly? I don’t have any answers to this…yet. Hopefully I will find some.
But one way I found to get a far better match to the QuicktimeX player result is to set the read node in Nuke to (RAW data) and therefore bypass the linearizing process and as Nuke quicktip reveals, maybe also some YUV colorspace conversion. Then add a grade node and set the gamma around 0.5. I found the value 0.509 to match the quicktime player result the closest I could get.
Note: I was trying differnt colorspaces in the read node – right now it is set to Alexa/LogC but the raw data checkbox disables any conversion. This has no effect.
Down in the script I use a merge/difference node to see the difference between the quicktimeX screenshot and the „homemade“ gamma curve in the Nuke viewer. I couldn’t do the test with the same files in flame yet. This test will be added one day…
Next is Compressor4:
The ProRes 444 format is the preferred way to work with FCP-X and Apple hardware, it comes directly out of the Arri Alexa in different color spaces and in general is a widely supported format by many tools and vendors.
So why not converting the 7D H264 files first into PR444 before start working with them.
I converted the H264 file to PR444 with Compressor and reviewed and compared it in QuicktimeX. I also used the write node in Nuke to create a PR444 file (read node of the H264 – sRGB / write node set to sRGB).
Compressor changes colors from the original H264 media to PR444. Not dramatically, but visible. Once this color transform happened, another re-compression to PR444 doesn’t change the colors again! Good to know…
As explained above Nuke is showing a different result than the quicktime player. For better or worse, I don’t know. Set both the read and the write node to sRGB of the H264 when exporting to PR444. This file can be imported again into Nuke and looks the same as the H264 original (apart from minimal new compression artifacts, which are not visible).
Of course the Nuke created ProRes file looks different than the one created by Compressor.
The Nuke viewer in wipe mode.
On the left side is the PR444 rendered out from Nuke.
On the right side is the original H264 converted to PR444 with Compressor.
If you compare the red colors just by eye with the first image on this page, to my eyes the Nuke result matches better than the one created by Compressor.
In part 1 of this series I encountered many unwanted color transforms with Compressor4.
Another pass of re-compressing with Compressor to PR444 doesn’t affect the colors anymore. It seems, once a file is a ProRes, Compressor is not altering the colorspace or luminance/chrominance levels anymore.
In the next part of this series of tests I will try the same with original Alexa ProRes files. Let’s see what happens there.
But I did one last test…with Motion5 and FCP-X!
As I am staying now inside the Apple world, I don’t expect any strange things happening between QuicktimeX and Motion/FCP-X.
This time everything works as expected. The screenshot of the Quicktime player matches the result of importing the original H264 into Motion5. There are very subtle differences, but these are very hard to see by eye.
Just by comparing the results again and again I found them. I think it is okay to ignore them.
The original H264 imported directly into Motion5. The image in the viewer looks the same than in the Quicktime player.
Another re-compression to PR444 doesn’t affect the colors.
The Nuke export to PR444 looks different. Here especially in the reds.
Another round of re-compression to PR44 is not changing the colors.
FCP-X can work directly with the H264 file for editing, but you can also choose to create optimized media automatically in the program. Then a ProRes 4:2:2 HQ file is generated in the background.
The two files look identical.
This all makes sense to me as Final Cut Pro X, Motion5, Compressor 4 and supposedly QuicktimeX are all working “under” ColorSync.
The original H264 imported directly into Final Cut Pro X. The image in the viewer looks the same than in the Quicktime player.
The original H264 imported directly into Final Cut Pro X. But this time check the option to create optimized media.
A ProRes 4:2:2 file was created in the background.
The same result you get by transcoding the H264 to PR422 or PR444.