aWarpSharp2 – rewrite of aWarpSharp

[pinterf]

When I'm touching it because of 16 bit port, you'll have to warn me again.

[real.finder]

When I'm touching it because of 16 bit port, you'll have to warn me again.

:goodpost:

AWarpSharp2 for VapourSynth already has 16 bit and c code, this maybe can make things less hard for port

[pinterf]

:goodpost:

AWarpSharp2 for VapourSynth already has 16 bit and c code, this maybe can make things less hard for port
I've seen that already, and yes, the hardest thing is to reverse-engineer a C-less non-intrinsic hand-optimized assembly. If source is nice, high bit depth port can be is done in hours even with simd.

[real.finder]

When I'm touching it because of 16 bit port, you'll have to warn me again.

isn't the aWarpSharp2 turn come yet? :rolleyes:

[pinterf]

Not priority. After tivtc x64 and avs+ conditional filters in mt

[hello_hello]

pinterf,

When I use the following in a script (NTSC DVD source) I get an error message "both sources must have the colorspace". It's copy and pasted from the readme.

aWarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2), aSobel().aBlur(), depth=2)

This works fine though.

ConvertToYV16()
aWarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2), aSobel().aBlur(), depth=2)

The same thing happens with version 2015.12.30.
Am I missing something? Cheers.

[pwnsweet]

I think it will be nice if there are depthV like internal avs Sharpen() amountV (http://avisynth.nl/index.php/Blur) so that we can work with only horizontal halos or colour bled safely without hurt the vertical details by set depthV=0 or depthCV=0

edit: blurV also

I second this, and would also like to see this implemented. Any updates pinterf?

[pinterf]

No updates yet.

[pwnsweet]

Thanks for the response. I'll continue to wait patiently

[jpsdr]

@pinterf
I think there is a bug in the aWarp.h file, if you check lines 193/194 vs 196/197.

[pinterf]

@pinterf
I think there is a bug in the aWarp.h file, if you check lines 193/194 vs 196/197.
You are right. x64 path is wrong.

[pinterf]

I see that you started investigating this plugin.

Back in May I made some additions, not sync'd up to github yet (avisynth+ headers, high bit depth constants, some helper function) but these are not really used, just prepared them as the first step of the transition.

Another modification is that I have moved aSobel to intrinsics (I don't like inline asm, mainly for maintenance reasons, it's more difficult to understand/modify for high bit depth and the possible speed gain (if any) is neglible (at least for aSobel which I have ported already)

This was my todo list:
- have C versions (either from jackoneill's Vapoursynth port/rewrite or from an earlier version of aWarpSharp, or reverse engineering asm)
- move inline asm to intrinsics
- Drop tricky asm path such as SSSE3, keep SSE2 only. It's too much work to keep SSSE3, too tricky to understand those shuffles. We are over SSSE3 era, I prefer adding avx2 code instead.
- get it work for high bit depth
- add new user requests to the plugin

[Myrsloik]

I see that you started investigating this plugin.

Back in May I made some additions, not sync'd up to github yet (avisynth+ headers, high bit depth constants, some helper function) but these are not really used, just prepared them as the first step of the transition.

Another modification is that I have moved aSobel to intrinsics (I don't like inline asm, mainly for maintenance reasons, it's more difficult to understand/modify for high bit depth and the possible speed gain (if any) is neglible (at least for aSobel which I have ported already)

This was my todo list:
- have C versions (either from jackoneill's Vapoursynth port/rewrite or from an earlier version of aWarpSharp, or reverse engineering asm)
- move inline asm to intrinsics
- Drop tricky asm path such as SSSE3, keep SSE2 only. It's too much work to keep SSSE3, too tricky to understand those shuffles. We are over SSSE3 era, I prefer adding avx2 code instead.
- get it work for high bit depth
- add new user requests to the plugin

A few observations here:
1. The VapourSynth port has effectively done all the work but oh noooo, open source acting like open source and APPROPRIATING ALL THE USEFUL WORK RIGHT NOW! is far too much to expect apparently...

2. The idea of a unified codebase never seems to have crossed your mind. It would be fairly simple to add in avs+ support to many existing VapourSynth plugins with a small and menial patch. Even other lesser coders could possibly be convinced to help. But nope. Not gonna do that either.

3. The insane idea to base the new C code off the asm. Most original C to asm conversions weren't tested for being identical with the C version because asm is typo prone and testing isn't for Avisynth developers. Therefore starting from the most likely to be wrong code is hilarious to me:D:D:D:D:D

4. ZOMG OPTIMIZE is a horrible strategy in general. I bet your avx2 version at most will be 3% faster than the same sse2 code for warpsharp.

5. If you can't grasp ssse3, then how do you expect to effectively use a superset of it with split lanes in avx2? :rolleyes:

6. Seriously dude, what desired feature apart from avs+ compatibility didn't jackoneill implement already?

[pinterf]

A few observations here:
1. The VapourSynth port has effectively done all the work but oh noooo, open source acting like open source and APPROPRIATING ALL THE USEFUL WORK RIGHT NOW! is far too much to expect apparently...

2. The idea of a unified codebase never seems to have crossed your mind. It would be fairly simple to add in avs+ support to many existing VapourSynth plugins with a small and menial patch. Even other lesser coders could possibly be convinced to help. But nope. Not gonna do that either.


Since then (after your kind reactions a few weeks ago) I have revised my opinion about borrowing code from Vapoursynth.
Personally, I never had to deal with open source things previously, perhaps I'm too old to accept immediately the obvious rules of (not so) current trends, but I'll try to, I promise :)
In the past I tried to avoid the situation when someone - whose work and time I really appreciate - is spending weeks or months on brand new things and the product then appears elsewhere only with the effort of porting.


6. Seriously dude, what desired feature apart from avs+ compatibility didn't jackoneill implement already?

I realized that modernizing this plugin based on this source is not the few-days-work category and mostly this is why I stopped working on it seriously.
Nor did I analyze the code yet, whether avx2 is feasible or not for warpsharp or for any components. When someone who wins this project will plunge into the details, will see whether avx2 is usable or not and in which parts.

[jpsdr]

I see that you started investigating this plugin.

Yes, for now, i'm just moving inline asm in external asm files, and the purpose is to break nothing doing this.
Others things will come later.
I didn't thought of searching previous versions for C code, but i will search if such a thing exist. It could be eventualy a good complement to the C vapoursynth version.

[real.finder]

I didn't thought of searching previous versions for C code, but i will search if such a thing exist.

the original awarpsharp by Marc FD was closed source, SEt did reverse engineered it in this Thread and made the awarpsharp2 as new and open source fixed version

but tp7 said that prunedtree can give the source for deen (also made by Marc FD maybe he is the same person) if you talk to him in rizon IRC

even though awarpsharp2 is less bugs than original awarpsharp, I note that original awarpsharp give better warp for chroma with same settings

[Myrsloik]

MarcFD and prunedtree is the same person

[jpsdr]

I took a closer look at the vapoursynth C code. Finaly it seems proper and well made, trying to keep the names of the variables and the structure as close as possible from the original code. It a very good job well made by jackoneill.

[jpsdr]

@pinterf
I think i've found another bug, in aWarpSharp.cpp line 503 it's more likely QBX (as 586 may confirm) and not QAX.

[pinterf]

Indeed, good catch. Optimization magic typo, I guess.

[real.finder]

I think I get why awarpsharp2 give different result

in original awarpsharp
int bm

Blur modes:

0 : hq 3-pass
1 : fast 3-pass
2 : fast 1-pass (Default)
3 : light blur

in awarpsharp2

int type

Type of blur:

0 : radius 6 blur (some kind of 13x13 average).
1 : radius 2 blur (some kind of 5x5 average), requires around 8x more passes than type=0 for the same effect (will be 2.5x slower), but will produce better quality.

for awarpsharp in awarpsharp2

Original aWarpSharp compatibility:

Mapping from original aWarpSharp parameters:

thresh = thresh*256
blur = blurlevel
type = (bm=0)->1, (bm=2)->0
depth = depth*blurlevel/2
chroma = 0->2, 1->4, 2->3

so the difference is the blur type, since there only 2 type in awarpsharp2

[Ben_Nicholls]

Any idea where "aWarpSharpMT_v1_0_0.7z" comes from? Googled away and can't find if it it is never than the 2016 versions...

[real.finder]

Any idea where "aWarpSharpMT_v1_0_0.7z" comes from? Googled away and can't find if it it is never than the 2016 versions...

https://forum.doom9.org/showthread.php?t=175064