(Page 2 of 2 pages for this article  <  1 2)

Filed under: *VIDEO* •Editing •Hardware •Final Cut Pro •

Does Premiere CS5 achieve the “impossible dream” for critical evaluation monitoring?

Sidebar: RGB versus component video

The primary colors in video are RGB, or red, green, and blue. However, a long time ago, video engineers discovered that given a situation of limited bandwidth, it is often more efficient to handle the video in a component derived version of RGB. This is because the human eye is more sensitive to the luminance portion of the video than the chroma portion. Component video assigns more of the bandwidth to the luminance. Over the years, there have been many different ways of expressing component video, including:

• Y, R-Y, B-Y (Y=Luminance, R=Red, B= Blue)
• Y,Cb, Cr
• YPbPr
• YUV

Sometimes the terms are associated more with one context than with another. In the component analog days, there were even fights among the standards in terms of the chroma levels (the EBU N10 level, the SMPTE level, and the Sony Betacam USA level, etc.) which sometimes caused mismatches when interconnecting equipment. I remember having to re-calibrate component analog switchers to work with a different standard… and having to prove to Leader Instruments that in the PAL world, Sony had accepted the EBU N10 level, so they would not stop forcing PAL component vectorscope users to have the display say “MII” in order to show the proper level for PAL Betacam SP. It was very different in the NTSC world, where the Sony USA chroma levels won over in popularity over the SMPTE levels. But that’s all nostalgia now:)

The way we record, and the way we monitor

With two important exceptions in the field (and a couple more in editing), digital video recording is done in component (YUV), both in consumer and pro. This is mainly due to the most popular códecs used in HD camcorders, decks, and in editing:

• All AVCHD camcorders use H.264 (MPEG4 part 10) to record in component.
• Canon photographic cameras that record HD video use H.264 (MPEG4 part 10) to record in component.
• Canon’s new professional tapeless camcorders (XF305 and XF300) use MPEG2 to record in component.
• Kodak and Sanyo hybrid cameras use H.264 (MPEG4 part 10) to record in component.
• All JVC Everio HD camcorders record use either MPEG2 to record in component, or AVCHD in component.
• All HDV camcorders (both 720p and 1080i/p) use MPEG2 to record in component.
• JVC’s professional tapeless camcorders use MPEG2 to record in component.
• All Sony XDCAM-EX and XDCAM-HD camcorders use MPEG2 to record in component.
• All Panasonic P2 HD cameras use either DV100 or AVC-Intra, both to record in component.
• All standard Sony HDCAM camcorders use DCT compression and records in component.
• Apple’s ProRes422 and ProRes422(HQ) record in component.
• Cineform’s also 422 records in component.

Exceptions that can record RGB:

• Sony HDCAM-SR offers the option of recording component or RGB 4:4:4.
• Red cameras record REDCODE in RGB 4:4:4.
• Apple’s ProRes 4444 records RGB.
• Cineform’s 444 records RGB.

As you can see, most HD digital video is component (YUV). Video monitors, projectors, and TV sets actually display RGB (whether or not they can accept either RGB and/or component). Therefore, a conversion must be made when playing a component video signal to be seen by the human eye. For critical evaluation, we need a proper and trustworthy realtime conversion. Although Apple’s colorspace conversions are certainly proper and trustworthy when rendered via software, Apple’s 2005 warning indicates that this is not the case with the realtime conversion done with the Digital Cinema Desktop feature. To my knowledge, this has not changed with any newer version of FCP, and if it has, no one from Apple seems to be flaunting it. Although Apple’s Color program handles all material exclusively in RGB, to my knowledge, the program still does not pipe its program output specifically or accurately to a graphic card output, but only to one of the professional i/o devices.

In the standard-definition days, editors who dealt with DV25 video (DV, DVCAM, DVCPRO25) natively, and couldn’t afford a professional interface from AJA, Blackmagic Design, or Matrox could monitor via the IEEE-1394 (FireWire, i.LINK) through a DV camcorder/deck or DAC device, and from there to an NTSC or PAL monitor. In those cases, the YUV to RGB conversion was done by the NTSC or PAL monitor. But to monitor HD properly —in HD— for critical evaluation from a component timeline, it has been necessary to use a professional interface.  When Apple committed to miniDisplayPort over 18 months ago, many people (including myself) began to wonder whether a direct connection to monitors might someday become possible for this purpose. As stated before: For critical evaluation, we need a proper and trustworthy realtime conversion, and as stated, apparently that hasn’t yet happened with Apple’s Digital Cinema Desktop feature so far. But keep reading!

