Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Creative Community Conversations FCP-X HW I/O-support: a hypothesis

  • Clayton Burkhart

    June 23, 2011 at 4:08 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.

  • Bernhard G.

    June 23, 2011 at 4:11 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.
    https://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

  • Chris Kenny

    June 23, 2011 at 4:32 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.

  • Clayton Burkhart

    June 23, 2011 at 4:52 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.

  • Chris Kenny

    June 23, 2011 at 5:07 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.

  • Chad Wilmoth

    June 23, 2011 at 5:09 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

  • Clayton Burkhart

    June 23, 2011 at 5:28 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

  • Chris Kenny

    June 23, 2011 at 5:43 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.

  • Clayton Burkhart

    June 23, 2011 at 6:00 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.

  • Chris Kenny

    June 23, 2011 at 6:21 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.

Page 2 of 3

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy