Avisynth+

[real.finder]

thank you both pinterf and TheFluff

Currently I work on port ContraSharpen_mod (https://web.archive.org/web/20140711175720/https://www.nmm-hd.org/upload/get~n1nycx8X7qw/ContraSharpen_mod.avsi) for Nnedi3_resize16 both by mawen1250 to avs+ and it has this expr, I will leave it in mt_lut for now until I fully complete the script

[real.finder]

if I go from out-of-range float clip (not 0..1.0 luma nor -0.5..0.5 chroma) to 8 bit int I got kinda wrong output unless I use mt_lut("x -0.5 0.5 clip",yexpr="x 0 1 clip",u=3,v=3) or Limiter(0,1,-0.5,0.5) before I convert to 8 bit, is this bug or this is normal?

[pinterf]

if I go from out-of-range float clip (not 0..1.0 luma nor -0.5..0.5 chroma) to 8 bit int I got kinda wrong output unless I use mt_lut("x -0.5 0.5 clip",yexpr="x 0 1 clip",u=3,v=3) or Limiter(0,1,-0.5,0.5) before I convert to 8 bit, is this bug or this is normal?
If it does not even fit into a 32 bit integer, there may be problems, but I'll check it when you specify how much it is out of range.

[real.finder]

If it does not even fit into a 32 bit integer, there may be problems, but I'll check it when you specify how much it is out of range.

test with this fat lut/expr from ContraSharpen_mod


ColorBars(width=640, height=480).converttoyv12
ConvertBits(32)
mt_lut("x 128 == x x 128 - abs 11 / 22 ^ 11 * "+string(33/100.0)+" * x 128 > 1 -1 ? * x 128 - 2 ^ 11 2 ^ 44 + * x 128 - 2 ^ 44 + 11 2 ^ * / * 1 55 0 == 0 11 55 / 4 ^ ? + 1 55 0 == 0 x 128 - abs 55 / 4 ^ ? + / * 128 + ?",scale_inputs="allf",use_expr=2, U=3, V=3)
ConvertBits(8) #ok with isvideofloat? Limiter(0,1,-0.5,0.5).ConvertBits(8) : ConvertBits(8)

[pinterf]

Thanks for the sample. When the pixel value is greater 128 (float format) - not that the usual max. is 1.0 - then the 8 bit conversion will not clamp to 255. Rare case, nevertheless I have fixed it on my side.

[amichaelt]

Usage Poll, 10 XP users versus 29 W10 users of Avisynth, is a bit more than 1.34%.

EDIT: Current total OS usage sample 58.
I use 2 * XP, 1 * W7, 1*W10, and voted for all 3, [was only supposed to vote for 1]

https://en.wikipedia.org/wiki/Selection_bias

[StainlessS]

Yep I see what you mean, I should have only voted for XP, as that is the one I use on most machines.

[tormento]

Usage Poll, 10 XP users versus 29 W10 users of Avisynth, is a bit more than 1.34%.
This forum is everything but a representative sample.

[StainlessS]

Yep you are correct, there will be MANY more XP users than show up on Internet Stats, many are totally offline (One of mine is occasionally given Internet access [several months since] the other one NEVER).

[StainlessS]

Dont know if below is bugged, or misleading error message, or both.


# OK
Blankclip(Length=1,Width=1,height=1,Pixel_type="YV24").PointResize(256,256)

# Resize: source image too small for this resize method. Width=1, Support=1.
Blankclip(Length=1,Width=1,height=1,Pixel_type="YV24").BilinearResize(256,256)

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV12").BicubicResize(256,256) # NOTE, YV12, Presumably error for chroma

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=2,height=2,Pixel_type="YV24").BicubicResize(256,256) # NOTE, YV24

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").Lanczos4Resize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").GaussResize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").BlackmanResize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").LanczosResize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").sincResize(256,256)

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=2,height=2,Pixel_type="YV24").Spline16Resize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").Spline36Resize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").Spline36Resize(256,256)

Return Last

For eg YV24, width=2, height=2, Says width = 2, Support=2 (when it clearly produces an error message, ie seems not to support 2).

Think its been like this 4E4 (believe it exists as above in avs standard).

EDIT: Presume similar on height, untried.
Above still happens.

Also,

W=1
H=1
CS="RGB32"
BlankClip(Width=256,Height=256,pixel_type=CS)
#BiLinearResize(W,H) # Resize: Source image too small for this resize method. Width=256, Support=256.
BicubicResize(W,H) # Resize: Source image too small for this resize method. Width=256, Support=512.
Return Last

Presume same for Height [and other Resizers/colorspaces], untested.
EDIT: "AviSynth+ 3.5 (r2947, master, i386)"

EDIT: Even chasing the error message is fun :)

W=1
H=1
CS="RGB32"
#BlankClip(Width=256,Height=256,pixel_type=CS)
#BiLinearResize(W,H) # Resize: Source image too small for this resize method. Width=256, Support=256.
#BicubicResize(W,H) # Resize: Source image too small for this resize method. Width=256, Support=512.

# Even chasing the error message is fun
#BlankClip(Width=512,Height=512,pixel_type=CS)
#BicubicResize(W,H) # Resize: Source image too small for this resize method. Width=512, Support=1024.

BlankClip(Width=1024,Height=1024,pixel_type=CS)
BicubicResize(W,H) # Resize: Source image too small for this resize method. Width=1024, Support=2048.

Return Last

[pinterf]

BlankClip(Width=1024,Height=1024,pixel_type=CS)
BicubicResize(W,H) # Resize: Source image too small for this resize method. Width=1024, Support=2048.

Return Last
[...]

I will definitely kill that error message about "support". Filter property, original and target size, crop size are all involved in the calculation.

filter_support = support() / min(target_width / crop_width, 1.0)
if (width_original < filter_support) --> error

support() values are
4 - Gaussian, sinc, Spline64, lanczos4
4 (or taps) - Blackman
3 (or taps) - Lanczos
3 - Spline36
2 - Spline16, bicubic
1 - bilinear

[StainlessS]

This calcs for 2.58, 2.60, and avs+


Function IsAvs26() { VersionNumber>=2.6}
Function IsAvsNeo() { FindStr(VersionString," Neo")!=0}
Function IsAvsPlus() { FindStr(VersionString,"AviSynth+")!=0||IsAvsNeo}
Function X_YMod(clip c) { c IsAvsPlus ? (NumComponents==1||IsRGB?1:Height/ExtractU.Height):(IsYV12 ?2:1) } # Y Min crop multiple for Progressive
Function X_XMod(clip c) { c IsAvsPlus ? (NumComponents==1||IsRGB?1:Width/ExtractU.Width):IsAvs26?(IsYV411?4:IsYUY2||IsYV16||IsYV12?2:1):(IsRGB?1:2)} # X Min crop multiple
Function X_CsXMod(Val CSP) { (CSP.IsClip)?CSP:(CSP.IsString)?Blankclip(Length=1,Width=16,height=16,Pixel_type=CSP):Assert(False,"X_CsXMod: CSP Clip or Pixel_Type string ONLY") Return X_XMod }
Function X_CsYMod(Val CSP) { (CSP.IsClip)?CSP:(CSP.IsString)?Blankclip(Length=1,Width=16,height=16,Pixel_type=CSP):Assert(False,"X_CsYMod: CSP Clip or Pixel_Type string ONLY") Return X_YMod }

Function X_MinResize(String Resizer,Val CSP,Bool "Wid",Bool "Src",Int "Taps") { # Minimum required Width or Height, Source or Dest, for Resizer and Colorspace, CSP can be Clip or String eg "RGB32"
S=Resizer.UCase I=FindStr(S,"RESIZE") S=(I==0) ? S : S.LeftStr(I-1) # Can use eg Resizer either "BiLinearResize or just BiLinear"
Ix=(S=="POINT")?0:(S=="BILINEAR")?1:(S=="BICUBIC")?2:(S=="SPLINE16")?3:(S=="SPLINE36")?4:(S=="SPLINE64")?5:(S=="GAUSS")?6:(S=="LANCZOS4")?7:(S=="LANCZOS")?8:(S=="BLACKMAN")?9:(S=="SINC")?10:-1
Assert(0 <= IX <= (IsAvs26?10:9), "X_MinResize: No such Resizer filter (" + S + "Resize)")
defT=Select(Ix, 0,-1,-2,-2,-3,-4,-4,-4,3,4,4)
Wid=Default(Wid,True) # True = Inquire Width, else Height
Src=Default(Src,True) # True = Inquire Upscale Src, else DownScale Dest
Assert(defT>0 || !Taps.Defined,"X_MinResize: "+S+"RESIZE Does not have a Taps arg")
Taps=(defT>0) ? Default(Taps,defT) : Abs(defT)
Assert(CSP.IsClip || CSP.IsString,"X_MinResize: CSP clip or Pixel_Type string ONLY")
Return (Wid) ? (Taps+1) * CSP.X_CsXMod : (IsAvs26) ? (Taps+1) * CSP.X_CsYMod
\ : (Src) ? (Taps+1) * 2 : Max((Taps+1)*2,4) # Fix for v2.58 Peculiarities
}


From here:- https://forum.doom9.org/showthread.php?p=1901605#post1901605

EDIT:
I do not take into account Dest size when inquiring min Src size, or Src size when inquiring min Dest size, it dont seem to matter, maybe I need more checks.
Also do not take into account src_left, Src_top etc, we assume full src.

EDIT:
filter_support = support() / min(target_width / crop_width, 1.0)
if (width_original < filter_support) --> error

# ...

1 - bilinear

If say Bilinear [support=1], and upsizing, so "min(target_width / crop_width, 1.0)" = 1.0, and filter_support = 1.0/1.0 = 1, so error if width_original < 1.0, however,
bilinear always fails unless width_original = 2, ie support + 1. Same with all of the others, and the reason for the "(Taps+1) * CSP.X_CsXMod" type stuff above,
you can substitute support where says Taps above.
Maybe there is some kind of float precision thing going on, where something like width_original < 1.00000000000001 provides error where it is intended not to.
Same happens when downsize, taps + 1 minimum.


S=1
BlankClip(Length=1,Width=S,Height=S,Pixel_type="RGB32")
Z=2
BiLinearResize(Z,Z) # Width=1 support = 1 error


EDIT: This looks like it
ResamplingProgram* ResamplingFunction::GetResamplingProgram(int source_size, double crop_start, double crop_size, int target_size, int bits_per_pixel, IScriptEnvironment2* env)
{
double filter_scale = double(target_size) / crop_size;
double filter_step = min(filter_scale, 1.0);
double filter_support = support() / filter_step;
int fir_filter_size = int(ceil(filter_support*2));

ResamplingProgram* program = new ResamplingProgram(fir_filter_size, source_size, target_size, crop_start, crop_size, bits_per_pixel, env);

// this variable translates such that the image center remains fixed
double pos;
double pos_step = crop_size / target_size;

if (source_size <= filter_support) {
env->ThrowError("Resize: Source image too small for this resize method. Width=%d, Support=%d", source_size, int(ceil(filter_support)));
}

Actually <= not <, so support actually means not supported ???
[Actually, I think qyot27 might have said something about < versus <= last time subject came up]
EDIT: Yep, RaffRiff42 and qyot27 both made mention:- https://forum.doom9.org/showthread.php?p=1836752#post1836752

[stax76]

Made some simple wrapper library for AviSynth and VapourSynth, it was necessary because AviSynth has no C or COM interface...

https://github.com/staxrip/staxrip/tree/master/FrameServer

https://github.com/staxrip/staxrip/blob/master/General/FrameServer.vb

https://github.com/staxrip/staxrip/blob/master/General/VideoRenderer.vb

[gpower2]

Made some simple wrapper library for AviSynth and VapourSynth, it was necessary because AviSynth has no C or COM interface...

https://github.com/staxrip/staxrip/tree/master/FrameServer

https://github.com/staxrip/staxrip/blob/master/General/FrameServer.vb

https://github.com/staxrip/staxrip/blob/master/General/VideoRenderer.vb

Good job m8!
I was experimenting myself recently on something similar for my C# projects!

[stax76]

@gpower2

No problem, I've committed a vs text encoding fix today. To convert from VB.NET to C# there is http://converter.telerik.com or if that don't work the jetbrains dotpeek decompiler can be used.

MysteryX has written code to access VapourSynth directly in C#, that would have been an alternative route I could have taken.

https://github.com/mysteryx93?tab=repositories

[qyot27]

AviSynth+ 3.5.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.5.0)

The big, shiny new feature this time around: native support for Linux, macOS, and BSD. Full list of changes:

