Calibrating for video accuracy

[Will Thompson]

I apologize if this question has been answered elsewhere, but I have searched and not found much.

I have two monitors, a Dell U2410 (wide gamut), and an older Dell TN-panel (will probably be replaced by a U2711). I want the best possible setup for accurate color reproduction when editing video (and ideally photos as well). It seems it should be possible to calibrate both displays and get accurate video color reproduction using only the monitor profiles, considering this is clearly possible with still images (although much trickier in Windows vs. OSX). However, advice I find is all over the map.

Is the recommendation to use an external monitor strictly because Premiere and other NLEs are not color managed? FCPX suggests that on a well calibrated monitor, colors will be accurate within the NLE and a dedicated monitor isn't necessary. This would be the ideal configuration for me, although I don't really want to use FCPX.

The U2410 covers a lot of gamut, so it seems like it should be able to get pretty close to any target after calibration, even if there is some dithering or banding.

Any enlightenment on this topic would be appreciated!

[Battle Vaughan]

Here's a very concise guide to using color bars; it's an Apple document but it applies to monitors in general: Color User Manual

and another: http://spareroommedia.com/video/monitor_setup.html

There are several other similar discussions, Google "calibrate video monitor color bars" and you'll see several. But these tell you what you need to know. HTH...

[Tim Polster]

Will this is a tricky subject. In the best case scenario, you would have a hardware card driven external monitor for video as well as computer screens for everything else.

At the heart of the matter is the difference between video and computer signals. Video for television viewing is in the YUV color space. This means DVDs & Blurays should be created from a YUV space environment.

Computers use the RGB color space. So anything you view on a computer driven screen (including video) is being derrived from the RGB color space. RGB & YUV are different.

What to do? The fact you know they are different is the first step. I think Premiere might have some sort of YUV emulation in the preview monitor but I do not know for sure.

Do you produce for television viewing or internet or both?

[Will Thompson]

Battle - Thanks for the links.

Tim - Mostly DVD/Bluray, but both. I will use an external monitor if it's absolutely necessary, but it seems like it shouldn't be -- a vestige of less advanced software having to punt to special purpose hardware. What I don't understand is why, if the monitor, OS, and application all know the gamut and color profile of both the monitor and the video signal, it cannot simply do the math and display the video signal as it's intended - RBG/YUV conversion is fairly simple. My understanding is that this is what FCPX does, although I don't use FCPX.

I prefer Premiere, but I am not opposed to working in other NLEs if they are more capable in this respect. However, work for some clients will require me to use other NLE software, part of the reason I want to make sure what I am seeing is accurate before sending it off.

[Shaun Roemich]

Originally Posted by Will Thompson

but it seems like it shouldn't be -- a vestige of less advanced software having to punt to special purpose hardware. What I don't understand is why, if the monitor, OS, and application all know the gamut and color profile of both the monitor and the video signal, it cannot simply do the math and display the video signal as it's intended - RBG/YUV conversion is fairly simple.

A quick analogy using your argument above...

"I would like to print glossy stickers.

But I want a proof on flat white letter paper, not glossy heavy weight sticker stock.

Why can't you give me an accurate representation of how the colours will look and how shiny it will be?"

YUV and RGB have different colour space/reproduction. YUV (video) displayed on a native RGB device through an RGB connection (VGA, DVI, HDMI to a computer monitor from a computer) cannot ACCURATELY be displayed, IMHO. A wide gamut display receiving a YUV signal through a YUV connection (analog component, HD-SDI, HDMI at VIDEO resolutions from a YUV source) can be much more accurate.

[Tim Polster]

I think Shaun has given a great example.

It is not about advanced or simple software it is about sending the proper signal to a proper monitor. Computers deal in RGB unless a specific device converts and distributes. Without that "simple" hardware card you will have a tough time getting an YUV signal from a computer.

[Will Thompson]

Tim and Shaun - I don't think the analogy is accurate, unless you are talking about doing no YUV to RGB conversion at all. CMYK to RGB is a very common color space conversion used in print workflows, and calibrated RGB monitors can accurately match on screen RGB to a CMYK printer. YUV color space is no different. (Converting between Y'UV and RGB)

And the conversion doesn't have to be done in hardware. All DVD/Bluray player software and most media players convert YUV to RGB, and these are used in calibrated theater environments. DI codecs are a mix of YUV- and RGB-based, so some conversion must be happening in NLEs that support them.

I understand that having an external monitor can be a matter of personal preference. But if it is not preferred, I don't see why color reproduction can't be just as accurate within the NLE. FCPX evidently manages it - is it a limitation of Premiere (or Avid)?

[Shaun Roemich]

Originally Posted by Will Thompson

All DVD/Bluray player software and most media players convert YUV to RGB, and these are used in calibrated theater environments

What outputs are RGB on a DVD/BluRay player?

Analog component is YUV (despite having red, green and blue cable identifiers). HDMI can pass either but USUALLY passes YUV at TV resolutions.

[Shaun Roemich]

Originally Posted by Will Thompson

I don't see why color reproduction can't be just as accurate within the NLE.

