Clayton Burkhart
Forum Replies Created
-
Clearly the omission of so many aspects of pro editing is a subject of debate, but the lack of inclusion of Apple Color in any way shape or form without a doubt speaks volumes about where the boat is turning. The only way it could not be EOL is if they released a standalone version like Compressor and Motion at a later date.
Anyone who has done any pro grading at all, with control surfaces would say this is a strategy. There is no way professional grading could be done in a sophisticated manner for large scale projects with the new tools that are provided by FCPX. So glaring an emission in the post workflow would suggest “conspiracy” if that is how you want to put it.
-
[Stefan Buhrmester] ” This is the FCPX forum. There is nothing professional about it.
;-)”
LoL
-
[Chris Kenny] ” Doing it in the display pipeline would make no sense. It would produce entirely inaccurate color even for things like web deliverables.”
Exactly. Which is what I unfortunately discovered along the way in the course of my own productions, and why I no longer trust Apple to provide me with an accurate monitoring output solution. 🙂
-
You are speaking about theory. I am talking about implementation. The mistake you are making is assuming that Apple wants to strictly institute accuracy throughout the pipeline.
They do not. At the end of the day they want the image to look “good”. I can guarantee you that no matter how much you calibrate an iMac for instance, institute floating pt technology or colorysnc on that display it will never be accurate or even close.
Why? Because it has a ton of enhancing applied through the processor on the graphics card so that it will look snappy, colorful and great for watching a DVD with the kids. Exactly who the intended audience of FCPX is for.
The only way you can get an accurate signal is by pulling the source material before it hits that graphics card.
I do not chose the implementation of YUV through an i/o solution because it is somehow more accurate than RGB, I chose it because I want to be absolutely sure to avoid all that MSG which is going to be thrown into the recipe to supposedly enhance the flavors of my meal.
-
An example of the kind of problems I am speaking about which are not addressed merely by the advent of floating point technology and colorsync:
“DVI/HDMI connections are particularly problematic when they originate from a computer graphics card. Simply put, these graphics cards are built to make your image look pretty, not accurate. However, something broadcast specific with an HDMI or DVI output that bypasses the graphics card of the computer in question (ie is connected directly to the computer) likely would not be subject to these same limitations and then you would have significantly fewer concerns.”
-Bram Desmet from Flanders Scientific -
Well, then I guess it all comes down to how much you believe in the implementation of this new technology by Apple to deliver a clean signal through colorsync.
I suppose if you are like Apple, you believe that the need for i/o YUV is already a thing of the past and that is my answer to the OP’s original hypothesis.
-
[Chris Kenny] “assuming you have a good quality computer display that has been profiled for ColorSync.”
And that’s just the trouble. Who will be doing the profiling and with what?
I can show you 15 different products today (some of them very expensive) on the market for profiling in the long standing graphic arts industry and if you were to make a profile on the same monitor with each of these products, no two would be the same, and this is for an industry which has been using Colorsync for many years.
All colorsync does is try to insure a relatively stable pipeline through YOUR own system.
It has almost never in my experience been accurate against an external standard.
The system implemented by Apple up to this point is actually responsible for adding many flavors to video which are indeed not there in your original source file. This is the built in compensation which Apple is adding on top of your video signal.
Colorsync does not insure that your signal will be clean and free of these additional layers, it only says to your system that it will intrepet them. Ever seen what something looks like when it has been intrepeted 3 or 4 times?
What i/o YUV does is bypass those additional layers of compensation by pulling the source material before it hits them.
So perhaps floating point technology will prove accurate enough to navigate that internal labryinth, eventually.
In the meantime I will stick with my FSI monitor and YUV.
-
[Chris Kenny] “Anything that can be represented in YUV can be represented in RGB. There’s no quality penalty for conversion if you do so in a sufficiently precise color space… and FCP X’s engine uses high-precision floating-point processing. You know what other app processes everything in a linear floating-point RGB color space? DaVinci Resolve. Would you like to argue that’s also not capable of accurate color output? Because my experience screening stuff I’ve graded with it in DI theaters says otherwise.
YUV, in the modern world, is best thought of as an internal implementation detail of some deliverable formats. With the precision of floating point, there’s no reason it needs to have anything in particular to do with how processing actually occurs.”
If this was actually true then of course you would have no need for expensive i/o cards. You could simply hook up your expensive grading screen by way of thunderbolt or DVI and off you go with Colorsync.
In which case Apple would be entirely justified in not having to provide that i/o connectivity which everyone is complaining is missing.
-
B
[Chris Kenny] “This makes no sense. There is no technical reason why using ColorSync for on-screen display precludes raw output through a video interface.”
No, what makes no sense is Colorsync for video output, because Colorsync is an RGB system which an I/O system bypasses.
So if you expect to actually USE Colorsync for video, that by it’s very nature precludes YUV.
This does not mean of course that you cannot HAVE video output at the same time, it only means that Colorsync in reality will have little or no relation to your true YUV video image.
The reason that I have pointed this out is to show that Apple has almost exclusively concerned itself with the individual who creates WEB content (which is RGB), not the video professional who creates for television, film, etc. (which is YUV).
I see this error all the time by people who actually believe that if they calibrate their screen with a puck for all their photoshop style applications they will actually be getting a calibrated video monitor for color correction and grading.
-
Colorsync for FCPX precludes any notion of i/o or independent monitoring.
It is an RGB based application of the software and would not take into account that i/o solutions are meant to completely bypass the very same graphics card which implements that calibrated workflow.
Clearly with it’s integration Apple assumes that it’s public is interested in computer screen viewing (read iMac), not professional monitoring, which is YUV.