Updated aWarpSharp version, with some new features

[poisondeathray]

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.

EDIT:
Quick test with AWarp looks the similar to me in vpy at 8bit , vs. vpy (16bit back down to 8bit), but DIFFERENT vs. avs 8bit this version , and different again to awarpsharp2 x86 version...

Some differences might occur depending on how you scale 8 to 16 to 8, which algorithm, dither algorithm (or no dither)

Post your script

Yes, it does look different, I'm looking closer....

[jpsdr]

First, my dll (beta) version here (http://jpsdr.free.fr/XBMC/aWarpSharpMT.7z).

Script : Video test is the VDub RGB test Cube in YV12, something like this :


a0=AVISource("Test.avi",False,"YV12").SetPlanarLegacyAlignment(True)
a=ConvertBits(a0,12)
b=aWarpSharp2(a)
c=aWarpSharp2(a0)
Interleave(b.ConvertBits(8),c)


After, replace aWarpSharp2 by aBlur, aSobel.

My code source is on the github (see first post).

Edit : Of course, there is also the possibility that i've messed-up porting/using the vpy code, even if i've double-checked after noticing this.

[jpsdr]

As always, the video test is the RGB Cube generated by VirtualDub in YV12.

Before checking the differences between 8 bits and >8bits, i've checked that for all functions and for each functions several parameter cases, the following produce pure grey result, to assure that multi-threading was working properly.
Exemple of one test case :

a0=AVISource("Test.avi",False,"YV12").SetPlanarLegacyAlignment(True)
a=ConvertBits(a0,10)
b=aSobel(a,threads=0,chroma=3)
c=aSobel(a,threads=1,chroma=3)
Subtract(b,c).ConvertBits(8)
Levels(127, 1, 129, 0, 255)


And then, after, i've compared the 8 bits version versus the >8 bits version :


a0=AVISource("Test.avi",False,"YV12").SetPlanarLegacyAlignment(True)
a=ConvertBits(a0,10)
b=aSobel(a,threads=0,chroma=3)
c=aSobel(a0,threads=0,chroma=3)
Interleave(b.ConvertBits(8),c)

This one, no visual difference noticed.


a0=AVISource("Test.avi",False,"YV12").SetPlanarLegacyAlignment(True)
a=ConvertBits(a0,10)
b=aBlur(a,threads=0,type=0)
c=aBlur(a0,threads=0,type=0)
Interleave(b.ConvertBits(8),c)

No difference noticed on the cube, but on the text under the cube, it seems that brightness is slighty different.


a0=AVISource("Test.avi",False,"YV12").SetPlanarLegacyAlignment(True)
a=ConvertBits(a0,10)
d=aSobel(a)
d0=aSobel(a0)
b=aWarp(a,d,threads=0,chroma=3)
c=aWarp(a0,d0,threads=0,chroma=3)
Interleave(b.ConvertBits(8),c)

No difference noticed on the cube, but on the text under the cube a big difference can be seen.

For now, i'm a little stuck with these results, i double checked my code with the vpy code, and didn't see any differences, but if someone who has vapoursynth and avisynth+ can compare (just visual in first) the results between vpy and the dll i've provided in the previous post.

[pinterf]

I had to provide chroma=3 for aSobel, or else the U and V planes contained undefined garbage (remnants of previous frames), aWarp used this garbage on U and V planes
EDIT: on the last sample script

[jpsdr]

Ah... Yes, you're right, for Sobel and aBlur default chroma is "1" (Don't care) -> I have to set the chroma for testing, otherwise my tests have no meaning.
I'll do that next time...

Question : Can src->GetReadPtr(plane) be different of dst->GetWritePtr(plane), or are they always the same ?
The fact is that aBlur output "src", so actualy for chroma "1" (don't care) or "2" (copy) nothing is done. But this is assuming that both read and write are the same memory.

[jackoneill]

Question : Can src->GetReadPtr(plane) be different of dst->GetWritePtr(plane), or are they always the same ?
The fact is that aBlur output "src", so actualy for chroma "1" (don't care) or "2" (copy) nothing is done. But this is assuming that both read and write are the same memory.

Probably don't assume that in Avisynth.

[pinterf]

Ah... Yes, you're right, for Sobel and aBlur default chroma is "1" (Don't care) -> I have to set the chroma for testing, otherwise my tests have no meaning.
I'll do that next time...

Question : Can src->GetReadPtr(plane) be different of dst->GetWritePtr(plane), or are they always the same ?
The fact is that aBlur output "src", so actualy for chroma "1" (don't care) or "2" (copy) nothing is done. But this is assuming that both read and write are the same memory.
If a GetReadPtr follows a GetWritePtr, they will be the same.
GetWritePtr will create a new copy from the frame that means it will give you new plane pointers.

[jpsdr]

Argh... Sorry, i just realise i made a typo mistake in my question... :(
Unless you corrected yourself and pinterf answered indeed my real question, my true question was :
Can src->GetReadPtr(plane) be different of src->GetWritePtr(plane), or are they always the same ?

Basicaly, even if it seems working, for aBlur as the filter return src in GetFrame (so input child), in case of "copy plane" for chroma, should it stay like it's for now, "doing nothing", or should i copy "src->GetReadPtr(plane)" to "src->GetWritePtr(plane)" ?

[pinterf]

Argh... Sorry, i just realise i made a typo mistake in my question... :(
Unless you corrected yourself and pinterf answered indeed my real question, my true question was :
Can src->GetReadPtr(plane) be different of src->GetWritePtr(plane), or are they always the same ?

Basicaly, even if it seems working, for aBlur as the filter return src in GetFrame (so input child), in case of "copy plane" for chroma, should it stay like it's for now, "doing nothing", or should i copy "src->GetReadPtr(plane)" to "src->GetWritePtr(plane)" ?
Sorry, it's frame->MakeWritable that will create a new brand new frame and will copy previous planes. GetWritePtr will simply increase an internal sequence_number, and ensures that only one GetWritePtr can be issued on the frame or else it returns NULL pointer.
But the plane pointers are unchanged for a simple GetWritePtr.

[jpsdr]

Ok, thanks.

[jpsdr]

Is there someone having vapoursynth who has been able to compare the results from my DLL (link in post #102) with the vapoursynth plugin ? For now, i still don't know if the different results are because i've messed up my port, or if my avs plugin produce the same result than the vp plugin.

[jpsdr]

Ok, about the 16 bits support. I've first used the vapoursynth code, but there was something odd with the aWarp code, so i've reversed to C the asm code, and got a proper result.
Nevertheless, there is some warning to provide.

I've been struggle to have result looks similar between 8 bits and > 8bits, but, because of some side effects, it's not the case.
For exemple, there is often average done.
On 8 bits, average of 127 and 128 will produce 128.
But on 12 bits, 127 and 128 expanded to 12 bits, it will result on average of 2032 and 2048 will produce 2040. But convert back to 8 bit, will produce 127 if troncated or 128 if rounded. Cumulate this kind of things, and it will explain why you can have sometimes small differences.

For testing, i was doing things like this (my video test was the RGB color cube you can create with VirtualDub) :

a0=AVISource()
a=ConvertBits(a0,16)
b=aSobel(a,threads=1,chroma=3)
c=aSobel(a0,threads=1,chroma=3)
Interleave(b.ConvertBits(8),c)

And check that there was no noticeable differences.
For aSobel, there is no noticeable differences, but, that doesn't mean there is no differences at all.

With the following :

a0=AVISource()
a=ConvertBits(a0,16)
d=aSobel(a,chroma=3,threads=1)
d0=aSobel(a0,chroma=3,threads=1)
b=aWarp(a,d,threads=0,chroma=3,depth=16)
c=aWarp(a0,d0,threads=0,chroma=3,depth=16)
Interleave(b.ConvertBits(8),c)

You begin to notice very small differences on very few places, because the effect of an even unoticeable difference on aSobel, can create a noticeable difference in aWarp.
If you don't set the depth parameter, and stay with default value, there is no noticeable differences.

As aBlur is a lot of average things, doing this :

a0=AVISource()
a=ConvertBits(a0,16)
b=aBlur(a,threads=1,type=1)
c=aBlur(a0,threads=1,type=1)
Interleave(b.ConvertBits(8),c)

result on small noticeable differences.

Finaly, the last test

a0=AVISource()
a=ConvertBits(a0,16)
b=aWarpSharp2(a,threads=1,chroma=3,type=1)
c=aWarpSharp2(a,threads=1,chroma=3,type=1)
Interleave(b.ConvertBits(8),c)

result on noticeable differences. Because no noticeable differences on aSobel (doesn't mean there is not) + small noticeable differences on aBlur result on noticeable differences on aWarpSharp2...:(

So, i've struggle to see if i could "trick" things to have no noticeable differences with aWarpSharp2. I've made a specific tricked aBlur and aSobel code, which worked "exaclty" as the same of pavgb, using 8 bits mask and offset, to have "reduced" 8 bits resolution on >8 bits mode.
I've been able to get

a0=AVISource()
a=ConvertBits(a0,16)
b=aBlur(a,threads=1,type=1)
c=aBlur(a0,threads=1,type=1)
Interleave(b.ConvertBits(8),c)

producing no noticeable differences.
But, despite all of this, there was still noticeable differences when doing :

a0=AVISource()
a=ConvertBits(a0,16)
b=aWarpSharp2(a,threads=1,chroma=3,type=1)
c=aWarpSharp2(a,threads=1,chroma=3,type=1)
Interleave(b.ConvertBits(8),c)

...:(

So, i gave up this idea of having no noticeable differences. There will be no trick in the code, but expect small differences between 8 bits and >8bits.
Still workings on things, so no releases for now, this was just to make a point statement.

[real.finder]

thank you for your efforts jpsdr

differences between 8bit and HBD in these kind of filters are normal, like mvtools, in full 16 bit filtering mdegrain will be different from only mdegrain 16 bit filtering (with 8 bit vectors)

differences doesn't mean it's bad, it mean wasting time on HBD worth it, since there are no point to have 100% same result with a lot of slowness!

[jpsdr]

Thanks to a great help and great contribution from pinterf, the 16 bits version is now working properly ! And it even comes with a gift, an optimised intrinisc code our master have the secret ;).

[jpsdr]

New version, see first post, and i've also added on it a part about the multi-threading.

[jpsdr]

There is issue with the Intel versions.

I'll update the release files on github, removing the Intel versions, and keeping only VS version, and adding an VS AVX2 version. Wait at least 24h to check/re-download the files.

[jpsdr]

Trashed Intel version, file updated, redownload it.

[ryrynz]

What's the issue? Always been stable for me.

[jpsdr]

The Intel compiler messed the code in the resampler part, meaning it could also have messed up something somewhere else... maybe... maybe not. Didn't noticed anything in on the other filters, but i rather play safety.
Issue is described from here (https://forum.doom9.org/showthread.php?p=1838128#post1838128).

[jpsdr]

New version, see first post, updated also the Multi-treading text part.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[StainlessS]

Thanks jpsdr, muchly appreciated. :)

[jpsdr]

If you're using both aWarp and NNEDI, i strongly suggest you take the plugin package (unless it's already what you're doing).

[real.finder]

seems there are bug with 16bit, it's either give corrupt output or crash

ColorBars(width=640, height=480, pixel_type="yv12")

convertbits(16)
aWarpSharp2()
convertbits(8)

also maybe it's time to add float clip (https://forum.doom9.org/showthread.php?t=176796) support :)

[jpsdr]

Float... Euh... No...
I'll take a look, soon, but not right now... (Strange, i'm sure i've tested 16 bits... :sly:).

Edit
Reproduced, but very odd... Revert back to an old avs+ version, as i've tested 16 bits (or i thought), but reproduced also.
Tested with threads=1 (just in case), still garbage but no crash.
Odd, that if i open the script in VDub an move the slide only forward, no garbage seen, but as soon as i move the slide backward, it creates garbage. Seems to occur with YV12 and YV16 but not YV24.
I don't understand why i didn't noticed when i've tested...
Anyway, i'll investigate, but later, thanks for report.

[real.finder]

Float... Euh... No...
I'll take a look, soon, but not right now... (Strange, i'm sure i've tested 16 bits... :sly:).

Edit
Reproduced, but very odd... Revert back to an old avs+ version, as i've tested 16 bits (or i thought), but reproduced also.
Tested with threads=1 (just in case), still garbage but no crash.
Odd, that if i open the script in VDub an move the slide only forward, no garbage seen, but as soon as i move the slide backward, it creates garbage. Seems to occur with YV12 and YV16 but not YV24.
I don't understand why i didn't noticed when i've tested...
Anyway, i'll investigate, but later, thanks for report.

maybe it's asm bug, that why opt parameter is useful in these cases

maybe it's good to add it as the VS dubhater awarpsharp2 did :)

[StainlessS]

RF bugged script no problem in MSVC XP_SSE2 version dll.


EDIT: Also no prob in MSVC Release_W7 [I dont have AVX]

[jpsdr]

maybe it's asm bug, that why opt parameter is useful in these cases

yep... :(


maybe it's good to add it as the VS dubhater awarpsharp2 did :)
yep... again :(

BTW, thanks StainlessS, at least it narrows for me where to search, it means it's probably in asm AVX or AVX2.
The other step will be to figure out between Blur, Warp or Sobel which one produce it.
But not now...:p

[jpsdr]

It seems the issue is in the aSobel, investigation continue (slowly)... :D

Edit
real.finder out of curiosity, which version did you use (Intel, MSVC) ?

[real.finder]

It seems the issue is in the aSobel, investigation continue (slowly)... :D

Edit
real.finder out of curiosity, which version did you use (Intel, MSVC) ?

I use MSVC since Intel not always faster even in Intel CPU

[jpsdr]

There is also issue on aSobel with 8 bits, the simple script

ColorBars(width=640, height=480, pixel_type="yv12")
aSobel(threads=1)

crash on Windows7 x86 with avs 2.6 with VDub x86.
But the same under Windows7 x64 with avs+ 3.5.1 opened with VDubx64 doesn't crash, but exhibit sometimes corrupted output. But opended with VDub x86, crash.
I'll investigate more... later.
But what realy surprise me it's that i didn't see it... The most simple basic test crash ! How can i have missed that ?!

[jpsdr]

I think i understand why i didn't notice it, it seems a WTF situation !!! :sly:
real.finder, can you tell me exactly what build version are you using ?
And are you using aWarpsharpMT.dll or plugins_JPSDR.dll ?

[jpsdr]

Ok, it's realy a WTF messed up situation.

On a Windows7 x86 with avs 2.6.1 on CPU without AVX (the only i can test right now).
With either aWarpsharpMT.dll or plugins_JPSDR.dll.
Intel W7 SSE4.2 => Crash.
Release_W7 (wich is with SSE2 build option) => Ok.
A VS2010 build => Ok.

So, either there is an issue with the code, but miraculously, it works perfectly fine on 2 builds on different compilers versions, either some compiler options (or compiler at all) screw things !!!
For now, i guess more the second one.

As soon as i can, i'll try a clang build, and check the reported messages to see if i have any hints (and check also if a clang build works).

[real.finder]

I think i understand why i didn't notice it, it seems a WTF situation !!! :sly:
real.finder, can you tell me exactly what build version are you using ?
And are you using aWarpsharpMT.dll or plugins_JPSDR.dll ?

aWarpsharpMT.dll winxp in x86

and aWarpsharpMT.dll win7 in x64

[jpsdr]

Ok, thanks. I'll continue to test and investigate, but it's realy odd, for now, i'm lost... :(

[jpsdr]

Ok... Waisting hours to investigate a false issue, because i forgot that for aBlur and aSobel the default value chroma is "don't care" !
So, garbage output can be expected ! :sly:

But, i've found the issue for aWarp. It was indeed specific to 16 bit and AVX path code, but it wasn't in the ASM code. There was in fact several issues, but all on the same place.

I thought the Intel compiler issues was a long decades past storie, but obvsiously the Intel compiler is still able to produce broken code, so, no Intel release anymore. I'll try clang releases for next deliveries.

[jpsdr]

New version, see first post.

[real.finder]

New version, see first post.

thanks :goodpost:

[real.finder]

since aWarpsharp2 has cplace parameter as

cplace: "MPEG1" (default) or "MPEG2". Indicates the chroma sample location
for chroma modes 4 and 6 in YV12 and YV16 colorspaces

it will be nice if it can use frame properties for default case instead of "MPEG1" :) and I think YV16 (422) always "MPEG2"

also maybe with adding opt parameter and float clip (https://forum.doom9.org/showthread.php?t=176796) support to make it more nice :)

[FranceBB]

+1 for floating point support. It would be nice to experiment a bit with 32bit float on plugin_JPSDR.dll :D

[jpsdr]

Sorry, but float support is not in my project. Tooooooooo much work for a plugin i'm not even personnaly using, just made hopping it could help the evangelion project, which unfortunately didn't even finish.

[real.finder]

Sorry, but float support is not in my project. Tooooooooo much work for a plugin i'm not even personnaly using, just made hopping it could help the evangelion project, which unfortunately didn't even finish.

it was helped but seems pwnsweet didn't finish the other things, anyway, if he need more help he is free to PM me here since many things in avs+ get better since then

pinterf also did/doing much work for a plugins/things that he don't use, same for Asd-g and maybe others, also even if I think working on scripts functions is easier than the dll plugins ones I also did work for scripts I don't personally use, so it's not bad thing rather good

anyway, thank you for everything you did, Of course we can't force you to do more things :)

[FranceBB]

Tooooooooo much work for a plugin i'm not even personnaly using

Got it. Understandable xD
Aside from awarpsharp which I rarely use too, I was kinda curious to see the benefit of 32bit float on tonemapping, you know.
Still, 16bit is probably just fine. :)

(slightly OT: I haven't seen you around in the last few months, I'm glad to see you're fine, given... you know... that there's a global pandemic. )

[jpsdr]

Yes, I'm fine, thanks.
I'm not doing any dev for now, just keep the strict bare minimal (critical bug fixes or like a new x264 tmod build i have to do... ;)).
I'm for now foccussing my spare time on totaly different things (an RPG campaign i want to master, a lot of comics, manga, novels i have to read, personnal video projects/fansubs).


Aside from awarpsharp which I rarely use too, I was kinda curious to see the benefit of 32bit float on tonemapping, you know.

Euh.... There is only the "standard" tonemapping functions in my HDRTools, but they accept float input. Or, are we talking of something else ?

[FranceBB]

Yes, I'm fine, thanks.
I'm not doing any dev for now, just keep the strict bare minimal (critical bug fixes or like a new x264 tmod build i have to do... ;)).
I'm for now foccussing my spare time on totaly different things (an RPG campaign i want to master, a lot of comics, manga, novels i have to read, personnal video projects/fansubs).

Yeah, everybody deserves a bit of spare time.
By the way, although some people found lockdown frustrating, many other used that time to finally do the things they have been planning to do for a while but that for a reason or another didn't have time to do. I was one of those people... until football came back and I had to get back to work on the field everyday.
Speaking of which, I still have some things I wanna do and one of them is to finish one of the series I began fansubbing years ago (long before I got my first job)... but man, every time I open Aegisub and I have to typeset I'm like "hell no" and I stop for another 6 months hahahahaha
Anyway, I'm glad you're ok. :)

[pwnsweet]

Sorry, but float support is not in my project. Tooooooooo much work for a plugin i'm not even personnaly using, just made hopping it could help the evangelion project, which unfortunately didn't even finish.

Evangelion 16 project is still ongoing! Big setback because computer died and some files needed to be recreated from the beginning. Now I'm using ESRGAN for upscaling and maximum quality so it will be even better than before. This takes time to learn how create training set and then tweak parameters for the model.

[real.finder]

I did try update http://avisynth.nl/index.php/WarpDeRing_source to HBD but I find another bug in 16bit


ColorBars(width=640, height=480, pixel_type="yv12")
convertbits(16)
awarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2),asobel(thresh=255).ablur(),depth=6)

https://i.postimg.cc/SXhB3mSx/New-File-4-012184.png (https://postimg.cc/SXhB3mSx)

[pinterf]

I did try update http://avisynth.nl/index.php/WarpDeRing_source to HBD but I find another bug in 16bit


ColorBars(width=640, height=480, pixel_type="yv12")
convertbits(16)
awarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2),asobel(thresh=255).ablur(),depth=6)

https://i.postimg.cc/SXhB3mSx/New-File-4-012184.png (https://postimg.cc/SXhB3mSx)
Do you have avx2? If so, try disabling it with SetMaxCPU("SSE4.1")

[real.finder]

Do you have avx2? If so, try disabling it with SetMaxCPU("SSE4.1")

yes, but even SetMaxCPU("SSE2") don't fix it