aWarpSharp2 – rewrite of aWarpSharp

[SEt]

Current version: 2012.03.28 (http://www.mediafire.com/?7bu46ab33dwex0o)

Previous versions:
2009.06.19 (http://pavelsx.googlepages.com/aWarpSharp_20090619.rar)
2009.05.24 (http://pavelsx.googlepages.com/aWarpSharp_20090524.rar)

aWarpSharp by MarcFD is nice plugin (especially for tasks like halo removing), but has some bugs and like to produce green artifacts on the image borders. Other WarpSharp plugins produced worse results for me, so i decided to rewrite aWarpSharp algorithm with better handling of borders and optimization for modern CPUs.

Besides complete algorithm aWarpSharp2, its parts are also available as aSobel, aBlur, aWarp and aWarp4. This way you can do advanced edge mask filtering (like MDegrain) before passing it to warp stage to get more stable result.

Good usage examples:

aWarp4(Spline36Resize(width*4, height*4, 0.375, 0.375), aSobel().aBlur(), depth=3)
aWarp4(nnedi3_rpow2(rfactor=2).Spline36Resize(width*4, height*4, 0.25, 0.25), aSobel().aBlur(), depth=3)
aWarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2), aSobel().aBlur(), depth=2)

Note that upsampling for aWarp4 should be left-top aligned, so Spline36Resize(width*4, height*4) or nnedi3_rpow2(rfactor=4) won't produce correct results.

For options explanation and values mapping from used in aWarpSharp by MarcFD - read the included aWarpSharp.txt.

Binary patched Toon-v1.0 to use aWarpSharp2 instead of aWarpSharp: Toon-v1.1 (http://pavelsx.googlepages.com/Toon-v1.1.7z)

[ChaosKing]

wow nice...

Just made a quick test.

awarpsharp(154,2,20)#new
awarpsharp(20,2,0.6)#old (marcFD)

1. new, 2. old
http://img43.imageshack.us/img43/6274/awarpsharpnew.th.png (http://img43.imageshack.us/my.php?image=awarpsharpnew.png) http://img223.imageshack.us/img223/815/awarpsharpold.th.png (http://img223.imageshack.us/my.php?image=awarpsharpold.png)

As you can see, the border is no longer green. The pictures look very similar and the plugin seems to be about 20% faster on my Pentium D.

Very good job SEt, i waited so long for a bug free awarpshap :D

[Adub]

You wouldn't happen to have tested the speed now would you, ChaosKing?

I would do it my self, but my rig is currently encoding a Bluray and will be doing so for at least the next 17 hours.

[7ekno]

Thanks SEt !!

Tried it for a drop in for the original aWarpSharp.dll, but MCTDenoise is giving errors with it not supporting some of the paramters passed (and dropping the original aWarpSharp.dll back in resolves it) ...

It's seems to be about 20-30% faster, so well done !!

Tek

[7ekno]

.double post.

[SEt]

All parameters of original aWarpSharp are supposted, but some are renamed - read aWarpSharp.txt for the mapping.

[lansing]

thanks for the rewrite, and I think sticking with the out naming would be more convenience for us

[Dark Shikari]

movdqu xmm2, [esi-1]
movdqa xmm3, [esi]
movdqu xmm4, [esi+1]
movdqu xmm5, [esi+edx-1]
movdqa xmm6, [esi+edx]
movdqu xmm7, [esi+edx+1]
...
movdqu xmm1, [esi+eax-1]
movdqu xmm3, [esi+eax+1]This is what palignr was made for; SSSE3-ifying this with palignr will avoid all the unaligned loads nicely. If you retain loads between loop iterations, you can reduce the number of memory accesses, too.

movdqu xmm6, [esi-6]
movdqu xmm0, [esi+6]
pavgb xmm6, xmm0
movdqu xmm5, [esi-5]
movdqu xmm7, [esi+5]
pavgb xmm5, xmm7
movdqu xmm4, [esi-4]
movdqu xmm0, [esi+4]
pavgb xmm4, xmm0
movdqu xmm3, [esi-3]
movdqu xmm7, [esi+3]
pavgb xmm3, xmm7
movdqu xmm2, [esi-2]
movdqu xmm0, [esi+2]
pavgb xmm2, xmm0
movdqu xmm1, [esi-1]
movdqu xmm7, [esi+1]
pavgb xmm1, xmm7
movdqa xmm0, [esi]Did someone say made for palignr ;)

movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi], 0
pinsrw xmm4, [eax+edx], 0
movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi+1], 1
pinsrw xmm4, [eax+edx+1], 1
movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi+2], 2
pinsrw xmm4, [eax+edx+2], 2
movd eax, xmm2
pinsrw xmm3, [eax+esi+3], 3
pinsrw xmm4, [eax+edx+3], 3
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+4], 4
pinsrw xmm4, [eax+edx+4], 4
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+5], 5
pinsrw xmm4, [eax+edx+5], 5
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+6], 6
pinsrw xmm4, [eax+edx+6], 6
movd eax, xmm7
pinsrw xmm3, [eax+esi+7], 7
pinsrw xmm4, [eax+edx+7], 7
mov eax, [esp]I'm going to have to start killing kittens if I keep seeing things like this.

movq xmm7, qword ptr [edi+ebx-1] // one line above actual position, but it gives 1.4x speedupHow about you figure out why it does? ;)

[owais]

Help!! with this new updated famous plugin i m geting kind of like this image :(

i used aWarpSharp(depth=12,blur=4,thresh=51,chroma=1)

Am i doing something wrong?

the colours are dancing

http://i276.photobucket.com/albums/kk1/owiowais/error.jpg


with old plugin i m getting normal, yeah but having green lines

i used aWarpSharp(depth=12,blurlevel=4,thresh=0.2,cm=1)

http://i276.photobucket.com/albums/kk1/owiowais/greenwidnoclordance.jpg

Edited

i hav found little bit that it is due to chroma=1 bascally i don know wat is chroma cause i m new to video (just started on march and learn a lot :p)

for me till now chroma= 2or 3 works well and 4 also, problem is with 1 for me .. 0 was giving me black and white colour hehe

[SEt]

Dark Shikari, i know not everything is optimally written, but i thought better release working version now than super-optimized never. I know that horizontal blur is made for palignr and will look into this when i have time, but i have no idea how to save kittens or why loading correct line gives 1.4x speed drop for the whole function, including those awful pinsrw that should be much more time consuming than just unaligned load from additional memory location.

owais, have you tried to read all the aWarpSharp.txt? There explained that cm=1 of original aWarpSharp is chroma=4 in mine and what chroma values mean.

[Dark Shikari]

Dark Shikari, i know not everything is optimally written, but i thought better release working version now than super-optimized never. I know that horizontal blur is made for palignr and will look into this when i have time, but i have no idea how to save kittens or why loading correct line gives 1.4x speed drop for the whole function, including those awful pinsrw that should be much more time consuming than just unaligned load from additional memory location."Should be much more time consuming?"

Does that imply you tested it, and found it to be faster?

If it's faster, I'm going to be inclined to blame cacheline-split. Test on an AMD chip or Nehalem and watch the penalties melt away.

[SEt]

I'm already on Nehalem and when i change
movq xmm7, qword ptr [edi+pitch*0-1]
movq xmm4, qword ptr [edi+pitch*0+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]
to
movq xmm7, qword ptr [edi+pitch*1-1]
movq xmm4, qword ptr [edi+pitch*1+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]
i see 1.4x slowdown in profiler for the whole function.

[Dark Shikari]

I'm already on Nehalem and when i change
movq xmm7, qword ptr [edi+pitch*0-1]
movq xmm4, qword ptr [edi+pitch*0+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]
to
movq xmm7, qword ptr [edi+pitch*1-1]
movq xmm4, qword ptr [edi+pitch*1+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]
i see 1.4x slowdown in profiler for the whole function.I was referring to the pinsrw with regard to the cacheline split.

If you're getting such a large slowdown merely by changing that, you should try to figure out why. Performance counters might be useful for analyzing that.

[Fizick]

Can I ask, why do you change parameters meaning? It is confusing, and not "fully compatible with original aWarpSharp".
If you prefer new parameters, please use new parameters names (or new name of plugin).

[SEt]

Played with performance counters for some time and here is what i found (removed all pinsrw for tests as they don't change the situation):
global slowdown is produced by
movq xmm7, qword ptr [edi+pitch*1-1]
but not by
movq xmm4, qword ptr [edi+pitch*1+1]
It results in spike of L1D.REPL and huge spikes of L1D.M_REPL, L1D.M_EVICT, L1D.M_SNOOP_EVICT in that area (also ILD_STALL.ANY, but i don't think it's interesting).
I've tried to change the only writing instruction here from movq to movdq2q,movntq but that changed nothing.


Fizick, i think the situation is similar to MVTools 1-2 :) It's fully compatible in terms of available functionality and effective ranges of parameters are supersets of the original ones. I know i should probably change the name to aWarpSharp2, but it looks kind of strange with aSobel, aBlur, aWarp. In truth it's more like a beta release to me due to mentioned wrong offsets in Warp and saturated multiplication by 6 at the end of Sobel that i don't like at all.

[IanB]

I'm already on Nehalem and when i changemovq xmm7, qword ptr [edi+pitch*0-1]
movq xmm4, qword ptr [edi+pitch*0+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]tomovq xmm7, qword ptr [edi+pitch*1-1]
movq xmm4, qword ptr [edi+pitch*1+1]
movq xmm1, qword ptr [edi+pitch*0]
movq xmm2, qword ptr [edi+pitch*2]i see 1.4x slowdown in profiler for the whole function.
Consider the memory address each is referencing and which cache line each uses. I have colour coded 3 different memory areas. In the fast case only 2 areas are used. Also accessing data not aligned to 64 bits has a penalty. And a very big penalty when you cross a cache line (64 byte) boundary. For the [edi+pitch*1-1] you maybe slipping into the previous cache line (what address is in EDI ?)

[SEt]

The code reads 3 lines of one frame while writing one line to another frame in simple loop. edi is global counter increased by 8 that is used as offset for all sources and destination. It's not cache line split problem as [edi+pitch*1+1] and [edi+pitch*0-1] are ok but not [edi+pitch*1-1], also the order of impact is too big and on Nehalem such penalties are small. It seems like some kind of cache (address?) conflict as the descriptions of performance counters that produce spikes:
REPL - Counts the number of lines brought into the L1 data cache.
M_REPL - Counts the number of modified lines brought into the L1 data cache.
M_EVICT - Counts the number of modified lines evicted from the L1 data cache due to replacement.
M_SNOOP_EVICT - Counts the number of modified lines evicted from the L1 data cache due to snoop HITM intervention.

But the code linearly reads from one location and linearly writes to another in simple loop.

EDIT: It's indeed seems like cache address conflict as lower 16 bits of [edi+pitch*1] and [output] are the same, but it doesn't give me any idea how to fix it besides caching [edi+pitch*1-1] from previous iteration (as both memory locations are what i get from avisynth).
EDIT2: And it seems to be L2-3 problem with scenario something like:
Cache lines in L1 are allocated independently, but when output L1 line is written to L2+ it mistakes next reference to [edi+pitch*1-1] as accessing the same location for that single -1 byte which results in the L1 cache lines ping-pong hell as seen by counters.

[IanB]

What does adding this:-mov al, byte ptr [edi+pitch*1-8]a few lines earlier into your code do?

And is pitch a constant or a register, i.e. are your hiding relevant code from us?

[Leak]

And is pitch a constant or a register, i.e. are your hiding relevant code from us?
Well, the code is in the archive he linked to in his first post, so I'd think he'd have a hard time really hiding it from you... ;)

np: Plastikman - I Don't Know (Closer)

[IanB]

@Leak <- :devil:,

I asked because
movq xmm7, qword ptr [edi+pitch*1-1]
does not appear in the code, but
movq xmm7, qword ptr [edi+ebx-1]
does appear in the code.

And when people want help, I like to make sure nothing is clouding the issue.

[SEt]

Problem solved. Thanks to Dark Shikari for kicking me to actually go see performance counters and IanB for idea what can help.
Placing earlier
mov al, byte ptr [edi+pitch*1-8]
changed nothing, but gave me idea that worked - i moved problem loads before write of previous iteration. A few more optimizations and new code works as fast as old one and sometimes even a bit faster. Will post it later when other things are done.

IanB, i started to use pitch*? instead of registers because included source had no register for pitch*1.

[Chainmax]

This is awesome, one of my favorite plugins to use on animated content finally updated and bug-free! Thank you so much, SEt :).

One question: in order to achieve the same effects as aWarpSharp(depth=16,cm=1) in MarcFD's original one would have to use aWarpSharp(depth=16,chroma=4) on your version, right?

[SEt]

Yes, and both are defaults btw.
It's not bug free yet - as described here it uses incorrect position in edge map. Next version will be correct one.

I'm interested in usefulness of bm=0/1/2 parameter (choice of internal blur type for edge map) - is it really needed now when you can use external one? There are probably enough blurs for AviSynth already.

[sh0dan]

movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi], 0
pinsrw xmm4, [eax+edx], 0
movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi+1], 1
pinsrw xmm4, [eax+edx+1], 1
movd eax, xmm2
psrldq xmm2, 4
pinsrw xmm3, [eax+esi+2], 2
pinsrw xmm4, [eax+edx+2], 2
movd eax, xmm2
pinsrw xmm3, [eax+esi+3], 3
pinsrw xmm4, [eax+edx+3], 3
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+4], 4
pinsrw xmm4, [eax+edx+4], 4
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+5], 5
pinsrw xmm4, [eax+edx+5], 5
movd eax, xmm7
psrldq xmm7, 4
pinsrw xmm3, [eax+esi+6], 6
pinsrw xmm4, [eax+edx+6], 6
movd eax, xmm7
pinsrw xmm3, [eax+esi+7], 7
pinsrw xmm4, [eax+edx+7], 7
mov eax, [esp]I'm going to have to start killing kittens if I keep seeing things like this.

I completely agree - while this might seem fast, it isn't. Movd r32,xmm has a latency of 6 cycles on Core2, pinsrw has a latency of 4. Both are eons.

Store the content of xmm2 and xmm7 into memory, do lookups in scalar assembler and read them back:


movdqa [temp1], xmm2 ; Store all pixels

; push eax, ebx, ecs on the stack, if you use them already

xor eax, eax
xor ebx, ebx
xor ecx, ecx

mov ax,[temp1]
mov bx,[eax+esi]
mov cx,[eax+edi]
mov [temp2], bx
mov [temp3], cx

mov ax,[temp1+2]
mov bx,[eax+esi]
mov cx,[eax+edi]
mov [temp2+2], bx
mov [temp3+2], cx

(you get the picture -use a macro, for nice code)

movdqa xmm3, [temp2]
movdqa xmm4, [temp3]

This way you only get the performance hit of the cache lookups, and a Store->Load Forward size mismatch penalty. And for please, use palignr, it is much faster on Core2.

[SEt]

I completely agree - while this might seem fast, it isn't. Movd r32,xmm has a latency of 6 cycles on Core2, pinsrw has a latency of 4. Both are eons.
Your numbers seems too high even for Core2. According to http://www.agner.org/optimize/ tables movd has latency/throughput of 2/0.33 on both Core2 and pinsrw 6/1.5 on 65nm and 2/1 on 45nm. On my Nehalem Everest measures "MOVD r32, xmm+MOVD xmm, r32" to have latency 4, "PEXTRW + PINSRW r32" latency 1, movd throughput 0.4, pinsrw throughput 0.66.

For speed of this part it's actually the other way around - at the beginning i thought it to be painfully slow too, but profiler says it's quite fast. Changing even movd/psrldq into movdqa/mov [+0/4/8/12] gives me 10% speed drop for the whole function. Changing pinsrw would likely cost even more. Of course it's measured on Nehalem and not on Core2 that everyone seems to love for reason that's beyond me. Modern CPUs taught me to believe only profiler when optimizing and not what you think is faster, so i'm not going to write something that "maybe better for Core2" when i have no means of confirming it by testing there.
And for please, use palignr, it is much faster on Core2. palignr is definitely great for some cases, but guess how much difference i measure between old unaligned hell of
movdqu xmm6, [esi-6]
movdqu xmm0, [esi+6]
pavgb xmm6, xmm0
movdqu xmm5, [esi-5]
movdqu xmm7, [esi+5]
pavgb xmm5, xmm7
movdqu xmm4, [esi-4]
movdqu xmm0, [esi+4]
pavgb xmm4, xmm0
movdqu xmm3, [esi-3]
movdqu xmm7, [esi+3]
pavgb xmm3, xmm7
movdqu xmm2, [esi-2]
movdqu xmm0, [esi+2]
pavgb xmm2, xmm0
movdqu xmm1, [esi-1]
movdqu xmm7, [esi+1]
pavgb xmm1, xmm7
movdqa xmm0, [esi]
pavgb xmm6, xmm5
pavgb xmm4, xmm3
pavgb xmm2, xmm1
pavgb xmm6, xmm4
pavgb xmm2, xmm0
pavgb xmm6, xmm2
pavgb xmm6, xmm2
movntdq [esi+edi], xmm6

and new (to be released)
movdqa xmm7, [esi+10h]
movdqa xmm0, xmm6
movdqa xmm2, xmm7
palignr xmm0, xmm5, 10
palignr xmm2, xmm6, 6
pavgb xmm0, xmm2
movdqa xmm3, xmm6
movdqa xmm4, xmm7
palignr xmm3, xmm5, 11
palignr xmm4, xmm6, 5
pavgb xmm3, xmm4
pavgb xmm0, xmm3
movdqa xmm1, xmm6
movdqa xmm2, xmm7
palignr xmm1, xmm5, 12
palignr xmm2, xmm6, 4
pavgb xmm1, xmm2
movdqa xmm3, xmm6
movdqa xmm4, xmm7
palignr xmm3, xmm5, 13
palignr xmm4, xmm6, 3
pavgb xmm3, xmm4
pavgb xmm1, xmm3
pavgb xmm0, xmm1
movdqa xmm1, xmm6
movdqa xmm2, xmm7
palignr xmm1, xmm5, 14
palignr xmm2, xmm6, 2
pavgb xmm1, xmm2
movdqa xmm3, xmm6
movdqa xmm4, xmm7
palignr xmm3, xmm5, 15
palignr xmm4, xmm6, 1
pavgb xmm3, xmm4
pavgb xmm1, xmm3
pavgb xmm1, xmm6
movdqa xmm5, xmm6
movdqa xmm6, xmm7
pavgb xmm0, xmm1
pavgb xmm0, xmm1
movntdq [esi+edi], xmm0

? The second version is only 10% faster (of course, on Nehalem again).

[Dark Shikari]

Of course it's measured on Nehalem and not on Core2 that everyone seems to love for reason that's beyond me.Maybe because that's what they own? It will be years before the Nehalem has a higher install base than the Core 2.Modern CPUs taught me to believe only profiler when optimizing and not what you think is faster, so i'm not going to write something that "maybe better for Core2" when i have no means of confirming it by testing there.Then ask someone for SSH access, there are billions of Core 2s.

? The second version is only 10% faster (of course, on Nehalem again).Try running the first set of code when you're not on a cacheline, and the second set when you are, perhaps?

[SEt]

Maybe because that's what they own? It will be years before the Nehalem has a higher install base than the Core 2. I suspect there is higher install base for P4/D than Core2 now, but does it mean we should optimize primary for P4? If care for something else it would be Phenoms and i suspect them to behave similar to Nehalem, not Core2.
Then ask someone for SSH access, there are billions of Core 2s.
Good idea, but i'd rather spend my time now for more important stuff, like actually releasing something.
Try running the first set of code when you're not on a cacheline, and the second set when you are, perhaps?
I'm not quite get your point here. I bench the code on real video processing. Also notice the 'movdqa' in the only memory load of second variant.

[Dark Shikari]

I suspect there is higher install base for P4/D than Core2 now, but does it mean we should optimize primary for P4? If care for something else it would be Phenoms and i suspect them to behave similar to Nehalem, not Core2.People who care about video processing speed are not using Pentium 4s.Good idea, but i'd rather spend my time now for more important stuff, like actually releasing something.Why is it that I can release code optimized for multiple modern CPUs while you can't?I'm not quite get your point here. I bench the code on real video processing. Also notice the 'movdqa' in the only memory load of second variant.And? x264 performs "real video processing" and has separate code paths for when the loads fall across a cacheline.

[SEt]

People who care about video processing speed are not using Pentium 4s.
People who really care about video processing speed would use Nehalem.
Why is it that I can release code optimized for multiple modern CPUs while you can't?
It's a matter of preference. I think optimization is important, but comes behind the features. I'd love to see in next x264 option to be 2x slower but produce 5% better quality/smaller file size instead of even 10% overal speed up.
And? x264 performs "real video processing" and has separate code paths for when the loads fall across a cacheline.
How can dq loads aligned on 16 bytes be across a cacheline?

[Dark Shikari]

How can dq loads aligned on 16 bytes be across a cacheline?You said that your palignr-based code is only 10% faster.

What if it was 70% faster when on a cacheline, and 10% slower otherwise? This would average out to 10% faster overall.

In that case, you'd want to use the unaligned code when not on a cacheline, and the palignr code when on a cacheline.

[SEt]

Ok, now i understand you. Profiled such case and it turned out that old and new code have exactly the same speed when not on a cacheline. So, those 10% are what palignr wins on cacheline split.

[Dark Shikari]

Ok, now i understand you. Profiled such case and it turned out that old and new code have exactly the same speed when not on a cacheline. So, those 10% are what palignr wins on cacheline split.By the way, the reason it's only 10% faster on Nehalem is because the Nehalem has only a 2-cycle penalty for cacheline splits.

The Core 2 Penryn has a ~12-14-cycle penalty, which will probably mean that SSSE3 code will go massively faster on Penryn; I'd guess at least 50% benefit.

[SEt]

I know that much about my Nehalem. :) But would love to read something like http://www.agner.org/optimize/ about its microarchitecture and instruction timings (regrettably, information there is only up to Core2 now).

[Dark Shikari]

