Renders from QT wrappers VS. REDCINE

[Mark L. Pederson]

I just wanted to post this because I have read some threads that make it clear to me that some people are missing something very basic on the Red workflow side.

The QT wrappers that do a real-time extraction of your .r3d files are coded for performance over quality. And yeah, look pretty damn good. HOWEVER, you do NOT get the same results when you process with full quality settings in REDCINE.

If you want the highest quality output - do not use the QT wrappers. Period.

Now, we LOVE the QT wrappers - we use them for DVD dailies and off-line edit proxies - because it's easy to build automated compressor workflows - and you can process FAST.

But as far as rendering these wrappers to Prores and going to broadcast - well ... not us.

Use the wrappers for speed - review, dailies, off-line edit.
Use REDCINE, REDALERT, SCRATCH for delivery.

I only posted this because I think there is a small number of folks out there that think the QT wrappers yield full quality -

 

[Scott M]

- because it's easy to build automated compressor workflows - and you can process FAST.

Out of curiosity, will it be possible to have full quality QT wrappers coded for this reason in the future?

Then again, if FCP is supposed to be able to open r3d files natively soon enough, that might side-step the issue, and the wrappers will remain for quick viewing only...

 

[M Most]

Out of curiosity, will it be possible to have full quality QT wrappers coded for this reason in the future?

Then again, if FCP is supposed to be able to open r3d files natively soon enough, that might side-step the issue, and the wrappers will remain for quick viewing only...

Final Cut Pro uses Quicktime, only Quicktime, and nothing but Quicktime. Nobody - Red included - has ever said otherwise. "Native" in the case of FCP means direct use via the Quicktime codec. Now, having said that, some at Red have hinted that the codec can and likely will be improved in terms of both quality and performance. Time will tell.

If you want direct reading of R3d files without the Quicktime layer, you currently need to look at Scratch or the Red applications (Red Alert and Redcine).

 

[Scott M]

Nobody - Red included - has ever said otherwise.

I was referring to posts like this one: http://www.reduser.net/forum/showpost.php?p=122325&postcount=10

If that's not the case, then disregard the second part of my question, and I'm still curious about the first part, is it possible to code a QT wrapper of full or higher quality for use in Compressor as an example if they are currently not recommended for broadcast level use?

 

[Rob Lohman]

Yes, quality improvements are coming to the QuickTime codec. I call it high quality, but not yet ultra-high quality

MrGlory: paul does not work for RED or Apple. He is giving out incorrect information. FCP only understands QuickTime. When you want to edit "native" you are using the QuickTime wrappers. We can sort of call this native since there's no transcoding or generating proxy files involved.

 

[Mark L. Pederson]

what would be very cool - and I don't know if it is possible - is if you could cut in RT with the wrappers - but when it is time to render the timeline - you click a button in FCP and that "toggles" the QT codec to ultra-high-quality (2K debayer) - or toggels to a different QT codec (which is ultra-high-quality 2K) - that would be very cool -

 

[Chris Kenny]

