This content has been marked as final. Show 2 replies
Well, simple answer: Other than in 32bpc there is no such thing as a true "super-white". Image processing runs on zeroes and ones, not electrical levels.
More complex answer: To retain or produce super whites, you must compress the ranges and work in a bit-depth that is higher then the required final output bit-depth. This is certainly the case in AE's 16bpc mode. Therefore the logical conclusion for you must be to compress down the ranges while working in AE, so e.g. a 90% white represents the actual target whitepoint and use the remaining 10% for everything beyond that range. This can be achieved with Levels and similar effects.
Furthermore you will then have to tell your edit suite how to correctly interpret the file to expand the levels again, which is actually what you are not doing at all, it seems. When you import stuff in FCP, you need to tell it what whitepoint it is supposed to use, not just import the file straight away. Not on my Mac at the moment, but this is certainly possible in the import dialog or the interpretation of the imported file. In addition, you must also set the project settings to deal with expanded ranges and not downconvert them.
in AVID you have to interpret the file before importing (example RGB or 601) but in FCP I don't see anything you can do before importing a quicktime!
I digitized a clip in HDTV Uncompressed 10 bit via a Kona 3 card (Apple Uncompressed 10 bit 4:2:2 codec). This clip have superwhite (white above 100 IRE).
Export quicktime movie current settings.
Then importing it in AE.
After effects project setting 8 bits (or I even tried 16 bits) with no color management.
I render it in 1920x1080 (Codec Apple Uncompressed 10 bit 4:2:2).
Then going back to FCP, every color and levels (black and luma) is exactly the same except there is nothing above 100 IRE.
I tried reimporting the original clip directly into FCP and the superwhite is still there (means After effects is clipping "superwhite").
I don't think it's a bit-depth problem but I'll try it in 32 bits.
Let you know after this test.