Why would it do a luma compression again :?:
Looking at the code of Limiter() (or even LegalClip() ), the actual code "clips" the pixels outside the TV range. If there are no pixels to clip, then nothing is done :!:
I think there's something misunderstood here :!:

-kwag

If the encoder does not implement a clipping itself, using it in the script does not have any effect !!! That's a thing you never understood :-(

What's the purpose to give source to the encoder in the range [16,235] if this one output the results of its computing in [0,255] :?:

Limiter or legalclip DON'T HAVE ANY MEANS !

WHAT :!:
Read what you said: If the encoder does not implement a clipping itself, using it in the script does not have any effect !!!
Of course it does :!:
If you feed the encoder with a range of 0-255, using Limiter() will CLIP the range :!:
Read: So if you feed a source which is already CCIR-601, and you have LegalClip() in your script, nothing happens because there's nothing to clip :!: I think you have it backwards :!: :roll:
We're talking about "Clipping the INPUT" :!:

Or, am I missing something here :?:

-kwag

Hya,
This is getting a bit off topic but nevertheless very interesting to watch closely.
This is why I love this forum: good arguments by great gurus like Phil, kwag and Inc. :D
Hope to hear more from you guys on this subject.
Cheers

Yeah ! You miss the real purpose of this clipping : to have a video that stay in the acceptable ouput for a TV set.

Right or not ?

If I'm right (and I think I am), what you give to the encoder doesn't have any importance ! The only important thing is what the encoder outputs !

And here, these encoders that don't implement the clipping will output in (0,255) whatever the range of the values they receive in entrance.

Do you expect that, because you use Limiter() in the source, the output will be in [16,235] :?:

Not exactly. Read on! WRONG :!:
If we feed the encoder with a range of 0-255 instead of CCIR-601, what do you think that will happen to the Q factor :?:
Similar (but not the same ) as feeding more pixels as input, the encoder must work harder.
Without LegalClip() or Limiter(), the luma/chroma levels are "wider" (if the source is not CCIR-601), thus making the encoder work harder on extra range, which will have an effect on output quality.
I hope that now it makes sense :!: ... that the luma/chroma range on INPUT, has an indirect proportional impact on OUTPUT quality per pixel, because of out-of-bounds DATA that the encoder must analyze :!:

-kwag

Okay, seen like this, that makes sense to use it. Even if that's completly modify the first purpose of the filter :wink:
Let say it's just a filter like an other one whom purpose is to have a better compressibility.

feature from avisynth 253 and new versions:

sh0dan's post:
* The default luma range in Limiter is corrected to 16-235 (it was 16-236).
http://www.kvcd.net/forum/viewtopic.php?t=7416

"Changes to 2.53 Released" :
- Added "pc_range=true/false" parameter to overlay.
This will make all RGB<->YUV conversions inside Overlay assume
[0->255] YUV range, and not CCIR 601 [16->235] range.
:arrow: Default is false.
http://cultact-server.novi.dk/kpo/avisynth/avs_cvs.html

then?..... what we do and how?!?!

Keep at least ONE instance of Limiter(), at the beginning of the filter chain.
This will ensure that the input video is always clipped to CCIR-601.
I think the last "Limiter()" at the end of the chain can be removed, because I just don't see how any filter can produce out of bounds (range) video.
Unless there's an AviSynth filter that actually does produce data on the full range, then as a double safety measurement, the last "Limiter()" would also guarantee that any filter in the chain that does produce data out of the range, will also be clipped.

Think of it like this:
1) The first "Limiter()" will clip the input video to CCIR-601, thus feeding the filter chain with the TV range.
2) The last "Limiter()", will ensure that ANY filter that produces data out of CCIR-601 range will be clipped, before actually entering the encoder.

So yes, I will use both instances, just in case :!:

-kwag

very clear why and where use limiter but, if choose:
:arrow: "pc_range=true/false" parameter to overlay,
we still need to use limiter (the first, the last....both? ) :?:
:?

:imstupid:

:logfile:
:wink:

