Log in

View Full Version : Updated aWarpSharp version, with some new features


Pages : 1 [2] 3 4

real.finder
30th November 2017, 21:39
Haven't tried x86 version, if you really want me to test it I guess I could, I suspect it'll still not work. I think your internal multi-threading isn't entirely stable ^.^

try this http://rgho.st/6FZwRLKPv

this is test build that jpsdr give me before, it was not really mt yet

try both x86 and x64, cuz maybe there are some bug in 64 asm, that why jpsdr ask you to test the x86 one

real.finder
30th November 2017, 21:42
Maybe you can try warpsharp is very good for animation.

maybe, but I use warp sharp things for halos and others (like fix the chroma bleed) away from did sharp or make lines thin

Motenai Yoda
1st December 2017, 01:48
Maybe you can try warpsharp is very good for animation.

It sounds so 2006

btw awarpsharp/awarpsharp2 thresh=1/255 ≈ warpsharp

ryrynz
1st December 2017, 08:03
try this http://rgho.st/6FZwRLKPv


Tried it, crashes even without setMTmode and prefetch.
I tried installing x86 avisynth etc but I just get crashes trying to load it, dunno why and don't want to spend my night trying to figure it out, so I can't answer is x86 works or not.
I don't use it and I've put enough time into this as it is, Pinterf's version works. I'll come back to this later next year and see if it works any better then.

jpsdr
1st December 2017, 10:17
I tried installing x86 avisynth.
... I don't understand, if you have avs+ installed, you have both x86 and x64 avisynth, so you can test the x86 or x64 dll without the need of installing anything. Even more, you put the x64 dll in "plugin64" and the x86 dll in "plugin". There is some misunderstanding here, i never asked you to use/install 2.6 avisynth, just test the x86 dll.

Or have i a missconception of the system you are using or how is configured your system ?

edcrfv94
1st December 2017, 10:47
aWarpSharp(depth=32.0, blurlevel=2, thresh=0.5, cm=0, bm=2)
aWarpSharp2(depth=32, thresh=128, blur=2, type=0, chroma=2)

The result are 100% same aWarpSharp2-20160624 64bit.

jpsdr
1st December 2017, 11:18
here we are
...

Can you provide the exact parameter you've used in both cases of post #22 ?
Because unfortunately, for now i don't see any "differences" in the aWarpSharp_20120328 and my version.

real.finder
1st December 2017, 12:38
Can you provide the exact parameter you've used in both cases of post #22 ?
Because unfortunately, for now i don't see any "differences" in the aWarpSharp_20120328 and my version.

just


awarpsharp()

real.finder
1st December 2017, 12:40
aWarpSharp(depth=32.0, blurlevel=2, thresh=0.5, cm=0, bm=2)
aWarpSharp2(depth=32, thresh=128, blur=2, type=0, chroma=2)

The result are 100% same aWarpSharp2-20160624 64bit.

yes cuz you use the aWarpSharp from aWarpSharp2 not the old aWarpSharp

jpsdr
2nd December 2017, 11:15
I think the issue may come from the chroma mode.
According here (http://avisynth.nl/index.php/AWarpSharp), it seems there is some error in the documentation about the default chroma mode, so if the filters afterward where made using a wrong default chroma mode, it will not be surprising that there is differences in chroma. More troublesome, mapping for chroma original mode 3 doesn't exist in the new aWarpSharp function, and a call with the remaped actual aWarpSharp with a chroma mode of 3 will result in an error.
Otherwise, only in new chroma mode 3 and 5 the blur level chroma specific has an effect on the chroma, not on the default mode (4).
So, for now, try playing with cm parameter on the new aWarpSharp version, to see if you can get back the original result.

real.finder
2nd December 2017, 12:07
I think the issue may come from the chroma mode.
According here (http://avisynth.nl/index.php/AWarpSharp), it seems there is some error in the documentation about the default chroma mode, so if the filters afterward where made using a wrong default chroma mode, it will not be surprising that there is differences in chroma. More troublesome, mapping for chroma original mode 3 doesn't exist in the new aWarpSharp function, and a call with the remaped actual aWarpSharp with a chroma mode of 3 will result in an error.
Otherwise, only in new chroma mode 3 and 5 the blur level chroma specific has an effect on the chroma, not on the default mode (4).
So, for now, try playing with cm parameter on the new aWarpSharp version, to see if you can get back the original result.

I tried but without any luck, only case that will be right is cm=0, the problem as I said in 2015 and up after added depthC, in awarpsharp() in awarpsharp2 dll it's always set to 0, just remove the depthC usage from awarpsharp() and it will be ok

edit: 3 should mean copy chroma, 0 like ignore chroma (fast and garbage like 1 in u or v in masktools)

so cm in awarpsharp should be:-
cm=0 -> chroma=1
cm=1 -> chroma=4
cm=2 -> chroma=3
cm=3 -> chroma=2

jpsdr
2nd December 2017, 12:31
Ok, i'll continue to investigate, and cheking the aWarpSharp2 from aWarpSharp_20120328 and my actual aWarpSharp. I didn't see any difference in the C part code, meaning i'll have to compare/check the asm code... Will be more troublesome, but if you said that the aWarpSharp2 from aWarpSharp_20120328 doesn't have the chroma issue, but the aWarpSharp2 from awarpsharp2-2015.12.30 have it, there must be a difference somewhere...

jpsdr
2nd December 2017, 14:35
Thanks for your pm, i was looking in the wrong way.
According the wiki page, the default is cm=3, should i also change that, or left at 1 ?

real.finder
2nd December 2017, 14:46
Thanks for your pm, i was looking in the wrong way.
According the wiki page, the default is cm=3, should i also change that, or left at 1 ?

left it at 1 cuz in old awarpsharp cm=1 is same as cm=3, there are some bugs in old awarpsharp and this one of them

jpsdr
2nd December 2017, 18:27
New version, see first post.

jpsdr
4th December 2017, 10:07
Is the chroma issue of post #22 fixed with this new version ?

real.finder
4th December 2017, 14:14
Is the chroma issue of post #22 fixed with this new version ?

yes, thank you

jpsdr
4th December 2017, 15:48
chroma values 2 5 6 are bugged as it doesn't scale back chroma/luma channels
maybe it can take them from last
At first glance, it seems that the code use the same "CopyPlane" function also in Warp4.
The issue i probably see it's that it seems to have been forgoten that this function copy plane of same size, when in aWarp4 the input is 4 times the output, resulting in copy being just a quarter of the source.
When source size is different from destination, from my point of view, the idea of "copying" make no sense. For me, there is nothing to fix, as these options should just not be avaible in aWarp4.
If i had to do something, i would just throw an "not avaible" or "incompatible" error .

GMJCZP
4th December 2017, 18:37
I have not tried it but also thank you very much!

real.finder
4th December 2017, 21:40
as these options should just not be avaible in aWarp4.
If i had to do something, i would just throw an "not avaible" or "incompatible" error .

that will make it worst I think

what about adding PointResize(input.Width()/4,input.Height()/4) before use the CopyPlane in awarp4? it will do the job

edit1: or PointResize(mask.Width(),mask.Height())

edit2: well, its not like the rpower=2, it not work as it should in rpower=4, it must use PointResize(input.Width()/2,input.Height()/2).PointResize(input.Width()/4,input.Height()/4)

or PointResize(input.Width()/2,input.Height()/2).PointResize(mask.Width(),mask.Height())

and it will not work well for chroma if the chroma and luma in same clip (YUV), it should be used with Y/Y8 Grayscale separated chroma

jpsdr
5th December 2017, 10:18
Yes for the "make it worst".
I'm not interested in wasting time adding a resampler, i just consider "copy" make no sense for aWarp4, so there will be no "copy" cases. When i do an update (not planed for now unless a bug is to be fixed), i'll update the readme and just "do nothing" in these cases (avoiding wasting time doing useless copy). It's at the user to do the proper things, and use whatever resampler he wants to make/create the missing planes.

ryrynz
5th December 2017, 11:48
I've spent some more time on this.. the x86 version is okay it's just the x64 that crashes.

jpsdr
5th December 2017, 14:29
Only with aWarp4, that's it ? aWarp works fine ?

Can you test all the chroma mode (0 to 6), and tell me is all are crashing, or if some are crashing and some not ?
x64 crashing and not x86 is typical of an issue in the asm code, but unfortunately, for now i've not been able to find the issue... :(

ryrynz
5th December 2017, 21:02
The problem is type=1 in ablur, setting to 0 fixes it.
I did try chroma 0-6, threads=1 as well on ablur but no change.

jpsdr
6th December 2017, 10:06
What..??? You told me in post #32 it was aWarp4... :confused:

Edit :
Now that you told me it's aBlur, it took me only a few seconds to find the potential issue.

ryrynz
6th December 2017, 10:20
What..??? You told me in post #32 it was aWarp4


You wouldn't use it without awarp4 most times :P I didn't think to narrow down and test the individual components but whatever I got there in the end. Bring forth the fix.

jpsdr
6th December 2017, 10:39
We have to wait that i have time to build and make a release to see if what i've found fix your issue.

jpsdr
6th December 2017, 21:47
New version, see first post.

ryrynz
6th December 2017, 22:28
Still crashing when I use type=1 on 1.0.2, tested with W7 build.

jpsdr
7th December 2017, 09:39
Ah... I think i've found out what i've missed grrr...:sly:

jpsdr
7th December 2017, 21:08
New version, see first post.

ryrynz
8th December 2017, 11:01
It's working now thanks. I see visual differences (shadowing around some lines) that aren't there in pinterf's version and his version more closely matches the original source.
I checked it vs version 1.0 to see if they were related to the changes in 1.0.1 but they're not. Can you provide the settings to achieve similar results to pinterf's version?

jpsdr
8th December 2017, 12:05
Good, but... Differences were not realy expected....

real.finder
8th December 2017, 14:08
It's working now thanks. I see visual differences (shadowing around some lines) that aren't there in pinterf's version and his version more closely matches the original source.
I checked it vs version 1.0 to see if they were related to the changes in 1.0.1 but they're not. Can you provide the settings to achieve similar results to pinterf's version?

I did some tests with ablur and awarp4 with 2015 and pinterf one all x86 vs this new mt one in x64 and they are 100% same

real.finder
8th December 2017, 14:22
seems not, the chroma is not work as it should

depthc=2 will make it similar to awarp4 default settings in older versions (pinterf one), so there are some bug in the default value of depthc in awarp4

jpsdr
8th December 2017, 14:58
Ah... Yes, i see... I've forgotten to adapt the default setting value.

real.finder
8th December 2017, 15:05
Ah... Yes, i see... I've forgotten to adapt the default setting value.

why you use 128 hack as (not set)?

why not use NULL as https://github.com/pinterf/aWarpSharp/blob/master/src/aWarpSharp.cpp#L1346 ?

and seems that pinterf did some edits to get ready to HBD too, like he use is444 instead of isyv24

pinterf
8th December 2017, 15:19
and seems that pinterf did some edits to get ready to HBD too, like he use is444 instead of isyv24
I did nothing in the core algorithms for hbd support, just changed some checking to a not-8-bit specific one.

jpsdr
8th December 2017, 15:21
NULL is 0... Meaning you can't set 0. I'm not Ok with it.
HBD... Another time.

real.finder
8th December 2017, 15:40
NULL is 0... Meaning you can't set 0. I'm not Ok with it.
HBD... Another time.

I know nothing in c++, avs default(something,value) or defined() and undefined() are nice, but seems they not have something similar in c++

StainlessS
8th December 2017, 18:30
I know nothing in c++, avs default(something,value) or defined() and undefined() are nice, but seems they not have something similar in c++

Below should be OK, (untested)

//PClip child = args[0].AsClip(); // Source clip, (non-optional, enforced by avsynth) # Added line

// ...
// ...
// ... // Below either can be used, IsClip() OR Defined() [EDIT: assuming arg specified as type clip]

PClip dc = (args[12].IsClip()) ? args[12].AsClip() : child; // Not defined then same as source clip

PClip dc = (args[12].Defined()) ? args[12].AsClip() : NULL; // Not defined then NULL


EDIT: I'm not sure, but may produce an exception if not defined and you try to use NULL as default ie [EDIT: in avs standard, avs+, dont know]

PClip dc = args[12].AsClip(NULL); // Think may cause exception on NULL default.

EDIT: Above, Presumably clip properties accessed without check on whether it is a clip, and exception produced when defaulted to NULL.

EDIT: Args descriptor string [following function name, 'GamMac',] telling Avisynth what filter will accept.

env->AddFunction("GamMac" ,
"c[LockChan]i[Scale]i[RedMul]f[GrnMul]f[BluMul]f"
"[Th]f[loTh]f[hiTh]f[LockVal]f[RngLim]i[GamMax]f"
"[dc]c"
"[x]i[y]i[w]i[h]i[omin]i[omax]i"
"[Show]b[Verbosity]i[Coords]b[Dither]b"
,Create_GamMac , 0);

c Non-Optional, [dc]c Optional.

real.finder
9th December 2017, 05:39
yes StainlessS, there should some workaround, anyway I don't develop dll's (at least now even if I did some tiny edits here and there), some c++ things are similar to avs Syntax, so I asked jpsdr about why not use the NULL things, the only background I have in the programming languages I got it during my middle school education before 2003 (it was in BASIC and/then Pascal)

jpsdr
9th December 2017, 14:31
Didn't know there was a Defined member to args, but when you think about it, it's obviously logical to have the possibility to check in a langage script if a parameter has been set or not. This may be used to avoid the 128 workaround. I'll check this a little later (not right now).

StainlessS
9th December 2017, 15:57
Stuff in public: section of AVSValue (from VERSION 3 Header, ie valid in v2.58 onwards).

class AVSValue {
public:

AVSValue() { type = 'v'; }
AVSValue(IClip* c) { type = 'c'; clip = c; if (c) c->AddRef(); }
AVSValue(const PClip& c) { type = 'c'; clip = c.GetPointerWithAddRef(); }
AVSValue(bool b) { type = 'b'; boolean = b; }
AVSValue(int i) { type = 'i'; integer = i; }
// AVSValue(__int64 l) { type = 'l'; longlong = l; }
AVSValue(float f) { type = 'f'; floating_pt = f; }
AVSValue(double f) { type = 'f'; floating_pt = float(f); }
AVSValue(const char* s) { type = 's'; string = s; }
AVSValue(const AVSValue* a, int size) { type = 'a'; array = a; array_size = size; }
AVSValue(const AVSValue& v) { Assign(&v, true); }

~AVSValue() { if (IsClip() && clip) clip->Release(); }
AVSValue& operator=(const AVSValue& v) { Assign(&v, false); return *this; }

// Note that we transparently allow 'int' to be treated as 'float'.
// There are no int<->bool conversions, though.

bool Defined() const { return type != 'v'; }
bool IsClip() const { return type == 'c'; }
bool IsBool() const { return type == 'b'; }
bool IsInt() const { return type == 'i'; }
// bool IsLong() const { return (type == 'l'|| type == 'i'); }
bool IsFloat() const { return type == 'f' || type == 'i'; }
bool IsString() const { return type == 's'; }
bool IsArray() const { return type == 'a'; }

PClip AsClip() const { _ASSERTE(IsClip()); return IsClip()?clip:0; }
bool AsBool() const { _ASSERTE(IsBool()); return boolean; }
int AsInt() const { _ASSERTE(IsInt()); return integer; }
// int AsLong() const { _ASSERTE(IsLong()); return longlong; }
const char* AsString() const { _ASSERTE(IsString()); return IsString()?string:0; }
double AsFloat() const { _ASSERTE(IsFloat()); return IsInt()?integer:floating_pt; }

bool AsBool(bool def) const { _ASSERTE(IsBool()||!Defined()); return IsBool() ? boolean : def; }
int AsInt(int def) const { _ASSERTE(IsInt()||!Defined()); return IsInt() ? integer : def; }
double AsFloat(double def) const { _ASSERTE(IsFloat()||!Defined()); return IsInt() ? integer : type=='f' ? floating_pt : def; }
const char* AsString(const char* def) const { _ASSERTE(IsString()||!Defined()); return IsString() ? string : def; }

int ArraySize() const { _ASSERTE(IsArray()); return IsArray()?array_size:1; }

const AVSValue& operator[](int index) const {
_ASSERTE(IsArray() && index>=0 && index<array_size);
return (IsArray() && index>=0 && index<array_size) ? array[index] : *this;
}


For the IsArray() thing:
https://forum.doom9.org/showthread.php?p=1538558#post1538558

#ifdef AVISYNTH_PLUGIN_25
extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env){
OutputDebugString(AVISYNTHNAME ": AvisynthPluginInit2 Calling env->AddFunction\n");
#else
/* New 2.6 requirement!!! */
// Declare and initialise server pointers static storage.
const AVS_Linkage *AVS_linkage = 0;

/* New 2.6 requirement!!! */
// DLL entry point called from LoadPlugin() to setup a user plugin.
extern "C" __declspec(dllexport) const char* __stdcall
AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {

/* New 2.6 requirment!!! */
// Save the server pointers.
AVS_linkage = vectors;
OutputDebugString(AVISYNTHNAME ": AvisynthPluginInit3 Calling env->AddFunction\n");
#endif

// The code below, registers the plugin with avisynth and tells it how to construct/create
// the filter, the argument types it accepts and whether they are optional/named arguments.
// AddFunction has the following paramters:
// AddFunction(FilterName , Arguments, Function-to-call,0);


env->AddFunction(
AVISYNTHNAME, // The name of the filter in Avisynth (as a string).
"c[intarg]i[version]b[show]b[bounce]i", // Arguments, THIS MUST BE EDITED TO SUIT THE FILTER ARGUMENTS.
Create_INTERNALNAME, // The function Avisynth will call to create an instance of the filter.
0 // Zero. (possibly 'user_data' arg in Create_INTERNALNAME, never seen used).
);
// This particular registration, says:
// The name of the filter in Avisynth is AVISYNTHNAME().
// First filter arg 'c' is an un-named compulsory clip ('[name]' means 'name' is optional),
// Second filter arg '[intarg]i' is an optional arg of type int.
// Third filter arg '[version]b' is an optional arg of type bool.
// Forth filter arg '[show]b' is an optional arg of type bool.
// Fifth filter arg '[bounce]i' is an optional arg of type int.
// In this case the filter is similar to an Avisynth script definition of
// AVISYNTHNAME(clip,int "intarg",bool "version",bool "show", int "bounce").
// Of course, this must match what it uses in the above Avisynth Filter Creation function,
// and is almost always what the class constructor accepts.

// Arguments is a string that defines the types and optional names of the arguments for your filter.
// The names of optional arguments are enclosed in '[]' as in [name] and followed by the type string specifier.
// An argument list of eg "cc" would indicate a filter requiring two compulsory un-named clips.
// An arg list of eg "c[]c" would indicate a filter accepting a compulsory un-named clip and an
// optional un-named clip, without the '[]' in the arg list string, Avisynth would NOT allow you to call
// the filter without both clips even if you gave a default value in the 'Create_INTERNALNAME' filter creator
// (previous function above).

// Argument type specifier strings.
// c - Video Clip
// i - Integer number
// f - Float number
// s - String
// b - boolean
// . - Any type (dot)
// Array Specifiers
// i* - Integer Array, zero or more
// i+ - Integer Array, one or more
// .* - Any type Array, zero or more
// .+ - Any type Array, one or more
// Etc

#ifdef AVISYNTH_PLUGIN_25
OutputDebugString(AVISYNTHNAME ": AvisynthPluginInit2 returning to Avisynth\n");
#else
OutputDebugString(AVISYNTHNAME ": AvisynthPluginInit3 returning to Avisynth\n");
#endif

// return "'Example' Example plugin";
return ("'" AVISYNTHNAME "' " AVISYNTHNAME " plugin");
// A freeform name of the plugin. Dont think this returned string is actually used for anything in Avisynth.
}

jpsdr
12th December 2017, 12:09
New version, see first post.

ryrynz
13th December 2017, 01:37
Working as expected, I can now upgrade to this, thanks.

jpsdr
11th January 2018, 17:46
I'm working on the 16bits version using the vapoursynth code, but something bothering me.
When compiling, i have a warning (telling me that value is troncated) on this :

__m128i word_32768 = _mm_set1_epi16(32768);

The fact is that the parameter for _mm_set1_epi16 is defined as short, so 32768 is out of range, and i'm wondering if finaly the code is working...:confused:

static FORCE_INLINE __m128i mm_max_epu(const __m128i &a, const __m128i &b)
{
__m128i word_32768 = _mm_set1_epi16(32768);

__m128i a_minus = _mm_sub_epi16(a,word_32768);
__m128i b_minus = _mm_sub_epi16(b,word_32768);

return _mm_add_epi16(_mm_max_epi16(a_minus, b_minus),word_32768);
}

pinterf
11th January 2018, 18:09
I'm working on the 16bits version using the vapoursynth code, but something bothering me.
When compiling, i have a warning (telling me that value is troncated) on this :

__m128i word_32768 = _mm_set1_epi16(32768);

The fact is that the parameter for _mm_set1_epi16 is defined as short, so 32768 is out of range, and i'm wondering if finaly the code is working...:confused:

static FORCE_INLINE __m128i mm_max_epu(const __m128i &a, const __m128i &b)
{
__m128i word_32768 = _mm_set1_epi16(32768);

__m128i a_minus = _mm_sub_epi16(a,word_32768);
__m128i b_minus = _mm_sub_epi16(b,word_32768);

return _mm_add_epi16(_mm_max_epi16(a_minus, b_minus),word_32768);
}

Works, you can disable specific warnings by using #pragma or use -32768. (and -1 for 0xFFFF)
Edit: or you can make it work faster for SSE4.1 using directly _mm_max_epu16. I think there are very few non-SSE4.1 computers are out there, the rest deserves implementing the fast method.
(RgTools is full of such unsigned 16 bit instructions when using 10+ bit clips, and is falling back to C when no SSE4.1 is present.)

jpsdr
11th January 2018, 19:58
Ok, thanks.

jpsdr
16th January 2018, 15:03
Has anyone tested/compared the vapoursynth 16 bits aWarpSharp results plugin vesus the avisynth 8 bit ?
I've implemented the 16 bits using the vapoursynth code, but results are not realy the expected ones.
For testing, i've used the auto test video RGB color cube created by VirtualDub (in YV12 format).
aSobel 8 and 16 bits look similar.
aBlurl 8 and 16 bits look slighty different, but, why not.
Issue i have is that aWarp 8 and 16 bits look too much diffent, and aWarpSharp 8 and 16 bits look toooooo much different.