Apple Final Cut Pro Legacy Forum
444 Codec & Video Processing
444 Codec & Video Processing
by Rivai Chen on Apr 1, 2010 at 9:52:27 pm

Hi guys

I have been wondering about this for a while.

What is the relation or amount of contribution between 444 codec (prores,cineform, etc) and video processing limitation in FCP ? There's no way that we can set 444 color space in FCP. You either have YUV 10bit high precision or RGB 8 bit.

So let's you are working with 444 codec in the timeline and you need to render out to 444 codec or DPX (gluetools). Wont it affect the quality ? or not ?

Anybody can shed some lights into this ?

Thanks


Re: 444 Codec & Video Processing
by Jerry Hofmann on Apr 1, 2010 at 10:01:57 pm

ProRes 4444 is 10bit YUV... it's just that it has more color information per pixel than say 4:2:2 has. ProRes 4:2:2 is also 10bit YUV, but with less color information per pixel... does this clear it up for you?

Jerry

Apple Certified Trainer, Producer, Writer, Director Editor, Gun for Hire and other things. I ski.

8-Core 3.0 Intel Mac Pro, Dual 2 gig G5, AJA Kona SD, AJA Kona 2, Huge Systems Array UL3D, AJA Io HD, 17" MBP, Matrox MXO2 with MAX Cinema Displays


Re: 444 Codec & Video Processing
by Rivai Chen on Apr 1, 2010 at 10:10:02 pm

Hi Jerry

Thanks for clearing up the prores stuff. But the question is about 444 RGB codec say Cineform 444 or animation, where you are not working in YUV space. How does this affect the final render. FCP cant handle 444 RGB 10bit. So if you have such codec and would like to maintain until final render (say to DPX), is this impossible ?

If not, having AJA or blackmagic hardware, does it help at all ?

Thanks


Re: 444 Codec & Video Processing
by Jerry Hofmann on Apr 1, 2010 at 10:25:26 pm

I think the 444 codecs will work with FCP. You can select sequences to render in RGB. Doesn't have to be YUV.

Look in the Sequence settings, it's there in the Video processing tab. Would this solve the problem you think you might have?

Jerry

Apple Certified Trainer, Producer, Writer, Director Editor, Gun for Hire and other things. I ski.

8-Core 3.0 Intel Mac Pro, Dual 2 gig G5, AJA Kona SD, AJA Kona 2, Huge Systems Array UL3D, AJA Io HD, 17" MBP, Matrox MXO2 with MAX Cinema Displays


Re: 444 Codec & Video Processing
by Rivai Chen on Apr 1, 2010 at 10:29:48 pm

Yeah exactly those that bothers me. RGB 8 bit from video processing tab! 10 bit is the minimum that should have. I'm using version 6, not sure if FCP 7 is going to be different. I assume not.


Re: 444 Codec & Video Processing
by Jerry Hofmann on Apr 1, 2010 at 10:35:15 pm

It is the same in FCP 7...

Jerry

Apple Certified Trainer, Producer, Writer, Director Editor, Gun for Hire and other things. I ski.

8-Core 3.0 Intel Mac Pro, Dual 2 gig G5, AJA Kona SD, AJA Kona 2, Huge Systems Array UL3D, AJA Io HD, 17" MBP, Matrox MXO2 with MAX Cinema Displays


Re: 444 Codec & Video Processing
by Michael Gissing on Apr 1, 2010 at 10:58:33 pm


Except version 7 gives you the ProRes 4444 codec


Re: 444 Codec & Video Processing
by Rivai Chen on Apr 1, 2010 at 11:01:44 pm

Is this YUV or RGB ?


Re: 444 Codec & Video Processing
by Jerry Hofmann on Apr 2, 2010 at 12:23:03 am

ProRes is a YUV codec.

Jerry

Apple Certified Trainer, Producer, Writer, Director Editor, Gun for Hire and other things. I ski.

