In 32-bit there isn't really a simple logic to what codecs do what.

The simpler approach is to consult the table in my article (or a similar table if they exist).

1- Pick a working color space (studio or computer RGB). Suppose you pick studio RGB.

2- Convert all your sources to that working color space. So any computer RGB sources (e.g. still images) need to be converted to studio RGB... on those clips, apply the "computer RGB to studio RGB" color corrector preset.

3- When you make your deliverable, check what color space that codec expects. Suppose you are rendering to Windows Media (which expects computer RGB).
Nest your .veg into a new project, apply a studio to computer RGB conversion to that, and render that out.

I don't know. I think it could be better... having to manually convert color spaces is not something you have to do in other NLEs.

1) I have an HD camcorder that limits output to 100IRE.

2) Superwhites are not illegal in all editing programs. With FCP you simply check the box if you want Superwhite handling.

3) None of the production systems you mentioned are EDITING systems -- they are primarily compositing systems that usually require very specific graphics cards. The NLEs with the largest installed base do NOT use GPUs so it's a stretch to claim that GPUs explain "volumes." The "volumes" you talk about must exist in the data values themselves -- not in a FP unit. I think you are confusing the range of bit-values in data with the computation of colorspace during conversions.

Bottom-line, Vegas users must do what they need to do. But now all of us know we must not ignore these issues. For examples, do folks always check Superwhites in FCP?

The problem here is that there are different RGB standards/types and that the allowed range of values is not what sets them apart, it is also what the Red Green and Blue colors are.

Wikipedia (what else?) has a nice graph with different RGB volumes. AFAIK sRGB is roughly the same as SMPTE 601 and used for consumer products like TV's. Adobe RGB and Apple RGB are computer RGB types.

Also you may what to take a look at this paper: . A Review of RGB color spaces...from xyY to R'G'B'. Yes it is a PDF and yes, it will make you feel like doing homework.

George/

Problem with vegas pro 8
 

Ok i'm having a bit of a problem with Vegas pro 8.
I shot a lot of footage at the weekend,around 8hrs,all1080/50i,all in SQ,except 1 hr of HQ,115gb in total.
I need to compress it down,client wants WMV,now even when i put a small amount in the timeline,even just 30 mins,vegas won't render the complete clip,a couple of mins is fine,but any more than that,no,computer just keeps hanging,the green process bar will stop at say 52% but the time remaining keeps going down and the time elapsed keeps going up,then when time remaining is at zero,time elapsed jut keeps going.
All my footage is on an exteral hard-drive,seagate freeagent pro,500gb,running via esata,i've never had any problems with vegas until i started using this drive,but i've also never tried render this much footage on one go before.
Could it be anything to do with the drivers i installed for the esata card ?

I'm thinking of reinstalling vegas to se if that helps.
Has anyone out there removed everything from their pc that isn't needed for editing,ie,antivirus,web-browser and associated web programs and anything else i can think of ? Does this make a difference to the pc ?

Thanks,Paul.

Hi Michael,

What is your intended viewing device for your project? If you are producing for computer viewing (and are talking about studio 8 bit in your question) then that should be fine, but the downside is that you will have the colorspace change which will entirely change the look of your video at the end, so you will need to edit with "incorrect" colors until you make the final change.

Also, if you are going for web output, the 32 bit final conversion will produce a huge file in comparison to a 8 bit Computer RGB start point.

Wrong - the Vegas 32bit floating point is the calculation precision setting, and will only increase render time, not the output file size.

For now, not yet having a Blu-ray burner or Blu-ray DVD software, I am rendering to m2t data disk for playing from PS3 (or computer HDD) to common HD LCD/Plasma TV. The 8-bit allows me to see the histogram correctly as it displays similar to the EX1 histogram and when I change to 32 bit for render I see no color changes on my monitor, and my monitor looks almost exactly the same as the final result on a TV screen.

Just to clarify, which 8 bit are you referring to (studio or computer)? I would think it odd if Studio matched your EX1 histogram, and if conversion to 32 bit did not dramtically change the histogram and the colors. Also, when you mention your monitor, are you refing to a computer display or an external monitor?

