vectorscope / waveform monitor ?
 

Hey guys,

I'm trying to color correct my footage, but I'm really having a hard time just using the sliders.
Now I'm reading books about it and it seems that I need a vectorscope / waveform to do the collor correcting.

So is it a good idea to buy an external vectorscope and waveform or do you advice working with plugin vectorscopes and waveforms ?
Which one do you advice ?

Thanks

Absolutely VITAL in my workflow to have a WFM/Vectorscope. Outside of the scopes that ship as part of most NLE's, there are a few solutions that work very well, albeit, rather expensive. I use Hamlet's VDscope, which is a very nice software solution. Blackmagic Design has just released a dedicated PCIe bus card that will connect to a 24 inch LCD display, also for monitoring WForm and vector.

I would stay away from hardware scopes, simply because they are very, VERY expensive and won't always work with the delivery style, be it DVI, HDMI, HD-SDI, composite, component, or what have you.

Do you also work with Adobe OnLocation ?

I used to use the original software from SeriousMagic called HDRack. When Adobe bought SeriousMagic, they changed the name to OnLocation and made re-licensing of HDRack practically impossible. After this experience, I avoid OnLocation as much as possible, however, it still works for this application, albeit, somewhat crippled by Adobe.

Color Finesse PI 2.1.10 is has a great interface with all this information in view at all times in Full Interface mode if you're using Premiere or After Effects.

A HUGE problem with Adobe's acquired products / companies is that they do a lousy job of supporting these products. They lose the good engineers from the acquired companies so they don't have the ability to carry forward the products. With OnLocation for example, it was "thrown in the box" with Premiere CS3 for PC but they couldn't get it to work with Mac so it wasn't included with Premiere CS3 for Mac. Even on the PC, it didn't work in an integrated workflow manner, it was just a gadget in the box. In attribution to the fact that Adobe didn't have the engineering ability to support OnLocation, they dropped it with CS4.

If you're monitoring in SD then you can pick up decent SD analogue waveform / vectorscopes monitors 2nd hand. My setup includes a 2nd hand waveform monitor which I picked up for £250 and it works a treat.

Personally, I'd avoid any hardware wfm/vectorscopes, because they are very finicky about setting up with the right cables, cable terminators and are specifically designed for a specific I/O signal type....composite, component, HD-SDI, DVI, etc.

I'm using a Hamlet VDSCOPE, software WFM/Vectorscope; and, this works quite well, albeit expensive to purchase. If I were looking to get something, and, I had a spare PCIe bus slot on my workstation, I'd go for this new product from Blackmagic Design...
Blackmagic Design: Blackmagic UltraScope

Incredibly cool, Bill. May include that in the next edit bay.

Surely the built in software waveform/vectorscope on NLE systems works well enough? I use the waveform all the time on Sony Vegas and always seems to have good results.

Jonathan: Lot's of things (most of them bad) can happen to a video stream between the edit software and the output device, especially if using a hardware IO. As well, just changing codec's within software can create nightmarish gamma and/or brightness shifts that can take a sequence that is broadcast legal and throw it out of range.

If you aren't preparing material for broadcast, the external wf/vs may be overkill, but it is a valuable tool IF you need it.

This is really a pretty good indication of someone who hasn't much experience outputting to a variety of codecs. What you see inside the NLE is not always what you get, and this is especially true of Vegas which has a very hokey scope setup.

Final luma values can be a very suble change from legal to non legal or blown out and milky. Without a production monitor, the only way to tell quantitatively is with a good scope set.

I came to Adobe as part of the Serious Magic acquisition, and I have to correct you on several points, Jim,
1) Adobe hired the entire Serious Magic engineering team. One of the guys who worked on DV Rack has moved onto another product, but the rest of us are all working on OnLocation.
2) As you note, in the CS3 cycle we did not have time to port OnLocation CS3 to Mac [there were only about 7 months between the acquisition and pens-down for CS3]. However, OnLocation CS3 for Windows was included with Premiere for Mac. You may be thinking of Ultra, which was also Windows-only but was not included in the Mac boxes.
3) OnLocation remains under active development. We released an entirely new version of OnLocation for CS4, ported to the Mac and with an entirely new, more versatile UI, as well as powerful new metadata management features. Again, you might be thinking of Ultra, which was not updated for CS4 and was removed from Production Studio.

All: If you’re interested in beta-testing the version that we’re now hard at work upon, please drop me a note at mapes@adobe.com. Beta-testing is your best way to have a voice in the direction we grow the product and perhaps to help us find some bugs before they make it into the wild. We’re also eager to observe real world customers using OnLocation, so if you’re a) an experienced hand with OnLocation, b) willing to let a few of us visit your set for a day, and c) ideally work in the vicinity of Sacramento, CA, please get in touch.

Bill, would grading to what the NLE shows you as legal and then applying a colorsafe before rendering keep you w/in legal range?

BTW, what's so hokey about Vegas' scopes? I actually like them more than MC's, well at least the fact that they are realtime.

Peter...

After years of struggling with Vegas, I finally understood that the codec used to render/export the timeline greatly affects the final result. Some codecs do not change the luma and chroma values when they are rendered/exported, other codecs will remap luma/chroma values without warning. Glen Chann has a white paper that describes this in more detail. With this knowledge, I purchased an external scope to be able to look at the rendered/exported video, independently of the Vegas scopes.

Having done this, I made two observations. Indeed, the luma values of an rendered/exported video don't always match the values shown in the Vegas scopes. Sometimes this is due to the final codec remapping of the luma values, sometimes the Vegas scopes are just plain incorrect. Have you ever experienced a case where the Vegas scopes show broadcast legal RGB 16-235 values, only to discover after exporting/rendering that your final video looks washed out or milky? This is a perfect example of the remapping effect applied by some codecs. In fact, external scopes will reveal that the final luma values are 32-242. This is because the final codec remapped the broadcast RGB values, even if they originated as broadcasst RGB. I've actually experienced codecs that do NOT remap when rendered to, but, the vegas scopes are showing the wrong luma values.

By the way, Media Composer scopes are subject to the same policy of reporting timeline luma and chroma values, NOT luma/chroma values after final rendering/exporting. I have never seen the MC scopes report wrong values, tho', as I have with vegas. This is due, I believe, to the difference in the way MC and Vegas handle broadcast or video RGB Values.

In another example of Vegas' funkiness, I will refer to the Cineform DI, which I use rigorously in my editing workflow.It's my understanding that SCS mandated to Cineform that use of the Cineform DI in Vegas ALWAYS remap the luma values to be broadcast legal 16-235. This despite the fact that the Cineform DI is fully capable of keeping luma values to video values of 0-255. Within MC, imported Cineform DI luma values are left in the 0-255 range if RGB mapping is selected. They are remapped 16-235 if 601/709 mapping is selected. At least MC gives the editor a predictable and reliable method of choice, unlike vegas.

Anyway, I hope I've answered your question.