PC and Video levels - something I don't quite understand

[Lyris]

I'm aware of the different ranges used by PC and TV 8-bit video: 0-255 for PC, 16-235 "usable" for video. When I calibrate TVs, I always set Black as 16, with 17 just being visible.

This is what I don't understand. I go into Photoshop and create two distinct black boxes in a 720x480 video frame. The box on the left has RGB values of 0,0,0. On the right I make a box that's 16,16,16.

Then I make a 500-frame video file out of this frame (using Sony Vegas Pro 8) and render it out to a YUY2 .AVI file using the Lagarith codec. I then use Cinema Craft Encoder SP3 to encode and send this out to DVD.

So on the calibrated TV that's been set up using accurate test patterns (so that the Black Level is 16), it stands to reason that all I should see on the screen is nothing, just black, correct? What actually happens is that the portion I made 0,0,0 shows up as absolute black and the 16,16,16 value is lighter grey.

Since I don't have hardware scopes of my own to confirm, can someone explain what's going on here? Is what I created in Photoshop as 0 being set to 16 by something on the PC side?

[poisondeathray]

Vegas expects computer rgb (0-255) from still images. So it thinks 0 = black

Export out as RGB (e.g. uncompressed AVI), then use avisynth to scale it e.g.

ConvertToYV12(matrix="Pc.601") #or Pc.709 for HD content, add interlaced=true for interlaced content

Specifying a PC matrix for your RGB=>YV12 conversion will stretch the contrast, so YUV black = 16 , white =235 . If you don't like the stretch, then you have to prepare your still images differently for 16-235, or use one of the workarounds in the articles below

If you are using video and stills with different color spaces, it can get complicated. Vegas handles different import formats, differently, and will change the behaviour based on settings (8-bit vs. 32-bit), and export formats. Do a forum search, as much of this has been discussed in the past, with links to articles . Here are a few to get you started

http://www.glennchan.info/articles/vegas/v8color/v8color.htm
http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm

[Lyris]

Thanks for that it - it looks like the varying behaviour of different codecs and programs is what's confusing me.
These programs should really flash up a big red warning whenever they're doing these conversions to warn you of what's happening!

[J_Darnley]

Specifying a PC matrix for your RGB=>YV12 conversion will stretch the contrast, so YUV black = 16 , white =235 . If you don't like the stretch, then you have to prepare your still images differently for 16-235, or use one of the workarounds in the articles below

WTF? A PC matrix will not stretch anything.

[poisondeathray]

WTF? A PC matrix will not stretch anything.

RGB 0,255 => YUV 0,255 instead of becoming YUV 16,235 when you use Rec601/709 . Are you saying this is false ?

[J_Darnley]

RGB 0,255 => YUV 0,255 instead of becoming YUV 16,235 when you use Rec601/709 . Are you saying this is false ?

That is true.
A pc matrix does RGB 0,255 -> YUV 0,255
Rec does RGB 0,255 -> YUV 16,235

[poisondeathray]

In his example, he had a full range source. When converted to YUV 0,255 - and then when it's decoded back to RGB for viewing with a rec601 matrix (since he's using SD DVD ), it will look "contrasty" - black will now be anchored at 16, white at 235, and the values in between will be "streched out" hence giving the "contrast stretch". However, if viewed with a pc matrix, it will retain 0=black, 255=white and look the same full range original source. The former is what will likely happen in his specific situation.

[Lyris]

Let's go with another example and take Sony Vegas out of the equation. Let's say I capture a Digital Betacam tape (video levels) to the computer using Blackmagic's lossless codec (video levels). I refer to that AVI file in an AVISynth script which changes the frame rate and does a resize. I verify the results in VirtualDub. Then I feed the script to Cinema Craft SP3.

Am I correct in saying that VirtualDub's preview window can't be trusted for monitoring because it will always stretch 16-235 to 0-255?

I don't think this specific example has been discussed before, so apologies if I'm re-asking. Everything so far has looked fine, but I hate not knowing what's going on behind the scenes and if levels are being shifted around, I'm concerned about posterisation and other artefacts creeping in.

[poisondeathray]

Let's go with another example and take Sony Vegas out of the equation. Let's say I capture a Digital Betacam tape (video levels) to the computer using Blackmagic's lossless codec (video levels). I refer to that AVI file in an AVISynth script which changes the frame rate and does a resize. I verify the results in VirtualDub. Then I feed the script to Cinema Craft SP3.


I would check at each stage what colorspace, and what levels you have.

If you use BM's uncompressed, (not the MJPEG), and since you are already using avisynth , check the colorspace and levels. Is it RGB at this stage ? If it's YUV colorspace , then you could use histogram() or videoscope() to check your levels

Then you have to check how CCE SP3 handles various input formats , and what levels it outputs (I assume YV12 16-235, but other encoders handle YUY2 input differently than YV12 - e.g. procoder)


Am I correct in saying that VirtualDub's preview window can't be trusted for monitoring because it will always stretch 16-235 to 0-255?


IIRC, it depends how it's setup in vdub in the options. Vdub's YUV=>RGB conversion is actually 16-235 internally - what I mean by that is Y=16 gets mapped to RGB 0, and Y=235 gets mapped to RGB 255. (e.g. when you use full processing mode, or allow vdub to do the RGB conversion instead of specifying a PC matrix with avisynth), not sure what the preview window (input or output) actually show. What matters is how you do the conversion from RGB back to YUV colorspace.

