Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Final Cut Pro X Released

Tim Morten said:
The actual output from your graphics card is the monitor refresh rate you select in the driver. The number of unique frames displayed per second is up to the software you are using.
Click to expand...

Yes, but if the GPU can drive the screen at a refresh rate that matches the video frame rate (or is an even multiple of it), you get entirely accurate motion cadence. Otherwise the display pipeline is implicitly adding pulldown. (Mind you, most computer displays won't sync up at anything but 60 Hz; but TVs or video projectors hooked up via DVI to HDMI adaptors often will.)

Bruce Allen said:
But I haven't seen any evidence for this actually going on under the hood in FCP X.
Click to expand...

Apple claims it has a "ColorSync-managed color pipeline". This would be pretty hilariously misleading if it were just doing quick and dirty gamma correction. FCP 7 did quick and dirty gamma correction, and Apple never advertised it like that.

Of course all of the QT/ColorSync behavior is rather badly documented, so who really knows.

Andrae Palmer said:
I'm still trying to grasp the differences between ICC profiles and 3D LUTs
Click to expand...

ICC profile conversion can produce the same results as 3D LUT conversion. In fact, I believe Light Illusion has an application that can generate an ICC profile based on a 3D LUT.
 
Chris Kenny said:
ICC profile conversion can produce the same results as 3D LUT conversion. In fact, I believe Light Illusion has an application that can generate an ICC profile based on a 3D LUT.
Click to expand...
Wow this thread has grown since I left it :)
Thanks Chris for the (above) reply. The last few have been very educational and helpful :)

Sure beats the first 100 + pages.
 
Chris Kenny said:
Of course all of the QT/ColorSync behavior is rather badly documented, so who really knows..
Click to expand...

I'm amazed no one has written about their experience with this. Since documentation is so terrible... some user reports right now would be confirmation of the workflow.
 
Chris Kenny said:
Yes, but if the GPU can drive the screen at a refresh rate that matches the video frame rate (or is an even multiple of it), you get entirely accurate motion cadence. Otherwise the display pipeline is implicitly adding pulldown. (Mind you, most computer displays won't sync up at anything but 60 Hz; but TVs or video projectors hooked up via DVI to HDMI adaptors often will.)
Click to expand...

Chris, you are out of your depth.

The GPU doesn't drive the screen refresh: the display controller does. These are normally two different pieces of silicon, and are conceptually distinct even when they are not.

The GPU can be programmed to wait for vsync, but it is common for graphics applications (including editing software) to output at a framerate other than the refresh (many folks set their refresh high to reduce eyestrain in office environments).

Computer monitors have broadly supported multi-sync since the late 1980's. NEC even had a line of CRT monitors sold under the brand name "Multisync". How low or high a specific monitor will sync depends on the manufacturer. Pixel persistence or response time are important to note as too long a value can cause smearing.

When the GPU outputs frames at the same frequency that the display controller is driving the monitor at, every frame is unique. When less frames are output, some frames are repeated. Which frames get repeated depend entirely on the software you are using. Most professional editing packages output with a regular cadence that matches standard pull-down, where such a standard exists. When a standard doesn't exist (such as displaying 24 unique frames at 70hz), they presumably make their own non-standard decisions. Note that it is possible to have different refresh rates on individual monitors in a multiple monitor setup.

Does any of this really have bearing on Andrae's original question? Not much... I put it forth for the sake of accuracy, given the seeming misunderstandings indicated by Chris' posts.

Cheers,
Tim
 
Tim Morten said:
Chris, you are out of your depth.

The GPU doesn't drive the screen refresh: the display controller does. These are normally two different pieces of silicon, and are conceptually distinct even when they are not.

The GPU can be programmed to wait for vsync, but it is common for graphics applications (including editing software) to output at a framerate other than the refresh (many folks set their refresh high to reduce eyestrain in office environments).

Computer monitors have broadly supported multi-sync since the late 1980's. NEC even had a line of CRT monitors sold under the brand name "Multisync". How low or high a specific monitor will sync depends on the manufacturer. Pixel persistence or response time are important to note as too long a value can cause smearing.
Click to expand...

Nothing you're saying has any particular relationship to how modern GPUs interact with modern LCDs and projectors over digital interfaces. Most desktop LCD displays use a fixed 60 Hz refresh. Eyestrain is no longer relevant to refresh rate because LCDs decouple flicker (which is now a consequence of backlight frequency) from image refresh. Control over physical refresh rates now resides in the display itself. Displays that support e.g. 24 Hz signals will generally change their physical refresh rate to provide accurate motion cadence for such signals.
 
Chris Kenny said:
Nothing you're saying has any particular relationship to how modern GPUs interact with modern LCDs and projectors over digital interfaces. Most desktop LCD displays use a fixed 60 Hz refresh. Eyestrain is no longer relevant to refresh rate because LCDs decouple flicker (which is now a consequence of backlight frequency) from image refresh. Control over physical refresh rates now resides in the display itself. Displays that support e.g. 24 Hz signals will generally change their physical refresh rate to provide accurate motion cadence for such signals.
Click to expand...

Desktop LCD hardware is not in any way limited to 60hz. The response time of the panel equates to how quickly the display transistors can reset to display new data. 60hz implies a response time of 16ms. MANY desktop LCD displays support response times in the 6-12ms range.

If you can provide a credible reference for your claim that panels force refresh to 60hz, please do. Otherwise, my conclusion remains that you are out of your depth.

Thanks,
Tim

PS - You're still incorrectly using the term GPU to imply that it drives the display, which it does not. The GPU fills the frame buffer, from which the display controller drives the display. The GPU is one component on a graphics card, not a synonym for the graphics card itself.
 
It seems professionals are having a very hard time understanding this ColorSync implementation. It's not mentioned in the help docu. I just emailed Larry Jordan about it and he's trying to find the answer himself. Alphons Brookson at IT Enquirer reports that it uses a matrix based profile, "The fact that you need a matrix based profile to see colours the way they’re supposed to be, is stated nowhere in the Help file, and you’re also not warned in advance." --- http://photo.it-enquirer.com/2011/0...ss&utm_campaign=review-final-cut-pro-x-part-2

Now Apple Color could use 3D Luts. If Colorsync in FCPX only supports 3x3 matrix ICC profile then this would be a serious downgrade in accuracy.
 
Andrae Palmer said:
It seems professionals are having a very hard time understanding this ColorSync implementation. It's not mentioned in the help docu. I just emailed Larry Jordan about it and he's trying to find the answer himself. Alphons Brookson at IT Enquirer reports that it uses a matrix based profile, "The fact that you need a matrix based profile to see colours the way they’re supposed to be, is stated nowhere in the Help file, and you’re also not warned in advance." --- http://photo.it-enquirer.com/2011/0...ss&utm_campaign=review-final-cut-pro-x-part-2

Now Apple Color could use 3D Luts. If Colorsync in FCPX only supports 3x3 matrix ICC profile then this would be a serious downgrade in accuracy.
Click to expand...

The main thing is:

Why the heck did Apple decide to do things in such a non-standard, undocumented way? If they are using 3D LUTs, great. Can we get some info on matrix size, etc? This is Final Cut *Pro* X after all.

This reminds me EXACTLY of their attitude with the hated Quicktime Gamma bug:

"It's not a bug, it's a feature! We manage video -> computer gamma for you automagically!"

If Apple don't feel like having a simple, well-documented system of 3D LUTs, I'd much prefer it if FCP X didn't touch a damn thing - leave me color values numerically identical please - and let me use a 3rd party 3D LUT system that I actually trust!

Bruce Allen
www.boacinema.com
 
Bruce,

Good point on the support/documentation issue! If it was Adobe Premiere Pro we'd have an answer right here on our message board. Anyone got email contact for the FCPX team or FCPX support? I've been googling trying to find a way to get more detailed information. I would just love to ask the Colorsync question. Hopefully Larry Jordan will get some feedback.


Paul Nordin said:
Andrae, I've got to commend you for doggedly pushing through the noise here in an attept to get down to the truth of the matter. Far too many "educated guesses" are at play. Thanks.
Click to expand...

Well I'm not on here trying to look smart... Chris Kenny made some claims about FCPX ColorSync that sounds wonderful. If he's right then we all can save a lot of money with this new workflow especially for web based content. I would love if Chris or anyone else could show me the way. i do have Final Cut Pro X installed on my Mac Pro and I'm genuinely curious to see how this Colorsync stuff would work. My thoughts on FCPX overall is that it's a bunch of marketing gimmick but hey that's not stopping me from digging into it.

By marketing gimmick I mean stuff like "background rendering"... if people really knew how this was implemented in FCPX they would realize it's crazy... doesn't make any sense whatsoever. It's hard for FCPX to background render your project when every time you start interacting with your timeline the background rendering stops. Every time you add a new filter, color correction the back ground rendering pauses, cancels and then restarts. How can FCPX know your final intent... so how can background rendering work? I guess it can work if you are doing nothing on your timeline but then again that's what we have now in Premiere Pro and FCP. I don't want my CPUs doing a bunch of unnecessary work, storing crap all over the place. A much better workflow is to finalize your clip and then send it to Adobe Media Encoder or Compressor... and then continue on with editing another sequence... that's the background rendering we are all accustomed to and it works.

If I'm wrong... show me the way... I'm here to learn.
 
RE: Background rendering

I don't know how you work, but I might work on a 10 minute segment on a 90 minute timeline for an entire day. FCP can background render all of the clips in the other 80 minutes while I am working. Is it not working that way for you? Is it necessary to segment a longer timeline to get it to work?
 
Andrae

RE ColorSync - um, why not just skip ColorSync, buy a DreamColor or Flanders monitor, calibrate it to 709 space - and use it with an editing system that isn't gamma-retarded (eg either Avid or Premiere)?

For what actual jobs would it be useful to you to have a half-baked poorly-documented color-conversion system trying to do things automatically without telling you what the hell is going on? Again, full real color management would be nice (although I wouldn't trade my Viewer window for it :) - but it sounds more and more like Quicktime's botched "automatic" gamma conversion - which would also have been great if it worked right, but Apple never really bothered to fix it.

RE background rendering - no, it's good! That's the point - if there are idle CPUs, they just speculatively render. Yes that means that if you change things they have to restart, but the point is that this should be invisible to you - the real trick is to make sure that this background rendering gets out of the way the moment you need those CPUs back for an active task. Even with grand central dispatch this is easier said than done.

Bruce Allen
www.boacinema.com
 
Tim Morten said:
Desktop LCD hardware is not in any way limited to 60hz. The response time of the panel equates to how quickly the display transistors can reset to display new data. 60hz implies a response time of 16ms. MANY desktop LCD displays support response times in the 6-12ms range.
Click to expand...

I am using "refresh rate" to mean the number of frames sent to the screen per second by the graphics hardware (this is basically all "refresh rate" is on modern digital systems; it has other implications on pre-digital systems), i.e. the thing you can select in operating system display configuration settings:

refresh_rate.png


You appear to be using it as a synonym for "response time", which is non-standard and is not what I was referring to.

Refresh rate and response time are not coupled to each other in any way. Old passive matrix LCDs, which had such egregious ghosting problems (i.e. poor response time) that you basically couldn't watch video on them, were generally 60 Hz devices, the same as modern desktop displays. They could display 60 unique frames a second... those frames just bled into each other really badly.

Tim Morten said:
Otherwise, my conclusion remains that you are out of your depth.
Click to expand...

It's entertaining to see someone so wrong act so patronizing.

Tim Morten said:
PS - You're still incorrectly using the term GPU to imply that it drives the display, which it does not. The GPU fills the frame buffer, from which the display controller drives the display. The GPU is one component on a graphics card, not a synonym for the graphics card itself.
Click to expand...

You are being obnoxiously pedantic. Using the term "GPU" to refer to the entire graphics card is extremely common.

Andrae Palmer said:
Chris Kenny made some claims about FCPX ColorSync that sounds wonderful.
Click to expand...

Before this goes too far off track here... I made some claims about what's technically feasible. I explicitly said I don't know if FCP X's use of ColorSync realizes these possibilities.
 
All I have to say about refresh rates is that I have had a 10bit-capable, 48hz-capable DreamColor monitor plugged into my iMac for several years.

And of course, unlike Windows, OS X only gives me the option to run it at 8bits and 60hz.

If Apple wanted to limit us to desktop video monitoring and actually cared about pros, you'd think they'd get on this.

Bruce Allen
www.boacinema.com
 
Go Adobe, answering tech Qs outside their own forums... Above and beyond... Big points.
 
Scott Crawley said:
RE: Background rendering

I don't know how you work, but I might work on a 10 minute segment on a 90 minute timeline for an entire day. FCP can background render all of the clips in the other 80 minutes while I am working. Is it not working that way for you? Is it necessary to segment a longer timeline to get it to work?
Click to expand...

How it's working right now in FCPX is if you scrub through your timeline background rendering pauses. If you add a new video effect background rendering stops and restarts from the beginning. You can set when the background rendering starts but it pauses for everything you are doing on the timeline. Your method of working is what anyone can currently do with Premiere Pro and FCP by utilizing Adobe Media Encoder or Compressor. Apple is trying to reinvent something... their way of implementing it doesn't make much sense... because it's not really background rendering if you can't use FCPX while rendering.


Bruce Allen said:
Andrae

RE ColorSync - um, why not just skip ColorSync, buy a DreamColor or Flanders monitor, calibrate it to 709 space - and use it with an editing system that isn't gamma-retarded (eg either Avid or Premiere)?

For what actual jobs would it be useful to you to have a half-baked poorly-documented color-conversion system trying to do things automatically without telling you what the hell is going on? Again, full real color management would be nice (although I wouldn't trade my Viewer window for it :) - but it sounds more and more like Quicktime's botched "automatic" gamma conversion - which would also have been great if it worked right, but Apple never really bothered to fix it.

RE background rendering - no, it's good! That's the point - if there are idle CPUs, they just speculatively render. Yes that means that if you change things they have to restart, but the point is that this should be invisible to you - the real trick is to make sure that this background rendering gets out of the way the moment you need those CPUs back for an active task. Even with grand central dispatch this is easier said than done.

Bruce Allen
www.boacinema.com
Click to expand...

I own a NIST Spectroradiometer calibrated Flanders Scientific LM-2461W. Flanders will calibrate these for free. I was just trying to open myself up to this new underwear editor revolution. :-) Regarding background rendering... the problem is that the background rendering in FCPX pauses even when you scrub through your timeline. If you are actively editing then it's pausing way too much. Actively editing means scrubbing, playing or browsing through clips.... basically interacting with your video clips. Now that doesn't make any sense. It's not really background rendering. It's waiting for FCPX to be idle so it can render.


Todd Kopriva said:
This page answers that question and points to various videos and white papers that go into more depth:
"Color management and color profiles"
Click to expand...

Thanks! That's why I've been telling everyone to switch to Premiere Pro... I was doing this way before FCPX was released.
 
Andrae Palmer said:
How it's working right now in FCPX is if you scrub through your timeline background rendering pauses. If you add a new video effect background rendering stops and restarts from the beginning. You can set when the background rendering starts but it pauses for everything you are doing on the timeline. Your method of working is what anyone can currently do with Premiere Pro and FCP by utilizing Adobe Media Encoder or Compressor. Apple is trying to reinvent something... their way of implementing it doesn't make much sense... because it's not really background rendering if you can't use FCPX while rendering.
Click to expand...

I don't think I understand why this is such a problem. If you close the Background Tasks window (so that you become unaware of the rendering process), the whole thing goes on its merry way and you are none the wiser. Your work doesn't slow down, and your rendering will eventually get done. My understanding is that rendering isn't actually "necessary" for editing but just improves the quality of the images somewhat and perhaps speeds some operations up a bit. But, maybe I am missing something?
 
Terry VerHaar said:
I don't think I understand why this is such a problem. If you close the Background Tasks window (so that you become unaware of the rendering process), the whole thing goes on its merry way and you are none the wiser. Your work doesn't slow down, and your rendering will eventually get done. My understanding is that rendering isn't actually "necessary" for editing but just improves the quality of the images somewhat and perhaps speeds some operations up a bit. But, maybe I am missing something?
Click to expand...

The problem is that it's not background rendering while you are editing. The process is paused while you are scrubbing, playing or trying out new effects. My issue with it is that it's not doing it's job. It's only background rendering when you are idle... basically not interacting with FCPX.
 
You must log in or register to reply here.
Back
Top