vectorscope / waveform monitor ? at DVinfo.net

Bart Wierzbicki · May 6th, 2009, 04:31 AM

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

Bill Ravens · May 6th, 2009, 06:13 AM

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.

Bart Wierzbicki · May 7th, 2009, 02:23 AM

Do you also work with Adobe OnLocation ?

Bill Ravens · May 7th, 2009, 07:30 AM

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.

Douglas Thigpen · May 7th, 2009, 05:15 PM

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.

Jim Snow · May 10th, 2009, 09:43 AM

Quote:

Originally Posted by Bill Ravens

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.

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.

Jack Kelly · May 16th, 2009, 09:38 AM

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.

Bill Ravens · May 16th, 2009, 09:47 AM

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

Shaun Roemich · May 16th, 2009, 11:33 AM

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

Jonathan Palfrey · May 17th, 2009, 02:45 PM

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.

Shaun Roemich · May 17th, 2009, 02:53 PM

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.

Bill Ravens · May 17th, 2009, 03:26 PM

Quote:

Originally Posted by Jonathan Palfrey

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.

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.

Mark Mapes · May 19th, 2009, 05:46 PM

Quote:

Originally Posted by Jim Snow

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.

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.

Peter Moretti · May 21st, 2009, 07:15 AM

Quote:

Originally Posted by Bill Ravens

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.

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.

Bill Ravens · May 21st, 2009, 07:29 AM

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.

May 6th, 2009, 04:31 AM	#1
Bart Wierzbicki Regular Crew Join Date: Jun 2008 Location: Zonhoven Posts: 153	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

May 7th, 2009, 05:15 PM	#5
Douglas Thigpen Regular Crew Join Date: Jun 2008 Location: San Diego, CA / Apex, NC Posts: 81	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. __________________ Douglas Thigpen http://www.dthigpen.com/ - http://www.nicetryproductions.com/

May 16th, 2009, 09:38 AM	#7
Jack Kelly Major Player Join Date: Oct 2004 Location: London, UK Posts: 243	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. __________________ Jack Kelly's filmmaking website AfterCarbon.org

May 16th, 2009, 11:33 AM	#9
Shaun Roemich Inner Circle Join Date: Sep 2002 Location: Vancouver, British Columbia (formerly Winnipeg, Manitoba) Canada Posts: 4,088	Incredibly cool, Bill. May include that in the next edit bay. __________________ Shaun C. Roemich Road Dog Media - Vancouver, BC - Videographer - Webcaster www.roaddogmedia.ca Blog: http://roaddogmedia.wordpress.com/

May 17th, 2009, 02:53 PM	#11
Shaun Roemich Inner Circle Join Date: Sep 2002 Location: Vancouver, British Columbia (formerly Winnipeg, Manitoba) Canada Posts: 4,088	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. __________________ Shaun C. Roemich Road Dog Media - Vancouver, BC - Videographer - Webcaster www.roaddogmedia.ca Blog: http://roaddogmedia.wordpress.com/

May 6th, 2009, 06:13 AM	#2
Bill Ravens Join Date: Nov 2001 Location: santa fe, nm Posts: 3,264 Images: 10	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.

May 7th, 2009, 02:23 AM	#3
Bart Wierzbicki Regular Crew Join Date: Jun 2008 Location: Zonhoven Posts: 153	Do you also work with Adobe OnLocation ?

May 7th, 2009, 07:30 AM	#4
Bill Ravens Join Date: Nov 2001 Location: santa fe, nm Posts: 3,264 Images: 10	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.

May 16th, 2009, 09:47 AM	#8
Bill Ravens Join Date: Nov 2001 Location: santa fe, nm Posts: 3,264 Images: 10	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

May 17th, 2009, 02:45 PM	#10
Jonathan Palfrey Regular Crew Join Date: Nov 2008 Location: Torbay, UK Posts: 170	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.

May 21st, 2009, 07:29 AM	#15
Bill Ravens Join Date: Nov 2001 Location: santa fe, nm Posts: 3,264 Images: 10	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.