I know that much about my Nehalem. :) But would love to read something like http://www.agner.org/optimize/ about its microarchitecture and instruction timings (regrettably, information there is only up to Core2 now).Intel's latest optimization guide has Nehalem documentation, but not timings.

Mubench (http://akuvian.org/src/mubench_results.txt) has mostly-accurate Nehalem timings.

[Gokumon]

Why is it that I can release code optimized for multiple modern CPUs while you can't?

Because you get paid to work on x264 while SEt doesn't get paid to work on his aWarpSharp rewrite?

[SEt]

Finally an update:

renamed main filter from aWarpSharp to aWarpSharp2 for less confusion with original aWarpSharp
fixed wrong offsets in Warp
added new blur type - produce better quality, but around 2.5x slower
blur will be more precise around frame borders if SSSE3 is available
some optimizations, mostly noticeable on Core2
removed support for undocumented parameters of original aWarpSharp

[Dark Shikari]

Because you get paid to work on x264I do? That's news to me, because I haven't gotten a check.

[LoRd_MuldeR]

I do? That's news to me, because I haven't gotten a check.

What about your (previous) engagement at Avail Media? :p

[Dark Shikari]

What about your (previous) engagement at Avail Media? :pAs it happens, summer internships end at the end of the summer ;)

[Gokumon]

As it happens, summer internships end at the end of the summer ;)

Okay, from what I read from your posts it seemed to be an actual full-time position not an internship. Let's put it this way instead then, some people don't necessarily have as much time and effort to spend to write assembly for many multiple CPUs as other people may be able to.

[SEt]

Rebuilt version 2009.06.19 with new header to correct threading problems.

[MyCometG3]

SEt
Thank you for your effort.
I have ported this plug-in to GCC. Impemented into my CoreVF framework, under MacOS X env. It runs well. Great!

One thing, Warp() function seems to check CPU is SSSE3 ready every line inside asm, is this required?
I have split SSSE3 loop and SSE2 loop, seems to run well. It could be faster.

(I am not sure, but original code does not run well under CoreDuo - no SSSE3 support; Of course not original, but gas rewritten code though. Splitting loops works well both on Core2Duo and CoreDuo)

[SEt]

There should be no problem with that conditional jump - any modern cpu should be able to always correctly predict it so it will consume no time at all. And even mispredicted once per line is very small cost. What you are observing might be cache related - it has far more serious impact on performance. But of course it's only a theory.

[Monamona]

Is there any chance that the filter will be modified to work under YUY2?

[lych_necross]

I like the rewritten aWarpSharp. Now, if only Toon.dll would get updated to support the new version...

[SEt]

I'm not going to add YUY2 support, but probably will add YV16.

[Lynx Pardinus]

You mean YV16, wich won't be supported until Avisynth 2.60, or the planar YUY2 supported by MVTools, masktools and many others ?

[SEt]

YV16 of Avisynth 2.60+.

[lych_necross]

Supporting yv16 instead of yuy2 is odd, but okay. I waited 1+ years for for 2.58, whats another couple of years ;)

[thewebchat]

In the awarpsharp.txt file included with your filter, you mention that the mapping between "thresh" in aWarpSharp2 and aWarpSharp is "aWarpSharp2 value * 256" but the aWarpSharp documentation says that thresh goes from 0.0 to 1.0. How does this work?

Edit: Oh, sorry, read the equation the wrong away around. Sorry about that. Someone can delete this post.

Edit2: I am getting an access violation (reading from 0x0 at 0xfaa1415) when setting blur to "1". The documentation says that values from 0 to 100 are supported.

Edit3: Oh wait, that's just a mod16 error.

[Soulhunter]

I thought green border artifact bug was fixed years ago... >.>

[SEt]

As requested, i've updated Toon to use aWarpSharp2 instead of aWarpSharp. As i don't see the sources - made it by patching the dll, so no optimizations or bugfixes in this v1.1.

lych_necross, YUY2 is very inconvenient format for vectorized processing (MMX/SSE) while YV16 has no such problems and adding its support to YV12 code is almost trivial.

[lych_necross]

Oh, I didn't know that. Thats cool as I usually use YV12 anyways.
P.S. SWEET!!! :D new toon.dll!! I think Soulhunter originally posted toon.dll, so he would probably have the sources.

[Adub]

Soulhunter didn't make Toon, he just posted it on behalf of the author, who I'm pretty sure is mf.

[Soulhunter]

Soulhunter didn't make Toon, he just posted it on behalf of the author, who I'm pretty sure is mf.
...who was banned here some time ago
...so he cant post here anymore
...so I do it for him