[2Bdecided]

There was a time VirtualDub wouldn't accept YUV input! I think pre v1.6. You had to have a YUV codec (typically Helix) on your system. Anyway, long time ago now!

Current VirtualDub seems to scale 16-235 YUV > 0-255 RGB for display on my system, and I can't see any option to change this.

If I need to know what I'm seeing, I add the appropriate converttorgb(matrix="......") line to the end of my script before previewing it. Obviously need to remove it before encoding!

Cheers,
David.

[Lyris]

Suddenly actual hardware video scopes begin to look very appealing...

So, I did some tests last night to better understand exactly when and how the remapping is occurring in my pipeline. I used Vegas' own internal media generators to make two squares, one 0,0,0 and the other 16,16,16. Then I output this to AVI files using various codecs, and encoded that AVI file using CCE SP3 using different Luminance Level settings.

It turns out that the Blackmagic codecs (well, the lossless ones I tried) are RGB? Or do they just "report" themselves as RGB to avoid the "hidden remapping" behaviour? AVISynth's info() command reports that they're RGB32.

So, although I've not witnessed any visual artefacts as a result of it, it seems that in cases where I have to satisfy my videophile paranoia, Lagarith is no longer acceptable as an intermediate format (shame, because the compression ratio was excellent) and I have to use something designed to pass levels through. I feel better knowing that I can at least make a DVD with below-black and above-white information should I be so inclined, I just hate having stuff done behind my back.

[poisondeathray]

So, I did some tests last night to better understand exactly when and how the remapping is occurring in my pipeline. I used Vegas' own internal media generators to make two squares, one 0,0,0 and the other 16,16,16. Then I output this to AVI files using various codecs, and encoded that AVI file using CCE SP3 using different Luminance Level settings.

This can be problematic. I would simulate whatever workflow you will be using. Unless it's going to be using vegas' internally generated media generated images for your projects - or you'll arrive at the wrong conclusion. I would make a test video with a test chart, the same characteristics as your inputs would be (colorspace , codec, etc..) e.g. You can download some from belle nuit and make a video from it. You can derive more information than just levels from this. eg. rec601 vs. 709 , evidence of colorspace conversions., etc...
http://www.belle-nuit.com/testchart.html


It turns out that the Blackmagic codecs (well, the lossless ones I tried) are RGB? Or do they just "report" themselves as RGB to avoid the "hidden remapping" behaviour? AVISynth's info() command reports that they're RGB32.


BM has different codecs. You probably used fourcc "r210" which is 10-bit 4:4:4 RGB . I think they have others like their own version of "v210" which is 10-bit 4:4:4 YUV , and "hdyc" which is 8-bit 4:2:2 YUV

What nature is the signal of the betacam ? How do you have it hooked up ?


So, although I've not witnessed any visual artefacts as a result of it, it seems that in cases where I have to satisfy my videophile paranoia, Lagarith is no longer acceptable as an intermediate format (shame, because the compression ratio was excellent) and I have to use something designed to pass levels through. I feel better knowing that I can at least make a DVD with below-black and above-white information should I be so inclined, I just hate having stuff done behind my back.

Do you mean lagarith in the context of using vegas or lagarith in general ? Lagarith only replicates what you feed it.

Remember if vegas is in your equation, it handles different input and export formats ... differently. If you feed it a YUV source, it will be handled differently and depending on 8-bit vs. 32-bit settings, than if you fed it a RGB still.

[Lyris]

What nature is the signal of the betacam ? How do you have it hooked up ?

SDI.

Do you mean lagarith in the context of using vegas or lagarith in general ? Lagarith only replicates what you feed it.


Yes, Vegas AND Lagarith, I should have been more clear.

Yet another example with a question at the end.
I take the freshly-captured DigiBeta tape (Blackmagic codec AVI) into VirtualDub. Both the preview video window and the internal Levels filter indicate that remapping has taken place. So naturally, if I were to create a derivative of that file, the resulting file will also have the remapped levels. I can't find any option in VirtualDub to stop this behaviour - is there one?

[um3k]

If you use "Fast Recompress" when converting the file in Virtualdub, it will skip RGB conversion.

[2Bdecided]

Suddenly actual hardware video scopes begin to look very appealing...

So, I did some tests last night to better understand exactly when and how the remapping is occurring in my pipeline. I used Vegas' own internal media generators to make two squares...I think the reason you're having so much trouble is that you're using Vegas and expecting it to work properly. ;)

It's "well known" that Vegas does different things with levels depending on what you export to.

If you want this to work properly, you have to use a known good workflow. Picking a codec in Vegas which you haven't verified is not going to give you a "known good workflow".


With AVIsynth and tools like DG(AVC)Index that let you get the video into AVIsynth in a controlled way (i.e. unlike DirectShowSource where you're not always sure what's happening!) you should be able to verify the levels of the final MPEG-2 or MPEG-4 encodes. With VFW codecs, you have to verify which colour format is being served to AVIsynth by default (easy enough with info() after AVIsource), and check what colour and level conversions, if any, are happening on the way in.

Cheers,
David.