With a traditional, conventional NLE system, the uncommon RGB timelines (i.e. 4:4:4) are processed in RGB and (when desired to output to an HDCAM-SR recorder in RGB 4:4:4 mode) the video output leaves via dual-link HD-SDI (or nowadays, via 3G-SDI). But let’s go back to the more common situation, where the timeline is YUV. With a traditional, conventional NLE system, YUV timelines are normally processed in YUV and the video output leaves the computer in YUV, where they are output as SDI or HD-SDI to a monitor, and it is the monitor’s responsibility to carry out a realtime, hardware-based, proper and trustworthy conversion to RGB. Some professional i/o devices offer either DVI or HDMI output. In the case of DVI (which by definition is always 8-bit RGB), the realtime proper and trustworthy conversion to RGB is carried out by the professional i/o device. Some of them with HDMI output, i.e. Blackmagic Designs, offer the HDMI output strictly with YUV output, which means that the Blackmagic product (from a YUV timeline) is leaving the colorspace alone, and the HDMI monitor is then in charge of the YUV>RGB colorspace conversion. (As explained in my DreamColor articles, it is not recommended to connect an HDMI output from any current Blackmagic product directly to a DreamColor monitor, since the DreamColor engine demands a signal that is already both truly progressive and RGB. If you do that, the DreamColor engine will shut off) On the other hand, several products from AJA and Matrox offer HDMI outputs, where the operator can select that the HDMI output be either digital YUV or digital RGB. When selecting the RGB option, the realtime proper and trustworthy conversion from YUV to RGB is handled 100% by the professional i/o. Yet another option, covered in this article, are the external converter boxes that go from SDI or HD-SDI to either HDMI or DisplayPort (model dependent), from both AJA and Blackmagic. All of the converter boxes covered in this article can convert the source signal to RGB (when required). In that case, the proper and trustworthy conversion to RGB (when necessary) is handled 100% by that converter box.

The impossible dream, fulfilled?

For many years, editors and readers of my articles have been asking me: “Why can’t I just connect my critical video evaluation monitor directly to an extra output of my computer?” If you have been reading this and my other articles, you know why that has not been possible up until now, and you will also have read why Apple even warned us at NAB 2005 and in support article TA27705. However, if you have been reading points 1 through 4 above, you may be saying that you have already disqualified those points.

I was happily surprised to hear that —for the first time in Adobe Premiere’s history— version CS5 now handles realtime YUV to RGB colorspace conversion 100% on its own, and that Adobe guarantees the accuracy of this realtime conversion with all transitions and modes that use 32-bit floating-point, which fortunately covers all seven of Premiere CS5’s color correctors!



The image (left), courtesy of Adobe and Karl Soulé, shows how to indicate when you have selected a floating 32-bit function. In the past, part or all of this work was in the hands of either the operating system or the GPU’s driver, but now all of this work is handled completely by Adobe. Karl Soulé of Adobe tells us all about it in episode 3 (English) of TecnoTur, which is already available free via iTunes or at TecnoTur.us. You can listen to it immediately here:

Consider subscribing free right now so you’ll be sure to receive all new episodes automatically as soon as they become available.

Sidebar: Why not output YUV over DP or HDMI from the computer…?

Some readers may be asking: “Why not output YUV over DisplayPort or HDMI from the computer, and let the monitor do the conversion to RGB?”

Even though DisplayPort and HDMI can handle either YUV or RGB, so far in my experience, all of the computer implementations of DisplayPort handle RGB-only, and any HDMI computer implementations that Greg Staten has seen currently handle RGB-only. Although a driver could be written to send YUV over these computer outputs, I have two reasons why I believe maintaining them as RGB makes more sense:

