I'd appreciate some pointers for processing Rec.601 YV12 footage for Rec.709 MPEG-2 encoding. Much of it is shot outdoors with the background over-exposed to compensate for a darker foreground. According to Histrogram() most frames have invalidly high luma values. Here's a 2-frame sample clip.
Whenever RGB conversion becomes necessary in the process, for this kind of luma range which would be the best matrix to convert back and forth with - Rec601 or PC.601? Although I've been able to generate terrible results, I'm not sure how to gauge the better-looking ones, being displayed on a PC monitor at PC range I presume.
In this case which matrix would be best for converting Rec.601 YV12 to Rec.709 for final output - Rec709 or PC.709?
How does one actually convert Rec.601 YV12 to Rec.709 YV12? With Rec.601 YV12 input, ConvertToYV12(matrix="Rec709") fails with
Does that mean converting Rec.601 YV12 -> Rec.709 YV12 can't be done without an intermediate conversion to say RGB?ConvertToYV12: invalid "matrix" parameter (RGB data only)
Many thanks in advance,
+ Reply to Thread
Results 1 to 30 of 133
You can't go directly from rec.601 YV12 to rec.709 YV12 with ConvertToYV12(). You could ConvertToRGB(matrix="rec601") followed by ConvertToYV12(matrix="rec709"). But doing that directly on your overblown brights will kill the detail in the sky. You want go tame those brights first. You could use ColorMatrix(mode="Rec.601->Rec.709") to avoid that. But you should really tame those brights before encoding anyway. Something like ColorYUV(gain_y=-20). So
ColorYUV(gain_y=-20) ConvertToRGB(matrix="rec601") ConvertToYV12(matrix="rec709")
Look for darker shots and make sure ColorYUV(gain_y=-20) doesn't cause the darks to get too dark. If so, you have reduce the contrast and change the offset too.
Last edited by jagabo; 11th Mar 2013 at 07:56.
Why do you need to convert it? My recollection is that you can encode and flag Rec.601 colour to MPEG-2 just fine. IIRC if you don't specify what the colour is, SD video defaults to Rec.601. I could be wrong.
btw, I used to think using matrix="PC.601" etc instead of "Rec601" was the way to preserve superwhites/blacks, but it's not quite correct...
...which would be unfortunate when doing a colour conversion.
This will bring over-bright luma in range quite simply, without affecting black...
...but there are other ways.
Looks like I've opened myself a can of worms...
If I leave the levels alone, is there anybody downstream who's expected to clip them? Or does it depend on the implementation of the particular encoder, renderer etc?
edit: Is there some tool that can tell with which matrix a particular clip has been encoded with?
Also, non-PC-centric RGB video over HDMI is always black=16 white=235, not the highlight-clipping black=0 white=255 that is most commonly found on PCs. (By preference, non-PC-centric video is YUV over HDMI if both devices support it - but if one doesn't, you get 16/235 RGB instead).
That said, it is far better to ensure the video is legal and valid (and preferably NOT just by hard-clipping it to the limits) - i.e. luma sits between 16-235 except for sharpening overshoots, and luma+chroma point to real RGB values.
You can usually fiddle with the brightness and contrast settings to bring out details outside those regions (when YUV is transmitted). But who want's to fiddle with the settings for every video they play?
Encode to the standard and you won't have to.
Problem is, some old camcorder videos look far better if you let all the illegal values through and watch them on a sympathetic TV. Once fixed, they look too dark and too desaturated. Example...
That's not the problem here.
I am talking about BluRay players and TVs, not PCs and graphics cards.
In any case, the OP should fix the levels in his video before encoding, it's a trivial task. There's no need to go into all the myriad ways he might be able work around bad levels using his DVD/BD player's or TV's settings.
Last edited by jagabo; 11th Mar 2013 at 13:25.
David is correct regarding consumer electronics RGB over HDMI, the exception is 640x480 which is always full range according to the spec .
But CE almost never is set to RGB, since all consumer formats are YCbCr
The bottom line , as everyone agrees, is just to use legal range YCbCr
Last edited by poisondeathray; 11th Mar 2013 at 13:38.
This has been a most... illuminating discussion!
this, but I'm not sure how authorative that is either.
David's discussion? [Edit: actually from this specific post: "Even using PC-range, not all YUV combinations are 'valid'"] And how to check for such illegal combinations?
Thanks very much for the suggestions (and another helpful illustration from jagabo), I'm going to try them out.
Last edited by fvisagie; 11th Mar 2013 at 14:10.
is it possible for individually valid Y, U and V values to represent invalid RGB values in combination
You are over complicating this. Your camcorder is just like 99% of recent consumer camcorders: it records luma 16-255. Just use the levels line I provided above (or the equivalent smoothlevels line if you want) to map it to 16-235, and leave it at that. No need to worry about illegal colours. No need to worry about 601/709.
If you wish to do manual per-shot colour correction in your NLE, then go for it, but that's a separate issue.
Yes, that last link has the pretty pictures I recall.
You don't need to learn about it (except for curiosity) - just use Cedocida DV codec, and either force YUY2 (either using the control panel for the codec, or using pixel_type="YUY2" in the AVIsource command in AVIsynth), or forec YV12 and select "MPEG 2 interlaced" as the decoder option in the Cedocida control panel.
If you do it incorrectly, it's quite hard to see any difference, and very hard to say for certain that it's "wrong" just by looking at the result.
Yes, not worth worrying about. Just keep track of interlaced vs. progressive issues. Eg., ConvertToYV12(interlaced=true) for interlaced video, ConvertToYV12() for progressive.
Back to 601 vs. 709 one last time, if I mix this DVCAM with HD content, is it advisable to convert one's format to that of the other, say the DVCAM to Rec.709?
edit: I notice that when normalising levels bright horizontal lines appear in the histogram, also visible in jagabo's picture above. They're present with both of ColorYUV() and levels(); their number and position just vary in each case. What do those lines represent?
Last edited by fvisagie; 12th Mar 2013 at 09:39.
With mixed content you usually convert to whatever the final format is going to be. e.g. if it's an HD timeline intended for HD export, you convert the SD material to Rec709 using colormatrix
Everything else still applies - you need to either "legalize" values in YCbCr before converting to RGB, or use a full range matrix before converting to RGB, otherwise the "Rec" matrices will clip your overbrights
e.g. either use smoothlevels() instead of levels, or use levels() with dither=true (only available in avisynth 2.6.x) , or you can add dithering separately with the dither tools (e.g. gradfun3 or related filters)
Going from 240 (255-16+1) shades of grey to 220 (236-16+1) shades of gray results in some adjacent Y values become mapping to the same Y value in the output because you are working with integers. For example say you have 4 possible Y values 0, 1, 2, 3, and you want to reduce the range from 4 to 3. You multiply every Y value by 3/4 (0.75) to generate the new value: 0.00, 0.75, 1.50, 2.25. But you're working in integers so you have to round those number to the nearest integer: 0, 1, 2, 2. The original values 2 and 3 both mapped to 2 in the final output. That's what those horizontal lines in the histogram represent.
AVIsynth can do it very well.
Several NLEs say they let you mix formats within one project, but the ones I've tried do the conversion pretty poorly.
When working in HD, I used AVIsynth to convert SD to HD before rendering a project. If I know I'll use most of the SD clips, I might convert them all before I start. If I'll only use a small fraction, then I'll use the SD versions in the NLE to start with, and create HD versions in AVIsynth only of the ones that survive to the final edit. Some NLEs make it easy to replace a clip with a better quality version without messing with the edit.
I note that a YUV histogram is often used to check these values for correction. Well and good, but IMO Avisynth's Levels histogram is OK for luma levels but rather useless for color ranges -- and I read in Doom9 somewhere that the U and V panels in that histogram are inaccurate.
I use that histogram for a preliminary luma check, but I convert the video to RGB (using 601 or 709, whichever applies) and then use the ColorTools histogram in VirtualDub to check the color range, or use the RGB histograms in Photoshop Pro or AfterEffects. I do this because I feel that YUV tells me how the data is stored, but RGB tells me how it will be interpreted and displayed. I've seen a great many YUV histograms with perfectly fine 16-235 luma levels, but colors were smashed against all sides of the RGB histograms. Often, my eyes can see these effects without reverting to 'grams and 'scopes. I make preliminary corrections for legal values in both luma and chroma using Avisynth tools (ColorYUV, etc.).
A contrast/brightness technique mentioned is the use of pluges and contrast bars, in versions for both PC and TV. These are OK for general quickie setup, but there are more precise methods. Because of the way PC monitor brightness and contrast controls work (or don't work), a pluge is often the only tool available other than colorimeter/software kits designed for PC hardware. The kits are far more accurate than either the controls or the eyeball. But for TV I have EyeOne colorimeters and HCFR software to set black and white levels, which at the same time serves as a gamma setup.
For TV calibration, I use IRE-0 to IRE-100 gray test patches from the GetGray calibration disc. GetGray itself is an SD tool, but gray patches for SD and HD are the same for RGB setup of SD and HD alike. For color, you'd use the GetGray color patches for SD but go for the AVSHD709 disc for HD color tests. For SD and HD grayscale-only, either of the gray patch sets will work.
Setting TV white level: Mount the colorimeter on the TV, plug its USB cable to a computer, and start the HCFR software. Begin by displaying a 100% (IRE-100 bright white) gray panel. Adjust TV contrast until the IRE-100 panel gives a "reasonable" luminance reading in the range of 30 to 40 cd/m2 for LCD/plasma/CRT. This cd/m2 figure is not arbitrary: it corresponds to a universally accepted brightness level for viewing in average indoor lighting without smashing brights all over the place. I like a fairly punchy image, so I set for a white level of 40 cd/m2. You can go higher or lower, but doing so will affect the target gamma of 2.0 or 2.2 (I shoot for 2.0).
Setting TV black level: Next, display an IRE-10 dark gray panel (not IRE-0). Adjust the Brightness control until you get an IRE-10 luminance reading that is 0.65% of the IRE-100 reading. If the IRE-100 was 40, then the IRE-10 reading should be in the neighborhood of 0.26 cd/m2 (40 X .0065 = 0.26). Because Contrast and Brightness tend to interact, you likely should repeat the readings and readjust until you get the 40 and 0.26 readings. You have now set a gamma in the area of 2.0 or so. Later, after grayscale calibration, the overall gamma will have been modified, so it's a good idea to check those black and white levels again. Some TV's are not capable of a 2.0-2.2 gamma; in that case, the plug pattern will verify the set's capabilities and allow tweaking.
A saturation setting should follow the levels and grayscale calibration. Some experts contend that Saturation is best set using a 100% or 75% Red color patch (use Rec601 color patches for SD, Rec709 color patches for HD -- although, in fact, there's not that much difference between them). Display a 100% or 75% light gray patch, take a reading with HCFR, and note the Y-level reading. HCFR gives x,y, and Y' (the same as YUV "Y") for that patch. You want to note the Y color luminance reading from that patch. Next, display a matching 100% or 75% Red patch, careful to match 100% or 75%, whichever you're using. Set the saturation control until the Red Y-level reads 21% of the white patch.
Some experts suggest that primary Green is a better base (especially if you're viewing a Panasonic TV with its volcano-level Reds). For a Green patch, set saturation to 70% of the white Y-level. Or of you want to get picky, SD Green should be 70% of the white patch, HD should be 71%. If you can see the difference, you're pretty damn good. If you use other colors, the percentage of white-to-color Y readings goes along these lines:
Setting Tint is far more complicated. To do it precisely, you need HCFR and its Rec601 or Rec709 CIE test matrix to adjust Blue and Green CMS matrix levels -- not possible if you don't have individual CMS controls on your TV, and most TV's don't have them. In that case, the old blue viewing filter and the Tint test screen from the GetGray or AVSHD disc will have to suffice.
These methods can't be used on a PC. For one thing, many PC monitors don't have accurate RGB controls; their effects vary widely across the RGB range, and it's not possible to adjust Y-saturation levels on anything except pricey pro monitors. For a PC, the XRite calibration kits are quite accurate and thorough. One begins by following the software prompts, which usually involve setting brightness to 120 cd/m2 or so. Most monitors have settings far beyond this value, which means they are bright as hell. The software gives you a grid in which to align a cursor when brightness/contrast are properly set. The rest is automated, acting mostly on the graphic card's LUT to make 38 RGB grayscale x, y, Y', and gamma corrections.
Not long ago I posted some HCFR images showing how close these PC calibration kits can get: https://forum.videohelp.com/threads/335402-VHS-capture-critique?p=2083260&viewfull=1#post2083260. This post used HCFR's sRGB panels.
Here are two articles that describe the TV and projector calibration process:
Here is a link to sample PC calibration:
Following these guides for PC/TV, bad video processing becomes immediately obvious, and proper video looks....well, the way it's supposed to.
Last edited by sanlyn; 25th Mar 2014 at 20:02.
You can use a sequence like:
WhateverSource() Subtract(last, ConvertToRGB(last).ConvertToYUY2()).Levels(112,1,144,0,255)
Your video after ColorYUV(gain_y=-20):
Nice little tool. Yet another addition to my jagabo tips folder.
Last edited by sanlyn; 25th Mar 2014 at 20:02.
I should have pointed out that you should use the interlace flags for interlaced video; the right matrix for the YUV/RGB conversions; and the right conversion back to YUV (YV12 or YUY2). The code as written above is for progressive rec.601 YUY2.
For example, with interlaced rec.709 YV12 you would use:
WhateverSource() Subtract(last, ConvertToRGB(last, interlaced=true, matrix="rec709").ConvertToYV12(interlaced=true, matrix="rec709")).Levels(112,1,144,0,255)
Last edited by jagabo; 12th Mar 2013 at 11:19.
For me Avisynth 2.6.x won't be an option yet for a while. How would you chiefly contrast smoothlevels() vs. separate dither tools like gradfun3, e.g. when would one generally prefer the one over the other?
avisynth call is still smoothlevels() as before
How would you chiefly contrast smoothlevels() vs. separate dither tools like gradfun3, e.g. when would one generally prefer the one over the other?
You originally mentioned converting for RGB (presumably for use in other programs). Some of the problems with RGB plugins in avisynth /vdub is that they work at lower 8 bit depth an in non linear sRGB - so the conversion math isn't as accurate, and you get more banding with gamma error (1+1 doesn't equal 2). The "correct" way would be to linearize everything using a linear workflow when doing color corrections in RGB
If you are going to do any kind of spacial or temporal filtering there's no reason to bother using SmoothLevels or whatever. Because of the noise in the video, the loss of precision is evenly spread over the entire image. Adjust the levels, then do the other filtering.