View Full Version : How necessary or important are the BT.709 parameters?
poisondeathray
12th May 2010, 20:03
It's not that simple as well :devil:
Small preview is done in computer RGB. Full screen preview on OCHI compliant IEEE 1394/DV monitor is done in studio levels.
Full screen preview in widnows secondary display can have color correction applied. If you select icm profile it will look different. If you check "Use studio RGB (16-235)" it will... well, you get the idea.
Yes, hence my multiple recommendations to use a calibrated broadcast monitor :) . I was simply relating one of the most common pitfall for most vegas users - they are trying to color correct to the preview but get something entirely different. The explanation why is as above.
And I agree it's not that simple either. :) The small preview uses the windows GDI interface, so it's appearance will depend on the graphics card settings for the desktop which maybe different (and usually is) that that for the graphics card display settings overlay mixer which is used for many media players...
Even playback in the media player can have so many factors, from decoder, renderer settings etc...
For most camcoders (including Sony AVCHD camcoders) Vegas keeps TV Levels in 8-bit and 32-bit Studio Levels modes.
I think you are mistaken; it expands to full range (native AVCHD) in 32-bit mode. (I should be more clear - In Vegas 9 you have the option to keep video levels or studio RGB in 32-bit mode.)
Quicktime sources mostly produce PC levels.
There is more than just a levels shift, a gamma shift as well . This is a well documented "quicktime gamma shift bug"
Keiyakusha
12th May 2010, 20:06
Warperus
The biggest problem is that sebazvideo don't want to post real samples before processing and after exporting from vegas and after encoding it. And then describe what he sees with this particular samples and what he expect to see of course.
Most of this talks is just guesswork. We don't even know if we talking about same things. For example video with a lot of green colors may look like have some problems with levels, but in reality the problems is color coefficients. etc.
sebazvideo
12th May 2010, 20:07
Well, then it looks like sebazvideo will never find consistency with Vegas :Р
Well, maybe not, I'll just be happy if I can get the video encoded in x264 with the same visual levels. Even if the theory behind it is not 100% correct, as long as it looks the same on my blu-ray player and TV set both in factory picture settings than when I'm editing in Vegas, I'm happy.
sebazvideo
12th May 2010, 20:09
I'm afraid he wants full range x264 output. And I'm not sure if it's a reasonable wish...
Full range or not, what I want is that when I do the final encode and I author it to a BD, that it looks the same on my blu-ray player than it looks in the Vegas timeline. It won't look exactly the same, obviously, because of the extra compression, but as long as it looks good and the dark areas look as dark as I set them to be while editing in Vegas, then I'm happy.
poisondeathray
12th May 2010, 20:11
Well, maybe not, I'll just be happy if I can get the video encoded in x264 with the same visual levels. Even if the theory behind it is not 100% correct, as long as it looks the same on my blu-ray player and TV set both in factory picture settings than when I'm editing in Vegas, I'm happy.
"same visual levels" as what? the vegas preview? (i.e. the preview that is using full range and illegal :) )
I mentioned this earlier, some setups can handle full range material. But I would say >99% cannot.
If yours can, great. But if you take your disc to a friends house for example, you're not going to be pleased
sebazvideo
12th May 2010, 20:13
Warperus
The biggest problem is that sebazvideo don't want to post real samples before processing and after exporting from vegas and after encoding it. And then describe what he sees with this particular samples and what he expect to see of course.
Most of this talks is just guesswork. We don't even know if we talking about same things. For example video with a lot of green colors may look like have some problems with levels, but in reality the problems is color coefficients. etc.
I could post some samples, except the exports to uncompressed RGB and Lagarith, because those are huge. I could narrow the 15 seconds to maybe 5, but still the unc. RGB would take forever to upload. Besides, I have a million things to do and running out of time, so I can't keep spending hours performing these tests, at least for now.
sebazvideo
12th May 2010, 20:16
"same visual levels" as what? the vegas preview? (i.e. the preview that is using full range and illegal :) )
The secondary monitor preview in Vegas, without using its color profile option, has the same levels (at least visually) than the footage from my camera. So I apply filters based on that, or maybe not, I just do straight cuts, depending on the project. So as long as the final encode has the same visual levels (meaning the dark areas look as dark as in the original footage or as dark as a set them to be in Vegas) that's all I need.
Keiyakusha
12th May 2010, 20:22
Full range or not, what I want is that when I do the final encode and I author it to a BD, that it looks the same on my blu-ray player than it looks in the Vegas timeline. It won't look exactly the same, obviously, because of the extra compression, but as long as it looks good and the dark areas look as dark as I set them to be while editing in Vegas, then I'm happy.
Please understand that you need to solve that by yourself based on all information you got in this thread. If you want someone to teach you Vegas, you need at least real samples because this thread already full of theory.
I could post some samples, except the exports to uncompressed RGB and Lagarith, because those are huge. I could narrow the 15 seconds to maybe 5, but still the unc. RGB would take forever to upload.
A couple of frames from different positions should be enough.
poisondeathray
12th May 2010, 20:42
The secondary monitor preview in Vegas, without using its color profile option, has the same levels (at least visually) than the footage from my camera. So I apply filters based on that, or maybe not, I just do straight cuts, depending on the project. So as long as the final encode has the same visual levels (meaning the dark areas look as dark as in the original footage or as dark as a set them to be in Vegas) that's all I need.
But how are you determining what the original footage "looks like?" (Please don't say vegas in 8-bit mode)
Just because the 2nd monitor preview "looks like original footage" - this is of little value.
The purpose of the 2nd monitor is to emulate what you would get on a DVD / Blu-ray / broadcast, not calibrated to "same visual characteristics as you original". Your goal isn't to make it look the same as the original - who cares if it looks the same... your goal is to be able to color correct and make adjustments and see in real time what you would get on the blu-ray/dvd etc...with legal settings.
Warperus
12th May 2010, 21:34
As far as I remember original footage looks like footage played by camera directly connected to TV set.
In a perfect world computer connected to that same TV set produces the same result in secondary Vegas display (with proper calibration).
Then you burn BD directly from Vegas and get the same result... in a perfect world.
sebazvideo
13th May 2010, 00:50
OK, so this week I'm way too busy, but I really want to learn more about this, so next week I'll find something that I can shoot for a few seconds so I can upload that clip and the exports and you can all give me your impressions if you want. This is really interesting to me but until next week I can't really spend more time on it.
diffid
13th July 2010, 16:16
I never mentioned still images. My comments were specfic to what he was using, i.e AVCHD video. Native AVCHD is treated as studio RGB (16-235) in 8-bit mode internally, but the preview display is computer RGB ,hence the big confusion.
I've found that my mpeg2 shooting Canon Vidcam, my Canon video shooting DSLR and an old DV cam, all shoot close to full range 0 - 255, not minor excursions.
If Vegas expects 16 - 235 then does it squash the 0 - 255 into 16 - 235 or crush and clip?
poisondeathray
13th July 2010, 17:01
I've found that my mpeg2 shooting Canon Vidcam, my Canon video shooting DSLR and an old DV cam, all shoot close to full range 0 - 255, not minor excursions.
If Vegas expects 16 - 235 then does it squash the 0 - 255 into 16 - 235 or crush and clip?
Nope, it doesn't crush or clip in 8-bit mode. It keeps the excursion data in that range, but it's up to you to make it "video legal". If you don't make it "video legal", then it will be blown out if you put it on a DVD or blu-ray on the majority of setups. Play with the luminace waveform monitor in vegas, it will help you understand what is going on.
All this means is the YUV=>RGB conversion isn't expanded to 0-255 (but in 32-bit mode full range, it will be expanded to 0-255 i.e. white is mapped to 0, black to 255).
The earlier discussion was regarding how Vegas' small preview windows differs from what you actually get for a variety of reasons.
The Canon DSLR footage may act differently, because of quicktime wrapper. There maybe gamma shifts and levels issues (depending on what your frame of reference is)
diffid
13th July 2010, 21:18
Ok, thanks again.
One last query,
"All this means is the YUV=>RGB conversion isn't expanded to 0-255 (but in 32-bit mode full range, it will be expanded to 0-255 i.e. white is mapped to 0, black to 255)."
In 32bit mode then if I have a file where lowest value is say 7 and highest 253, you're saying that it gets expanded to 0 - 255 in 32bit mode, not left where it is?
I'm aware the 32bit mode is for higher precision calcs, less rounding errors on the image processing, but not aware it expanded.
I play around with some clips and watch the waveform, as you suggest to get the hang of it.
foxyshadis
13th July 2010, 22:14
Sounds useful; if the camera's automatic exposure clipped highlights or lowlights, you can retrieve them in post-processing if desired before clipping to 16-235.
poisondeathray
13th July 2010, 22:21
In 32bit mode then if I have a file where lowest value is say 7 and highest 253, you're saying that it gets expanded to 0 - 255 in 32bit mode, not left where it is?
Usually yes, but it also depends on the input file format type and which type of 32-bit mode, and also the export format. Look at the charts from the glenn chan articles posted earlier. Different formats will behave differently in vegas.
Also in Vegas 9, you can specify 32-bit mode video levels instead of full range. In Vegas 8, 32-bit mode always expanded using full range
The export format also matters. Vegas is very weird so you have to experiment a bit - different export formats also behave differently. Some YCbCr export formats (converted from internal RGBA) are re-expanded some are compressed. Remember all this confusion is from colorspace conversions; basically where to map "white" and "black", but also the other calculations for the conversion. If you import a YCbCr format, it may or may not be converted to RGB internally (usually is except for smart rendered formats) , and may or may not be exported as RGB or YCbCr. Each colorspace conversion is a step where something can get mapped incorrectly or not to your expectations.
To make matters worse, the Vegas small display usually has no correlation with whats actually going on. The small display uses the windows GDI desktop settings (not the graphics card overlay settings) - so it will look very different than if you played the same video in a media player like WMP or MPCHC that is using overlay mixer as the renderer
Also, DV-AVI is a special case, because it is smart rendered in vegas (allows passthrough of untouched segments, and re-encodes only affected GOPs where you have things like transitions or overlays) , but as soon as you do some global filters like color correct - it functions in RGBA, not YCbCr colorspace. If you do cuts only editing , with no effects, vegas is working in YCbCr with DV-AVI - so levels are passed through same as the source - because there is no colorspace conversion.
Warperus
15th July 2010, 15:11
In 32bit mode then if I have a file where lowest value is say 7 and highest 253, you're saying that it gets expanded to 0 - 255 in 32bit mode, not left where it is?
There are 2 different 32-bit modes in Vegas 9: full range and studio levels.
There are 4 general possibilities:
1) Light-grey 253 stays at 253, dark-grey 7 stays at 7.
It is normal situatio if full range video is imported into vegas full range 32-bit mode.
It is nearly normal situation if studio levels video (with illegal values) is imported into vegas studio levels 32-bit mode.
Generally this situation should be handled with before you process your video further. Apply color balance or color correction.
2) Light-grey 253 is shinked down to ~234, dark-grey 7 is shrinked up to 22.
It is normal situation in case of full range file and studio levels 32-bit project (that is, decoder like ffdshow shrinks 0-255 into 16-235).
3) Light-gray 253 is clipped down to 235 (as well as everything above 235 is clipped down to 235). Dark-grey 7 is clipped up to 16 (as well as anything other lower than 16).
Quite possible situation in studio levels 32-bit project (and 8-bit project), it happens in case of clipping being applied to illegal values in decoder.
I've got such result in ffdshow with obviously improper (yet default for that K-Lite codec pack) settings with fraps (it was CGI full range source).
4) Light-grey is clipped up to 255 (as well as anything else higher than 235 in input file), dark-grey is clipped down to 0 (as well as anything else lower than 16 in input file). Here 16 becames 0.0, 235 becames 255.0
Situation is similar to previous (3), but it may happen in full range 32-bit project.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.