It is not only a missing filters ploblem (excuseme I don't know if you think about following, it is only a suggestion and help)

You must to have present that blidnpp needs both dimensions divisible by 16. When not, addborders (0,0,x,y) must to be just after avisource line to correct dimensions. I think, and Dialhot can confirm or not this, that it won't be enough to leave Moviestacker to put crop rows as actually, and after this to put blindpp row, because blindpp (like first blockbuster and convolution3d) must to be before gripcrop and gripsize rows. In other words, you must to change your filters order for give support to dialhot V4 optimal script.

eg.

V4 Dialhot Script order
Your order
@Dialhot:
Just in case of Gripfit replacement with Bicubic or Lanczos resize, where its addborders row (don't missunderstand, not the divisible by 16 addborders row previously mentioned) must to be placed?
Do we must to put it in Gripborders row place?

The addborders is always the last line in a script (eventually followed by the subtitle lien if you want them into the borders and not into the picture).

@ Prodater64

I'm aware that BlindPP needs a screen frame multiple of 16x16, and the additional addborders to "fix" the possible incorrect size is an easy one. :wink:
About the filters order, we could talk here for months discussing what filter should become first (or last) and not get in an agreement. So I plan to implement a selectable order to the filters. That should do it. 8)

Hi Muaddib,
That I was going to ask you soon if it was possible.
Also if there could be a flag for putting the same filter twice in the scrip.
Of course that would be for a limited amout of filters like limiter, blockbuster and a few others.
Cheers

As we all know, we can write in moviestacker avisynth script window, and we can scripting with another filter than moviestacker supports. If we put this filters not supported, in moviestacker avisynth scripts folder, does it (moviestacker) previews and/or compares correctly?

yes if you put the correct address to load the filter in the script...like this:

LoadPlugin("X:\foldername\namefilter.dll")
:wink:

Just wondering if when I choose interlaced resizing is the script adjusted so that the filters are applied correctly for interlaced material? Planning to some VHS captures and conversions soon that I would like to keep interlaced.

Unfortunately not yet. The interlaced resizing (as it is now) is applied only to the resizing. All filters will be applied as progressive.
If you want all filtering to be applied separated in the interlaced fields, you'll have to do it manually. But you could try it the way it is and see if you like the quality.

@ Manipulators of Moviestackers AVS Script output:

On interlaced sources keep in mind that when only spatial filters are applied perform simple right behind the source import line:

separatefields()
AnyResizer(Here Settings output by Moviestacker "interlaced" mode!! used)
YourOnlySpatialFiltersHere()
Weave()

In case of temporal filtering:

separatefields()
AnyResizer(Here Settings output by Moviestacker "interlaced" mode!! used)
even=selecteven(). YourTemporal or Spatial FiltersHere()
odd=selectodd().YourTemporal or Spatial FiltersHere()
interleave(even,odd)
weave()

Means on a Simple interlaced captured PAL 768x576 (quadra pixels) resized to 704x576 (square pixels!) source we would use TemporalSoften like this:

Mpeg2source("Path:\ToMyMpegSource.d2v)
separatefields()
Bicubicresize(704,288) # half height cause of separated fields!!!
even=selecteven().TemporalSoften(2,5,8,5,2)
odd=selectodd().TemporalSoften(2,5,8,5,2)
interleave(even,odd)
weave()

As Temporal Filters do compare pixels in a radius count of Frames/fields and NOT in a radius on neighbour pixels on the SAME Frame/field .... a Temporal interlaced filtering the upper fields and lower fields have to be treaten temporal in their group (upper field group and lower field group).

;-)

NEVER do a filtering on interlaced sources without separated fields! As this would "touch/modifiy" the interlaced architecture which would be recognised on Tv! ... There do exist some smart temporal or spatial filters which do treat interlaced sources in the correct way ... but I don't trust in this ;-)


@ muaddib

My suggestion according to ready made scripts for implemenattion in Movietsacker would be:

- several templates could be offered within Movistackers folder
:arrow: for MA, for interlaced MA, for OptimalScript, for interlaced Optimal script, for 29iTo24p conversion by Sharfis_Brain ... etc.
In these Templates there has to be only the width and heigth incl Resizer Model via %Varaibles% defined which will be set in Moviestackers engine automatically when a special Script Template is choosen.

Advantage: IF there will be an update of Optimal script or (even) MA ... you just have to update the template and not the program code.
Also knowledged users could do write their own spcific templates which will b often used (like in case of captures) by respecting the %Variables% when authoring a template.

:arrow: totally automatism :arrow: more time for Girls, girls, girls :arrow: :D

Hi incredible!

Thanks for pointing me the correct way to do it.
I'll keep that in mind while/when implementing it in MovieStacker.

About your suggestion… that’s a great idea!
And I will carefully study the possibility. :wink: