FORUMS: list search recent posts

FCP-X HW I/O-support: a hypothesis

COW Forums : Apple Final Cut Pro X Debates

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Bernhard Grininger
FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 10:19:38 am

Hello,

I thought about the issue that FCP-X is currently not able to connect to
professional I/O-HW:

- FCP-X based on the new A/V-Foundation.
- Since OSX 10.6 doesn't have the A/V-Foundation, FCP-X needs to be an
insulated island of A/V-Foundation inside a quicktime ecosystem.
- Part of this ecosystem are the i/o components, the drivers from the hw-vendors are using.

That means (hypothetical):
- as soon as Lion is available and introducing the A/V-Foundation to OSX,
we could immediately expect broad support of professional I/O-HW
- without Lion there will be no direct FCP-X hw-support at all!
- another implication is, that we could expect native support of XDCamEX
and RedcodeRAW footage - without the requirement for quicktime rewrapping

Best regards,
Bernhard


PS:
also thought about SoundtrackPro:
There is a huge unknown in the equation no-one considered so far:
Logic Studio.
What will be the future of it? Does it use the quicktime framework too?
If yes, Logic needs also to be renewed. Will STP also be renewed alongside?


Return to posts index

Peter Blumenstock
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 10:22:29 am

So... why would they release FCP X now then. With Lion available next month.The four weeks hardly make a difference. And if if that was the case any sensible company would simply say that that's the case. There is no reason to keep it quiet. Think about it. It isn't coming, It never will. Move on.


Return to posts index

Jean-Fran├žois Robichaud
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 7:29:03 pm

"So... why would they release FCP X now then. With Lion available next month.The four weeks hardly make a difference."

Then again why not? FCP X works today as a standalone application. There doesn't seem to be much reason to wait before release. People who want to can use it now, and it works very well as standalone application, as long as you have a simple workflow. If 3rd-party hardware requires Lion, then it still gives people the chance to become familiar with the software.

Apple has got to have the worst transparency issues in the business. I don't have a crystal ball so I don't know what are their plans for FCP X, but I do have an hunch as to what they have in STORE: App Store purchases for extra features; for 3rd-party tools, that's a 30% cut for Apple, if there's no way to bypass the store. Why did you think they went all App Store with the release?


Return to posts index


Peter Blumenstock
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 8:12:42 pm

They went App Store because it is an app that doesn't require volume licensing or larger deployment because it simply will not be used by any professional facility but by prosumers.


Return to posts index

Steve Connor
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 10:24:13 am

If it was that simple they would have waited for Lion before they released or they would make that information public. It would be great if you are right though

Steve Connor
Adrenalin Television

Have you tried "Search Posts"? Enlightenment may be there.


Return to posts index

Michael Aranyshev
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 11:12:56 am

Well iPad and iPhone don't have either PCI slots or FireWire so why to write the code supporting Video I/O?


Return to posts index


Clayton Burkhart
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 12:09:57 pm

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.


Return to posts index

Chris Kenny
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 2:21:32 pm

[Clayton Burkhart] "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."


This makes no sense. There is no technical reason why using ColorSync for on-screen display precludes raw output through a video interface.

--
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.


Return to posts index

Clayton Burkhart
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 2:47:58 pm

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.


Return to posts index


Chris Kenny
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 3:05:53 pm

[Clayton Burkhart] "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.
"


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.

--
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.


Return to posts index

Clayton Burkhart
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 3:24:00 pm

[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.


Return to posts index

Chris Kenny
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 3:32:37 pm

[Clayton Burkhart] "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 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."


There are two issues with that currently. First, OS X doesn't provide 10-bit output from GPUs. Secondly, many GPUs can't natively sync at some of the refresh rates required for video.

But there are potential solutions to for both of these problems visible in the future. The requirement to use special hardware just to perform video monitoring is something that could very well go away in the next five years. FCP X's ColorSync support could probably eliminate it for a significant fraction of users today. Mind you, I haven't done tests yet, but theoretically a video I/O interface and an external broadcast monitor should no longer be necessary just to get generally accurate color in FCP X, assuming you have a good quality computer display that has been profiled for ColorSync.

--
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.


Return to posts index


Clayton Burkhart
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 4:08:44 pm

[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.


Return to posts index

Chris Kenny
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 4:32:04 pm

[Clayton Burkhart] "And that's just the trouble. Who will be doing the profiling and with what?

I can show you 15 different products today 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."


This problem is no easier to solve with respect to ColorSync profiling than with respect to calibrating broadcast displays. The same underlying technical issues are there. And actually, this whole problem is a lot easier for video than for graphic arts, because dealing with print and RGB/CMYK conversions is much, much harder. (CMYK really can represent things that fundamentally can't be represented in RGB, and the way ink on paper behaves in terms of color mixing is radically different from the way RGB color works.)

[Clayton Burkhart] "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?"

That doesn't really make sense. To provide accurate color, all display pipelines have to map between numerical values in an incoming signal, and the physical characteristics of the display. Simple broadcast monitors do this with a fixed color matrix that can be tuned with some relatively crude controls. More advanced displays or display pipelines (the kind of systems you use for digital cinema) use LUTs. A LUT can be applied either by dedicated hardware the video signal flows through, by an engine in the display, or by the software in the host system. This is all ColorSync is really doing: it's applying a LUT to the image going to your computer display. There isn't really any "extra" color conversion here vs. what happens with LUT-based external monitoring.

People have tuned video monitoring into this dark and scary thing that requires all sorts of special hardware and magical incantations. And it sort of was, when you were working with digital data, but what mattered was an analog signal on an analog display. These days, though, it's all just digital pixel data from end to end.

--
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.


Return to posts index

Clayton Burkhart
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 4:52:51 pm

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.


Return to posts index


Chris Kenny
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 5:07:09 pm

[Clayton Burkhart] "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."

Again, the use of linear floating point RGB processing does not in any way imply that YUV output through video I/O interfaces is not possible (once support for such hardware is added). In the digital cinema world, YUV output from software that works in RGB is extremely common. See, for example, essentially every DVD or Blu-ray you've ever watched of a movie that went through a DI pipeline. Video I/O devices already routinely let you select either RGB or YUV output regardless of the underlying footage format.

In the digital world, RGB and 4:4:4 YUV are just two ways of encoding exactly the same pixel data. 4:2:2 and 4:2:0 YUV are the same thing with some color resolution data discarded. There aren't colors that YUV can represent that RGB can't, or anything like that. In point of fact, all displays are RGB devices, so YUV is always converted to RGB before display anyway. If YUV could encode something that couldn't be represented in RGB, you could literally never display it.

--
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.


Return to posts index

Clayton Burkhart
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 5:28:55 pm

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


Return to posts index

Chris Kenny
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 5:43:07 pm

[Clayton Burkhart] "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"


Um... Flanders Scientific makes some great monitors, but that statement is just not true. It is simply not the case that graphics cards arbitrarily change RGB pixel data before passing it to the display. The traditional problems for monitoring video on computer displays, with respect to color, have been that a) the operating system messes with image data on its way to the display (I think this is where the confusion in the above quote comes from), and b) computer monitors don't natively display Rec. 709 color. Adding ColorSync support fixes the former problem by taking control of the precise mechanism in the OS that was previously changing image data in undesired ways, and fixes the latter by mapping between Rec. 709 and the display's own native color space. (And these days the display's native color space, if it's not a cheap piece of crap, is larger than Rec. 709, so this mapping is lossless.)

--
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.


Return to posts index


Clayton Burkhart
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 6:00:16 pm

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.


Return to posts index

Chris Kenny
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 6:21:10 pm

[Clayton Burkhart] "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"."


FCP X can do automatic color enhancement, but there's an explicit option for it (which is turned off by default), and the enhancement is obviously applied to the footage itself, not in the display pipeline. Doing it in the display pipeline would make no sense. It would produce entirely inaccurate color even for things like web deliverables.

--
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.


Return to posts index

Clayton Burkhart
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 6:34:45 pm

[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. :-)


Return to posts index

Chris Kenny
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 6:40:57 pm

[Clayton Burkhart] "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 output solution. :-)"

Please be very specific about what you're talking about here. Because you're claiming Apple has done something that makes zero sense for them to have done. What specific tests have you performed that lead you to believe FCP X deliberately 'enhances' video in the display pipeline?

--
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.


Return to posts index

Bernhard Grininger
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 4:11:19 pm

Hello,

Digital Cinema is and was always RGB.
Also PremierePro, Motion (also the old one!!!) and AfterFX uses RGB rendering.
And Smoke works only in uncompressed 10bit RGB at all!

AJA needed to implement a WYSIWYG (WhatYouSeeIsWhatYouGet) method
to get video properly out of PP. The same with Matrox. So RGB is not that odd.

When feeding our hp dreamcolor we send out a HDSDI signal to a BMD HDLink Display Port,
to convert the YCbCr (not YUV bdw) signal into high-quality RGB.

Nothing here convinced me there will be no possibility for proper high-quality video output in FCP-X!
And if Apple tends to introduce also a new paradigm to video monitoring at delivering
high quality DisplayPort signals up to 16bit color deph per channel, than it's more than ok.
http://en.wikipedia.org/wiki/DisplayPort

Personally I would expect a very high quality output class delivered with AVFoundation
with the lion update.

Best regards,
Bernhard


Return to posts index

Colin McFadden
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 2:36:59 pm

This is relatively accurate.



Return to posts index

Chad Wilmoth
Re: FCP-X HW I/O-support: a hypothesis
on Jun 23, 2011 at 5:09:35 pm

Since we're in Hypothesis Land...
apple-television-set-rumors-revived-to-launch-in-2011

Maybe above rumored Apple branded television display has a Thunderbolt port and built-in Colorsync???

Chad Wilmoth
Visual Reality Studios
http://www.visual-reality-studios.com


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]