But, the aWarpSharp version in his dumpster (2nd Google result when searching for aWarpSharp.dll) should already contain the fixed version I mentioned in my last post... So, is there really a reason to update Toon.dll besides the minimal (the old aWarpSharp already runs way above realtime, doesn't it?) speed gain?

[SEt]

I don't see any fixed version of aWarpSharp.dll. I prefer to have one WarpSharp filter for everything and it's always better to be faster.

[Great Dragon]

Hi guys.
I have VD crash with this script:
s=AVISource("h:\dt_314.avi")
a1=trim(s,0,13566).crop(10,0,-6,0)
a2=trim(s,13567,22584).crop(6,0,-10,0)
a3=trim(s,22585,32818).crop(8,0,-8,0)
a1++a2++a3
mergechroma(awarpsharp2(blur=16,thresh=128, type=1))

and if I put mergechroma code right after input clip like this:

a1=AVISource("h:\dt_314.avi").mergechroma(awarpsharp2(blur=16,thresh=128, type=1)).trim(0,13566).crop(10,0,-6,0)
a2=AVISource("h:\dt_314.avi").mergechroma(awarpsharp2(blur=16,thresh=128, type=1)).trim(13567,22584).crop(6,0,-10,0)
a3=AVISource("h:\dt_314.avi").mergechroma(awarpsharp2(blur=16,thresh=128, type=1)).trim(22585,32818).crop(8,0,-8,0)
a1++a2++a3

I have an error: "Invalid arguments to function "awarpsharp2".

In same with simple usage like this:

AVISource("h:\dt_314.avi")
mergechroma(awarpsharp2(blur=16,thresh=128, type=1))

filter works like a charm.

[Gavino]

if I put mergechroma code right after input clip like this:

a1=AVISource("h:\dt_314.avi").mergechroma(awarpsharp2(blur=16,thresh=128, type=1)).trim(0,13566).crop(10,0,-6,0)
...
I have an error: "Invalid arguments to function "awarpsharp2".
That's because the input clip for the call to awarpsharp2() is not explicitly provided, and 'last' is not defined at that point in the script.
You need to do it like this:

AVISource("h:\dt_314.avi")
mergechroma(awarpsharp2(blur=16,thresh=128, type=1))
a1=trim(0,13566).crop(10,0,-6,0)
a2=trim(13567,22584).crop(6,0,-10,0)
a3=trim(22585,32818).crop(8,0,-8,0)
a1++a2++a3

Don't know why VD should crash with your original script though.

[Keiyakusha]

This script crashes for me even without aWarpsharp2.

s=AVISource("something.avi")
a1=trim(s,0,13566).crop(10,0,-6,0)
a2=trim(s,13567,22584).crop(6,0,-10,0)
a3=trim(s,22585,32818).crop(8,0,-8,0)
a1++a2++a3
Access Violation in Decoder ffdshow (libavcodec or xvid) for divx 720p video. When awarpsharp2 is present, Access Violation is reported for awarpsharp2

EDIT: oops, quoted wrong script. now is fine.

[Great Dragon]

Gavino, Thanks man. I still need to learn avisynth language a lot.

[Esc]

When I try to use aWarpSharp2 after MCTemporalDenoise, I get error:
CAVIStreamSynth: System Exception - Access Violation at 0x4981415, reading from 0x0.
Other functions seem to not matter at all. Here are the two lines
MCTemporalDenoise(settings="high",edgeclean=true)
aWarpSharp2()
If I switch them, it works again.
Source is mpeg2source from a dvd rip.

Nice thinning btw!

[MajorX]

Is it good to use aWarpSharp() for good result ...means default value for anime content (BluRay source)?

[kypec]

Dear experienced developers,

I'm having hard time to make aWarpsharp2 function properly. Please find sample VOB with AVS script (http://www.mediafire.com/?dvcva96khcka9gq) (~15 MB) and also all
necessary plugins (http://www.mediafire.com/?log40wj33dbw25w) (~10MB) to reproduce the error.
Whenever there is the last line which invokes sharpening functionaWarpSharp2(thresh=120, blur=2, type=0, depth=16, chroma=4)included the script fails.
AVS2AVI and AVSMeter both crash with failure pointing to awarpsharp.dll
AvspMod crash report when trying to preview the script:
Traceback (most recent call last):
File "F:\AvsPmod\src\AvsP.py", line 7405, in OnMenuVideoRefresh
File "F:\AvsPmod\src\AvsP.py", line 11109, in ShowVideoFrame
File "F:\AvsPmod\src\AvsP.py", line 11696, in PaintAVIFrame
File "pyavs.pyo", line 343, in DrawFrame
File "pyavs.pyo", line 320, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0x00000000

I'm using AviSynth 2.60, build Sep 13 2011. No multithreading involved at all, Win 7 x64 @ Intel E8400, 8GB RAM.

Is there any alternative plugin that would provide same/very similar output to aWarpsharp?

:thanks: in advance for your replies!

[SEt]

Fixed, see updated link in first post.

[Chainmax]

Thanks, SEt! :)

[SEt]

While I'm at it, let's post some improvements that were implemented years ago but never made it to public: new version 2012.03.28.

Changes:
1) Added new final part aWarp4 that takes 4x upsampled source for better final subpixel interpolation. Allows producing much sharper result with lower depth, so less deformations. Examples:

aWarp4(Spline36Resize(width*4, height*4, 0.375, 0.375), aSobel().aBlur(), depth=3)
aWarp4(nnedi3_rpow2(rfactor=2).Spline36Resize(width*4, height*4, 0.25, 0.25), aSobel().aBlur(), depth=3)
aWarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2), aSobel().aBlur(), depth=2)

Note that upsampling should be left-top aligned, so Spline36Resize(width*4, height*4) or nnedi3_rpow2(rfactor=4) won't produce correct results.

2) aWarpSharp2 can now be also called by aWarpSharp() with internal parameters conversion for compatibility with ancient scripts. Direct aWarpSharp2 call is encouraged though.
3) New chroma values: 5 and 6: the same as 3 and 4, but luma isn't processed and just copied. Useful for filtering sources with certain chroma problems.
4) Changed some defaults.

[kypec]

:thanks: SEt, much appreciated!

[mastrboy]

Thanks :)

[handsomejack]

I cant download Toon 1.1, please upload to another host.

[poisondeathray]

I cant download Toon 1.1, please upload to another host.

Toon-v1.1
http://www.mediafire.com/?6p3dx7cpc7dyakl

[handsomejack]

Thanks poisondeathray, you are lifesaver :D

[luke83]

Toon-v1.1
http://www.mediafire.com/?6p3dx7cpc7dyakl
what's matter Toon in aWarpsharp2???

It's good idea to do anti-aliasing and temporal filtering over edge mask before passing it to warp stage if you want more stable results.
do you mean an external anti-aliasing filter? (like AAA, DAA or FAA)
Is there an internal function for that?

[poisondeathray]

what's matter Toon in aWarpsharp2???



Green borders with awarpsharp (hence the reason for awarpsharp2's existence), read the first post .

http://forum.doom9.org/showthread.php?p=1289036#post1289036




do you mean an external anti-aliasing filter? (like AAA, DAA or FAA)
Is there an internal function for that?

I don't know who you are quoting for this ? or what context this refers to ??

[luke83]

Green borders with awarpsharp (hence the reason for awarpsharp2's existence), read the first post .
honestly i had green borders with the new version of Avisynth 2.6 MT optimized by SET XD
However...

I don't know who you are quoting for this ? or what context this refers to ??
I've quoted it from the readme of awarpsharp2

[killerteengohan]

This plugin works pretty good. I wouldn't mind more control over the depth though for a more exact line measurement.

Is there a way to use depth with decimals like with the regular awarpsharp or can it be implemented?

I cannot use depth=3.5 on awarpsharp2 but its fine with awarpsharp.

depth=1 is almost the same as depth=3.5 on the original awarpsharp when it comes to line thinning, but not quite as much and if I set it to depth=2 in awarpsharp2, its more than depth=3.5 on the original awarpsharp and I was hoping to get the about the exact same thinning level.

[Reel.Deel]

This plugin works pretty good. I wouldn't mind more control over the depth though for a more exact line measurement.

Is there a way to use depth with decimals like with the regular awarpsharp or can it be implemented?

I cannot use depth=3.5 on awarpsharp2 but its fine with awarpsharp.

depth=1 is almost the same as depth=3.5 on the original awarpsharp when it comes to line thinning, but not quite as much and if I set it to depth=2 in awarpsharp2, its more than depth=3.5 on the original awarpsharp and I was hoping to get the about the exact same thinning level.

You started a thread a while back in which SeT said this:

aWarpSharp2 is exactly the same algorithm as aWarpSharp, only with some bugfixes. If you are getting significantly different results – you are doing something wrong. Latest aWarpSharp2 supports aWarpSharp alias that remaps the parameter values automatically if you absolutely can't read the documentation.

Btw, aWarpSharp2 has integer parameters because algorithm uses actually integers, so again aWarpSharp2 is exactly the same as aWarpSharp, just removes the false feeling that slight change in float number changes something when it actually maps to the same integer inside.

[real.finder]

hi SEt

this http://www.dropbox.com/s/5s6xht0xu80otbz/aWarpSharp_20120328_x64.zip?dl=1 from http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins

has the same crash http://forum.doom9.org/showpost.php?p=1744196&postcount=18 in avs 64 (http://forum.doom9.org/showthread.php?t=152800)

and in avs+ 64 (even with "width=640, height=480", since avs 64 will work fine here)


AVSMeter 2.1.5 (x64)
AviSynth+ 0.1 (r1576, x64) (2.6.0.5)

Exception 0xC000001D
STATUS_ILLEGAL_INSTRUCTION

Press any key to exit...


but in avs+ 32 with awarpsharp2-2015.10.25 by cretindesalpes will be fine in both image size

Apart from this problem, I think Y8 is important for speed up script like aWarpSharp4xx since aWarpSharp2 uses MPEG-1 chroma placement, yes, make aWarpSharp2 uses MPEG-2 chroma placement and supports other planar colorspaces is better but I think add Y8 more important

[cretindesalpes]

aWarpSharp2 2015-12-30 (https://ldesoras.fr/src/avs/awarpsharp2-2015.12.30.zip):
Support for YV16 and YV24 colorspaces
Support for Y8 colorspace, by _08
Added parameter depthC specifying the depth for the chroma planes, by _08
Added parameter cplace to specify MPEG1 or MPEG2 chroma placement
Some crashes of the beta version hopefully solved.

[real.finder]

aWarpSharp2 2015-12-30 (http://ldesoras.free.fr/src/avs/awarpsharp2-2015.12.30.zip):
Support for YV16 and YV24 colorspaces
Support for Y8 colorspace, by _08
Added parameter depthC specifying the depth for the chroma planes, by _08
Added parameter cplace to specify MPEG1 or MPEG2 chroma placement
Some crashes of the beta version hopefully solved.

:thanks:

this work with no crashes, now the only thing is missed is x64 plugin

[ryrynz]

:thanks:

this work with no crashes, now the only thing is missed is x64 plugin

Yeah this is preventing me from using AVS+ 64 bit. I've mentioned it on jackoneill's Vapoursynth port thread.

[Reel.Deel]

Yeah this is preventing me from using AVS+ 64 bit. I've mentioned it on jackoneill's Vapoursynth port thread.

You can find the 64-bit plugin here (http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins), but it's the 2012 version. You can use it with aWarpSharp4xx (http://forum.doom9.org/showthread.php?t=171488) to provide the same functionality as the 2015 version. A 64-bit version of cretindesalpes updated aWarpSharp2 would be better though.

[ryrynz]

A 64-bit version of cretindesalpes updated aWarpSharp2 would be better though.

Thanks, I've hit up cretindesalpes about it. I doubt SEt would be interested and jackoneill isn't, I guess that leaves one or two guys in the Avisynth+ thread, fingers crossed.

FWIW it seems the current 64 bit version doesn't appear to be entirely stable, I get crashes approximately 20% of the time using awarpsharp or awarp4 on file playback when using latest Avisynth+ through ffdshow. No problems with the 32 bit version.

[Reel.Deel]

FWIW it seems the current 64 bit version doesn't appear to be entirely stable, I get crashes approximately 20% of the time using awarpsharp or awarp4 on file playback when using latest Avisynth+ through ffdshow. No problems with the 32 bit version.

Post your script. I've haven't had any problems so far but I'm not using ffdshow.

[pinterf]

Due to popular demand (ryrynz) :), I updated this nice plugin for those who were missing only this chain before plunging into the 64 bit world.

aWarpSharp2-20160624, x64 / x86 (https://github.com/pinterf/aWarpSharp/releases/tag/aWarpSharp2-20160624)

Remark: does not work with Avisynth 2.5x interface.

[GMJCZP]

Thanks, it works in XP x86!

[Selur]

@pinterf:
using aWarpSharp(depth=64.00,blurlevel=4) I get:
aWarpSharp2: 'depth' must be -128..127
according to http://avisynth.nl/index.php/AWarpSharp depth for aWarpSharp should be a float in the range of 0.0 - 64.0
aWarpSharp(depth=64.00,blurlevel=3) works fine
probably some internal mapping error, reported the error also to the issue tracker of the github project.

[Groucho2004]

according to http://avisynth.nl/index.php/AWarpSharp depth for aWarpSharp should be a float in the range of 0.0 - 64.0
AWarpSharp != AWarpSharp2. AWarpSharp2 expects int for depth.

[Selur]

@Groucho: I know, I never said it was and I never assumed it,....
a. the description of http://avisynth.nl/index.php/AWarpSharp2 states that the dll implements multiple functions aBlur, aSobel, aWarp, aWarp4, aWarpSharp, aWarpSharp2 and the implementation of aWarpSharp should be compatible to the old dll (which it aside from the combination of depth=64 and blurlevel=4 does seem to be)
b. depth itself isn't the issue; my guess is aWarpSharp is implemented by mapping the calls internally to aWarSharp2 and that there is a mapping error in case of the mentioned parameter combination

[Selur]

Okay, but why does it only complain with blurlevel=4 and not blurlevel=3 ?

[Groucho2004]

Okay, but why does it only complain with blurlevel=4 and not blurlevel=3 ?
Sorry, too early, need coffee.

[pinterf]

@pinterf:
using aWarpSharp(depth=64.00,blurlevel=4) I get:

according to http://avisynth.nl/index.php/AWarpSharp depth for aWarpSharp should be a float in the range of 0.0 - 64.0
aWarpSharp(depth=64.00,blurlevel=3) works fine
probably some internal mapping error, reported the error also to the issue tracker of the github project.
The mapping is: depth * blurlevel * 0.5.
This is 128, when depth=64.0 and blurlevel=4, so you get a 'depth' must be -128..127 error message.

[Selur]

shouldn't it be more like:
(depth * blurlevel * 0.5)-1
to not throw an error?

[pinterf]

I don't see the logic behind the re-mapping depth value -128..127 exactly. What do negative numbers mean there?
The source code uses the parameter as depth << 8 and a comment says it should be 0..7FFF
Anyway, depth(64)*blurlevel(4) may silently be mapped to 127. Is it a good idea? (And the error message is confusing, too, needs polishing)

[Selur]

Anyway, depth(64)*blurlevel(4) may silently be mapped to 127. Is it a good idea?
Probably a bit ugly, but personally I wouldn't mind as long as it doesn't break anything else.

[real.finder]

Due to popular demand (ryrynz) :), I updated this nice plugin for those who were missing only this chain before plunging into the 64 bit world.

aWarpSharp2-20160624, x64 / x86 (https://github.com/pinterf/aWarpSharp/releases/tag/aWarpSharp2-20160624)

Remark: does not work with Avisynth 2.5x interface.

x64 work now :thanks:

[TCmullet]

I've been using aWarpSharp for about a year. I just noticed there's an aWarpSharp2, and it allegedly has a function aWarpSharp built in in a way that lets you use the original parameters for aWarpSharp so that old scripts still work.

I got:
aWarpSharp2-20160624.7z

I copied the aWarpSharp.dll from the x86 folder and to my plugins folder of Avisynth. It blows up saying aWarpSharp not found.

What's going on? Of course my system is Windows 10, 64-bit. However, I always use x86 (32-bit) versions of all video processing software to ensure reliability. Is there REALLY an aWarpSharp (original version) built in to aWarpSharp2? It doesn't seem to work.

[Groucho2004]

It blows up saying aWarpSharp not found.
You can always test your Avisynth installation and plugin functionality with AVSMeter:
Run "AVSMeter -avsinfo" and look for any error messages.

However, I'm quite certain that your problem is related to missing MS runtimes (VS2015 x86 (http://download.microsoft.com/download/4/5/6/456cf79a-4046-4232-8e6f-7cf3d8075d9a/vc_redist.x86.exe)).

[TCmullet]

Yes, that was it. Thanks, and thanks or the link. When I refound the doc here:
http://avisynth.nl/index.php/AWarpSharp2
... it DOES say you need it. I hadn't bothered to read the "requirements" as I thought it would be the same as aWarpSharp "1". Also, the link there for the c++ runtime is broken, therefore especially thanks for a working link. I knew I had c++ runtime, but turns out it was 2013; obviously outdated.

[StainlessS]

I knew I had c++ runtime, but turns out it was 2013; obviously outdated.

You need all runtimes specific to the software that you run, the latest dll's are of no use to software requiring earlier runtimes.

Here is an All-In-One installer:- http://repacks.net/forum/viewtopic.php?t=125

Get the latest version of above if you find you have similar problems with other s/ware.

EDIT: Although you do sometimes get later versions of a specific runtime, eg a later version of VS CPP 2015 runtimes,
but still called VS CPP 2015 runtimes even if released in 2016.

[real.finder]

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

[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