Best graphics format for Pro Res

[Chris Borjis]

png should work just fine. .tif or .tga would look the same but be bigger. .png is a great format, a lot like pro res in that its a “vbr like” type of compression so file sizes are not huge just to be huge.

there is no real time supported graphics format, though you could open the graphic in quicktime pro I suppose and export it as pro res to keep everything real time.

As long as the final product is rendered out fully and looks good on a studio monitor it shouldn’t really be an issue.

[Martin Williams-peck]

Hi,

Have you tried changing just the timeline format to 8-bit uncompressed?

I have had problems when using a simple resize on ProRes material in a ProRes timeline, gives the green preview render bar, but put the same ProRes material with resize in a 8-bit timeline and there is no render bar.

[Jeremy Garchow]

What you are seeing is the difference in computing power needed to process 8 bit vs 10bit.

If you want to compare apples to apple so to speak, you really should compare ProRes to 10 bit uncompressed and see the difference in speed there.

Jeremy

[Alex Elkins]

Thanks for the response Chris.

“…you could open the graphic in quicktime pro I suppose and export it as pro res to keep everything real time.”
I tried this but unfortunately it made no difference. Good idea though.

“As long as the final product is rendered out fully and looks good on a studio monitor it shouldn’t really be an issue.”
It isn’t an issue as such, but it looks to me like a minor flaw to an excellent format. When working with uncompressed 8 bit I don’t need to render the graphic overlay as my system will support its playback and ETT without doing so. Thus saving space by capturing Pro Res loses its appeal as I then have to render the entire programme because the graphic bug is used throughout, which adds significantly to the amount of media – original rushes plus render files. Then on top of that there’s the time waiting for things to render, which is no good when there are deadlines!

I’m guessing that perhaps a faster processor might be a way to avoid this?

[Alex Elkins]

Hi Jeremy,

I see what you’re saying, that makes a lot of sense. So a faster processor would avoid that?

[Alex Elkins]

Martin, you’ve just saved me a hell of a lot of rendering!

For the record, here’s what I’ve done;

Editing PAL Pro Res material using a timeline based on the prompted settings – Upper Field, Anamorphic, Compressor = Apple Pro Res

Changing sequence settings to compressor = Uncompressed 8 bit actually made things worse – the entire timeline goes to preview quality, even bits without graphic composites.
BUT
Then changing field dominance to Lower has put the whole timeline to ‘RT Full’ which means no rendering. Fantastic!

[Alex Elkins]

Just a follow up for anyone reading this – the change in sequence settings from compressor = Pro Res to compressor = Uncompressed 8 bit isn’t exactly what solved the problem. It is actually to do with setting the timeline to render in 8 bit YUV rather than 10 bit (under the video processing tab).

So practically this means I can render using Pro Res, thus saving huge amounts of storage space, but as it’s processing 8 bit, not 10 bit (10 bit being native to Pro Res) it can process a lot more things in real-time.

For the record, what are the technical differences between 8 and 10 bit? I can’t physically see a difference, so in real terms is it comparable to the minute difference between Pro Res and Pro Res HQ? Presumably 10 bit is necessary when working with 4:4:4:4 footage or similar? I haven’t got my hear around all of this so if someone could straighten it out it would be much appreciated.

[Chris Borjis]

[Alex Elkins] “Presumably 10 bit is necessary when working with 4:4:4:4 footage or similar?”

those extra 2 bits typically are seen on things like a smooth gradient from black to white or a blue sky with no stepping or banding effect. in 8-bit it usually does this, i say usually because I once owned a discreet smoke* that though 8-bit, it utilized a high precision algorithm, just enough that it could create a smooth gradient.

when you get into 4:4:4 RGB you should have 12-bit or 16-bit precision or higher.

[Jeremy Garchow]

[Alex Elkins] “Hi Jeremy,
I see what you’re saying, that makes a lot of sense. So a faster processor would avoid that?”

To a certain extent, but the difference in 8 bit vs 10bit vs 12bit vs whatever bit is exponential, so the processing power goes up considerably at higher qualities so it won’t be avoided completely. A faster processor will help, but 10bit processing requirements are still high even with today’s fast processing. This also has to do with how the application you are using is written and the implementation of real time effects. Some other system other than FCP have hardware aided processing that help speed up 10bit effects. FCP does it all in software applying a lot of load to the entire system architecture.

Jeremy