SansGrip Filters: LegalClip() is not clipping?
:!: In making a number of scripts for a number of AviSynth versions, I just cannot seem to get LegalClip() to work. That is, after I apply it, I still get blacks at $000000 and whites at $ffffff.
:arrow: I made a test script for AviSynth v.2.0.7 that should, when run, produce a checkered pattern due to selective application and non-application of the LegalClip filter: Code:
clip1 = BlankClip(width=150,height=100,color=$000000) :?: Can anyone help with this? |
Hi easymenu,
You can make an easier test. Encode one minute clip of some material with LegalClip(), and encode the same one minute without LegalClip(). The one minute clip without LegalClip() should be larger. At least for me, as I did try that about a month ago :roll: Edited -kwag |
:) Thanks for the suggestion.
:arrow: Okay, so I made two very simple AVS 2.0.7 scripts for a short MPEG2 352x480 clip (BTW, this testing is with a WinNT4 system, which uses DirectX3 generally and DirectX6 for graphics -- so no problems with the infamous DirectX8.1) : Code:
MPEG2Source("video.d2v") Code:
MPEG2Source("video.d2v") :arrow: So I made another test script. This one contained a number of test areas around the CCIR601 clipping points (both low and high). To prevent Windows display / monitor settings from corrupting a visual examination, I included Histogram() for graphical representation of the actual output: Code:
# legalclip() in AVS 2.0.x :arrow: First, a couple of "granted's". ConvertToYUY2() must be used before using LegalClip(). Is there a problem in ConvertToYUY2()? Also, the test colors are set in RBG but the clipping is implemented in YUV. While they don't correspond exactly, there will still be obvious jumps of brightness on the processed, out-of-CCIR601-range colors. :?: I looked quickly at the LegalClip() source code. In the C++ section, the code that sets up the "clipping table" looks correct. The actual pixel replacement code is in Assembly code (and that is not for casual reading). If there is any problem in LegalClip(), I would suspect it would be in the Assembly section. As if that is not enough, here's something more. :!: I similarly tested AVS 2.5b (with a Win98 system w/DirectX9) and it's built-in, more flexible, clipping function "Limiter()". Guess what? Same results (that is, no apparent clipping)! :?: So am I a bug-finder-genius or just "unfit for CCIR601 duty"? |
Let me ask you something easymenu, when you did your .d2v project, did you use "PC Scale" or "TV Scale" :idea: :idea:
Because if you used TV scale, DVD2AVI already produced a clipped file :idea: So it shouldn't make any difference if you use LegalClip() or Limiter(), and that is what you are seeing :!: -kwag |
:!: I just checked the DVD2AVI 1.76 settings. I did have it set to "TV", not "PC". I'm rerunning the test to get new filesizes with the "PC" setting. It should be done by the time I'm finished writing this.
:arrow: Of course, this wouldn't explain my AVS-generated-video test results. If I have the CCIR601 theory correct, those generated blacks and whites should be changing (and they're not). Alternately, when I do limiting with TMPGEnc's filters (one for low cutoff and one for high cutoff), the proper result is instant and obvious. (Try it and let me know what you think.) :!: While the file is generating in TMPGEnc, I'm sampling the output screen with EyeDropper. A presently displayed title on black-background has a black reading of RGB=0,0,0 for the LegalClip() script. This actual result on a real video source shows it's not being CCIR601-clipped. :!: Okay, both files are finished with the "PC" setting -- 3,833,105 w/o LegalClip(), 3,833,192 w/LegalClip(). Interesting ... no different than the "TV" setting file sizes. I guess that's not a factor here. :?: Regarding AVS 2.5b, any idea where they got their code for Limiter() (LegalClip() maybe? -- same results make me wonder)? The docs don't detail such credits. |
SansGrip should probably take a look at this 8O
|
@kwag:
wow, I just understood 75% of this but... I always thought LegalClip() would reduce file size, by clipping frequencies that can not be displayed anyway... did I miss out on that one? :roll: |
Quote:
-kwag |
I just did a little test by adding SansGrip's RangeInfo filter to my script and comparing the high and low pixel values with and without LegalClip(). After it was through evaluating the end credits, the results were;
without LegalClip() low-0, high-255 with LegalClip() low-16 and high-235 |
Quote:
|
:) Thanks for checking on this (and for referencing something that can verify CCIR601 values). Of course I'm relieved to know others can and have verified it's operation (and a little embarrassed at my panic, too :oops: ).
Anyway, I'm off to more testing on my original clips, which didn't seem to be altered by LegalClip() (and for that matter Limiter() ). Now, with RangeInfo(), hopefully I can get (self) satisfactory answers to my original questions. |
:arrow: I've preformed some tests based on the math of RGB to YUV conversion. This is a formula from one site:
Quote:
RGB = $000000 [black ... grey value of 0] Y = (0 * .299) + (0 * .587) + (0 * .114) = 0 RGB = $0f0f0f [grey value of 15] Y = (15 * .299) + (15 * .587) + (15 * .114) = 15 RGB = $101010 [grey value of 16] Y = (16 * .299) + (16 * .587) + (16 * .114) = 16 RGB = $111111 [grey value of 17] Y = (17 * .299) + (17 * .587) + (17 * .114) = 17 Notice that for equal-RGB (shades of gray) values, the YUV luminance values are the same (as one would intuitively expect). :arrow: If the following AVS code is run (I test in MPLAYER2.EXE), it generates assorted black backgrounds. RangeInfo() then reads out statistics on what it believes are the YUV values that LegalClip() uses to "clamp" to CCIR601 values. RangeInfo() also allows for a green mask of pixels within it's set limits. Code:
# RangeInfo() in AVS 2.0.x RangeInfo for black $000000 screen: Quote:
Quote:
|
There is nothing worrysome about your findings, except that you use the wrong algorithm for calculating YUV. These are the specs defined as CCIR601.
This is the code actually used: Code:
inline int RGB2YUV(int rgb) WHITE = RGB(255,255,255) = YCrCb(235,80,80) You should read up on your colorspaces and get your facts straight - you using assumptions from RGB colorspace and wrongly applying them to the YUV colorspace. Both Legalclip (2.0) and Limiter (2.5) are cropping correctly - as are the RGB <-> YUV routines correct. |
I found a nice link http://www.animemusicvideos.org/guid...olorspace.html with the help of Dr. Google that explains this stuff pretty good :D Well- it sure helped me :wink:
ren |
Very good page! Recommended reading :)
|
Quote:
:?: So, from your example, quoted above, are you saying that the full range of RGB brightness values (from 0 to 255) is, or as translated, CCIR601 legal? And does this, by obvious extension, apply to all RGB colors as well? While I was waiting for a reply with, perhaps, definitive information, I thought to expand my script displays to include color as well. The AVS ColorBars() command produces a final RGB image (at least, on screen) with a "16" value for the low (actually, the lowest is "7", but that color strip is put there as an "illegal color" for eyeball brightness adjustment) and a "235" value at the high. That is what I expect for an RGB image within CCIR601 "legal colors". :arrow: So I made a script that displays colorbars with maximum color brightness levels from 0 to 255 -- one plain, one filtered with LegalClip(): Code:
# AVS 2.0.7 script :?: Please, any comments about this "colorbar dilemma"? |
RGB cannot be CCIR601. RGB is ALWAYS 0-255 in all definitions. RGB is only black when RGB is 0.
YUV can be "fullrange" (seldom seen) or it can be CCIR601 as it is in all MPEG formats, the DV format, etc. So in short terms: RGB is ALWAYS 0-255. YUV is MOSTLY 16-236, and should ALWAYS be so for AviSynth processing. |
Quote:
:arrow: I have two practical questions as relates to recording broadcasts and storing on digital media (CD's for present, DVD's in future). :?: QUESTION 1 My (previously posted) script's "0-255 RGB colorbars" are not altered by LegalClip() (0-255 goes in, 0-255 comes out) -- meaning they are within YUV CCIR601 in AviSynth. Yet, AVS ColorBars() generates "16-235 RGB" colors. Why does AVS's ColorBars() generate 16-235 RGB colorbars rather than 0-255 RGB colorbars? :?: QUESTION 2 When I grab a frame (in, for example, PowerDVD) from a DVD movie, it's RGB range isn't 0-255, rather it is 16-235. With a DVD (for television viewing) being within YUV CCIR601, and with that equivalent to 0-255 RGB, why do I get 16-235 RGB frame? |
Quote:
|
Quote:
|
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.