View Full Version : How important is the use of Limiter()
FredThompson
18th July 2003, 02:18
Is CCIR-601 compliance really a serious issue with modern TVs?
Richard Berg
18th July 2003, 06:00
Considering the quality loss with (S)VCD and the resolution of standard TV, levels are a second-order concern at best. However, where I'd be worried is how a compressor deals with illegal YUV values -- it may clip, it may squish, it may allocate bits that the decompressor then rejects (thus wasting them), etc.
FredThompson
18th July 2003, 06:09
Yes, that makes sense. The reason I ask is Limiter() doesn't support RGB or YUY colorspace, correct? If there's a way to emulate Limiter() function for them in AviSynth 2.5.x, I'd be very interested to know.
ARDA
18th July 2003, 07:30
@FredThompson
quote:
--------------------------------------------------------------------------------
Originally posted by FredThompson
The reason I ask is Limiter() doesn't support RGB or YUY colorspace, correct?
--------------------------------------------------------------------------------
Limiter() supports YUY2 and YV12 colorspace.
If you need to output RGB, you could use ConvertToRGB.
Look at
Changes to 2.52 Released
http://cultact-server.novi.dk/kpo/avisynth/avs_cvs.html
I hope this can be useful
Arda
FredThompson
18th July 2003, 07:40
What I'm concerned about is lots of filters used lightly and they don't all support the same colorspace. Going back and forth is bound to introduce some loss.
It seems to me the proper place for Limiter() is the absolute last command because restricting range before doing calculations could lead to less accurate results.
It seems to me the proper place for Limiter() is the absolute last command because restricting range before doing calculations could lead to less accurate results.
Very debatable because if filterA say made Y levels less than 16 and FilterB assumes no levels are below 16 and does calculations accordingly - you could get unpredicatable results.
All YUV filters should keep to the YUV limits but Limiter() is available if you either know or suspect the output of another filter/plugin needs correcting.
regards
Simon
FredThompson
18th July 2003, 08:02
Oh, I see.
I was thinking about rounding error in the pure math sense.
JohnMK
19th July 2003, 08:16
Does Limiter() bring any advantages to LCD displays as well as TV displays? I know LCDs aren't as good as CRTs in certain aspects . . .
Mug Funky
19th July 2003, 16:29
this is interesting stuff, because i know that all the DV camcorder's i've ever used will actually record outside this range.
i'm not aware of encoders trashing bits outside this range, but i haven't studied the issue...
as far as YUV filters in avisynth changing these values, i've never seen that either. i'm kinda hoping i haven't permanently screwed any video from not knowing this...
oh well. what i'd do if your levels fall outside this range is use "levels(0,1,255,16,255)" to squeeze the values into this range, rather than clip them like limiter does. no point losing values, and the decrease in contrast isn't noticable on a TV that normally can and has been adjusted to these ranges.
Wilbert
19th July 2003, 17:04
I was thinking about rounding error in the pure math sense.
I think you are right here ...
FredThompson
19th July 2003, 19:29
@Mug Funky
Take this clip and do a ConvertToYUY2() and see what happens to the detail in the oversaturated white areas:
http://www.geocities.com/fredthompson6/Screenshots/Rajiv3Sample.htm
I know the quality of the video is poor but it gives a decent test sample.
Holomatrix
8th August 2003, 14:13
Glad I found this thread because I do NTSC SVCD encodes and have a script that I like but it has Limiter() in it and was wondering if I really need it in the script? not sure what it is used for. Can someone please explain. Is it just for compliance and does not really help video quality? Thanks
FredThompson
9th August 2003, 06:39
Limiter forces the luma to a tube TV-safe range. Personally, I don't like it and don't use it any more. IMHO, it's not a quality-based decision to limit luma based on old tube technology.
jorel
9th August 2003, 09:59
Originally posted by FredThompson
Limiter forces the luma to a tube TV-safe range. Personally, I don't like it and don't use it any more. IMHO, it's not a quality-based decision to limit luma based on old tube technology.
true FredThompson,very clear!
;)
i did simple explanations in my second post in this thread:
.....forgot my poor english,ok?
:)
http://www.kvcd.net/forum/viewtopic.php?t=4983&start=32
Limiter enforces correct minimum and maximum values for the Y, U and V values within the Avisynth enviroment.
Within Avisynth
16 >= Y <= 235
16 >= U <= 240
16 >= V <= 240
and Limiter makes it so :)
Its a safety net.
Its a standards enforcer.
It limits errors made by other Avisynth filters.
regards
Simon
FredThompson
9th August 2003, 19:40
Hmmm...Simon has a good point about errors caused by poorly-written filters. (Now watch me get jumped for that phrase ;)
yaz
12th August 2003, 14:10
Originally posted by FredThompson
Hmmm...Simon has a good point about errors caused by poorly-written filters ...
hmm ... i don't know any 'poorly-written' filter as regards the topic, but ... there's somewhere a quite lengthy thread about 'unifying' the yuv scaling of filter outputs. iirc, limiter was a result of that long debate.
about the topic itself. besides the capability of TVs we should also consider the limitations of the encoders/decoders, tvo cards/softwares, softw/hardw players, ... so, everything that takes part in the encoding & decoding (playback) process. say, 1 of my tvo cards had an 'auto-clipping' feature (which drove me mad:-) another made a kinda 'auto-levelling' so as to stay within the ccir std. some tvo softwares still have the same built-in 'functions'.
u should also know that some avs functs do 'auto-clamp' (tweak, levels, ...) so, u don't need limiter when using any of these. maybe that's why some people don't see 'any difference' with or wout limiter. afm, i always use it (not limiter but coloryuv) as i do always see the difference. on the other hand, i don't see any wrong in using that but even found very usuful, say, against 'black-blocking'.
i hope nobody feels harm. not my intention. i just think a proper yuv scaling is always essential.
the bests
y
Si
12th August 2003, 17:26
i don't know any 'poorly-written' filter
You want to try some of mine then ;)
Simon
Holomatrix
12th August 2003, 17:34
@ yaz - So are you saying that I can use coloryuv() at the end of my script? I use filters like Undot() and Deen() so using limiter() for me would be usless? I need help with 'black-blocking' in dark areas, this will help smooth them out?
Thanks
yaz
13th August 2003, 12:36
@simwalter :-))
i know some of your filters. they are perfect as regards yuv scaling. that's all i meant :-))
@holomatrix:
- afaik, undot & deen output full(pc) yuv scale. (i don't use them, i favour flux & mip/c3d) u can check the yuv scale anywhere & anytime by coloryuv(analyze=true).
- i don't use limiter (tweak, levels, ...) as coloryuv can do all of yuv transformations. it's quite complex at the first glance but there are some useful equations for 'taming' it. (pls, use search to find them)
- black blocking: imho, a quite complex phenomenon, bad color/yuv scaling is a significant part. u can read a lot about it in the xvid forum. in the faq there are some very good starting points. one of the main conclusions of that lengthy debates was the necessity of perfect yuv scaling. i guess, that's why sh0dan incorporated limiter. note, limiter can clip anywhewre in the 0-255 range(!), def. is ccir.
ifm, i always check the yuv output at the very end of the scripts (even if i don't use any filter!) & transform them (near) to the ccir values if necessary. to make it perfect i use coloryuv(opt="coring") as the very last step (it's practically the same as limiter) this way i can eliminate a significant amount of that annoying blocks.
the bests
y
Holomatrix
13th August 2003, 16:01
Thanks, what I figured out last night was using this; coloryuv(opt="coring", Autogain=true) gives me great results. Would it hurt to keep Limiter in? Why I ask is that with Limiter() it give me a better filesize compression.
Thanks
Wilbert
13th August 2003, 16:10
Would it hurt to keep Limiter in?
No. I guess you loose some speed.
Why I ask is that with Limiter() it give me a better filesize compression.
Hard to believe. Do you have some tests?
Holomatrix
13th August 2003, 16:13
Yes, what I'll do is do some more tests on a chapter at work here and post the mpv file sizes for you.
Holomatrix
13th August 2003, 16:52
Ok, did my tests. Actually with Limiter() my filesize was bigger here at work on my P4, I could have swarn at home on my AMD TB 1.4 the filesize was smaller ?? Anyway, I did a chapter of Die Another Day and with Limiter() my .MPV size was 30,013 and without Limiter() it was 28,483. And ofcourse all the other settings were the same.
My script;
Import("C:\MovieRip\RESAMP~1.AVS")
LoadPlugin("C:\PROGRA~1\DVD2SVCD\AVISYN~1.5PL\Mpeg2dec\MPEG2D~1.DLL")
mpeg2source("C:\MovieRip\DVD2AV~1.D2V")
DetectedTop=60 DetectedHeight=356
BlocksToCropHorizontal=2 BlocksToCropVertical=0 BlockOptimization=16
ResizeMethod=1 Bicubic_b_Value=0.0 Bicubic_c_Value=0.6
GammaCorrection=1.0 Hue=0 Saturation=1.0 Brightness=0 Contrast=1.0
DebugMode=0
DestinationWidth=720
DestinationHeight=360
LoadPlugin("C:\Filters25\SimpleResize.dll")
Import("C:\Filters25\AVS\SemiAutoCropAndResize.avs")
MaxTreshold=1.52
scd_trigger=30
nf=0
undot()
Limiter() - would have gone here
asharp(1,4)
STMedianFilter(8,32,0,0)
MergeChroma(blur(1.52))
MergeLuma(blur(0.2))
ScriptClip("nf=YDifferenceToNext()"+chr(13)+"nf>2.5 ? asharp(-(fmin((nf/30),1)),0):TemporalSoften(2,7,7,3,2)")
ScriptClip("nf >scd_trigger ? asharp(-2,0):asharp(0,0)")
Limiter() - and here
function fmin(float f1,float f2){return(f1<f2) ? f1:f2}
coloryuv(opt="coring", Autogain=true)
ConvertToYUY2()
ResampleAudio(44100)
yaz
14th August 2003, 08:50
@holomatrix:
whoaa ... man, is it a part of a bigger script, or what? it can be reorganized heavily. ok, about the topic itself:
- limiter is (& does) the same as "coring". if u find any difference that can't be bigger than a kinda 'rounding error'. if the diff is really significant sg goes wrong.
- ok, i just can't stand it ... :-) i can't find any reason to put the 1st limiter to there where it is. how did u find that place? btw, which limiter d'u mean, when u talk about 'with/wout'? (i guess it's the first)
- be careful with autogain! it can trick u out :-) read avs manual!
the bests
y
Holomatrix
14th August 2003, 15:29
@yaz - well that is my whole script :) I was putting Limiter() in those spots because of KWAG's optimal Motion Adaptive script here - http://www.kvcd.net/forum/viewtopic.php?t=3483
Let me know your thoughts
Thanks
yaz
14th August 2003, 16:06
Originally posted by Holomatrix
@yaz - well that is my whole script :) I was putting Limiter() in those spots because of KWAG's optimal Motion Adaptive script here - http://www.kvcd.net/forum/viewtopic.php?t=3483
Let me know your thoughts
Thanks
yes, i know that scripts but i've never used them. at the 1st glance, they make very heavy blurring, so, not my taste. anyway that scripts are much simpler than yours, aren't they? :-)
as yours:
- i'd put sharpener after denoisers (STMed, mergeluma/mergechroma). no sense of increasing the noise before denoising (imho)
- no sense of limiter right before 'coring'. (if there's, pls, note sh0dan, as sg goes wrong) they are the same.
- putting limiter/coring at the very beginning would sweep the very dark & very bright regions (if the scale is 0-255 &if there's some noise really there), anyway, i can't see any reason to use it in the filter chain.
- asharp(-x) is undocumented, be careful with that. maybe just a side effect.
in general, do your source really need such heavy blurring? afais, u work with a dvd. is that really so noisy. all filters in your script seem to be 'overtuned' for a clear dvd. don't use any filter only if it's really necessary. do a step-by-step approach & watch the result of each filter. keep only that which makes necessary effects.
the bests
y
r6d2
14th August 2003, 16:26
@yaz,
These scripts indeed do heavy filtering, bluring, denoising, and more, not counting that they sometimes take forever to encode. Their attempt is to provide a remedy for the 1 CD rip fever.
As always, beauty is in the eye of the beholder.
Sometimes you get great results, sometimes you only get crap. But anyway, it is an interesting area of investigation.
Thanks for your input.
Holomatrix
14th August 2003, 16:33
Yes, I do enocoding from clear DVD's usually, but why I think I need all the filtering is because I cram 2 hr movies onto 1 cd. So I need to be able to fool the eye in thinking that the video is sharp and no blocks. So, really all the filters I use is to increase compression so I can decrease my Q quality value in CCE. Maybe you can post me a script I could try and see if it will give me the compression and quality I'm after.
Thanks
yaz
15th August 2003, 12:06
@r6d2
yeah, producing 120min/cd vcd is not easy, i know. even if special templates & quant matrices are used.
@holomatrix
- with (let's keep forum rules!) 'dvd-like' sources i rarely use any heavy gun. i'd rather play with the codec settings if necessary. a basic script seems like this:
crop
bicubicresize(neutral)
unfilter(5,5)
coloryuv(adjust yuv near to ccir, opt="coring")
i make a test with such a script (xvid/2pass) if there's some annoying noise left behind by the codec i put mip/fluxsmooth before resize but only with (very) mild settings. in most cases it's enough to maintain reasonable compression & to get good loking outputs.
i must mention that i watch films only on tv, so the time spent with 'nose on the screen' is minimal. i don't state it's the universal solution but in the last few months i haven't met any sources of 'that kind' needing more than that. in add, xvid provides facilities to gain(or loose:-) compressibility. before having tried all of that i don't go on further filtering.
tv capts is another game. the heavy filtering is unavoidable there. however, i try to keep that also on minimum. i prefer crispy, high contrast movies even if the price is some ringing&blocking here&there which means 'incomplete' noise removal too. that's me :-)
- '1cd' is not a measure anymore. how big u mean? 650, 700, 800, 900? if these all are too small 4u , burn your encoded stuff onto a dvd. or (what a friend of mine do) keep it on a separate hd & when it's full buy a new one. 80gigs in your pocket, no size limit anymore. sounds good, doesn't it :-)) these possibilities are getting reality.
the bests
y
Holomatrix
15th August 2003, 14:30
Oh, you do Xvid, have you tried that with SVCD?
yaz
26th August 2003, 10:54
Originally posted by Holomatrix
Oh, you do Xvid, have you tried that with SVCD?
i've done. just for u :-) i fed a script (intended for xvid) wout any change into tsunami & i made an svcd (~100min/2cd). i was surprised but it looked damn good. i haven't tried 1cd compression cus my system went wrong in the meantime but i don't expect too much. imho, mpeg1/mpeg2 is not intended for low bitrate.
the bests
y
cweb
12th October 2003, 17:12
Sometimes (for some recordings, not all)
coloryuv(opt="coring", Autogain=true)
gives me some random boxes which mess up the video.
I noticed that this can be solved by using Autogain=false.
Just thought this might be useful and perhaps the problem could be fixed some time...
sh0dan
12th October 2003, 19:49
@cweb: autogain was never intended for more than a single scene at the time, as it is very dumb.
A thread that might be of interest:
http://forum.doom9.org/showthread.php?s=&threadid=62328&highlight=autogain
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.