Vapoursynth

[Selur]

@Jukus: looks fine here using ffms2,...
Ah okay, I see it if I don't drop halve of the fields.
Seems like the field order gets mixed up.

[vcmohan]

Can I get link to source code of BlankClip function?

[feisty2]

Originally Posted by vcmohan

Can I get link to source code of BlankClip function?

https://github.com/vapoursynth/vapou...ilters.c#L1184

[stax76]

On the github website there is a search field in the top left corner, enter BlankClip there or whatever you search.

Or download the code, open the code folder in Visual Studio Code and click on the search button in the side bar.

https://github.com/vapoursynth/vapou...implefilters.c

[vcmohan]

Originally Posted by feisty2

https://github.com/vapoursynth/vapou...ilters.c#L1184

many thanks. I am trying to code a plugin where there will be no input clip but only outputs frames. I find in blankclip

VSNodeRef* node = vsapi->propGetNode(in, "clip", 0, &err);
if (!err) {
        d.vi = *vsapi->getVideoInfo(node);
        vsapi->freeNode(node);
        hasvi = 1;
    }

What should I do. I have no node as input, but have I to include a node and bind it to something? Or I should have no ref to node in my code?
in the arInitial part what is the purpose of the following?

if (d->vi.fpsNum > 0) {
                VSMap* frameProps = vsapi->getFramePropsRW(frame);
                vsapi->propSetInt(frameProps, "_DurationNum", d->vi.fpsDen, paReplace);
                vsapi->propSetInt(frameProps, "_DurationDen", d->vi.fpsNum, paReplace);
            }

Is there an instance where fps == 0?
What is keep?
May be I am testing your patience! Sorry for it.

[feisty2]

you could try using my c++ wrapper for the vs api, things are as simple, straightforward and obvious as it can get.
this is an example that has no input but has multiple outputs: https://github.com/IFeelBloated/vsFi...es/Palette.hxx

[Selur]

Small question about the whole Limiter&Levels filter:
Can someone clear this up?
Is it okay to use Limiter&Levels on YUV content, or should they only be used on RGB content and the planes-parameter is basically a bad idea?
Or is RGB only required for Levels when gamma is used?

Cu Selur

[Selur]

with:

# Loading F:\TestClips&Co\files\10bit Test.mkv using LWLibavSource
clip = core.lsmas.LWLibavSource(source="F:/TestClips&Co/files/10bit Test.mkv", format="YUV420P10", cache=0)
# making sure input color matrix is set as 470bg
clip = core.resize.Point(clip, matrix_in_s="470bg",range_s="limited")
# making sure frame rate is set to 25
clip = core.std.AssumeFPS(clip, fpsnum=25, fpsden=1)
# Setting color range to TV (limited) range.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)
# Color Adjustment
clip = core.std.Levels(clip=clip, min_in=160, max_in=1020, min_out=160, max_out=880)
# adjusting output color from: YUV420P10 to YUV420P8 for x264Model (i420@8-bit)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P8, range_s="limited")

(this should be the same as using In 40/255 and Out 40/220 in 8bit right?)
I get a green image, where as when using:

clip = core.std.Levels(clip=clip, min_in=0, max_in=1020, min_out=160, max_out=880)

(this should be the same as using In 0/255 and Out 40/220 in 8bit right?)
everything looks fine.
-> to me this looks like there is some problem/bug with the min_in restriction with YUV420P10

Cu Selur
iirc scaling should be:

bit depth    TV scale 	PC scale
8 bit 	       16-235 	0-255
10 bit 	       64-940 	0-1023
12 bit 	       256-3760   0-4095

[poisondeathray]

@Selur ,

In YUV, usually levels means Y levels

For levels, add

planes=[0]

[shph]

poisondeathray, Y levels looks more like special effect than something commonly used. See my post here
https://forum.doom9.org/showthread.p...97#post1923597

[poisondeathray]

Originally Posted by shph

poisondeathray, Y levels looks more like special effect than something commonly used. See my post here
https://forum.doom9.org/showthread.p...97#post1923597

Your post deals with "gamma" - gamma is an RGB concept

(Gamma can refer to Y plane; it acts as "power" function - and you can check with a Y waveform; but usually not applied to CbCr planes because they are color difference channels)