8-Core 3.0 Intel Mac Pro, Dual 2 gig G5, AJA Kona SD, AJA Kona 2, Huge Systems Array UL3D, AJA Io HD, 17" MBP, Matrox MXO2 with MAX Cinema Displays


Re: 444 Codec & Video Processing
by gary adcock on Apr 2, 2010 at 12:25:00 am

[Rivai Chen] "There's no way that we can set 444 color space in FCP. You either have YUV 10bit high precision or RGB 8 bit. "

Not true, with hardware having Dual Link support and a little concentrated effort, you can do 444 as either Y'Cb'Cr' or RGB . It is not a simply choosing a setting, you have to setup and tune the workflow much like you would on any of the big iron finishing suites. (Avid and Autodesk both use OEM Kona cards for output on their high end hardware)

"So let's you are working with 444 codec in the timeline and you need to render out to 444 codec or DPX (gluetools). Wont it affect the quality ? or not ?"

That answer would depend on what the original content started- DPX from a DDR or Filmscan? or something you whipped up in Motion. For the record the ProRes 4444 codec supports both RGB and Y"Cb'Cr' Video color spaces at up to 12 bit with alpha channel support up to 16bit.

FCP does not have the ability to correctly create DPX frames by itslself- and understand Color does not just pop DPX from random timelines out correctly and never has.
Other applications will be doing the creation and output for this type of workflow Correct?
why else would you do via the DPX way then?

Can it be done, Yes.
I work on systems everyday that can handle the task, but it is not cheap and only 'kinda" easy after the 4th or 5th time you change hardware configs. Its much easier to do if you integrate it into an established workflow, not as good as being a standalone player when you are outputting 444 but there are tools.

gary adcock
Studio37
HD & Film Consultation
Post and Production Workflows for the Digitally Inclined
Chicago, IL

http://blogs.creativecow.net/24640




Re: 444 Codec & Video Processing
by Rivai Chen on Apr 2, 2010 at 3:57:16 am

Hi gary

I dont understand what you're really saying. FCP can only set to high-precision YUV or RGB 8 bit. That part is true but you claimed it as not true.

If via hardware, i know AJA KONA 3 delivers RGB 10bit codec. For smoke, we are working with internal dpx file. But this is FCP that we're discussing here. i find there's no way to have such setting RGB 10bit even if you have the AJA hardware.

So what suggested hardware and setting are you proposing in Final Cut ?

The original content is comes from RED 12bit linear and it's RAW. If you convert the RAW at highend format say Cineform. I would like very much to maintain it until the final export to DPX via gluetools.

Here's the answer i just got from David Taylor Cineform :
The underlying answer is a bit complicated, and I’d rather not write an essay, but FCP can render in deep precision if the underlying (de)compressor supports a certain floating-point 444 YUV pixel format called R4FL. As you may know you can convert losslessly between YUV 444 and RGB if you use floating-point math. So FCP requests floating-point YUV 444 from CineForm compression (even though we store RGB), so we perform the conversion from our 12-bit RGB format to floating-point YUV before handing the requested data to FCP. So there is some color transformation going on, but it uses floating point math, and that is how FCP maintains deep precision. The destination for the floating-point 444 YUV must of course be able to handle that format as its source (which CineForm does). If any link in the chain can’t handle FP then the whole chain drops back to 8 bit. In our experience few workflows through FCP are greater than 8 bits, but CineForm maintains deep precision throughout.



Rivai


Re: 444 Codec & Video Processing
by gary adcock on Apr 2, 2010 at 7:17:03 pm

[Rivai Chen] "FCP can only set to high-precision YUV or RGB 8 bit."

There is nothing that I can find published by Apple that say that FCP is limited to 8bit color, many of the filters and effects -yes- but not the processing. As of FCP 7's release RGB material can access 32-bit float space for rendering. (do a search for 10bit RGB in FCP help)