New:
New: Native Linux, macOS, and BSD support.
New function:
bool IsVersionOrGreater(int majorVersion, int minorVersion [,int bugfixVersion]) function
Returns true if the current version is equal or greater than the required one in the parameters.
The function is checking the current version against the given parameters (similar to a Windows API function)
e.g. IsVersionOrGreater(3, 4) or IsVersionOrGreater(3, 5, 8)
New: "Expr" helpers:
Constants "yrange_min", "yrange_half", "yrange_max"
Unlike the luma/chroma plane adaptive "range_min", "range_half", "range_max" these constants always report the luma (Y) values
new parameter: bool clamp_float_UV (default false)
this parameter affects clamping of chroma planes: chroma is clamped between 0..1.0 instead of -0.5..0.5s
"clamp_float" is not ignored (and set to true) when parameter "scale_inputs" auto-scales 32 bit float type pixels
New "yscalef" and "yscaleb" keywords similar to "scalef" and "scaleb" but scaling is forced to use rules for Y (non-UV) planes
new allowed value "floatUV" for scale_inputs.
In short: chroma pre-shift by 0.5 for 32 bit float pixels
Affects the chroma plane expressions of 32 bit float formats.
Shifts the input up by 0.5 before processing it in the expression, thus values from -0.5..0.5 (zero centered) range are converted to the 0..1 (0.5 centered) one.
Since the expression result internally has 0..1.0 range, this then is shifted back to the original -0.5..0.5 range. (since 2.2.20)
Note: predefined constants such as cmin, cmax, range_min, range_max and range_half will be shifted as well, e.g. the expression will see range_half = 0.5

These modifications are similar to Masktools2 2.2.20+
New: AddBorders, LetterBox: new color_yuv parameter like in BlankClip


Fixes:
Fix: ConvertBits 32->8 for extremely out of range float pixel values.
When pixel value in a 32 bit float format video was way out of range and greater than 128 (e.g. instead of 0 to 1.0 for Y plane) then the ConvertBits(8) had artifacts.
Fix potential crash on exit or cache shrink (linux/gcc only?)
Layer: support RGB24 and RGB48 (internally processed as Planar RGB - lossless pre and post conversion)
Fix: RGBP to 444 8-14bit right side artifacts at specific widths
Fix: "scalef" and "scaleb" for 32 bit input, when scale_inputs="floatf" produced wrong result
Fix: missing rounder in V channel calculation of PlanarRGB->YUV 8-14bits SSE2 code
Overlay: show error when Overlay is fed with clips with different bit depths
Fix: TemporalSoften possible access violation after SeparateFields (in general: after filters that only change frame pitch)
Fix: Shibatch.DLL Access Violation crash when exit when target rate is the same as vi.audio_samples_per_second or audio_samples_per_second is 0
Build system: Cmake: use platform toolset "ClangCL" for using built-in Clang support of Visual Studio.
Since VS2019 v16.4 there is LLVM 9.0 support.
Use: Tools|Get Tools and Features|Add Individual Components|Compilers, build tools, and runtimes
[X] C++ Clang compiler for Windows
[X] C++ Clang-cl for v142 build tools (x64/x86)
(for LLVM Clang installed separately, please use llvm or LLVM - no change in its usage)

[StainlessS]

Lovely and shiny, thanx muchly :)

[ChaosKing]

Linux + mac support, nice! So it does not rely on vfw anymore? Are there already tools what supports "native" avs files on linux?

Happy avs filter recompiling :D

[DJATOM]

It seems like ffmpeg is the only available software that supports avs+ on linux. Probably it's possible to compile avs2yuv/avs2pipemod, but I'm not interested to do so right now.

[FranceBB]

Introducing Linux and Mac OSX Support is a very important achievement!
Some people (including me) never thought this day was going to happen, but here it is...!
Kudos to all of you, guys!
And as always, it also works like a charm on Windows XP as well! (I just tested it) :)

[Groucho2004]

AviSynth+ 3.5.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.5.0)Nice work. :thanks:

[wonkey_monkey]

So is this, not pinterf's, now the Avisynth+?

[qyot27]

So was 3.4; development moved back to the original AviSynth/AviSynthPlus git repo last summer.

[qyot27]

Linux + mac support, nice! So it does not rely on vfw anymore? Are there already tools what supports "native" avs files on linux?

Happy avs filter recompiling :D

x264 and FFmpeg on Windows have used the C interface for talking to AviSynth.dll directly for ages (x264 = 2009, FFmpeg = 2013). VfW was just a provided interface; on Windows it still is. This does mean that the AviSource/WAVSource/SegmentedFileSource filters don't exist on non-Windows OSes, though.