Levels in YUV , generally refers to Y plane only; applying it to the CbCr planes is the reason for the green discoloration Selur is observing

[shph]

Levels in-out min-max applied in YUV to Y only also look subjectively incorrect and very different to Levels applied in RGB to all planes.
Same as Gamma, Levels in-out min-max applied in YUV to Y only look more like some sort of special effect but not like something that people usually expect from levels correction.

[poisondeathray]

Originally Posted by shph

Levels in-out min-max applied in YUV to Y only also look subjectively incorrect and very different to Levels applied in RGB to all planes.
Same as Gamma, Levels in-out min-max applied in YUV to Y only look more like some sort of special effect but not like something that people usually expect from levels correction.

That's expected because gamma is a RGB concept.

Levels in/out min/max and gamma in Y looks correct for a Y levels correction. That's what a Y levels adjustment means.

RGB is additive color model . If you start with x value of R and double it, it gets more "red" . Same with Y' (in terms of it increases in brightness, it's not necessarily double) . But this does not happen with CbCr because they are color difference channels - the color completely changes

[shph]

This is all correct and was explained few posts earlier. I just try to explain that there two options to apply Levels/Gamma/Limiter that give different results:

- RGB channels together
- Y in YUV model

Why do you think that Y in YUV model looks correct but RGB is incorrect? If you compare result to image editors it appears that Y in YUV model looks "incorrect". My personal understanding of this filter is that both results look interesting and may be useful depending of artistic taste or some special requirement. Levels/Gamma/Limiter in RGB model behave like classic Levels tool in any image editing app.
Levels/Gamma/Limiter - Y in YUV model probably behave more like some sort of analogue video filter in equipment that operates in YUV.

[shph]

Examples:

Limiter in RGB model (forced RGB input was created by TimeCube filter with applied empty identity.cube LUT):


Limiter - Y in YUV model:

[poisondeathray]

Originally Posted by shph

Why do you think that Y in YUV model looks correct but RGB is incorrect?

I never said it was incorrect. It's correct for RGB .

I said it was correct for Y, and working correctly for Y channel

If you compare result to image editors it appears that Y in YUV model looks "incorrect".

An image editor works in RGB

[Selur]

I guess the confusion is that one intuitively assumes that YUV + planes=all would behave like RGB.
Okay, so:
a. either applying level limits only in Y or RGB (Levels and Limiter)
b. when using gamma always use RGB (Levels)
or expect the unexpected?

[poisondeathray]

Originally Posted by Selur

a. either applying level limits only in Y or RGB (Levels and Limiter)

Levels limits by clipping can technically be applied to CbCr too, but the range is different than "legal" range Y (CbCr 16-240 in 8bit values, whereas Y is 16-235).

But if you use min/max in/out parameters, or gamma, range compression/expansion is applied or a power function (for gamma) - and that's when you can get unexpected results because of the way CbCr's works (color difference)

RGB range limiting is rare. There are 2 situations where the RGB range would be limited - for r103 compliance or studio range RGB. RGB is typically "full range" in 99.99999% of scenarios.

b. when using gamma always use RGB (Levels)
or expect the unexpected?

Not always; Adjusting "Gamma" - the parameter - can be used on Y channel as a power function . eg. you might want to roughly brighten shadows to a higher degree than highlights

The math for the Y curve is the same as , R, G, B curves (ie. the shape of the curve) when you adjust "gamma" for the latter. YUV obviously isn't RGB, so there is no reason to assume you'd get something visually similar

If you view a Y waveform, you can see what levels (any of the parameters, including gamma) in Y is actually doing to the image. People have used levels or smoothlevels in avisynth (since forever) . You know this, Selur

There are scenarios/ reason why one might prefer manipulations in YUV, but others in RGB

NLE's that work in YUV - their YUV levels "gamma" parameter works the same way, and their R,G,B "gamma" parameter for RGB levels works like an image editor

[HuBandiT]

Originally Posted by Selur

I guess the confusion is that one intuitively assumes that YUV + planes=all would behave like RGB.
Okay, so:
a. either applying level limits only in Y or RGB (Levels and Limiter)
b. when using gamma always use RGB (Levels)
or expect the unexpected?

The answer depends on what you are trying to do.

What are you trying to do?

[Jukus]

Is there no way to use ffmpeg filters inside a script?