Vapoursynth

[Selur]

Using R52:

clip = core.resize.Bicubic(clip=clip, format=vs.RGB48, matrix_in_s="470bg", range_s="limited")
# color adjustment using TimeCube
clip = core.timecube.Cube(clip=clip, cube="I:/Hybrid/64bit/vsfilters/ColorFilter/TimeCube/PQ_to_BT709_slope.cube")
clip = core.resize.Bicubic(clip=clip, format=vs.YUV444P16, matrix_s="470bg", range_s="limited")
clip = core.std.Levels(clip=clip, min_in=16, max_in=235, min_out=16, max_out=235)

-> green screen

clip = core.resize.Bicubic(clip=clip, format=vs.RGB48, matrix_in_s="470bg", range_s="limited")
# color adjustment using TimeCube
clip = core.timecube.Cube(clip=clip, cube="I:/Hybrid/64bit/vsfilters/ColorFilter/TimeCube/PQ_to_BT709_slope.cube")
clip = core.resize.Bicubic(clip=clip, format=vs.YUV444P10, matrix_s="470bg", range_s="limited")
clip = core.std.Levels(clip=clip, min_in=16, max_in=235, min_out=16, max_out=235)

-> green screen

# adjusting color space from YUV420P10 to RGB48 for vscube
clip = core.resize.Bicubic(clip=clip, format=vs.RGB48, matrix_in_s="470bg", range_s="limited")
# color adjustment using TimeCube
clip = core.timecube.Cube(clip=clip, cube="I:/Hybrid/64bit/vsfilters/ColorFilter/TimeCube/PQ_to_BT709_slope.cube")
clip = core.resize.Bicubic(clip=clip, format=vs.YUV444P8, matrix_s="470bg", range_s="limited")
clip = core.std.Levels(clip=clip, min_in=16, max_in=235, min_out=16, max_out=235)

-> works

Same happens when using RGB30 in the scripts.


Levels documentation says:

clip

    Clip to process. It must have integer sample type and bit depth between 8 and 16, or float sample type and bit depth of 32. If there are any frames with other formats, an error will be returned.

since there isn't an error I assume this is a bug in Vapoursynth or I'm doing something wrong when converting RGBX to YUV.

So:
a. can others reproduce this?
b. is this a bug in Vapoursynth or am I missing something?


Cu Selur

[poisondeathray]

@Selur , for the 10bit levels cases, it should not be 16 and 235. It should be 64 and 940. And 4096-60160 for 16bit

Also, you are adjusting all channels, not just Y - is that what you wanted ?

And for CbCr, in 8bit it would be 16-240 , 64-960 for 10bit, 4096-61440 for 16bit

[Selur]

@Poisongdeathray: Ah okay, I assumed Levels would to the scaling automatically.

[Selur]

Small question: is there a way to disable auto-loading of filters inside a script (on Linux and Mac) to be sure that only the filters which are explicitly loaded in the script are tried to load?

[Myrsloik]

Originally Posted by Selur

Small question: is there a way to disable auto-loading of filters inside a script (on Linux and Mac) to be sure that only the filters which are explicitly loaded in the script are tried to load?

Implemented in the doodle1 branch but it's only accessible through the environment policy interface so it's very iffy. Unfortunately I can't give you an example either right now.

[Selur]

no problem, I'll wait till it hits the main branch, but happy there it's in the works.

[shph]

