Processing plane

[TbtBI]

Hi.

It seems y/u/v=1 is copying the plane. For example mt_lut("x 16 -", y=1) luma is copied. Is it expected behavior?

[DJATOM]

From docs:

int "y" (3), int "u" (1), int "v" (1)

These three values describe the actual processing mode that is to be used on each plane / channel. Here is how the modes are coded :

    x=-255..0 : all the pixels of the plane will be set to -x.
    x=1 : the plane will not be processed. That means the content of the plane after the filter is pure garbage.
    x=2 : the plane of the first input clip will be copied.
    x=3 : the plane will be processed with the processing the filter is designed to do.
    x=4 (when applicable) : the plane of the second input clip will be copied.
    x=5 (when applicable) : the plane of the third input clip will be copied.

As you can see, defaults parameters are chosen to only process the luma, and not to care about the chroma. It's because most video processing doesn't touch the chroma when handling 4:2:0.

[TbtBI]

I expected after mt_lut("x 16 -", y=1) luma would be the same as mt_edge(y=1) - no data. Also mt_edge().extractv() - https://images2.imgbox.com/ab/92/QjiNfRqf_o.png

[pinterf]

No data is not the same as nulled data. y=1 means that you can expect undefined memory content, either a random pattern or if Avisynth framebuffer reuse algorithm is in work, possibly the Y plane of a previous random frame. The Y plane of the new result frame is neither read nor written. The reason that option =1 exist: quicker execution when you know that you won't use a specific plane later. No time is spent even with the plane copy.

[TbtBI]

Thanks for the detailed answer.