Months back, there was some discussion from Red folks of there being an RGB version of Redcode, which could be seamlessly mixed with the RAW variant on a Final Cut timeline (to allow for rendering, etc. since you can't render back to Redcode RAW). I see ProRes is currently being used for this in FCP, but it's 4:2:2 and 10-bit, rather than 4:4:4 and 12-bit, so it's not precisely ideal. Is Redcode RGB (as a desktop workflow tool) still on the horizon, or has it gone out the window with the de-emphasis of RGB on the camera?

 

[I Bloom]

what would be very cool - and I don't know if it is possible - is if you could cut in RT with the wrappers - but when it is time to render the timeline - you click a button in FCP and that "toggles" the QT codec to ultra-high-quality (2K debayer) - or toggels to a different QT codec (which is ultra-high-quality 2K) - that would be very cool -

Unfortunately that would require some participation from Apple, which so far I don't see any. The current three wrappers we have, are only there because there is no hook in quicktime that would allow you to communicate what quality you want to view the file in, seems like a pretty simple programming task, one or two new member functions and an addition to the UI. Apple doesn't seem to be jumping on it.

I'm thinking we could maybe trick FCP into switching between wrappers. It might not be a pulldown menu, but it might be pretty quick and painless.

Ian

 

[Scott M]

Yes, quality improvements are coming to the QuickTime codec. I call it high quality, but not yet ultra-high quality

Good deal, thanks for the info!

MrGlory: paul does not work for RED or Apple. He is giving out incorrect information.

Understood, won't reference that again.

what would be very cool - and I don't know if it is possible - is if you could cut in RT with the wrappers - but when it is time to render the timeline - you click a button in FCP and that "toggles" the QT codec to ultra-high-quality (2K debayer) - or toggels to a different QT codec (which is ultra-high-quality 2K) - that would be very cool -

Indeed, I've been impressed with the quality of the current wrappers, but a process like you suggest would be a pretty sweet workflow.

I'm thinking we could maybe trick FCP into switching between wrappers. It might not be a pulldown menu, but it might be pretty quick and painless.

This is what I figured would be the process we could manipulate when the "higher quality" wrappers are designed.

 

[Mark L. Pederson]

Unfortunately that would require some participation from Apple, which so far I don't see any.

just because you don't see it - doesn't mean forces are not at work ...

 

[Chris Kenny]

Unfortunately that would require some participation from Apple, which so far I don't see any. The current three wrappers we have, are only there because there is no hook in quicktime that would allow you to communicate what quality you want to view the file in, seems like a pretty simple programming task, one or two new member functions and an addition to the UI. Apple doesn't seem to be jumping on it.

Even if Apple never supported this stuff officially, the same functionality could exist with an only slightly more awkward UI. Instead of selecting your quality right in Final Cut, Red could have a utility that you could just drop a bunch of exist QuickTime proxies on to change their settings. Take some low-quality proxies and edit with them, turn them into high-quality proxies (this is presumably just a matter of changing a few bytes in their headers), change your Final Cut sequence settings as appropriate, and render out to your delivery format.

 

[I Bloom]

Even if Apple never supported this stuff officially, the same functionality could exist with an only slightly more awkward UI. Instead of selecting your quality right in Final Cut, Red could have a utility that you could just drop a bunch of exist QuickTime proxies on to change their settings. Take some low-quality proxies and edit with them, turn them into high-quality proxies (this is presumably just a matter of changing a few bytes in their headers), change your Final Cut sequence settings as appropriate, and render out to your delivery format.

Actually you can do this today just by swapping files with the same name and reconnecting.

 

[Benjamin Rowland]

just because you don't see it - doesn't mean forces are not at work ...

I agree with Mark. Check out the Apple web site:
http://www.apple.com/finalcutstudio/action/?movie=red

Based on this clip on Apple's site, I'd say that forces are at work.

 

[I Bloom]

I agree with Mark. Check out the Apple web site:
http://www.apple.com/finalcutstudio/action/?movie=red

Based on this clip on Apple's site, I'd say that forces are at work.

That clip has been up since April. That's about 5 Red-years.

Ian

 

[Benjamin Rowland]

But it's still up.

 

[I Bloom]

But it's still up.

I think their going to do it, just at a glaciel pace in comparison to Red developement.

On my list for Apple:
Support for switching proxies on the fly in quicktime infrastructure.
Adaptive proxie switching in FCP
Quicktime gamma overhaul
4K support in FCP and Color (you can already make a 4000x4000 timeline. So the addressing space for a 4K (4096) or 4.5K 16:9 frame is already in place)

That plus a full quality quicktime codec from Red and it's showtime.

edit: sorry if this comes off sounding really negative. What has already been achieved is really awesome. Just a few more things to make 4K simple and widely available.

Ian

 

[Mark L. Pederson]

I think their going to do it, just at a glaciel pace in comparison to Red developement.

On my list for Apple:
Support for switching proxies on the fly in quicktime infrastructure.
Adaptive proxie switching in FCP
Quicktime gamma overhaul
4K support in FCP and Color (you can already make a 4000x4000 timeline. So the addressing space for a 4K (4096) or 4.5K 16:9 frame is already in place)

That plus a full quality quicktime codec from Red and it's showtime.

edit: sorry if this comes off sounding really negative. What has already been achieved is really awesome. Just a few more things to make 4K simple and widely available.

Ian

I'll take a new render engine - 100% CoreVideo please.

 

[I Bloom]

I'll take a new render engine - 100% CoreVideo please.

Why is that important to you Mark? Does that equal performance or quality in your mind?

 

[Mark L. Pederson]

Why is that important to you Mark? Does that equal performance or quality in your mind?

In my mind both. GPU technology is ... well ... the deal. If they don't do it now - they will regret it. Regardless, there are still issues in FCP and how it renders that drive me nuts - 10-bit RGB, etc. I will say, last build got lots of XML stuff nailed down. I do love FCP - IMO - I just think they need to feel some pressure - I fear they may be a bit too cocky about it's growth and success - not to worry - Adobe is gonna make 'em sit up and start coding faster after NAB 2008 -

 

[Curran Giddens]

4K support in FCP and Color (you can already make a 4000x4000 timeline. So the addressing space for a 4K (4096) or 4.5K 16:9 frame is already in place)

Actually you can do this today just by swapping files with the same name and reconnecting.

These are some of the tricks I will try using until things get sorted. Actually, I'm more of an FX/compositor, so my FCP editor will try these workarounds.