I am not an expert but this may be a bug in Vapoursynth (my original post here https://forum.selur.net/showthread.p...d=9159#pid9159)
Gamma correction works normally if source transformed to RGB. But in YUV it produce green/purple (depends of gamma adjustment direction) color shift.

Examles:
planes: all Gamma adjusted in YUV. Green/Purle color shift problem (probably bug in Vapoursynth):


planes: luma Gamma adjusted in YUV. No color shift problem, but "desaturation" effect that is essential for this sort of luma only adjustment.

planes: all Gamma adjusted in RGB. This is how any normal gamma adjustment usually look:


As a reference here is screengrab with gamma adjusted PhotoLine graphic editor. Some difference may be due video player screengrabs color management and range transformations, but overall look is near the same. It is dark but not desaturated:

[VS_Fan]

Originally Posted by shph

I am not an expert but this may be a bug in Vapoursynth (my original post here https://forum.selur.net/showthread.p...d=9159#pid9159)
Gamma correction works normally if source transformed to RGB. But in YUV it produce green/purple (depends of gamma adjustment direction) color shift.

It's not a bug. A brief suggestion: Don’t include the chroma planes if adjusting gamma with core.levels in vapoursynth

Recommended reading: Why gamma-correction is applied to RGB instead of YUV or similar?

Also, here’s some info from Avisynth’s Levels

When processing data in YUV mode, Levels only gamma-corrects the luma information, not the chroma. Gamma correction is really an RGB concept, and is only approximated here in YUV. If gamma=1.0 (unity), the filter should have the same effect in both RGB and YUV modes. For adjusting brightness or contrast in YUV mode, it may be better (depending on the effect you are looking for) to use Tweak or ColorYUV, because Levels changes the chroma of the clip

[Selur]

Vapoursynth documentation should also include some of this,..

[shph]

That makes sense. Y is Luma (tonality data only) and UV is saturation (color data only). Gamma is tonal curve only, so seems it is just useless and incorrect to apply it to UV color data or to YUV all together.

It is ok to apply Gamma only to Y in YUV model.
It is ok to apply Gamma to all RGB channels together or to separate R G B channels in RGB model.

And so we came to YRGB color correction concept used in DaVinci Resolve and some other color grading apps

[Cary Knoop]

Originally Posted by shph

It is ok to apply Gamma only to Y in YUV model.

It really is not ok!

[shph]

Cary Knoop, Can you explain further why?

As i noticed earlier Y gamma is not the same as RGB gamma. Y gamma is more like some special effect when you need adjust gamma without saturation.

[shph]

Here is another observation. Tweak is a part of VapourSynth? It was a discussed earlier that color correction results don't match exact to other image editors, but seems it is just due different math concepts of same adjustments in different apps https://forum.doom9.org/showthread.php?t=175093

But also i noticed that Tweak Contrast always shifts a lot to dark side of gradient. It feels like center Pivot point for that tool is way off. Could it be a bug? Maybe Tweak also require some special gamma transformation?
You can download Test Patterns generated in DaVinci Resolve here: https://www.dropbox.com/sh/bak63hnr7...jPuQaaxFa?dl=0


To compare, here is how normal contrast adjustment look s in Davinci Resolve or any other app:

[Cary Knoop]

Originally Posted by shph

Cary Knoop, Can you explain further why?

As i noticed earlier Y gamma is not the same as RGB gamma. Y gamma is more like some special effect when you need adjust gamma without saturation.

You mess up your colors by modifying Y'.

If you want to do what I suspect you want to do you should use something like L*a*b*.
Unfortunately, Vapoursynth does not support this color model.

[poisondeathray]

Originally Posted by shph

Here is another observation. Tweak is a part of VapourSynth? It was a discussed earlier that color correction results don't match exact to other image editors, but seems it is just due different math concepts of same adjustments in different apps https://forum.doom9.org/showthread.php?t=175093

But also i noticed that Tweak Contrast always shifts a lot to dark side of gradient. It feels like center Pivot point for that tool is way off. Could it be a bug? Maybe Tweak also require some special gamma transformation?

tweak is just a port from avisynth tweak

If you want to increase contrast in a fashion similar to how Resolve and other NLE programs work, use havsfunc SigmoidDirect , for an increasing contrast "s-curve". The cont value units do not correlate directly with other programs

clip = haf.SigmoidDirect(clip, cont=blah, planes=[0])

gif demo, cont from 1 to 36


There is also VapourSynth-Curve, which can take photoshop acv files, and can work in YUV or RGB, and you can apply to each/all planes

[shph]

Yes, that sort of symmetrical S-curve variations usually expected when something named as "Contrast". Also center point position of that curve sometimes may be adjusted and that adjustment named "Pivot" in other apps. So it maybe a bug in Tweak, or Tweak may be just designed like this for some purpose.

[feisty2]

for some unknown reason, this seems to crash vspipe (like it's stuck in an infinite loop or something)

from vapoursynth import *
import os
clp = core.std.BlankClip(format=GRAYS)
clp.set_output(42)
os.system(f'vspipe -o 42 {__file__} tmp.bin -p')
clp = core.raws.Source('tmp.bin', 640, 480, src_fmt='GRAYS')
clp.set_output()

@Myrsloik what is happening here?

[feisty2]

I found a workaround to solve the problem

from vapoursynth import *
import os
clp = core.std.BlankClip(format=GRAYS)
clp.set_output(42)
if 'cache_flag' not in globals():
    os.system(f'vspipe -o 42 -a "cache_flag=yes" {__file__} tmp.bin -p')
    clp = core.raws.Source('tmp.bin', 640, 480, src_fmt='GRAYS')
clp.set_output()

it doesn't seem very pretty though...

[feisty2]

I wonder if there's a better (more accurate) way of doing this with vs.core or the vs environment stuff:

def TraceFilePathOfTheRunningScript():
    Frame = inspect.currentframe()
    Callers = inspect.getouterframes(Frame)
    del Frame
    for x in Callers:
        if x.filename.endswith('.vpy'):
            return x.filename

it should work for most cases but it relies on the script being a .vpy file, which I guess might fail in some rare cases?

[Jukus]

I don't know if need to write about this, where and how correctly, but this file opens correctly with lsmas, but all the frames are mixed up when using ffms2.
https://1fichier.com/?w8vicd396ctnl4ds9e45