So many things to clarify :)

u won't see "significant" differences with 32-bit FP, unless you didn't set the levels properly. If the levels are set improperly you will see significant loss of contrast or crushed blacks, depending on whether you clipped or compressed.

If the levels are set properly, what u WILL see is improved detail in the shadows and hilites. If your monitor is not calibrated, the nuances of 32 bit FP will go un-noticed because the monitor is clipping the data.

What Sami posted in post #13 for 8 bit and 32 bit (top 2 examples without any studio to computer RGB) is what I am seeing. I guess I do consider that a significant change, and I would not classify his shot as highly clipped for the subject. In any event, I would not want to make alterations based on his 8 bit and then convert to 32.

It's abundantly clear from his histograms, that his levels were NOT set right! I'm getting so tired of this arguement. Go back and look at his histogram. The highs are out of legal limit and the lows are way above the legal limit. So, in an NTSC display, of course everything looks washed out. Everything must fit in the 16-235 range, not 10-255, not 24-255.

People are BLINDLY applying the studio to computer RGB and computer to studio RGB presets without thinking about what they're doing, nor are they crosschecking the results against the histogram. You can't be unconscious when you start pushing buttons without understanding what you're doing.

I "believe" I am in Computer RGB always. The mxf files from the camera (directs via Clip-Browser -no Cineform) appear to be in Computer RGB because if you do a Computer to Studio conversion you see a change but if you do a Studio to Computer conversion on the mxf files you do not see a change. At present, until I learn a better way, I am making NO levels adjustments and NO color space conversion at any time. I edit in 8-bit so the scopes make sense, but editing in 32 bit by eye seems to me to be just as good. I'm not concerned with legal levels for broadcast - just final result on LCD/Plasma HD TVs played from disk.

There is so much talk about these conversion it seems they need be used at some time I do not know when. Maybe I will find out when I use my Cineform HD but have not run it yet.

You will, eventually end up with clipping from the monitor that will look like it's the NLE's fault. I hope you aren't charging people money for that.

Bill: Don't understand what you mean by "clipping from the monitor". Please explain what you mean and more importantly, tell me what I "should" be doing. That would be very much appreciated and I might even go away.

Mike..

;o) sorry, forgive my rudeness. It's very frustrating that Sony makes this so hard. (OK, it's not all Sony's fault, but, I want to blame them)

DVD players and TV monitors will display colors in the RGB 16-235 range. This is what Sony euphemistically calls "studio RGB", but really, it's "video RGB". The reason broadcast companies have these limits aren't because it's some kind of law. It's because TV sets won't display luma values below 16 or above 100. So, if you deliver a DVD with luma values outside this range, it will clip because the display player and monitor just can't deliver at that value. In fact, some TV sets will go berserk if you feed black levels below RGB16 because that space carries a bunch of sync and timing signals for the TV raster. Now, none of this applies if all you ever do is display on a computer monitor since it CAN and will display 0-254. But, if the LCD display isn't adjusted properly, it will clip anyway, since you've left it no headroom for misadjustment.

OK, what to do. It's really quite simple. If you want to stick to 8 bit, only, that's fine. But, be aware that some codecs like Quicktime, Windows Media(from within Vegas), and all still images come into Vegas in Computer RGB. If you're limiting yourself to working in 8-bit,they MUST be corrected to 8-bit, or you'll suffer image losses.

Rather than keep all this "sometimes I do and sometimes I don't" in your head, it's so much simpler to just look at the histogram for all your clips. If the left end isn't 16, adjust it with the LEVEL FX slider, don't worry about using the preset. If the right end isn't 254, adjust it with the FX slider, don't worry about using the preset.

Can't get much simpler than that unless you want to use the "Broadcast Colors FX", but, it's not recommended because it fixes out of range values by soft clipping.

Understand, please, that we're talking various levels of finesse. In most cases, your average home videographer won't ever see the differences. But, anyone who knows what they're watching, will see it in a moment.

Did I say that all camera records superwhites? I simply didn't say that.

By definition, they are illegal. Y' > 235 is not in legal range. Illegal values are illegal... I don't know how else to put it.

It (the setting under the video processing tab anyways) changes how still images are decoded... turning that setting on will decode still images so that values can end up in the superwhite range (to 'match' other Y'CbCr sources). It's not useful/helpful in my opinion, but that's what it does.

Superwhites are still illegal.

I never said that GPUs explain volumes.

Ok the point is this.

1- Visually/graphically, you can plot out the colorspaces. e.g. you can take 8-bit computer RGB, 8-bit studio RGB, and 8-bit Y'CbCr and plot it out on a 3-D graph. You can pick Y', Cb, and Cr as your axes (or RGB; doesn't really matter). You would see that Y'CbCr has the largest volume, then studio RGB, then computer RGB.

That's what I mean by volume. If you don't have such a graph, then it's not necessarily a helpful way of thinking about things / visualizing things.

2- In the end, it means the same thing. Y'CbCr gamut is larger than studio RGB, which in turn is larger than computer RGB.

So suppose you start you have these two sets of values:
Y' = 254, neutral chroma
Y' = 253, neutral chroma

If you convert those values to studio RGB, you get 253 RGB and 254 RGB. No clipping will happen.

If you convert those values to computer RGB, you get:
(254 - 16) * 255 / 219 --> ~277.12...
(253 - 16) * 255 / 219 --> ~275.96...

Now if you use 8-bit (unsigned int) to store computer RGB, then clipping will happen because 255 is the largest value that a 8-bit unsigned int can represent.

So this is how studio RGB represents a larger range of numbers than computer RGB.

2b- If you use floating point numbers, no clipping will happen because floating point numbers can represent a huge range of numbers. You can look this stuff up in computer science literature.
(*Many floating point implementations use a range of 0.0f - 1.0f; but you more or less get the same results).

Yes you have to if you are making a broadcast master. You either use the broadcast safe filter, or adjust the signal (e.g. the VTR's proc amp) while ingesting, or run material through a video legalizer.

No, it's not true. Yeah it would make sense but it's not true. :(
32-bit Vegas project: HDV decodes to computer RGB levels.
8-bit Vegas project: HDV decodes to studio RGB levels.
Material converted to the Cineform codec decodes to studio RGB levels, regardless of whether the Vegas project is in 8-bit mode or 32-bit mode.

It's pretty easy to tell because you can flip between 8-bit and 32-bit modes, and undo/redo that. You'll either see an obvious color shift or no color shift.

You should be seeing a change... :/

I've already spelled out the answer. Bill means well but he is not giving you the right answer.

Hi Bill,

Thanks for the response. If the end product will be QT, WVM etc, however, it would seem a good way to shoot. Keep the brights just below the clipping threshold (granted, the example appears to be just above) and back them back down in post. Open in 32 bit or convert to Computer RGB and adjust for a nice full 0-255 histogram. Leave a bit of whites headroom if you wish for viewers who may have poorly (or un) calibrated monitors.

Bill... that's not really true.

DVDs store values as Y'CbCr. They do not store values as RGB.

From a practical level, you need to make sure the Y'CbCr values have the right levels. So in Vegas, you need to make sure your R'G'B' values are converted to Y'CbCr correctly. This is tricky because the RGB-->YCbCr conversion depends on what the codec is doing. In Vegas, Vegas' MPEG2 codec will behave differently depending on whether the project is 8-bit or 32-bit.

If you want the color spaces converted correctly, some of my previous posts have that information.

It's such a shame that an amazing program like vegas would leave it's users in such confusion. I personaly have decided that i don't have time for wrangling colour space, i really do expect that to be sorted by the NLE, maybe im asking too much but either way im leaving vegas as i have done my research and these types of discussions on other NLE's are only about 2 or 3 posts long with clear and logical solutions as opposed to a vegas discussion which is 5-6 pages deep with what seems to be a multitude of different routes to an uncertain result.

I never understood why alot of people working mainly for broadcast stayed clear from Vegas, it's not because it's an uncapable program but i think its asking too much time and too much experimenting for something that should be straightforward, and it doesnt help when new codecs and new recording formats are introduced to add to the "ok so what colour space should i use with this" question. Think i'm going to boot edius up until my new mac arrives.

Bill:

In your color restrictions, 16-235, are you not talking old-fashioned CRTs? Are not modern LCD TVs the same technology as computer monitors? Is that not why my rendered files played on a HD LCD TV from a Blu-ray player look the same as my Vegas preview windows? OR am I in Studio RGB when I think I am in Computer RGB?

Because this has become confusing, not just to me but a lot of us, is why I asked to skip the theory and set out a Vegas work-flow for the EX1. That's what Randy asked for initially and no one has done that. Someone who knows he is right please list the next few steps you take after you have the mxf files out of Clip-Browser and on the time-line and what you do when it is time to render. My images are so good I can't believe I'm doing it wrong but opinion is I am. For simplicity lets forget still and generated media, and stick with just the camera files.

Don't forget to get the 4.6 update that directly supports the EX1.

I suspect the reason FCP users don't worry so much is that when Randy Ubillos designed the first generation of what became FCP, he already had years of experience as the person who wrote Premiere. Premiere was, like Avid, based upon RGB. He, like many of us, saw how folks liked Media 100.

Media 100 used YUV and was based on the QT SDK. Knowing that some folks need to output to film recorders -- he included an RGB OPTION in FCP.

In fairness to Sony -- over time users of Apple software have run into nasty issues with 10-bit operation and with unwanted gamma shifts. Why for example does AIC sometimes look lighter than HDV?

Bottom-line, it's often hard to learn how ANY NLE works and how to solve problems.

Pehaps this will help
 

Maybe this is a bit late. Anyway I figure a picture is worth a 1,000 words so here goes. Images are from my EX1, around 1 stop overexposed white paper, masked to extract only one section.

These are from the Vegas 8 scopes, set to Computer RGB. Note, that setting only changes the scaling.

Image 1) Project 8 bit.
Image 2) Project 32 bits, gamma 2.22
Image 3) Project 32 bit with Computer to Studio Levels FX in preview window
Image 4) project 8 bit, Studio to Computer Levels FX applied to clip, Computer to Studio FX applied to Preview.

Hopefully what you can see from 1,2 &3 is that switching to 32bit causes the scopes to indicate that clipping is occuring. Adding the Computer RGB to Studio RGB FX to the preview window gets you back to where you should be on the scopes and in fact nothing gets harmed.

Image 4 shows that attempting the same in 8 bit will bring you possibly unstuck, you can cause real digital clipping in the pipeline.

Bob, this is all very nice... I can play with Vegas levels, RGB conversions, switching 8/32bit, etc. and achieve similar results (BTW it's a question of indiviual taste which is better: a slight clipping here and there, or broader latitude).

The main, simple question as asked by Michael somewhere else (can't keep track of those many threads any more) remains unanswered, though:

- just what is the best workflow for EX1's mxf in Vegas Pro 8?

Therefore, I'm sticking to what I was able to gather from the many interpretations and opinions, but mainly my own experience - i.e.:

- stay in 8bit as long as I don't heavily edit (composit, and such)
- avoid RGB space conversions
- make sure my final render is in proper video format (for HD, "Unspecified" is OK)
- use the preview window for monitoring cuts and alike
- use the secondary display with Studio RGB filter to assess the colours.

Sticking to this procedure, I'm back to the confidence level I had with HDV/Vegas 7. And it suits me for now with my EX1, as well - the BD's I'm burning are simply beautiful!

For output intended for computer monitor, 3 scenarios are workable depending on desired speed of editing:

1. Open in 8 bit (which will be studio RGB without any action), convert to Computer RGB and tweak levels to avoid clipping. Render as is.

2. Open in 8 bit (which will be studio RGB without any action), edit without conversion, convert to 32 bit prior to render and tweak levels to avoid clipping.

3. Work in 32 bit end to end.

All produce gorgeous video.

Yep that will work. It is appropriate for 8bit (but not for 32-bit Vegas project), EX1 footage (MXF, not cineform), and rendering to MPEG2. Change the variables and it may or may not be appropriate anymore.

2- If you have fades to black, you should insert a solid color generator of 16 16 16 RGB underneath.

3- If you want more highlight detail, you can map superwhites into legal range with the Levels filter. I can't remember the exact numbers off the top of my head.

here's a question i can't seem to figure out.

i have footage that i transferred from my ex1 into final cut pro on my mac. my friend wants to take a crack at editing the footage in vegas 8 but the files won't play for him. any suggestions?

thanks,
ag

I was beginning to think I've been making a mountain out of a molehill. Isn't it reasonable to expect a rendered video file to maintain the color balance as set before the render?

So, exactly what workflow will do this? It's pretty clear Vegas8 won't.

Well, I'm not here to flog this horse without offering a possible solution. I have noticed in all the trial runs I've been making, the Cineform Intermediate codec is consistent, repeatable and doesn't distort any of the color mapping. So, conclusion 1...use cineform intermediate for mastering.

OK, how to make MPEG2 files for DVD production: I have a copy of Cinecraft Encoder Basic. Dropping the CFHD.avi file into CCE results in a clean mpeg2 file that stands up to examination of the colors, and duplicates the source file colors quite well.

I can't help but feel we are all missing something as i really can't believe that sony vegas would have such serious flaws, i mean its an NLE that claims to stand up to the best out there and many acclaimed people in the industry have given it the thumbs up, do you mean the likes of Douglas Spotted Eagle and co have missed such a fatal flaw?.

I've been using vegas for years and have always noticed my colours would never be consistent when i render out but i guess its something i got used to. Imagine, a program i have been defending does'nt even have acurate scopes, this is not acceptable. Surely theres something wrong here, i'm going to point sony towards this thread to try and get some answers because im dissapointed.

Daniel...

I can't speak for DSE, and he's always been someone in whom I have a lot of respect. Yet, he's been curiously absent from this discussion.

OK, I think I've been making progress on this topic. Jon Fairhurst has suggested some color corrections to convert from REC 709 to REC 601 and back. While his coefficients haven't worked for me, I think this is the right track. Vegas 8b has all the appearances of having been rushed out the door before its time. It's still a good app IF the engineers at SCS realize that there's some things they need to fix RIGHT NOW. The complexity is too much for the casual user, myself included and I'm hardly a casual user, and they need to automate a lot of it. And it CAN be automated.

IMHO, Glenn Chan has been working prettty hard to get things straight, but, he works for VASST, who's also on the Sony feed bag. None of us have access to harware scopes to figure this all out, like Glenn does. Still, I think their intent is...ummmm.....good, altho' I'm not so sure about the Sony machine. I'm willing to wait for Sony to prove they still have our interests at heart. In the meantime, I'm using Canopus Edius and have been reasonably happy with the output. They're just not as evolved as Vegas...;o(

Many years ago I tried a MacIntosh....what a disaster. I really hate to think of reinvesting everything in FCP. Last resort, worst case scenario, AFAIK.

Oh well, we can hope.

A- Glenn Chan does not "work for VASST." Glenn and I did a color correction DVD together, and it is considered a staple in training for Vegas. He is a presenter on one out of roughly 168 DVDs we offer.

B-VASST isn't at all on the "Sony Feedbag." We create products related to training, including MASSIVE numbers of product for Final Cut Pro, Canon camcorders, Lighting, Audio, Web Compression, Avid, Adobe, Editing/Production, and yes...Sony Vegas and some of the Sony camcorders. We do not receive one thin penny from Sony for our training related to either Vegas or Sony Broadcast camcorders. The implication we are "on the Sony feedbag is a bit bothersome.

C-I'm absent from this thread because believe it or not, I can't find time to read every thread in every forum that mentions the EX1 (which we own 4 of) and/or Sony Vegas software. I try...but can't see them all, not with all the fora out there to be watched. Somewhere in the day, production and revenue takes priority over forums.

Glenn has no financial motivation whatsoever to bring these details to light or to research the subject (outside of his education) so far as I'm aware.
Frankly, I know the workarounds (when they're necessary), some of them are outlined in my Vegas Pro 8 book (for which I also do not receive any compensation from Sony, they have their own book, competitive to mine, written by someone who does not use Sony Vegas, you've never once seen that author post in any Vegas forum, and likely never will).
Glenn is right, of course...DVDs store data as YCbCr. Values for broadcast are different than for DVD, and the codecs behave differently. The only "mistake" I feel Sony have made, is that the scopes currently don't reflect everything that is happening in every mode. I wish it did.

Either way... Sorry my "absence" in this discussion tweaks anyone, but it does seem Glenn has this well in hand.

Maybe this will help.
Recorded Multiformat bars in the EX1, got those into Vegas 8, set project to 32bit 2.22 gamma, rendered out to 50i HDV and bought m2t file back into the same project. The output matches the source, what more can one ask for apart from the scopes being off but that's easily fixed anyway. The attatched screen shots were taken with Vegas switched back to 8 bit. Even in 32 bit both files read the same on the scopes.

An interesting view given IMHO both EDIUS and FCP are far more "evolved" than Vegas: EDL import for batch recapture (impossible with Vegas), dual monitors (so you can actually trim your source clips), professional appearing GUI (you actually have a full set of VTR buttons for both monitors and true toolbars), real 3-point editing (not a crude drag to cursor), realtime video filters, standard high-quality REALTIME lossless codecs (no need to buy CineForm), built from Day 1 as a video editor (no need to deal with audio functions -- like metronome, busses, burn CD -- items many video editors have zero experience with or need of), and in the case of FCP, a full complement of supporting programs include in the box.

To be fair, Vegas offers: built-in 5.1 mixing which I love and its support of Sony camcorders is great. For some, the ability to do audio editing and mixing with the same tool is a virtue, not a vice. And, the neat way of creating transitions is unmatched -- especially for those of us that often drag-and-drop edit.

Edius is used in broadcast around the world (because of GV) and this year's Best Pix was edited on FCP. Don't like these two -- go with Media Composer which remains the broadcast and film editor of choice around the world.

Steve...

my comment about the maturity of the software was aimed at Edius, alone, not FCP. It's not FCP I have a negative opinion for, it's Macintosh. But, that's a personal thing. Some people swear by Pennzoil, some people swear by Mobil1. It's kinda a religious sort of thing. After having used edius for a few days, I must say that I really like working in the YUV space. The display monitor is much better than Vegas', and the real time mxf and m2t playback beats Vegas to death. The edius scopes actually have an RGB/IRE/YUV eyedropper that's just terrific! I really feel the lack of that in Vegas.

Just MHO.

-As far as the original poster's problem goes, I don't have any information to add that isn't in the article(s) on my website or already in this thread. If the information is confusing or hard to follow, then that is my fault. My intention is to explain how Vegas works (especially since some of the behaviours may be unintuitive) and how to get desired results in Vegas.

I think it's fair to say Canopus has always been more concerned with the internals than with providing a huge set of functions. (They are real video geeks.) So I'm not surprised you find missing functions.

And now that they are owned by GV, which wants to sell it to broadcasters, I wonder if they'll add 5.1 sound.

I've often imported into Vegas from FCP/Canopus because of the need for 5.1. (Vegas runs great under Bootcamp.)

I just got my EX-1 the past weekend and I have transfered some files over to Vegas Pro8 for reviewing/editing. For some reason the videos are playing back choppy about 5-10 seconds after the video starts. I feel like my system is not able to handel it.

My computer specs are:

Intel core 2 duo 2.4ghz
2gig ram
nvidia 8800GT 320mb superclocked
500gb 7200rpm hard drive
Windows Vista

Is it my system or have I not tweaked Vegas correctly?

Feedback appreciated

-Dennis

What is your preview window set to? Running anti-virus?

I turned off anti-virus and there was no difference. The first time I ran a preview tehre was no problems but on the second day I started to see the choppyness and sound was also choppy. Preview window I believe is set to good or auto...

It helps ALOT to turn off 32 bit FP.
It also helps to convert to cineform intermediate before ever bringing your footage into Vegas.
Another thing to do for smoother playback is to ensure your project settings match your input data characteristics.

Even with all these things, my laptop, which has the same processor as you report and Windoze XP Pro, stutters on playback of native EX1 HQ files in Vegas. My guess is that the 1920x1080 format just takes the breath out of these processors.