But yes, a patch exists to be able to use AviSynth+ in FFmpeg on Linux, et al. (https://github.com/qyot27/FFmpeg/commits/avsplus_linux). It getting into FFmpeg upstream is dependent on whether they want a deprecation message to tell people to upgrade from AvxSynth or not (and then delay the actual switch until after the next release of FFmpeg).

[LigH]

This is this now the Avisynth+, and not pinterf's?

It is our AviSynth+ now :cool:

[pinterf]

qyot27 never gives up :), thank you for pushing this through and answering my very basic questions. Supporting multiple platforms is a bit more difficult though. At least for someone (me) who is using linux in every five years for only a day or two. All I can say that Midnight Commander rulez :)

And a missing thing from the change log (I'll put it on Wiki)

Since on Linux we do not have Windows font rendering engine, as a quick solution a filter named "Text" was created with the same parameters as SubTitle.
"Text" is available on Windows as well.
It is using a simple 10x20 matrix fixed font (planned to have some more), similar to what debug text in some Avisynth external filters are using, but with color and halocolor for outline.
Size and orientations related parameters are simply ignored. SubTitle on linux is simply redirected to this new filter.

[real.finder]

AviSynth+ 3.5.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.5.0)


:thanks: but why there are no "filesonly" aka portable? :)

[poisondeathray]

:thanks: but why there are no "filesonly" aka portable? :)

You can extract them from Groucho2004's installer using 7zip
https://forum.doom9.org/showthread.php?t=172124

[StainlessS]

filter named "SimpleText"
Nearly, close but no cigar :)


Blankclip(width=120,height=120,Color=$808080)
/*
Text "cs[x]f[y]f[first_frame]i[last_frame]i[font]s[size]f[text_color]i[halo_color]i[align]i[spc]i[lsp]i[font_width]f[font_angle]f[interlaced]b[font_filename]s[utf8]b"
*/

Text("Hello\nWorld",lsp=0,align=5)


https://i.postimg.cc/6pVvr9Hh/Text.jpg (https://postimages.org/)

[poisondeathray]

pinterf's test version had fixed the errors in this post with the internal avs conversion
https://forum.doom9.org/showthread.php?p=1897686

pinterf test version
https://forum.doom9.org/showthread.php?p=1898860

But using the recent 3.5, r3043 , some differences are back. 12bits again "fixes" it

avsresize/zimg/zlib works using 10bits with either version

[Reel.Deel]

Thank you pinterf and qyot27. Awesome job! :thanks:

[pinterf]

Nearly :)


Blankclip(width=120,height=120,Color=$808080)
/*
Text "cs[x]f[y]f[first_frame]i[last_frame]i[font]s[size]f[text_color]i[halo_color]i[align]i[spc]i[lsp]i[font_width]f[font_angle]f[interlaced]b[font_filename]s[utf8]b"
*/

Text("Hello\nWorld",lsp=0,align=5)


https://i.postimg.cc/6pVvr9Hh/Text.jpg (https://postimages.org/)
You are so right. I'm getting old. Seems that I have really done it :)

[pinterf]

pinterf's test version had fixed the errors in this post with the internal avs conversion
https://forum.doom9.org/showthread.php?p=1897686

pinterf test version
https://forum.doom9.org/showthread.php?p=1898860

But using the recent 3.5, r3043 , some differences are back. 12bits again "fixes" it

avsresize/zimg/zlib works using 10bits with either version
I can see the same small differences which are normal I think. The big differences are over.

[poisondeathray]

I can see the same small differences which are normal I think. The big differences are over.

It's an improvement, but it should be lossless

PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609

infinity with vapoursynth / avsresize / zlib/zimg
PSNR r:inf g:inf b:inf average:inf min:inf max:inf

[StainlessS]

You are so right. I'm getting old. Seems that I have really done it :)

Good memory :) you did really do it.


class SimpleText : public GenericVideoFilter
/**
* SimpleText creation class
**/
{
public:
SimpleText(PClip _child, const char _text[], int _x, int _y, int _firstframe, int _lastframe,
const char _fontname[], int _size, int _textcolor, int _halocolor, int _align,
int _spc, bool _multiline, int _lsp, int _font_width, int _font_angle, bool _interlaced, const char _font_filename[], const bool _utf8, IScriptEnvironment* env);
virtual ~SimpleText(void);
PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env);

static AVSValue __cdecl Create(AVSValue args, void*, IScriptEnvironment* env);