The output of your computer to its attached monitor is RGB. Therefore anything occurring on the computer screen is being output via RGB. A second output (for example, FCP's Digital Cinema output Full Screen) could potentially do a software conversion to bring it closer but if you are talking about the viewer window in the interface being reference quality as YUV, you are deluding yourself.

Close enough? Sure. Especially for web output but don't claim it is referenced, because it isn't.

[Will Thompson]

Shaun - DVD/Bluray player software like Apple DVD Player for Mac, or PowerDVD, Arcsoft TMT, etc. for the PC. All of these apps do the conversion in software to accurately display YUV content in RGB space.

My understanding was that even if an HDMI monitor receives a YUV signal, most will still convert to RGB before displaying anyway. This may vary by device, however, and do I have experience with the higher end monitors. Either way, you can connect a Mac or PC to a calibrated HDTV or monitor via HDMI or DVI, and the RGB signal will be virtually indistinguishable from an unadulterated TUV signal.

[Will Thompson]

Originally Posted by Shaun Roemich

if you are talking about the viewer window in the interface being reference quality as YUV, you are deluding yourself.

Why am I deluding myself? There is no technical reason this can't be done, and FCPX claims to do it. If you have an explanation, I'm all ears.

[Shaun Roemich]

Originally Posted by Will Thompson

Either way, you can connect a Mac or PC to a calibrated HDTV or monitor via HDMI or DVI, and the RGB signal will be virtually indistinguishable from an unadulterated TUV signal.

Your experience is MASSIVELY different than mine.

Despite knowledgeable people suggesting the contrary, you appear to want to believe what you believe. Power to you. I shall not waste any more virtual "breath" here. The fact that IO devices such as the Matrox MXO2 series, the AJA IO series and numerous BlackMagic Design and others products exist to do EXACTLY what you are claiming can be done natively in software either means:
- these manufacturers are snake oil salesmen;
- I and MANY of my colleagues are gullible;
- Myself and Tim are correct; or
- you are correct and I and many others have been bilked of our money and have been made fools of, despite seeing results that are different from yours.

[Will Thompson]

Shaun - I don't think I have implied that you or anyone is gullible or is selling snake oil products. If I have, my apologies.

There are many reasons to use an external monitor, so I don't understand why the suggestion that it may be unnecessary for some uses with the right software warrants such exasperation. Apple suggests the same with their claim that ColorSync can render reference quality within FCPX. I don't know where Premiere and Avid stand. Apple may be overselling FCPX, I don't know, but I haven't seen anything definitive on these topics.

The existence of a hardware solution doesn't mean software cannot be just as capable, as evidenced by many media players/encoders/streamers that create reference quality output that you are welcome to compare yourself. Whether accurate color-rendering capabilities are built into the latest NLE software, or if it is OS-dependent, etc, I don't know. This is why I started the thread. It's not personal.

[Sareesh Sudhakaran]

Originally Posted by Will Thompson

What I don't understand is why, if the monitor, OS, and application all know the gamut and color profile of both the monitor and the video signal, it cannot simply do the math and display the video signal as it's intended - RBG/YUV conversion is fairly simple.

YUV is not a color space, but an encoding standard based on sampling an analog video signal.

RGB is not a color space, but a color model.

If you're mainly into high definition video, HDTV, e.g., you are looking at a color space commonly called Rec. 709. This color space is almost equal (for all practical purposes) to sRGB.

Theoretically, Rec. 709 can hold infinite colors, though there are many colors that the human eye can see that fall outside its domain.

Now, to answer your question:

An OS has to cater to many applications and processes running simultaneously, any of which might suddenly need to display a message or GUI or whatever. Not all applications are made using the same 'principles', and unless an OS has access to the source code it cannot know for sure what math is actually being used.

E.g., when you apply a plug-in to a video - the app that runs the plug-in just executes the code, but the app does not have access to the math. The OS does not have the code to the app or the plug-in.

The app has to create a 'mathematical environment' so that the plug-in can work its magic without any bottlenecks in the math. 'Good' applications today must adhere to two basic math principles - running on 64-bit OS and providing a 32-bit linear float environment. This ensures a level playing ground for the latest technological advances and algorithms. Two apps that adhere to this are After Effects and Nuke.

Mathematics is just a tool - where you reach will depend on how you start - floating point or not? Log or linear? Which algorithm to use?

It's like a dysfunctional family, with the OS as the father, the app as the mother who sleeps around with other OS's and the plug-in as the teenage kid on dope. They're all trying to get along. In comes the unknown guest video who can screw up or maintain this balance. The best everyone can do is to stay out of each other's way.

This can be corrected if each and every manufacturer in the pipeline were to open its hardware and software for the world to see - just like a functional family who chats openly over dinner and solves their issues.

This led to three major developments:

1. Apple - completely closed system - the Corleones
2. Windows - Semi-closed system with the OS/father taking charge - King Lear
3. Open source - the Simpsons

[Shaun Roemich]

Some interesting reading here to help explain:

Color Models

Sareesh: my statement of colour space was to indicate the reproducible colours within the colour encoding scheme (yuv versus rgb). Gamut would have been more accurate.