• To be compatible with the HP DreamColor (since the DreamColor engine demands an RGB source anyway), and all other monitors with these inputs will also take RGB, including the JVC DT-V24L1 I covered back in this article.
• Since an editor/grader/colorist can alternate between YUV timelines (with YUV footage) and RGB timelines (with RGB footage), and the final goal is RGB at the display, with YUV timelines, one last conversion is inevitable. However, I would hate to reduce an RGB timeline to YUV, only to have it be re-converted back to RGB again. I realize that that is what happens with traditional SDI and HD-SDI outputs which are not dual-link or 3G (or with those dual-link SDI or 3G-SDI systems which have been set for YUV), but that is a necessary and natural sacrifice since they were designed either to feed recorders that natively record YUV, and/or to SDI monitors that were only designed to accept YUV over SDI. I also realize that that’s what happens whenever we watch video that is distributed as YUV, be it from DVD, Blu-ray, web, cable, or (H)DTV. I just want to simplify monitor workflow and be a purist in closed NLE and grading systems, by having the least number of conversions possible, especially since raw RGB footage contains more chroma information… and that’s the way the computer outputs are currently working anyway.

Other NLE programs which may also make this possible

Greg Staten of HP has told me that some versions of Avid Media Composer may also make this possible, but I do not have more details than that. There may be other NLE programs that also offer this, but I haven’t heard of them yet. If you have confirmed information about another NLE program that offers it —and whose manufacturer guarantees it— please comment below.

Other reasons to include a professional i/o, despite new possibilities

If you have studied all four points and have determined that you are 100% covered, i.e.:

• You never capture from live or tape (anymore), or if you do, it can be exclusively via IEEE-1394.
• You never print to tape (anymore) and don’t playback live to air (anymore).
• You only deliver progressive programs (despite the fact that you may receive some interlaced raw footage).
• Your NLE program does a proper and trustworthy realtime conversion to RGB for your critical monitor.
• Your system has a spare non-mirroring output, ideally DisplayPort or HDMI (to be 10-bit), or at least DVI (which would be 8-bit).

Then currently, I know only one more reason to purchase a professional i/o for your NLE, especially if it will be a laptop: Matrox’s MAX option, which for a laptop, is currently available only inside of one of the MXO2 family of i/o boxes, and only with the initial purchase. I already covered the MXO2 family here, and I’ll be publishing the MAX article very soon!

Related articles:

• Allan Tépper’s: Why should I care if my monitor shows ITU Rec.709?
• Allan Tépper’s: Who is the ITU, and why should I care?
• Allan Tépper’s: How to connect your HD evaluation monitor to your editing system properly: Let me count the ways!
• Allan Tépper’s review: DreamColor from HP: an ideal tool for critical image evaluation
• Patrick Inhofer’s review: HP’s DreamColor: A PVM CRT Replacement?
• Allan Tépper’s: DreamColor direct interfaces
• Allan Tépper’s: DreamColor converter boxes for non-compliant systems
• Allan Tépper’s: Matrox’s original MXO crashes the Direct DreamColor interface party
• Allan Tépper’s: Why the iPad will dictate your shooting framerate & shutter speed
• Allan Tépper’s: When 25p beats 24p…
• Allan Tépper’s: Canon HV40: a great inexpensive feeder deck for native Sony 3G HDV recordings
• Allan Tépper’s: When to edit native, When hybrid, and When pure i-frame… and Why
• Allan Tépper’s: Panasonic’s AVCCAM incomplete native progressive recording modes
• Allan Tépper’s: Why capture HDV via HDMI?

Allan Tépper’s consulting, articles, seminars, and audio programs

Contact Allan Tépper for consulting, or find a full listing of his articles and upcoming seminars and webinars at AllanTepper.com. Listen to his TecnoTur program, which is now available both in Castilian and in English, free of charge. Search for TecnoTur in iTunes or visit TecnoTur.us for more information.

Disclosure, to comply with the FTC’s rules

No manufacturer is paying Allan Tépper or TecnoTur LLC specifically to write this article. Some of the manufacturers listed above have contracted Tépper and/or TecnoTur LLC to carry out consulting and/or translations/localizations/transcreations, and some of them have sent him equipment for evaluations or reviews. At the date of the publication of this article, none of the manufacturers listed above is/are sponsors of the TecnoTur programs, although they are welcome to do so, and some are, may be (or may have been) sponsors of ProVideo Coalition magazine.