While a single link HDSDI signal is limited to RGB8 bit, a Dual Link signal easily supports up to 12 bit log as RGB so I do not understand where that thinking is from. Maybe its because the RT engine in FCP defaults to 8bit for rendering as do most of the filters and effect.

If you are working in 10bit RGB RT is turned off by default, there is a reason when there is no realtime processing any bit depth in the original is handled without issue.

"this is FCP that we're discussing here. i find there's no way to have such setting RGB 10bit even if you have the AJA hardware."
See above.
Here in lies my last point in the previous post- for this type of highend workflow FCP is traditionally only part of the picture, and that is why there are specific easy setups for aja's 10bit log codec.


"The original content is comes from RED 12bit linear and it's RAW. "
Its only 12bit if you handle it correctly- that would assume that you are converting to DPX within the RED software or using one of the highend tools that support R3D output at that quality.

"I would like very much to maintain it until the final export to DPX via gluetools"
Why not convert your content to DPX to start with?

" If any link in the chain can’t handle FP then the whole chain drops back to 8 bit. In our experience few workflows through FCP are greater than 8 bits, "

I know David and he is one smart guy and in Cineform they have the single best cross-platform codec available. He is correct when he says that few have workflows that are above 8bit.

In this quote he never says, as you imply, that it cannot be done.

Many of the FCP filters and effects render in 8bit and the RT engine for the most part working in 8bit, but within ProRes it does maintain 10bit processing of YUV. Unfortunately Apple does not allow other codecs (like Cineform or Sheer) that privilege. Turning off the RT engine does allow you the ability to handle the content at the native bit depth with less interference.

Working in 10bit RGB within FCP is just not as common as people think it is and it takes diligence throughout the process, thats why the highend has always been about the proprietary tools and processing and workflow.







gary adcock
Studio37
HD & Film Consultation
Post and Production Workflows for the Digitally Inclined
Chicago, IL

http://blogs.creativecow.net/24640




Re: 444 Codec & Video Processing
by Uli Kunkel on Jun 9, 2010 at 5:00:26 pm

Gary,

The documentation in FCP 7's manual on 10 bit RGB processing is vague and non-specific from what I can tell. Everything you've said looks to be true, but I'm still looking for verification on a couple of things.

- If an FCP Timeline set up for ProRes 444 is set to "Always Render RGB," will I still be outputting 10 bit RGB color through my Kona card onto SR?

- Will simple dissolves render to 10 bit RGB in the timeline, or will they only be 8 bit?

Somewhat unrelated question...

- I am rendering Red footage from Color to ProRes 4444 for a Davinci 2K color correction off of SR tape. If my FCP timeline is relinked to the Red _H Proxies and sent to Color, will Color be accessing the same color space (12 bit RGB) as it would if I had used the "Native" workflow from the Red FCP whitepaper?

Thanks for your advice.

Uli


Re: 444 Codec & Video Processing
by Rafael Amador on Apr 3, 2010 at 8:54:41 am

Hi Rivai,
There is nothing published by Apple, neither inside FC, that leads to think that 10b RGB rendering is possible.
In his post, the guy of CineForm, basically says that they are unable. They have to convert and render in YUV.
Last year, after similar discussion, I asked Graeme Nattress about. Also Owen Smithyman of BitJazz (Sheer codec).
Nobody even considered the possibility of FC rendering in 10b.
Owen proved that was possible to cut and export without rendering, keeping the 10b RGB.
Personally, I don't understand any piece of software hiding what should be his best highlight.
Cheers,
Rafael
PS: 444 is not a color space but a "mapping/sampling pattern" (422, 420, 411).
Tolking about 444RGB makes no much sense as long as there are no 422/420/411 RGB formats.
Down sampling in RGB is not possible.


www.nagavideo.com


Re: 444 Codec & Video Processing
by Rivai Chen on Apr 3, 2010 at 4:45:48 pm

Hi Rafael,

Yeah agree, the most important note from David Taylor is the calculation between YUV and RGB in FCP is done thru floating point calculation. That's the key. As long your incoming and destination format can handle this, it should be alright. This is ensuring enough. I still have no idea why this is not documented. Sometimes, we just need to ask developers about the factual data. There's other misleading or half complete information spreading around that QT for windows is always 8 bit and designed that way which of course not the case. I heard such false assumption from other people who supposed to be pro. The point is sometimes we have to do a lot of check and asking around to seek such information, it will be so much easier it's documented properly.

Anyway, at least i got the answer :)

Rivai


Re: 444 Codec & Video Processing
by gary adcock on Apr 3, 2010 at 7:27:07 pm

[Rivai Chen] "There's other misleading or half complete information spreading around that QT for windows is always 8 bit and designed that way which of course not the case"


The QT player application is 8bit on both mac and windows. The files may not be, but the base app is.



gary adcock
Studio37
HD & Film Consultation
Post and Production Workflows for the Digitally Inclined
Chicago, IL

http://blogs.creativecow.net/24640




Re: 444 Codec & Video Processing
by Rivai Chen on Apr 4, 2010 at 1:53:29 am

Which is exactly half complete and people forget there's a deep pixel precision.


Re: 444 Codec & Video Processing
by Rafael Amador on Apr 4, 2010 at 3:21:20 am

[Rivai Chen] "Yeah agree, the most important note from David Taylor is the calculation between YUV and RGB in FCP is done thru floating point calculation. That's the key. As long your incoming and destination format can handle this, it should be alright. "
No, this is not alright, but it seems that is the only chance.
You don't go RGB>YUV>RGB, when you can stay in RGB all the way through.

[Rivai Chen] "I still have no idea why this is not documented. Sometimes, we just need to ask developers about the factual data. There's other misleading or half complete information spreading around that QT for windows is always 8 bit and designed that way which of course not the case. I heard such false assumption from other people who supposed to be pro."
Analog was more difficult to manage, but everything was standard. Everything was in the books.
In NL digital, everything (Applications, codecs) are proprietary. They do whatever they want inside their software and they don't have to document it.
Professional Third Part developers complains that they are absolutely lost about many internal processes in FC.
Some says that Apple do not disclose documents because there are too may internal tricks and substandard processes used to overcome the FC and QT shortcomings.
rafael




www.nagavideo.com


Re: 444 Codec & Video Processing
by Eliot Piltz on Jul 21, 2010 at 8:01:20 pm

Rather than start a new topic, I have a related question. Can someone advise me on the render settings for a final output of a show I'm finishing? It was edited at ProRes422HQ, graded in Apple Color and rendered out in 16-bit ProRes4444. Now back in FCP, there are many titles, subtitles, transitions, speed changes etc. that have to be rendered. Should I set the video processing to high-precision YUV or RGB? This is going to HDCAM SR for festivals, but of course should be broadcast safe, as we only want to make one master. Also, is there any need to change the ProRes gamma settings to None, or will "Automatic" not mess anything up?

Thanks very much!
Eliot

Mac Pro 2.66 GHz 8-core (4,1); 12 GB Memory
ATI Radeon HD 4870 (512 MB); ACD 30" and 24" dual display
Sony BVM-L230, Blackmagic Intensity Pro, Drobo 8-bay 16 TB
OS X 10.6.2, FCP 7.0.2


Re: 444 Codec & Video Processing
by Johnathan Throbins on Jul 26, 2014 at 4:25:52 am

So what are you guys using to online?
It smoke the only answer if you want to retain a 10+bit RGB workflow from Resolve? Do you have to online in resolve?

In particular when I deliver a feature sometimes the original editor wants to add the titles or someone will crop from 16:9 to 2.39 for a DCP and render that, I'm worried they're bumping it down to 8bit.

Also Resolve isn't good with the editing, even in resolve 11 I don't love it. I'd rather go back to FCP 7 but that's not a great option. Is there an affordable online editing tool? Is smoke the cheapest good option?


Thanks.





© CreativeCOW.net