Sony Vegas - need to apply Studio RGB to PC RGB Effect

[Butcher Wing]

I couldn't tell where to post this one. Point me in the right direction if there is one.


The problem I have - Whenever I open a commercial dvd VOB in Sony Vegas it looks too 'bright' with reduced 'contrast' and reduced 'saturation'.

Anyway, after much trial and error I discovered that I had to apply the "Studio RGB to Computer RGB" filter to the time line to get the image to look like it should. ie: normal

So, why do I have to apply this filter? I shouldn't have to. It should look correct without any filters applied. :( Someone else I know edits in Sony Vegas and doesn't have to apply the filter.

[poisondeathray]

because sony vegas uses "studio rgb" in default 8-bit mode

this means Y'CbCr [0,255] video gets converted to 16-235 RGB . ie. Black gets "mapped" to RGB 16,16,16 , white gets "mapped" to RGB 235,235,235

other programs have black at 0,0,0 and white at 255,255,255

have a look at these articles
http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm
http://www.glennchan.info/articles/vegas/colorspaces/colorspaces.html

EDIT: it should say Y'CbCr[16,235] => RGB[16,235] for studio RGB, see below

[Butcher Wing]

Let's just say.. I don't understand all that stuff. I've read that site before and went cross eyed.
That site did help me to work out why my videos were looking so bright and low in saturation though.


But what I really want to know is... Does everyone need to apply this "RGB filter" to their projects then?

Because my friend reckons he's never come across this problem with Sony Vegas.


I use Sony Vegas 7. He uses Sony Vegas 8.

[poisondeathray]

You can use 32-bit mode and it will expand the range instead of RGB16-235. I can't recall if vegas 7 has it, it might have been introduced in 8 . 32-bit mode is a lot slower to render projects

[Butcher Wing]

Ok, cheers. I guess I'll stick with applying the RGB conversion filter. Or get a newer version of Vegas. :D

[Butcher Wing]

Installed Vegas Pro 10


Edit: In project properties I found and enabled ---"32bit floating bit point (full range)"--- and it went to the correct RGB. Yay!

That's good, but should I need to do that?

[Wilbert]

because sony vegas uses "studio rgb" in default 8-bit mode

this means Y'CbCr [0,255] video gets converted to 16-235 RGB . ie. Black gets "mapped" to RGB 16,16,16 , white gets "mapped" to RGB 235,235,235
Looking at the articles i get the impression that YCbCr [0,255] is mapped to RGB [0,255] in studio rgb mode (since they state that the legal range of Y is [16,235] and it doesn't make sense to map the illegal part of the Y range in RGB [16,235]).

[poisondeathray]

Looking at the articles i get the impression that YCbCr [0,255] is mapped to RGB [0,255] in studio rgb mode (since they state that the legal range of Y is [16,235] and it doesn't make sense to map the illegal part of the Y range in RGB [16,235]).

You're right , it doesn't make sense.

The whole premise of "studio RGB" is to retain the full range of Y'. The article says "This color space can be useful, since it will retain a lot of the useful illegal values from Y'CbCr signals" , and I thought that for many years, until I actually tested it.

My testing show you lose Y' <16, >235 when inputting a full range Y' source when using studio RGB. I cannot recover any data at all in that range with any filter

Their tech supports say that nothing is clamped or clipped, but my tests show otherwise.

The only way I am able to preserve full range Y', when using sony vegas , is to use avisynths' "PC" matrices , or correct in Y'CbCr space using avisynth filters before the RGB conversion.

I'll test it again today



EDIT: yep, I'm pretty confident that's what's going on. I repeated these tests with v8 and v9. I used a RGB test chart with known full range values (converted to full range Y'CbCr with avisynth PC matrix) and tested with various full range Y'CbCr compression formats (in case vegas' decoder handles some formats differently), even uncompressed 8-bit Y'CbCr. Uncompressed RGB was exported each time to analyze the results (in case the vegas preview was incorrect, or vegas does some funky business with export compression)

[Wilbert]

Pretty bad if this is true. Does that mean that there are no values at all outside RGB [16,235]?

EDIT: yep, I'm pretty confident that's what's going on. I repeated these tests with v8 and v9. I used a RGB test chart with known full range values (converted to full range Y'CbCr with avisynth PC matrix) and tested with various full range Y'CbCr compression formats (in case vegas' decoder handles some formats differently), even uncompressed 8-bit Y'CbCr.
Just curious. How did you create the Y'CbCr clips?

[poisondeathray]

Pretty bad if this is true. Does that mean that there are no values at all outside RGB [16,235]?


Just curious. How did you create the Y'CbCr clips?


I used vdub in "fast recompress mode" and used a belle nuit test chart with avisynth to convert to yv12 using Pc matrix . I verified with histogram() on the various export formats from vdub that Y' levels were indeed correct full range before importing into vegas (in case I forgot to use fast recompress , or there was a rec601 conversion, or vdub was doing something funky)
http://www.belle-nuit.com/testchart.html


ImageSource("testchart720.tif")
AssumeFPS(24000,1001)
Trim(0,24)
ShowSMPTE(size=30)
ConvertToYV12(matrix="pc.709")



If you use "IYUV" from drastic codecs, then there are values outside RGB 16-235. This is what that article refers to as "uncompressed" where levels are passed through. Note Vdub's YV12 "uncompressed" behaves differently in vegas, just like all the other formats. I posted about this before with other programs too. For example quicktime pro handles IYUV differently than vdubs "YV12" when you select "no compression"
http://www.drastictech.com/download_codec.html

When you select "no compression" in vdub, the codec ID is different.

VDUB
Format : YUV
Codec ID : YV12
Codec ID/Info : ATI YVU12 4:2:0 Planar

DRASTIC IYUV
Format : YUV
Codec ID : IYUV
Codec ID/Info : Intel Indeo iYUV 4:2:0

IYUV is passed through correctly . Vdub's YV12 uncompressed isn't - it's clipped just like many other compression formats

I tried other formats, including mjpg, x264 using CLI (with the same avs script), UT video codec, lagarith, (all in YV12 mode, verified with avisynth info() and checked with histogram() before importing into vegas), many others

I would characterize the end result functionally as "clipping" because "clamping" would imply values are just squished . Although neither happens according to the waveform monitor in vegas - the superbrights/superdarks are not clipped or clamped and they are accessible - BUT you cannot see the gradations beyond 235 with any adjustment. It becomes 1 big bar. For example you cannot see the 239-251 demarcation. I couldn't find any combination of levels filters etc.... to recover the "superbright/superdark" values within vegas to usable values ie.. 0-15 becomes 1 black bar without gradations (with the exception of IYUV).

From these observations I think it would be more accurate to say YUV[16,235] gets mapped to RGB[16,235] in studio RGB mode (with the exception of IYUV). And looking at my old notes this is what a tech support said: "We do not map YUV 16-235 to RGB 0-255, in fact we keep YUV 16-235 as RGB 16-235" .

[Emulgator]

A warning about drastictech by me (just had this happening here):

WARNING !
Installing Drastictech codec 3.0.0 might destroy functionality of Edius 4.61.

After installing Drastictech codec a new Edius project can be built,
but already made projects with source files in uncompressed YUV, fourCC YV12 (ATIYVU12 4.2:0 Planar)
stall Edius on startup.

Uninstalling Drastictech and restart did not help !

Only System Rollback to a previous restore point got Edius functionality back.

P.S. Whatever the merits, I did not want to hand-edit registry in a beautifully working system.
The settings of this codec are only available through VirtualDub's compression settings
on any other VFW codec-aware app anyway.
Such hidden behaviour, no disabling and a incomplete uninstall is what bothers me a bit.

[kolak]

You have to manually remove Drastic's dlls. Uninstaller does not work properly!


Andrew

[poisondeathray]

Thanks for the warning.