int __stdcall SetCacheHints(int cachehints, int frame_range) override {
AVS_UNUSED(frame_range);
return cachehints == CACHE_GET_MTMODE ? MT_NICE_FILTER : 0;
}

private:
const int x, y, firstframe, lastframe;
const int size; // n/a
const int lsp;
const int font_width, font_angle; // n/a
const bool multiline;
const bool interlaced; // n/a
const int textcolor, halocolor, align;
const int spc; // n/a
const int halocolor_orig;
const char* const fontname; // n/a
const char* const text;
const char* const font_filename; // n/a
const bool utf8;
};


Only the names were changed to protect the innocent :)

[pinterf]

It's an improvement, but it should be lossless

PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609

infinity with vapoursynth / avsresize / zlib/zimg
PSNR r:inf g:inf b:inf average:inf min:inf max:inf

The algorithm has no more flaws I think. I have to check the coefficient accuracy.

[poisondeathray]

The algorithm has no more flaws I think. I have to check the coefficient accuracy.

PSNR (according to ffmpeg psnr) it's actually the same value with r2944 test version or r3043 (neither were lossless) ; so I was wrong , it wasn't "fixed" with that test version

pre r2944
[Parsed_psnr_4 @ 000000f905391940] PSNR r:59.321403 g:87.953516 b:73.777761 average:63.933949 min:63.933949 max:63.933949

r2944, r3043 - improved
[Parsed_psnr_4 @ 00000049feda2dc0] PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609

It's "inf" with vapoursynth or avsresize in all cases
[Parsed_psnr_4 @ 00000014ab642a00] PSNR r:inf g:inf b:inf average:inf min:inf max:inf

Results do not change if I test a written out bmp, or pipe into ffmpeg




Historically, ffmpeg swscale had many issues in the past with YUV/RGB conversions; but even it gets this 8bit RGB => 10bit YUV444 => 8bit RGB conversion correct now (at least with this test image)


ffmpeg -i yuv_exprm_02_bird.png -vf scale=out_color_matrix=bt709,format=yuv444p10le,scale=in_color_matrix=bt709,format=gbrp ffmpeg_swscale.bmp



ffmpeg -r 24 -i ffmpeg_swscale.bmp -r 24 -i yuv_exprm_02_bird.png -lavfi "[0:v]settb=1/AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=1/AVTB,setpts=PTS-STARTPTS[ref];[main][ref]psnr="stats_file=ff_psnr_ffmpeg_swscale.log"" -f null -


[Parsed_psnr_4 @ 00000098089e2140] PSNR r:inf g:inf b:inf average:inf min:inf max:inf



Thanks for your work pinterf and qyot27

[frencher]

Hi all,

I search for works my two plugins x86 HDR_AGC and svpflow :o

