Levels Q

[sargan]

I am learning my way with AviSynth.
If I wanted to set levels to 16:235 in YUV mode then I would use: ColorYUV(levels="PC->TV")

In RGB mode is there an equivalent command ?
I know there is: Levels(16, 1, 235, 0, 255, coring=false)
Looking it up tells me it is not the same as both luma and chroma components are scaled.
However is it the right command to use ?

What I want to do is reduce levels of files to [16:235] to offset the expansion that Youtube/Vimeo expansion.
(Doom9 often points to: http://www.bubblevision.com/underwater-video/YouTube-Vimeo-levels-fix.htm )

I want to set levels at time of deinterlacing with QTGMC .... the saved files will be in intermediate MagicYUV in RGB32
(Aiming to keep to RGB32 throughout.)

[raffriff42]

First use ColorYUV(analyze=true) to see if any action is required.

Do this for your edited clip and again for the YouTube (or Vimeo) -processed clip (you are allowed to download your own videos)

EDIT if you suspect the YouTube (or Vimeo) player of expanding the luma range, do a screen grab of it and compare to your edited clip.

Pretty sure no levels change is needed these days, if the uploaded clip is YUV and has a 16-235 luma range.

[sargan]

Just tried ColorYUV(analyze=true) but have no idea what the results mean.

Average (119.57/129.87/126.94)
Minimum (0/114/118)
Maximum (203/140/150)
could you explain how to interpret the results ?

I can set in Vegas the 16:235 with the 'computer > studio' levels fx

[raffriff42]

Just tried ColorYUV(analyze=true) but have no idea what the results mean.You generally note the lowest values of LumaY: Loose Minimum and the highest value of LumaY: Loose Maximum over a variety of scenes in your video.

"TV range" (16-235) video video should extend from about 16 to about 235.
"PC range" (0-255) video should extend from about 0 to about 255.


http://avisynth.nl/images/ColorYUV_analyze_Ex1.jpg
In this image, Loose Minimum = 19, very close to 16. Loose Maximum is quite low because the scene is dark.

http://avisynth.nl/images/Limit_Ex01.jpg

This image from the same movie (http://durian.blender.org/sharing/) has a good Loose Maximum sample at 234, but no true "black."

EDIT - Histogram is a good tool for this purpose as well; use that if you prefer. Both Histogram styles have distinct colors showing what is inside and outside the 16-235 range.

[raffriff42]

>only histogram and waveform can give you a correct understanding
wrong.

>Do not post incorrect advice.
yeah, you too.

>PC/TV setting choice is dead 10 years ago.
I never advised any setting, only discovery of existing range.

>Using PC range for 16-255 conversion is totally incorrect.
who said it was correct?

[TheFluff]

It should be noted that rean has his own definition what is correct; a definition that goes directly against all of the actual ISO/ITU standards for interoperable video. As far as I know he is the only person on this forum to insist that his way is correct. His theories have been extensively discussed before; see for example here (http://forum.doom9.org/showthread.php?p=1722885#post1722885) and the following posts until the end of the thread.

Basically the argument can be summed up as follows: the YUV standards say that as far as luma (Y) goes, 16 is black and 235 is white. Some cameras record video that contains super-white - values above 235. The standard says you should ignore these values; rean wants to use them anyway and claims he knows better than the standards. It's obviously wrong per definition, but it's your video so do whatever looks good to you.

In RGB, you usually use the full 0-255 range in all channels and don't have compressed levels (with the exception of some projectors, there was some discussion of this in the MadVR thread). If you have RGB video with compressed levels there's probably something weird going on somewhere.

[sargan]

Sorry to have got a few guys at odds with each other - not my intent

This came about as I had read here (and elsewhere) that I should set levels to 16:235 for example in link given in post #1
So you guys advise against me doing this as 'standard' and only apply if needed.

Was sort of hoping to get to a standard script for all my DV captures .... but if I can't then so be it.

[poisondeathray]

For sure 80-90% of camera sources (even consumer) record Y' 16-255. Usable, useful data in the 235-255 range. Take any camera in the last 20 years, from DV, to HDV, to AVCHD to DSLR's. If you "blindly" do a Rec conversion to RGB you will clip usable data. For sure. This has been shown again and again , and discussed to death. rean is correct in that regard.

The confusion lies when peole use the number 16-235 some people think it means RGB. It does not. The OP is using Sony Vegas. Studio RGB. This is 0-255 in RGB (RGB is always 0-255), but takes 0-255 in Y' and "maps" to 0,0,0 - 255,255,255 in RGB. It's analgous to avisynth's PC matrix. Vegas uses studio RGB for native camera formats. It has another conversion called "Computer RGB". It's analgous to avisynth's Rec matrix. It "maps" Y' 16-235 to 0,0,0-255,255,255. You clip superbrights, darks. "lossless" YUV codecs such has huffyuv, ut video, magic yuv get treated as Computer RGB, not YUV, and get clipped in vegas

[WorBry]

So has it been definitely established what the effective luma range of Sargan's video source is?

Very difficult to judge from the ColorYUV values

Just tried ColorYUV(analyze=true) but have no idea what the results mean.

Average (119.57/129.87/126.94)
Minimum (0/114/118)
Maximum (203/140/150)
could you explain how to interpret the results ?


I have an AVCHD camcorder (Canon HF-G10) that shoots 16-255, but it's not uncommon for ColorYUV(analyze=true) to report trace "blacker-than-blackpoint" values down to zero.

Like Rean said, really need to see a frame grab with:

Histogram(mode="levels")
or
Histogram(mode="classic")

And one of from a scene that spans a wide dynamic range - backlit window shot....that type of thing.

@Sargan - out of interest, what model of DV camcorder are your sources recorded on, as I'm assuming from:


Was sort of hoping to get to a standard script for all my DV captures .... but if I can't then so be it.

[Sparktank]

There's "OutRange" you can run on the video and it will log only values outside TV range (16-235).
http://avisynth.nl/index.php/OutRange
The log can be handy for "offline" analysis.
Just copy frame number and enter in Avspmod to see the frame with OutRange values.

Create your script:
SetMemoryMax(512)
LoadPlugin("path\OutRange.avsi")
DGSource("G:\Samples\Sintel 2010\Sintel.2010.1080p.dgi")
OutRange(0, 0, log="sample.log")
Default is to log luma ranges only.

Run your script through Avsmeter (http://forum.doom9.org/showthread.php?t=165528).
Let it run until it's finished and open the log.

For example, I got the 1080p encode of Sintel from their site.
OutRange log shows... (snippets)
67: YMax = 18; YMin = 15
68: YMax = 18; YMin = 14
69: YMax = 18; YMin = 14
70: YMax = 18; YMin = 14
Frames 67-70 have ranges below 16. Ymin=15, Ymin14.
Those are probably dark frames as their Ymax is 18.
It's like ColorYUV but without the need of having to watch it live to see the values.

Another snippet of frames going outside TV range:
460: YMax = 236; YMin = 58
474: YMax = 236; YMin = 55
752: YMax = 236; YMin = 43

The script doesn't have a summary feature nor do I know how to add maths.
But it helps to open it in something like Notepad where it shows line numbers in the left hand margin.

Sintel logged 17802 entries where a frame goes outside TV range.

http://avisynth.nl/images/ColorYUV_analyze_Ex1.jpg
In this image, Loose Minimum = 19, very close to 16. Loose Maximum is quite low because the scene is dark.

frame 2869 has different values though in the OutRange log.
2869: YMax = 202; YMin = 15

I used this one:
https://durian.blender.org/download/
HD 1080p (~1GB, MKV, 5.1)
http://i.imgur.com/cziPmU9l.png (http://imgur.com/cziPmU9)

[StainlessS]

ShowChannels:- http://forum.doom9.org/showthread.php?t=163829&highlight=ShowChannels


Plugins for Avisynth v2.5 & v2.6

Planar, YUY2 and RGB.

Simple plugin whose only function is to display the average Y,U and V
values for a YUV frame or R,G, and B for an RGB frame.
Also shows accumulated average for all frames visited so far.

Typical output for a YUV clip:-
---------------------------

347 ] Frames Visited = 348

This Frame Accumulated
Y U V Y U V
Ave 77.00 125.52 125.42 70.91 125.87 125.78
Min 4 80 95 0 69 83
Max 255 177 165 255 190 174
~Min 14 95 101 12 92 101
~Max 234 167 148 235 167 151

---------------------------

where
'AVE' shows average for current frame and accumulated average for all visited frames.

'MIN' shows minimum value for a channel, this frame and accumulated.

'MAX' shows maximum value for a channel, this frame and accumulated.

'~MIN' shows loose minimum value for a channel, this frame and accumulated.

'~MAX' shows loose maximum value for a channel, this frame and accumulated.

Loose minimum uses the filter arg float MinPerc, a percentage of total pixels to ignore
when finding the loose minimum, allows to ignore extreme stray pixels (noise).

Loose maximum uses the filter arg float MaxPerc, a percentage of total pixels to ignore
when finding the loose maximum, allows to ignore extreme stray pixels (noise).

The "loose" values are made to filter out very bright
or very dark noise creating an artificially low or high minimum / maximum.

The Accumulated Ave is a "Average of Averages", or "Average Mean" or "Mean Average", take your pick but accumulated seemed more appropriate
considering that it was not restricted to describing just the averages. Accumulated Min is the minimum of all minimums so far, etc.


EDIT: MinPerc is similar to eg YPlaneMin Threshold arg.
Builtin function YPlaneMedian, is implemented as YPlaneMin(Threshold=50.0)

EDIT:
YPlaneMin/YPlaneMax has the same sort of thing where what I've called 'MinPerc/MaxPerc' uses name of 'Threshold'.


YPlaneMin | v2.x | YPlaneMin(clip, float threshold)
YPlaneMax | v2.x | YPlaneMax(clip, float threshold)

threshold is a percentage, stating how many percent of the pixels are allowed above or below minimum.
The threshold is optional and defaults to 0.


The Accumulated Ave is a "Average of Averages", or "Average Mean" or "Mean Average", take your pick but accumulated seemed more appropriate
considering that it was not restricted to describing just the averages. Accumulated Min is the minimum of all minimums so far, etc.

Comment From ColorYUV source

// When 1/256th of all pixels have been reached, trigger "Loose min/max"


So ColorYUV ignores 1/256 of the darkest/lightest pixels, YPlaneMin ignores 0% default, and ShowChannels 0.1% or 1/1000 by default,
so a Minperc/Maxperc of 0.4% would be about the same as ColorYUV uses.



EDIT: Results are also exposed as Globals for use in runtime scipts and optionally written to output file (final accumulated results).

Typical Global Variable settings for RGB something like:-

SC_Ave_0=124.55 SC_Ave_1=126.06 SC_Ave_2=199.77
SC_Min_0=0 SC_Min_1=0 SC_Min_2=0
SC_Max_0=255 SC_Max_1=255 SC_Max_2=255
SC_LMn_0=0 SC_LMn_1=0 SC_LMn_2=0
SC_LMx_0=255 SC_LMx_1=255 SC_LMx_2=255
SC_AAve_0=129.24 SC_AAve_1=132.12 SC_AAve_2=126.68
SC_AMin_0=0 SC_AMin_1=0 SC_AMin_2=0
SC_AMax_0=255 SC_AMax_1=255 SC_AMax_2=255
SC_ALMn_0=0 SC_ALMn_1=0 SC_ALMn_2=0
SC_ALMx_0=255 SC_ALMx_1=255 SC_ALMx_2=255


Contents of AccFile for a small sample clip showing typical output using defaults:

SC_AAve_0=98.971779 SC_AMin_0=0 SC_AMax_0=255 SC_ALMn_0=14 SC_ALMx_0=241
SC_AAve_1=122.572746 SC_AMin_1=66 SC_AMax_1=200 SC_ALMn_1=99 SC_ALMx_1=160
SC_AAve_2=137.286911 SC_AMin_2=72 SC_AMax_2=209 SC_ALMn_2=108 SC_ALMx_2=175
SC_Visited=4000



ShowChannels(clip c,float "MinPerc"=0.1, float "MaxPerc"=0.1, bool "ver"=false,bool "Setvar"=false,String "Prefix"="SC_", \
bool "Show"=true,String ="AccFile"="",int "x"=0,int "y"=0,int "w"=0,int "h"=0,bool "Interlaced"=false)


Coords (x,y,w,h) allow for examining area of frame, down to single pixel resolution (even with chroma subsampling [assumes mpeg1 chroma placement]).

[WorBry]

@poisondeathray,


The confusion lies when peole use the number 16-235 some people think it means RGB. It does not. The OP is using Sony Vegas. Studio RGB. This is 0-255 in RGB (RGB is always 0-255), but takes 0-255 in Y' and "maps" to 0,0,0 - 255,255,255 in RGB. It's analgous to avisynth's PC matrix. Vegas uses studio RGB for native camera formats. It has another conversion called "Computer RGB". It's analgous to avisynth's Rec matrix. It "maps" Y' 16-235 to 0,0,0-255,255,255. You clip superbrights, darks. "lossless" YUV codecs such has huffyuv, ut video, magic yuv get treated as Computer RGB, not YUV, and get clipped in vegas

Interesting to read your comments there. A few months back I ran a very brief trial of Sony Vegas Pro 13, largely to see how it handled 1080/30PF.mts clips off my Canon AVCHD camcorder, as well as lossless transcodes thereof. I commented on the observations here:

http://forum.doom9.org/showpost.php?p=1749793&postcount=11
and then:
http://forum.doom9.org/showpost.php?p=1753108&postcount=15

Actually, when testing output to MagicYUV I found that it was possible to preserve the original 16-255 luma by setting the "Full YUV Range" in MagicYUV, and so avoid what amounted to clamping to 32-235 otherwise. This was using the native mts clips for input. In order to achieve the same outcome with MagicYUV YV12 transcode inputs, it was necessary to encode with the "Full YUV Range" option also. Rendering out to Cineform however there was no such issue; the original 16-255 scaling was preserved, just like the native Sony YUV output formats.

So your comment brings some explanation as to what was happening there. But I have a question. If, as you say "Vegas uses studio RGB for native camera formats", this means that Vegas is taking 16-255 range camera/camcorder clips, like my 1080/30PF.mts, and treating them as if they were full scale, correct? That being the case, on internal conversion to RGB, the source 16 code black-point will not be mapped to 0,0,0 RGB but a higher value. So when it comes to applying RGB color tools (curves etc) you'll never be dealing with "fully scaled out" RGB, for want of a better term. And presumably this black-point "lift" will also be evident on the RGB monitors (Parade, Histogram), tempting the unsuspecting user to adjust the levels accordingly and unnecessarily? Or does Vegas make some further adjustment to compensate for that?

Unfortunately I no longer have the trial on my PC to go back and look at these things. But from your experience is that what is found when editing native 16-255 range camcorder/camera recordings in Vegas?

[poisondeathray]

Actually, when testing output to MagicYUV I found that it was possible to preserve the original 16-255 luma by setting the "Full YUV Range" in MagicYUV, and so avoid what amounted to clamping to 32-235 otherwise. This was using the native mts clips for input. In order to achieve the same outcome with MagicYUV YV12 transcode inputs, it was necessary to encode with the "Full YUV Range" option also. Rendering out to Cineform however there was no such issue; the original 16-255 scaling was preserved, just like the native Sony YUV output formats.


Thanks, I just verified that the full range option does work in vegas with magicyuv - fantastic . But not in PP. It's beyond this topic, but there are pros/cons to using studio RGB. Other NLE's like PP can operate in YUV so you can "legalize" YUV levels before the RGB conversion occurs if you're converting to RGB, or you can keep YUV (that is, if the format is "treated" as YUV - "lossless" YUV codecs are not treated as YUV in PP)



So your comment brings some explanation as to what was happening there. But I have a question. If, as you say "Vegas uses studio RGB for native camera formats", this means that Vegas is taking 16-255 range camera/camcorder clips, like my 1080/30PF.mts, and treating them as if they were full scale, correct? That being the case, on internal conversion to RGB, the source 16 code black-point will not be mapped to 0,0,0 RGB but a higher value. So when it comes to applying RGB color tools (curves etc) you'll never be dealing with "fully scaled out" RGB, for want of a better term. And presumably this black-point "lift" will also be evident on the RGB monitors (Parade, Histogram), tempting the unsuspecting user to adjust the levels accordingly and unnecessarily? Or does Vegas make some further adjustment to compensate for that?



Note vegas has 2 modes for the scopes such as waveform and histogram, "computer RGB" and "studio RGB" . There is a switch that toggles the levels

It means a studio RGB conversion is applied. Yes - 16 in Y would be "mapped" to 16,16,16 in RGB. Y 0-255 is mapped to 0,0,0-255,255,255 in 8bit RGB if you're using 8bit mode. It's similar to "PC" matrix in avisynth, but very marginally different (actually there is a real Studio RGB function in avsiynth, by Trevlac if you search). There is a "black lift" in a sense, but it depends on how you have vegas setup (vegas operates slightly differently depending if you are working in 32bit mode linear, vs. 8bit "video") . Vegas automatically scales differently upon export (different export formats get different treatment). A common workflow for vegas is to use debugmode frameserver and avisynth for the final export . If you were using studio RGB levels, and the final export was some YUV format, you would use a PC matrix to conversion for the final YUV format (essentially you reverse the levels back) . The common confusion occurs when different types of inputs are used. Some are treated with studio RGB, yet others computer RGB. It has studio=>computer RGB and computer=> studio RGB presets so individual events can be adjusted

[WorBry]

Very interesting. Thanks for the clarification. Yes, I found the same with MagicYUV and PP. I was going through a "how do the pro NLE's handle luma scaling ?" exercise at the time.

[sargan]

@Sargan - out of interest, what model of DV camcorder are your sources recorded on, as I'm assuming from:

These are DV captures of old VHS recordings from late mid to late 90's
The source in most cases was an SVHS-C Panasonic model

Tapes captured by paying in an SVHS full size deck, play though a DVDR to an ADVC300 and using WINDV on PC

[WorBry]

I'm afraid I have no experience with VHS > DV captures. Others on the forum might.

But again:



Like Rean said, really need to see a frame grab with:
Histogram(mode="levels")
or
Histogram(mode="classic")


And one of from a scene that spans a wide dynamic range - backlit window shot....that type of thing.


.....would be more informative.