Note vdub uses YV12, so the U & V channel order is swapped . As mentioned earlier , some programs may handle IYUV/I420 differently than YV12 .

http://www.virtualdub.org/blog/pivot/entry.php?id=206
http://fourcc.org/yuv.php#YV12
http://fourcc.org/yuv.php#IYUV

Does anyone know of other options to render IYUV/I420 other than drastic or blackmagic ?

EDIT: maybe Helix ?
http://forum.doom9.org/showthread.php?t=56972

[kolak]

Thanks for the warning.

Note vdub uses YV12, so the U & V channel order is swapped . As mentioned earlier , some programs may handle IYUV/I420 differently than YV12 .

http://www.virtualdub.org/blog/pivot/entry.php?id=206
http://fourcc.org/yuv.php#YV12
http://fourcc.org/yuv.php#IYUV

Does anyone know of other options to render IYUV/I420 other than drastic or blackmagic ?

EDIT: maybe Helix ?
http://forum.doom9.org/showthread.php?t=56972

Use UT Video codec- lossless and amazingly fast. It supports RGB, YUY2 and YV12.

Andrew

[poisondeathray]

Use UT Video codec- lossless and amazingly fast. It supports RGB, YUY2 and YV12.



Thanks, I usually do

But there are specific circumstances where IYUV is treated differently, whereas other formats undergo other processing incl. UT, huffy, lagarith , FFV1 etc....

[2Bdecided]

But what I really want to know is... Does everyone need to apply this "RGB filter" to their projects then?No. It looks completely wrong while you're editing it without that filter, but some outputs will map 0-255 "studio" RGB > 0-255 standard YUV/YV12. Meaning everything looks right in the final output, but not when you're editing! Other outputs don't do the mapping, meaning it looks just as wrong in the output as when you're editing.

So, try a test edit, use whatever output you intend to, and view it. Try it on different players too (depending what it is) - sometimes some of those expand it again (even more = too much) while others don't.

@poisondeathray, isn't there a "keep superwhites/blacks" option somewhere? I'm sure I've done a full HDV project in Vegas and got the original superwhites out intact. I could be wrong. I bet Google knows ;)

Cheers,
David.

[poisondeathray]

No. It looks completely wrong while you're editing it without that filter, but some outputs will map 0-255 "studio" RGB > 0-255 standard YUV/YV12. Meaning everything looks right in the final output, but not when you're editing! Other outputs don't do the mapping, meaning it looks just as wrong in the output as when you're editing.


Thanks - I forgot to mention that - that was one of the reasons I used uncompressed RGB for the little tests, so there were no other conversions.

As an illustrative example, exporting WMV is handled differently by vegas than say h.264/mp4 (vegas handles the RGB=> back to YV12 conversion differently for some formats)



So, try a test edit, use whatever output you intend to, and view it. Try it on different players too (depending what it is) - sometimes some of those expand it again (even more = too much) while others don't.


This is important too . They are unreliable for testing. A normal media player won't convert to RGB using a PC matrix, so the preview won't display superbright/superdark values. Some use Rec601 , some Rec709. They are affected by renderer choice & settings, some by graphics overlay settings, internal settings... very inconsistent



@poisondeathray, isn't there a "keep superwhites/blacks" option somewhere? I'm sure I've done a full HDV project in Vegas and got the original superwhites out intact. I could be wrong. I bet Google knows ;)


No, you're correct . Some quick tests confirmed this. It seems the "native" formats like DV, HDV preserve their superwhites (and superdarks if the camera shoots them) . Even a "grey scale" test chart with known values with encoded with mpeg2 wrapped in a transport stream preserves them. Interestingly Premiere has related behaviours with "native" formats , but it's version of "uncompressed" that passes everything through is v210

But it seems like the popular formats used for "lossless" intermediates aren't necessarily treated as lossless by vegas (e.g. huffyuv, lagarith, ut video etc....)

What a mess. I guess the moral of the story is to test your workflow & software end to end