With only HDR it's works :)
With only svpflow works :)
With both HDR_AGC and svpflow WMP crash :(

How fix it :(

Thank's for all :thanks:

Plugins is
HDR > https://github.com/Anime4000/IFME/wiki/AviSynth--HDR-Video
SVP > https://www.svp-team.com/forum/viewtopic.php?pid=57410#p57410

https://www.zupimages.net/up/20/10/di6j.jpg

[LigH]

All I can say that Midnight Commander rulez :)

For Windows, the Far manager (https://farmanager.com) is my choice.

[pinterf]

PSNR (according to ffmpeg psnr) it's actually the same value with r2944 test version or r3043 (neither were lossless) ; so I was wrong , it wasn't "fixed" with that test version

pre r2944
[Parsed_psnr_4 @ 000000f905391940] PSNR r:59.321403 g:87.953516 b:73.777761 average:63.933949 min:63.933949 max:63.933949

r2944, r3043 - improved
[Parsed_psnr_4 @ 00000049feda2dc0] PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609


VapourSynth and avsresize is using the same library, they have to have the same results.

Avsresize has the advantage that it can convert _directly_ from 8 bit rgb to 10 bit YUV. I suppose that there is no 10 bit intermediate rgb result.

Test 1: I have tried ConvertBits(10) right before avsresize
Result: mixed ConvertBits - Avsresize chain stopped being lossless

a
ConvertToPlanarRGB()
ConvertBits(10) # Z advantage: single step 8 bit rgb 10 bit yuv
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP10")
ConvertToRGB24()
z1=last #RGBP10 step before RGB24 works


And finally: avsresize is possibly using float arithmetic internally.

There are several types of converters, their usage depends on bit depth and processor capability.

One method (SSE2) is using the usual 15 bit integer arithmetic. I'm using it for 10-14 bit targets.

The other is converting the pixels to float, do the matrix multiplication and then converts the result back to the integer domain. Now I'm using it only for 16 bit case because the first method's SIMD intrinsics support only signed data without any tricks (16 bit is unsigned).

Test2:
So I built a test version, where I was using the 32 bit float way for 10 bit data instead of the above mentioned integer arithmetics. Result: I only looked at the difference clips and visually (looking at rare dot distribution showing the non-losslessness) it had the same output as z_ConvertXXX (latter with the 10 bit input in order to compare apples to apples)

If I enable the internally float version for 10-14 bits, it can be a little bit slower* but of greater precision.
*no AVX implementation yet only SSE2/SSE4.1 so there is room for improvement to compensate the slowdown (which I think is not that much considering a whole big script)

But Avisynth resizer is not capable to chain bit depth conversion with rgb->yuv conversion so I'd say it'll never give such losslessness.

[pinterf]

With only HDR it's works :)
With only svpflow works :)
With both HDR_AGC and svpflow WMP crash :(

How fix it :(

Possibly HDRAGC source code is needed which is unfortunately not available (never published)

[TheFluff]

Avsresize has the advantage that it can convert _directly_ from 8 bit rgb to 10 bit YUV. I suppose that there is no 10 bit intermediate rgb result.

I don't think that's true, but this is:

And finally: avsresize is possibly using float arithmetic internally.

As far as I know zimg (avsresize) has no special direct conversions between any formats at all. Bitdepth changes, colorspace changes and resolution changes are separate filters internally and it builds a filter graph automatically to do the conversion you want. Depending on what you're doing, the graph builder may decide to start the processing by increasing the bitdepth, to reduce intermediate losses. Converting colorspace is one such case - if you do that, the first thing it'll do is convert the pixel type to float, then upscale the chroma if necessary, and only then proceed to convert to whatever target format and resolution you want.

See https://github.com/sekrit-twc/zimg/blob/master/src/zimg/graph/graphbuilder.cpp#L669 for details, it has comments describing the process of building a filter chain for doing arbitrary conversions.

[poisondeathray]

VapourSynth and avsresize is using the same library, they have to have the same results.



I have seen implementation differences between vapoursynth's resize, ffmpeg -vf zscale, and avsresize. Despite being based the same library. It might be that the "snapshot" was based on different build or commits, I didn't look too closely. But this occurs for certain.



Test 1: I have tried ConvertBits(10) right before avsresize
Result: mixed ConvertBits - Avsresize chain stopped being lossless



And ConvertBits(12) was NOT enough to "fix" it, yet 12bits is "enough" for internal resizer (for amplified visual differences, I didn't check PSNR). It doesn't entirely make sense, could something else be going on there?



Test2:
So I built a test version, where I was using the 32 bit float way for 10 bit data instead of the above mentioned integer arithmetics. Result: I only looked at the difference clips and visually (looking at rare dot distribution showing the non-losslessness) it had the same output as z_ConvertXXX (latter with the 10 bit input in order to compare apples to apples)

If I enable the internally float version for 10-14 bits, it can be a little bit slower* but of greater precision.
*no AVX implementation yet only SSE2/SSE4.1 so there is room for improvement to compensate the slowdown (which I think is not that much considering a whole big script)

But Avisynth resizer is not capable to chain bit depth conversion with rgb->yuv conversion so I'd say it'll never give such losslessness.


Thanks for taking the time to investigate this

Does that imply ffmpeg swscale is using float internally too? I'd imagine that it didn't for speed purposes

My memory is a bit rusty, but once upon a time, I recall someone did some matlab calculations and +2 bits was supposedly enough to cover this conversion (just like 12bit YUV444 was sufficient to cover 10bit RGB), but I should have looked into the details more thoroughly

[poisondeathray]

Test 1: I have tried ConvertBits(10) right before avsresize
Result: mixed ConvertBits - Avsresize chain stopped being lossless


Actually, double checking this with PSNR, Z1 was not lossless to begin with .

[Parsed_psnr_4 @ 00000062fb042cc0] PSNR r:inf g:inf b:92.591089 average:97.362301 min:97.362301 max:97.362301


a
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP10")
ConvertToRGB24()
z1=last





Z2 was lossless
[Parsed_psnr_4 @ 0000005dfa5d2cc0] PSNR r:inf g:inf b:inf average:inf min:inf max:inf


a
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP")
ConvertToRGB24()
z2=last


If you add ConvertBits(10) after ConvertToPlanarRGB(), it's no longer lossless either

[zeropc]

AviSynth+ 3.5.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.5.0)

The big, shiny new feature this time around: native support for Linux, macOS, and BSD. Full list of changes:

New: Native macOS support.


Nice ... Where can I get the macOS version? :)

[Richard1485]

There are build instructions here (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/docs/english/source/avisynthdoc/contributing/posix.rst) and a separate thread in this subforum for cross-platform support.

[pinterf]

As far as I know zimg (avsresize) has no special direct conversions between any formats at all. Bitdepth changes, colorspace changes and resolution changes are separate filters internally and it builds a filter graph automatically to do the conversion you want.
Thanks, I see. So the advantage there is simply not having an integer (e.g. 10 bit) intermediate result but rather a 32 bit float one?

[pinterf]

If I enable the internally float version for 10-14 bits, it can be a little bit slower* but of greater precision.
*no AVX implementation yet only SSE2/SSE4.1 so there is room for improvement to compensate the slowdown (which I think is not that much considering a whole big script)

Anyway, there are some RGBP->YUV444 enhancements in my development branch:
- Internal calculation method is changed to use floats for 10-14 bits as well (16 bit was already working like this) for greater precision
- much quicker AVX2 implementation for 10-16 bits (was: SSE2/SSE4)

[StainlessS]

BugRep:

From here[EDIT: LINK FIXED]:- https://forum.doom9.org/showthread.php?p=1728455#post1728455
@Martin53,

For your version StrReplace,

s=StrReplace("abc","","1")

ie replace "" with "1",
Causes silent crash due to stack exhaustion.
(Problem due to FindStr("abc","") returning result 1 [bit of a daft result, 0 not found would perhaps be more sensible]).
Should return source string s where StrLen(find)==0

Same here for Avs+ ReplaceStr().

Colorbars
S=ReplaceStr("hello","","1")
Subtitle(s)


EDIT: Script fix for StrReplace()


Function StrReplace(string base, string sought, string rep) { # http://avisynth.nl/index.php/HDColorBars
pos = FindStr(base, sought)
return (sought=="")||(pos==0)?base:StrReplace(LeftStr(base,pos-1)+rep+MidStr(base,pos+StrLen(sought)),sought,rep)
}


EDIT: Maybe this line on Wiki could stand some attention [meaning is inverted]:- http://avisynth.nl/index.php/Internal_functions#ReplaceStr
sig if false (the default), search is case-sensitive; if true, search is not case-sensitive.
EDIT: By the way, RT_Stats RT_StrReplace has default Sig=True, but of course choice is yours.

[StainlessS]

New types.h prevents plugin compile on older versions of visual studio [missing header files].
Mine is VS 2008 Express with Windows SDK 7.0.

Previous Types.h

#ifndef AVS_TYPES_H
#define AVS_TYPES_H

// Define all types necessary for interfacing with avisynth.dll

#ifdef __cplusplus
#include <cstddef>
#else
#include <stddef.h>
#endif

// Raster types used by VirtualDub & Avisynth
typedef unsigned int Pixel32;
typedef unsigned char BYTE;

// Audio Sample information
typedef float SFLOAT;

#ifdef __GNUC__
typedef long long int INT64;
#else
typedef __int64 INT64;
#endif

#endif //AVS_TYPES_H


New one

#ifndef AVS_TYPES_H
#define AVS_TYPES_H

// Define all types necessary for interfacing with avisynth.dll
#include <stdint.h>
#include <stdbool.h>
#ifdef __cplusplus
#include <cstddef>
#else
#include <stddef.h>
#endif

// Raster types used by VirtualDub & Avisynth
typedef uint32_t Pixel32;
typedef uint8_t BYTE;

// Audio Sample information
typedef float SFLOAT;

#endif //AVS_TYPES_H

What is minimum compiler/SDK required for plugin builds for Avs+ and avs Std v2.60 using avs+ headers.

(You can probably get headers from eg VS 2017 community)

EDIT: stdint.h on github:- https://github.com/glfw/glfw/blob/master/deps/vs2008/stdint.h