speak about correct working.

see matherial from vegas on TV thru (mini)DV-CAM, then apply any of effects (example put timecode - frame will be recompressed - and you see difference on TV, that you can't see on PC

I think you're problem may relate to having converted from YOU->RGB and then output RGB into a YUV color space.

You'll notice in the Broadcast Color FX a check box that says RGB->YUV, that may address the issue.

Also you need to remember that the NTSC color space is different to the PAL color space.

DaLIV,
I've tried translating the thread on the Russion forum to see axaclty what is being said but I'm sorry to say the translation made less sense to me than the Russian.

I'm certain there's a few people here who could shed some light on this but where going to need some input we can understand.

Also I tried to download the sample file, I can view it but can see no way to save it.

if your DV camcorder is PAL and can passthru dv input to TV - then place this frame on timeline (external monitor enable in preview and set checkbox recompress edited frames) and you can see on TV pure orange color of sun, but on pc monitor will be more yellow color. if you then apply any of effects to input (simplest is tv code) then on TV you will see the same picture (with yellow color) as on monitor.

if your camcorder is NTSC - then you need to create another sample - this can be got next way:
film the sunrise and check this video on TV - find where is sun is orange - and you will be able to see this effect. (so luma of sun is over the range so zebra effect when you film this will shows - it's will be normal)

this problem got in YUV->RGB conversion, back conversion may be not have this effect (not tested as no possible correctly get this frame in RGB colorspace).
when decode this frame you will got out of range YUVs and colors will be falsed.

I'm in PAL land so I'll try it out.
I could NOT get the sample image to download so I'll have to find something else to try.

I suspect the problem maybe that the colors are WAY outside the legal range in which case I'd expect any codec do do odd things with it. Does the same thing happen if you stop the camera down so the luma isn't out of range i.e. illegal?

If you use WMP9 and kick the URL off in it or indirectly via IE then use File| Save Media As to save the content away.

Otherwise drop that URL into FrontPage, or a notepad HTML document and right click the Save As in preview.

Otherwise try to save this:
Clip to test


Colour space is said to be 8bit RGB in Vegas but it does do a good job with YUV.

YUV is dominant in tape formats whilst RGB does exist as consumer "component" (baseband video) in Europe and the Pacific Rim, YUV is known as the consumer component video format in NTSC countries, for historical reasons. RGB/YUV do live in the electronic domain quite interchangably but with a similar bias to the aforementioned regional considerations. Where does that leave us?

Conversion of colourspace is an issue that some of the other NLEs say they are better than Vegas at by having project based colour resolution. Vegas has had the advantage over some of these by being hardware independent and by having spacial resolution for effect/transitions and positional/scaling controls. Even without mentioning the adaptive frame rate technology it possesses.

Still, there are situations where having a 10bit pipeline, RGB or even a YUV infrastructure would be worth having. AFAIK, 8bit RGB isn't on the packaging for Vegas, and neither is the acceptance that Vegas has something wrong with its ability to serve YUV data through its RGB pipeline and maintain registration, latitude and hide any errors with these that might otherwise show up on a colour match or assessment of contouring.

Perhaps "10-bit conversion" (or higher during the conversion) could be made a preference in Vegas5 (or whatever). Or even the ability to state that YUV/YUY2 working might be how the editor wishes a session to be calculated in. Whilst SSE/MMX instructions can help with conversion. The task does have an impact on performance. However a YUV pipeline would typically be a major rewrite to move or add that feature into the existing range of capabilties on Vegas.

There are however other software only NLEs that work in YUV space without conversion (except for input formats that only have representation/codec support for RGB). I'll name them if anyone wants to hear 'em?

I've done that with your AVI file and I did tests like this dozens of times in the past. If I render your AVI using Sony Pictures DV there is absolutely no difference to the original file regarding chrominance or luminance. Not on PC monitor, not on external monitor, not on the waveform and not on the vectorscope.

If you can see a difference in color or luminance then it is likely you are not using Sony Pictures DV either for encoding or for decoding. Sony Pictures DV does not make any changes to the color and luminance space no matter what which range the file has. And this is the way lots of dv codecs are appreciate to work.

Marco

>> I suspect the problem maybe that the colors are WAY outside the legal range in which case I'd expect any codec do do odd things with it.

This is true for codecs like Microsoft DV but not for codecs like Sony Pictures DV. Sony Pictures DV handles full color and luminance range. 0-255 will bei 0-255 after rendering and after decoding too.

Marco

Marco,
I'm 99% certain you're right. The question is I think what happens when you move a color into the YUV space?
From my limited understanding of these complications PAL has a restricted color space meaning that not all the range of colors available in RGB can be rendered in the PAL YUV colorspace.

What I don't understand is he's saying the image looks fine in the camera and even after forcing a rerender it looks fine on the PC monitor but after it's been rendered it looks different on a TV.

Whatever this is all about, its running at around 4 pages of posts on the Russian forum!

PAL colorspace of digital YUV signals are defined as:

0 is reserved for control signals

1 - 15 is footroom buffer

16 is black

235 is white

236 - 254 is headroom buffer

255 is reserved for control signals

This is what CIRR 601 says. So digital PAL signals can be 1 to 254. Remind 1 - 15 and 235 - 254 is a buffer range for under- and overexposure. Any PAL dv camera can record signals from 16 to 254, though it's YUV 4:2:0.

Some TV devices do limit the signal range from 16 - 235 (mine do NOT limit the upper range). Broadcasting stations do usually not allow signals below 16 and do limit signals over 235 when broadcasting. But this is a bit different to what digitial PAL YUV allows in generell.

Back to what DV codecs do:

There are several ways to proof codecs behaviour regarding luminance and chrominance. And there are different behaviours sometimes speaking of decoding or encoding. But Sony Pictures DV codec does not touch luminance or chrominance, neither when encoding nor when decoding.
Quite different work dv codecs like MS DV. This codec does compress the range down to 16 - 235 when encoding. And it does expand the range up to 0 - 255 when decoding. And this causes problems especially when decoding a YUV signal to RGB in some cases. For example if you shot a very light blue sky with your PAL dv camera, capture this and watch this shot using MS DV for decoding. This might cause the light blue sky to turn to white if the blue ranges have luminance values above 235. And - if you have light orange this will be turned to yellow then. This is very typical for this kind of dv codecs. But this does not happen when using dv codecs like Canopus dv or Sony Pictures dv.

As I said before - I tested this lots of times, even today with that sunset AVI file (which is not 16 - 235 but about 8 to 254). Rendering that AVI using Sony Pictures DV does no harm in any way.

Marco

Marco

if your external monitor connected to videocard - then you will not see changes as they works in rgb colorspace ... - you need output thru DV.
on TV are you see pure orange color or as on monitor with yellow color ?
this frame have no yellow color at all - and on pc you can't see this effect - only if without recompression passthru DV on TV.

you are right. you are not understand - YUV can have more colors than RGB24 suggest.
try YUV=252,68,150 - you will got RGB=310,280,154 - and as you see RGB will be cut to 255,255,154 - so colors losses.

advertiser .... - you work in sony ?
so let's make to me this values to rgb24 and back -and say are you able preserve this data working with soft that use RGB24?
YUV --- must be RGB --- RGB cutoff by any of codecs (sony also ...)
89 197 70 --- 224,52,-8 --- 224 52 0
204,171,90 --- 306,199,158 --- 255 199 158
214,184,76 --- 343,205,147 --- 255 205 147
47,181,85 --- 143,10,-33 --- 143 10 0
35,174,9 --- 115,-1,37 --- 115 0 37
255,139,124 --- 300,271,272 --- 255 255 255

all data frame in previous postings - and i'm already calculated to tou rgb - you can check ...

Actually you have it very much the wrong way around!

RGB can represent a much GREATER range of colors than YUV as used in televsion, that's where the problem comes from.

Also in the YUV space there is a difference between NTSC and PAL, to get technical PAL uses YUV and NTSC uses YIQ and the conversion equations are slightly different from RGB to YUV and YIQ.

I wasn't able to find a really good reference to this but I remember someone showing me the difference on one one of those color space vector diagram thingies that shows the color space for PAL and NTSC and the space that PAL can represent is smaller than that of NTSC.

try to calculate RGB values (remember that all soft use RGB24 - 8-bit for each color) from this Y-U-V values : by NTSC or by PAL as you want (it's no matter so it's only pixel order in macroblock defined, but not yuv2rgb conversion - that same for both)
89 197 70
204,171,90
214,184,76
47,181,85
35,174,9
255,139,124

I only have the equations for RGB->YUV and it's been too long since I learnt the maths to do the algebra so I've asked some to do the conversion for me.

However just looking at some of the numbers I'm pretty certain they are not broadcast legal i.e. no camera should be producing them.

My point was that in Vegas or most other NLEs that work in a RGB space you can produce RGB values that cannot be translated into YUV values that are within the limits of the broadcast specs. At the same time many cameras record values that are outside broadcast legal.

None of this is an issue specific to Vegas or even television, the same limitations apply going from RGB to CYMK.

And by the way not ALL NLE software works in 8 bit RGB space.

How comes your sunset AVI look absolutely identically after I rendered it to DV AVI (PAL)?

Marco

formulas you can find on : http://www.fourcc.org/fccyvrgb.php
camera will produce this values (if you have zebra - then it's will shown /any of matherial is not possible film without overluma)

not all work in rgb24 -it's right (and in addition any work in YUV) - but most of plugins works only in rgb24 - so if do not use any plugins - then you can do anithing, but not all what wanted.
not all rgb24 can be converted to broadcast - but here we discuss about problem:source matherial can not be processed without losses not pc generated matherial praparing to broadcast.

you render in vegas - then when you place on timeline - that was set length to your preffered - but no recode applied - so you got not passed thru decoder but simply copy this frame to your length.
if you want make any recodings - add timecode FX - then you will see differences (one more time i'm want to say - not see on PC or thru TV-out but thru DV)

Well yes you are absolutely right, many things can be shot in a video camera, can look great in the camera, can even look great on a precision studio monitor and look like rubbish when broadcast.

I have a DVD of material shot on a very high end camera, probably using 10 or 12 bit resolution, converted to mpeg in 4:4:4 and it looks stunning.

There ar many instances and I found lots of material on the web about how color rendition can go wrong when converting between color spaces. Each one is a compromise that works OK most of the time, convertting from one compromise to another has always been a problem in anything.

Let me see if I fully understand your problem:

You shot a sunset with a camera. Played that back to a TV. All looked fine.
Capture that into Vegas. Looks the same on PC monitor.
Send to TV via A/D converter to TV, still looks fine.
Add Time Code FX and render out. Still looks fine on PC monitor.
But now looks different on TV.

So what can we conclude from that?
Well presumably the render after the FX was added didn't change the RGB values or it would look different on the PC monitor, right?
But you're saying when the RGB values after the render are converted to YUV there is a difference?

Sorry but something doesn't make sense there. If after the render it looked different on the PC monitor AND the TV, that would make sense, something happened to the image during the render process but from what you say that didn't happen.

I did exactly this. If you see changes after rendering then you didn't use Sony Pictures DV.

Marco