(Page 2 of 2 pages for this article  <  1 2)

Then, which is the answer?

Posted by .(JavaScript must be enabled to view this email address)  on  07/04  at  06:02 AM

---

Hi,

Interesting article. I have two questions. First is the following a potential typo?  Should this headline have had a NOT? 
—-
Other reasons to include a professional i/o, despite new possibilities

——

It sure seems like it.  In fact there were a couple of places where it seemed as if there might be typos which had me confusing your meaning.  Maybe not.

Second, given the info you have provided, what products do you suggest for using as video scopes in this type of workflow?

Thanks,

Jef

Posted by .(JavaScript must be enabled to view this email address)  on  07/04  at  06:54 AM

---

Michael,

I’m glad to see our articles are being appreciated in the UK

It is very likely that it would have shown the anomaly you had, but to be sure, someone would have to test it. I have Premiere CS5 installed, but no longer have local access to a DreamColor or similar monitor. If you post the original logo somewhere, I can verify it the next time I have access to a DreamColor, or perhaps another reader will be able to do it even sooner. However, please understand that what the reason that you didn’t see it at first may be do to the proper monitoring, or it may be the way FCP7 previewed it before rendering it. So if someone attempts to test your original logo using CS5 with a DreamColor connected directly, it may be visible either in the status monitor, or on the DreamColor, or on both. if it is on both, then that would mean that it is the way that FCP7 previews it. If it is only visible on the DreamColor connected that way, then it is directly related to the configuration described in the article.

Allan Tépper

Posted by Allan Tépper  on  07/04  at  07:05 AM

---

Thanks for the reply Allan.

The worrying aspect to all this is that it didn’t show up after I’d rendered the file out to quicktime.  I watched the disc on a stand alone DVD player - discovered the error and then watched the disc on the laptop - again it didn’t show up.

Posted by MichaelSanders  on  07/04  at  07:20 AM

---

Jef,

The question mark in the title is 100% intentional. The reason for the question mark is because this potential achievement is very conditional: the editor must understand each one of the 4 points, and then ask her/himself whether s/he can really disqualify each one. Some will be able to do so, and others will not be able (yet).

The section called Other reasons to include a professional i/o, despite new possibilities is also there purposefully, as explained within.

For anyone who is able to disqualify the 4 points, Premiere CS5’s own scopes are my recommendation.

Allan Tépper

Posted by Allan Tépper  on  07/04  at  08:25 AM

---

Nice product, i liked it…

Posted by MoviesBlaster  on  07/10  at  03:57 PM

---

Hi
If I’m using DPX 10-bit log files in a compositing software like Nuke, which are always RGB, do I still need an I/O converter with my HP dreamcolor to critically view color?

Posted by .(JavaScript must be enabled to view this email address)  on  11/11  at  09:48 AM

---

AtlasStorm,

It depends upon whether Nuke send out a proper Rec 709 signal to the GPU. You would have to ask them.

Allan Tépper

Posted by Allan Tépper  on  11/11  at  09:54 AM

---

Allan, I just discovered your blog and podcast, great stuff. I moved to Premiere Pro from FCP about a year ago, and I recently replaced my secondary aging monitor, with an Asus Pro Art PA246Q monitor, which is supposedly a pretty good deal, and supposedly a 10 bit P-IPS display with 12 bit processing, though probably not close to a DreamColor. It also has HDMI and Displayport as well as DVI inputs. I’m connected to it with a Mac Pro with a NVidia Quadro 4000 via DVI (the Nvidia does have a displayport output).  It doesn’t have a specific rec709 setting, but it does have sRGB, and it is factory calibrated. I also used a Spyder 3 to calibrate it to the rec709 color space.

Anyway, I’m wondering if you know if Premiere Pro on the Mac can drive this (or any RGB connected monitor via DVI or displayport) for accurate color correction, if this has been proven or if it’s just a theory. I have a Black Magic Intensity Pro, which has HDMI and would probably be able to drive a good HDTV as a reference monitor, but I’ve found it to be problematic with Premiere Pro. It just seems very flakey.

Anyway, and new discoveries or advice is appreciated.

Posted by Keith Moreau  on  08/26  at  11:08 PM

---

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?

Submit the word you see below: