Compression (Flame)-Part 2


This time I use the same color bar I created in Nuke and use a TIFF16 image sequence inside of Autodesk Flame 2013. All of my tests are done on the pre 20th anniversary editon.

Although TIFF16 image sequences are slow to im- / export for Nuke and Flame, at least you always end with the same image results. For this check my other page about Image Formats in Flame/Nuke and AE.

Import the TIFF16 sequence into flame and view the image through a ColorCorrect Node to check the color values.

As expected the 8-bit values match 100%. To get the float values match as well, use a LUT node with the preset „Video_to_SceneLinear_via_sRGB“ to see 100% matching float values.

Flame - LUTFlame - BATCH


As in part 1 the goal is to create best as possible matching color&luma values from my color bars after exporting high quality uncompressed quicktime files and compress them to MP4 and ProRes444.

This time I dont use Apple Compressor (Version 4) but Episode which is another batch processing compression tool.



The output formats from flame are uncompressed quicktime files using the codecs 8-bit RGB (UC 8-Bit) and 10-bit 4:2:2 (UC 10-Bit 422). From these two files I generated each two MP4 and PR444 files.

All six resulting files are reimported into flame and compared to the original imported TIFF16 clip.


1.UC 8-Bit vs. TIFF16
The uncompressed quicktime matches 100% to the original clip.



2.UC 10-Bit 422 vs TIFF16
The uncompressed quicktime matches 100% to the original clip.



3.UC 8-Bit via „Episode“ to MP4 vs TIFF16
The luma values are good, they dont match 100% but they are very close and the difference is not visible by the eye.
The Chroma values are changed and a colorspace conversion has happened.



4.UC 10-Bit 422 via „Episode“ to MP4 vs TIFF16
The luma & chroma levels are both good! A MP4 created with this workflow gives you a very good matching result to the original clip!



5.UC 8-Bit via „Episode“ to PR444 vs TIFF16
The luma values are good, the chroma is reduced or compressed again and a colorspace conversion has happened.



6.UC 10-Bit 422 via „Episode“ to PR444 vs TIFF16
The Luma & Chroma values are matching perfectly!
So the best workflow is 2., 4. and 6.
Note that this is a FLAME –> Uncompressed QT –> Episode –> MP4/PR444 –> back into Flame workflow. The next step is to view the six resulting files in QuicktimeX and also in Nuke. And as before, here the results are differnent. More than I would like to…

These are the six QuicktimeX screenschots done in full screen mode.
And then measured again with the „DigitalColor Meter“ from OS/X.
Top to Down:
1. Flint UC8-Bit –> QTx
2. Flint UC10-Bit422 –> QTx
3. Flint UC8-Bit –> Episode MP4 –> QTx
4. Flint UC10-Bit422 –> Episode MP4 –> QTx
5. Flint UC8-Bit –> Episode PR444 –> QTx
6. Flint UC10-Bit422 –> Episode PR444 –> QTx

1. The luma values are lifted and the chroma values are altered. Also the image is cropped in Quicktime, because of the „clean aperture“ flag.
2. Espcially the green is clipping already to 1.0 at 0.7!
3. The full image is visible, because Episode is setting the „clean aperture“ flag right. Luma&Chroma does not match the original.
4. Again the green clips at 0.7!
5. The luma vales are changed and the saturation is reduced a lot.
6. The luma vales are changed but the saturation especially in the green channel is now closer to the original again.

Altough on flame 2., 4. and 6. ist matching to the original values, with QuicktimeX you can‘t view any of the files showing the original luma and color values. How sad is that!

The old Quicktime 7 player is actually doing a better job on some of the files, the luma levels are matching sometimes nearly 100%, but the chroma is always changed especially in the high values. I don‘t consider the old Quicktime 7 player as an alternative, because is not longer developed by Apple and I guess it will dissapear soon.
Apple, please fix QuicktimeX or at least give me a preference window where I can turn off all the automatic adjustments to the image that I don‘t want or need!
Now to Nuke. Of course apart from the two uncompressed files I don‘t want to work with the compressed PR444 and the MP4 in Nuke. But maybe it could be good to import it and check or review something. Set the read nodes to sRGB!

1. Apart from some minor rounding errors, the luma&chroma matches nearly 100%.
2. The luma levels are nearly there, the chroma is way off and the green clips at 0.7 already! Why is this working in flame and not in Nuke?? It‘s an uncompressed format!
3. Nuke 6.3v8 on OS/X Lion can‘t open the MP4 file.
4. Nuke 6.3v8 on OS/X Lion can‘t open the MP4 file.
5. Luma & Chroma levels are good! The color noise has a reduced saturation!
6. Luma levels are perfect! / chroma levels have a not visible difference!

So you could use 1. (only 8-Bit) and 6. (PR444 compression) inside of Nuke when the files are coming from flame.
For me that is not a workflow that I would use, but at least I found two formats where the image data is not altered too much to use (or just for review/compare) in Nuke.
What to learn from this exercise?
-Episode does a better job than Apple Compressor, because you can create MP4 and PR444 files that match the original image from flame 100% (apart from compression artefacts of course).
-Sadly these files are looking different when viewed in QuicktimeX. Which should be the fault of QTx.
-And the quicktime support of Nuke is not that great – unlike TIFF16, DPX or EXR files – the nuke read node might interpret information in the image that is not there as it happend with the UC-10Bit 4:2:2 uncompressed quicktime file.


1. Flint UC8-Bit –> reload in flame



2. Flint UC10-Bit422 –> reload in flame



3. Flint UC8-Bit –> Episode MP4 –> reload in flame



4. Flint UC10-Bit422 –> Episode MP4 –> reload in flame



5. Flint UC8-Bit –> Episode PR444 –> reload in flame



6. Flint UC10-Bit422 –> Episode PR444 –> reload in flame





Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *