Updated aWarpSharp version, with some new features

[jpsdr]

I've updated the aWarpSharp plugin, adding :
- New parameters for better tuning.
- Internal multi-threading.

This version works on all avs+ version, and on all 2.6.x versions.

Current version : 2.1.12

Sources are here (https://github.com/jpsdr/aWarpSharpMT).
Binaries are here (https://github.com/jpsdr/aWarpSharpMT/releases/download/2.1.12/aWarpSharpMT_v2_1_12.7z).

Version history
2.1.12 : Minor changes (more code refactory).
2.1.9 : Update to new AVS+ headers and fix awarp colorspace issue.
2.1.8 : Update to new AVS+ headers.
2.1.7 : Update on threadpool, no user limit (except memory).
2.1.6 : Fix on threadpool, using prefetch parameter created hang. Add negative prefetch for triming, read Multithreading.txt or Multithreading chapter here.
2.1.5 : Fix aSobel crash, fix on threadpool.
2.1.4 : Fix aWarp4 issues, update to new avisynth headers.
2.1.3 : Fix aWarp issue on 16 bits, update to new avisynth headers.
2.1.2 : Minor code change after threadpool update, fix in the number of threads.
2.1.0 : Update of the threadpool, add ThreadLevel parameter.
2.0.1 : Optimized CPU placement if SetAffinity=true for prefetch>1, SetAffinity back to default false.
2.0.0 : Add 16 bits support (thanks for pinterf's help), filter is MT_NICE.
1.0.4 : Fix aWarp/aWarp4 default settings.
1.0.3 : Fix (for good... :sly:) bug in aBlur x64 asm.
1.0.2 : Fix bug in aBlur x64 asm code, aWarp4 don't copy planes on some chroma modes (doc updated).
1.0.1 : Fix depthVC default value, fix depthC on aWarpSharp (thanks real.finder).
1.0.0 : First release.

==================================================================

The functions inside this plugin are :

aWarpSharp2(int thresh,int blur,int type,int depth,int chroma,int depthC,string "cplace",
int blurV,int depthV,int depthVC,int blurC,int blurVC,int threshC,
int threads,bool logicalCores,bool MaxPhysCore,bool SetAffinity,bool sleep,int prefetch,int ThreadLevel)

aSobel(int thresh,int chroma,int threshC,
int threads,bool logicalCores,bool MaxPhysCore,bool SetAffinity,bool sleep,int prefetch,int ThreadLevel)

aBlur(int blur,int type,int chroma,int blurV,int blurC,int blurVC,
int threads,bool logicalCores,bool MaxPhysCore,bool SetAffinity,bool sleep,int prefetch,int ThreadLevel)

aWarp(edge_mask_clip,int depth,int chroma,int depthC,string "cplace",int depthV,int depthVC,
int threads,bool logicalCores,bool MaxPhysCore,bool SetAffinity,bool sleep,int prefetch,int ThreadLevel)

aWarp4(edge_mask_clip,int depth,int chroma,int depthC,string "cplace",int depthV,int depthVC,
int threads,bool logicalCores,bool MaxPhysCore,bool SetAffinity,bool sleep,int prefetch,int ThreadLevel)


Parameters are exactly the same than the orignal aWarpSharp functions, and in the same order, so they are totaly
backward compatible.

Check the TXT file for a more complete description.
The new parameters are added at the end of all the parameters. They have been added to allow more tuning for processing, allowing separate values for horizontal and vertical, and different value for Y/C when not avaible originaly. The parameters are the following:

threshC: default thresh. Set the limit for edge detection on chroma planes.

blurV: Default blur. If blurV is different from blur, horizontal process will be
done only on blur passes, and vertical process will be done only on blurV passes.

blurC : Number of blur passes for the chroma, default (blur+1)/2 passes.

blurVC: Default blurC. If blurVC is different from blurC, horizontal process will be
done only on blurC passes, and vertical process will be done only on blurVC passes.

depthV: default depth. depth set the warping strength for horizontal, and depthV
set de warping strenght for vertical.

depthVC: default depthC. depthC set the warping strength for horizontal, and depthVC
set de warping strenght for vertical.

threads -

Controls how many threads will be used for processing. If set to 0, threads will
be set equal to the number of detected logical or physical cores,according logicalCores parameter.

Default: 0 (int)

logicalCores -

If threads is set to 0, it will specify if the number of threads will be the number
of logical CPU (true) or the number of physical cores (false). If your processor doesn't
have hyper-threading or threads<>0, this parameter has no effect.

Default: true (bool)

MaxPhysCore -

If true, the threads repartition will use the maximum of physical cores possible. If your
processor doesn't have hyper-threading or the SetAffinity parameter is set to false,
this parameter has no effect.

Default: true (bool)

SetAffinity -

If this parameter is set to true, the pool of threads will set each thread to a specific core,
according MaxPhysCore parameter. If set to false, it's leaved to the OS.

Default: true (bool)

sleep -
If this parameter is set to true, once the filter has finished one frame, the threads of the
threadpool will be suspended (instead of still running but waiting an event), and resume when
the next frame will be processed. If set to false, the threads of the threadpool are always
running and waiting for a start event even between frames.

Default: false (bool)

prefetch -
This parameter will allow to create more than one threadpool, to avoid mutual resources acces
lock/wait if "prefetch" is used in the avs script.
0 : Will set automaticaly to the prefetch value use in the script. Well... that's what i wanted
to do, but for now it's not possible for me to get this information when i need it, so, for
now, 0 will result in 1. For now, if you're using "prefetch" in your script, put the same
value on this parameter.

ThreadLevel -
This parameter will set the priority level of the threads created for the processing (internal
multithreading). No effect if threads=1.
1 : Idle level.
2 : Lowest level.
3 : Below level.
4 : Normal level.
5 : Above level.
6 : Highest level.
7 : Time critical level (WARNING !!! use this level at your own risk)

Default : 6

The logicalCores, MaxPhysCore, SetAffinity and sleep are parameters to specify how the pool of thread will be created and handled, allowing if necessary each people to tune according his configuration.

==================================================================

Multi-threading information

CPU example case : 4 cores with hyper-threading.

If you leave all the multi-threading parameters to their default value, it's set to be "optimal" when you're not using prefetch or if you are under standard avisynth, all the logical CPU will be used.
If you put SetAffinity to true it will allocate the threads on the CPU contiguously. Physical CPU 1 will have threads (0,1), ... physical CPU 4 will have threads (6,7), allowing optimal cache use. Make test to see what's best for you.

Now, if you are using prefetch on your script, things are different !
If you're using it with the max number of CPUs (8 in our exemple case), you still can make tests, but i would strongly advise to disable the internal multi-threading by using threads=1. In this case, there is no threadpool created, and all the other multi-threading related filter parameters have no effect, even prefetch.
If you're using prefetch on your script, with less than your CPU number, you may want to try to mix the external and internal mutli-threading, setting the internal multi-threading to a lower number of threads, and setting the prefetch parameter of the filter. This parameter will set the number of internal threadpool created, the best is to match the prefetch script value. If you don't set it (leave it to 1) or set a lower value than prefetch on your script, you'll have several instances (or GetFrame) created, but they'll not be running efficiently, because each instance (or GetFrame) will spend time waiting for a threadpool to be avaible, if not enough were created.
Unfortunately, as things are now, i have no way of knowing the prefetch value used in the avisynth script at the time i need the information, this is why you have to use the prefetch parameter in the filter.
In our CPU exemple case, you can have things like :

filter(...,threads=1)
prefetch(8)

or

filter(...,threads=2,prefetch=4)
prefetch(4)

or

filter(...,threads=4,prefetch=2)
prefetch(2)

or even

filter(...,threads=3,prefetch=4)
prefetch(4)

if you want to boost and go a little over your total CPU number.

Also, if your prefetch is not higher than your number of physical cores, you can try to put SetAffinity to true, but in that case, you have to set MaxPhysCore to false. The threads of each pool will be set on CPUs by steps.
For exemple, in our case :

filter(...,threads=2,prefetch=4,SetAffinity=true,MaxPhysCore=false)
prefetch(4)

Will create 4 pool of 2 threads, with the following :
pool[0] : threads(0 -> 1) on CPU 1.
pool[1] : threads(0 -> 1) on CPU 2.
pool[2] : threads(0 -> 1) on CPU 3.
pool[3] : threads(0 -> 1) on CPU 4.

filter(...,threads=4,prefetch=2,SetAffinity=true,MaxPhysCore=false)
prefetch(2)
Will create 2 pool of 4 threads, with the following :
pool[0] : threads(0 -> 1) on CPU 1.
pool[0] : threads(2 -> 3) on CPU 2.
pool[1] : threads(0 -> 1) on CPU 3.
pool[1] : threads(2 -> 3) on CPU 4.

Negative prefetch
The possibility to put negative prefecth to tune the prefetch parameter to optimal value has been added. The filter will throw an error if the number is not high enough to avoid waiting when requesting internal threadpool. For this to work properly, you have to put negative prefetch on ALL the filters of your script, and also ALL instances of the same filter.

Exemple :
filter(...,threads=2,prefetch=-2)
prefetch(2)
You'll see an error.

But with :
filter(...,threads=2,prefetch=-3)
prefetch(2)

You'll see no error, so the optimal is :
filter(...,threads=2,prefetch=3)
prefetch(2)

Once you've tune, put back a positive value.

[real.finder]

finally :thanks:

now this filter is very useful, even ablur can be used alone for Dot Crawl Removal, I did used in DDComb

and if you can added the others blur type (https://forum.doom9.org/showthread.php?p=1820161#post1820161) that was in original awarpsharp by Marc FD it will be more useful, aside form HBD in avs+

[jpsdr]

I don't know what they are, i need first the original code source. Where can i find it ?

[real.finder]

I don't know what they are, i need first the original code source. Where can i find it ?

you can ask prunedtree in IRC (rizon server) :rolleyes: same person that you asked about Debilinear

[jpsdr]

Yes, and you've already told me this... i just don't remember on what channel i can found him...:p

[real.finder]

Yes, and you've already told me this... i just don't remember on what channel i can found him...:p

in #darkhold and maybe others

[jpsdr]

Yes... Right, now i remember indeed... I'll try to get in touch with him.

[Motenai Yoda]

can you fix the awarp4 chroma bug?

[real.finder]

can you fix the awarp4 chroma bug?

what bug?

[ryrynz]

Does this now supersede Pinterf's version? ..Nevermind, readme clarified. :)

"Addition by pinterf on 20160623:
- AviSynth 2.6 interface, Avisynth+ header
- working x64 version
- minor cleanup"

[jpsdr]

now this filter is very useful, even ablur can be used alone for Dot Crawl Removal, I did used in DDComb


Isn't a threshold median filter more appropriate for this ? (If "Dot Crawl" is what i think, sometimes i'm not sure of the exact english technical version).

[real.finder]

Isn't a threshold median filter more appropriate for this ? (If "Dot Crawl" is what i think, sometimes i'm not sure of the exact english technical version).

median not work well with Dot Crawl (https://en.wikipedia.org/wiki/Dot_crawl) and it's slower

[jpsdr]

Ok, it wasn't what i thought, "dot" mislead me, so no surprise median is not adapted. Hard to remove, as it should have been done properly "before" either when demodulating chroma, or even more when creating the CVBS signal... :(

[Motenai Yoda]

what bug?

chroma values 2 5 6 are bugged as it doesn't scale back chroma/luma channels
maybe it can take them from last

[real.finder]

chroma values 2 5 6 are bugged as it doesn't scale back chroma/luma channels
maybe it can take them from last

yes, there are bug in chroma=6 or 5 or 2


ColorBars(pixel_type="yv12")
aWarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2), aSobel().aBlur(), depth=2,chroma=6)

[jpsdr]

Is it a bug i've introduced or was it also on the original ?

[jpsdr]

About original blur mode, i don't realy see the point as they are very similar from what i've understood taking a quick look. The hq mode is just the same of the R2, with just a little more accurate result, less rounding propagate errors. I'll explain. The actual version (both R2 and R6) uses pavgb function, wich compute the average of 8 bits data with the following formula : pavgb(A,B) = (A+B+1)>>1.
If you want to compute (A+2*B+C)/4 you can do the following :
A=pavgb(A,C)
result=pavgb(A,B)
But, you cumulate 2 successive pavgb and so rounding errors.
You can also do the followig :
Expand A,B,C on 16 bits, and compute (on 16bits) result=(A+2*B+C+2)>>2 and convert back to 8 bits.
This way, you have a little more accurate result.
Honestly don't see real interest of puting back the old hq blur mode, and as for the others, they are already implemented with the actual R2 and R6.

[real.finder]

Is it a bug i've introduced or was it also on the original ?

in original awarpsharp2 by SEt

About original blur mode, i don't realy see the point as they are very similar from what i've understood taking a quick look. The hq mode is just the same of the R2, with just a little more accurate result, less rounding propagate errors. I'll explain. The actual version (both R2 and R6) uses pavgb function, wich compute the average of 8 bits data with the following formula : pavgb(A,B) = (A+B+1)>>1.
If you want to compute (A+2*B+C)/4 you can do the following :
A=pavgb(A,C)
result=pavgb(A,B)
But, you cumulate 2 successive pavgb and so rounding errors.
You can also do the followig :
Expand A,B,C on 16 bits, and compute (on 16bits) result=(A+2*B+C+2)>>2 and convert back to 8 bits.
This way, you have a little more accurate result.
Honestly don't see real interest of puting back the old hq blur mode, and as for the others, they are already implemented with the actual R2 and R6.

there are big difference and superiority in original awarpsharp versus the new awarpsharp2

see here (https://forum.doom9.org/showthread.php?p=1687315#post1687315) and here (https://forum.doom9.org/showthread.php?p=1819947#post1819947)

and the hq is not only one, there are others (fast 1-pass is the default)

[jpsdr]

When i look at the code, the "fast 1-pass" is the actuel R6 with one pass...

[real.finder]

When i look at the code, the "fast 1-pass" is the actuel R6 with one pass...

why there are some notable difference then? bug in compatibility mapping for aWarpSharp parameters (http://avisynth.nl/index.php/AWarpsharp2/aWarpSharp)? and there are already one here (https://github.com/pinterf/aWarpSharp/issues/1)

[ryrynz]

Did anyone manage to get in touch with MarcFD for his original code if it's that much better? real.finder can you post screenshots for comparison?

[real.finder]

here we are

no filter
https://s18.postimg.cc/db14azh09/image.png

awarpsharp in awarpsharp2
https://s18.postimg.cc/bvzjme5o9/awarpsharp_in_awarpsharp2.png

awarpsharp in old awarpsharp
https://s18.postimg.cc/ai7wqjgjd/awarpsharp_in_old_awarpsharp.png

and according to SEt it should be same https://forum.doom9.org/showthread.php?p=1687695#post1687695

[ryrynz]

Thanks, I'm gonna have to go with awarp2 in this example, I can see the original awarp is a big sharper and thinner in some areas but awarp2 is sharper in some areas also.
The original awarp blows out the reds, Misato's shirt is worse (most noticeable around the arms) awarp2 is almost identical in appearance to the original frame as it should be.. you said chroma is better but that's simply not the case here.

[real.finder]

I'm gonna have to go with awarp2 in this example, I can see the original awarp is a big sharper and thinner in some areas but awarp2 is sharper in some areas also.
The original awarp blows out the reds, Misato's shirt is worse, awarp2 is almost identical in appearance to the original frame as it should be.. you said chroma is better but that's simply not the case here.

the original awarp is more clean and accurate, it not blows out the reds, it's just did the job with warp chroma to luma (Default behavior)

and aside from all that, awarpsharp2 has awarpsharp() for compatibility with old awarpsharp, it should be same (or at least with unnoticeable difference) regardless of whether they are better or worse

[ryrynz]

How is it accurate when it differs so much from the original frame? The reds are brighter than in the original frame and they shouldn't be. There's no win here for the original awarp.

[real.finder]

How is it accurate when it differs so much from the original frame? The reds are brighter than in the original frame and they shouldn't be. There's no win here for the original awarp.

not something unexpected here cuz it warp chroma with luma as I said

aside from chroma, you can see how it accurate without artifacts in the yellow text for example

[ryrynz]

The warping has stretched the very left side of the text but in other areas in the overlay it's more like the original frame, plus the overlay's appearance doesn't appear to match the effect on the lines in the actual
frame which is the more important part to be analyzing. I guess like anything awarpsharp2 could use a tweak or two but I'm still not seeing the original being more pleasing to me.

jpsdr, are you planning on tweaking this at all?

[real.finder]

so here another one that prove that old awarpsharp is better

https://s18.postimg.cc/rucuq99uh/warp2.png

https://s18.postimg.cc/u075k8xq1/old_warp.png (ignore the left line bug, it's know things since age and one reason that awarpsharp2 existing)

ColorBars(pixel_type="yv12")
info
aWarpSharp_aWarpSharp

[ryrynz]

Surely changing the depth parameter in awarp2 could provide a similar output?

[real.finder]

Surely changing the depth parameter in awarp2 could provide a similar output?

don't think so, the warp depth is same in both, I highly suspect the blur, maybe something else like aSobel but not the warp depth

[real.finder]

well, the chorma seems to have some bug in awarpsharp() in awarpsharp2, it's like using depthc=0, it should be depthc=depth/2 for 420, so:-

aWarp(aSobel(128).aBlur(2,0), depth=16,chroma=4, depthc=8)

this is the most close to original awarpsharp

but this made me learn something new, and it's I can use depthc=0 for chroma guide by luma :) I was think that depth=0 result will be always like unprocessed clip

edit1: well, no, it's not the same in Pinterf and older ver., as they seems to unwarp chroma if it guide by luma and depthc=0, awarpsharpmt is just use depth/2 for the depthVC (8 in this case)
SEt ver. (2012) work fine with the awarpshrp() in the awarpsharp2 dll, so the bug happened in 2015 one

edit2: also this lead us to another bug in the awarpsharpmt, and it's that depthVC default is not depthC as it should

aside form all thing, there are still there are some difference in both luma and chroma... not big but it's there

[ryrynz]

jpsdr, I can't for the life of me get awarp4 to work. If I just call awarpsharp() by itself it works fine.
No problems with Pinterf's version. Tried all versions, just get it crashing, plugin pack also crashes.

Ryzen on W10CU.

input4x = last.Spline64Resize(width*4, height*4, src_left=0.375, src_top=0.375)
edgemask = last.aSobel.ablur
aWarp4(input4x,edgemask,depth=2)

[jpsdr]

Did anyone manage to get in touch with MarcFD for his original code if it's that much better?
I've contacted him, and asked for the code, as i was asked to add the others blur modes.
I thought he would provide me the whole code, but he gave me only the blur part code. I've not asked him more, assuming he probably didn't want to give me the whole code...

[ryrynz]

Got nothing to lose, you might as well ask.

[jpsdr]

edit1: well, no, it's not the same in Pinterf and older ver., as they seems to unwarp chroma if it guide by luma and depthc=0, awarpsharpmt is just use depth/2 for the depthVC (8 in this case)
SEt ver. (2012) work fine with the awarpshrp() in the awarpsharp2 dll, so the bug happened in 2015 one

edit2: also this lead us to another bug in the awarpsharpmt, and it's that depthVC default is not depthC as it should

Oups... I thought i've fixed it, but depthCV is depthV as default instead of depth indeed...:( I'll fix it in a next release.
About edit1 : Do you meen the SEt version awarpsharp() is realy identical to original, but the versions afterward not anymore ?

[jpsdr]

jpsdr, I can't for the life of me get awarp4 to work

This code works for me. Does it for you ?

SetMemoryMax(64)
a=AVISource("Test.avi",False,"YV12").SetPlanarLegacyAlignment(True)
d=aSobel(a)
aWarp4(a.Spline36Resize(4*a.width,4*a.height),d)


Edit
Just tested this :

SetMemoryMax(64)
AVISource("Test.avi",False,"YV12").SetPlanarLegacyAlignment(True)
input4x = last.Spline64Resize(width*4, height*4, src_left=0.375, src_top=0.375)
edgemask = last.aSobel.ablur
aWarp4(input4x,edgemask,depth=2)

It works for me.

[ryrynz]

Tried the above but using ffdshow_source() and it crashes, it doesn't matter what MT mode I try whether I specify setmemorymax or not.
Tried W7 and XP releases for compatibility, I have the latest runtimes installed.

[jpsdr]

Ah... As i never use MT mode, i never thought of testing them... But strange, filters should report themselves as MT_MULTI_INSTANCE.
But if you use external multi-threading, in that case, maybe you should try adding threads=1 in the parameters.

[ryrynz]

Tried threads=1 on asobel, ablur and awarp4 with no success along with setting prefetch value accordingly.

[jpsdr]

Sorry... For now, no idea in that case. If you use AVISource and not ffdshow_source, does it crash ? Unfortunately, even if this is the issue, i would have no idea of the why...

[real.finder]

Oups... I thought i've fixed it, but depthCV is depthV as default instead of depth indeed...:( I'll fix it in a next release.
About edit1 : Do you meen the SEt version awarpsharp() is realy identical to original, but the versions afterward not anymore ?

SEt versions give output like aWarp(aSobel(128).aBlur(2,0), depth=16,chroma=4, depthc=8) the difference to versions afterward in chroma only (in 2015 when depthc added, in awarpsharp() seems it's always use depthc=0)

the luma (and chroma but luma is noted easly) small difference in all awarpsharp2 versions come from something else (blur maybe as I suspect)

[jpsdr]

If i understand properly, for now, what's trouble you more, is some chroma issue present in mine and pinterf version, but not in aWarpSharp_20120328 SEt version. Is that correct ?

[real.finder]

If i understand properly, for now, what's trouble you more, is some chroma issue present in mine and pinterf version, but not in aWarpSharp_20120328 SEt version. Is that correct ?

and in 2015 by cretindesalpes too

yes, it trouble more, and it should very easy to fix

[jpsdr]

Ok, at least it means :
- It's not me who introduced it.
- Checking the actual code vs the aWarpSharp_20120328 SEt version code, i should be able to find something.

[TheFluff]

you know, there is a vs port of this, with all the nice things already done, like all the asm rewritten to templated intrinsics, and it also supports high bitdepth
the entire thing is less lines of code than your x64 .asm file
so, to ask the question that needs to be asked, why on earth did you choose to base your version on the old garbage

[jpsdr]

Because... ;)

Maybe this will be done on a second time step, but for now, it's easier for me with this code to compare and check differences when i'm asked to "look like more the original version".

[jpsdr]

Tried all versions, just get it crashing, plugin pack also crashes.


Forgot to ask, just in case : On both x86 and x64 version ?

[edcrfv94]

so here another one that prove that old awarpsharp is better

https://s18.postimg.org/rucuq99uh/warp2.png

https://s18.postimg.org/u075k8xq1/old_warp.png (ignore the left line bug, it's know things since age and one reason that awarpsharp2 existing)

ColorBars(pixel_type="yv12")
info
aWarpSharp_aWarpSharp

Maybe you can try warpsharp is very good for animation.

[ryrynz]

Forgot to ask, just in case : On both x86 and x64 version ?

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 ^.^

[jpsdr]

Haven't tried x86 version, if you really want me to test it I guess I could
If you can test it, i would appreciate, to be sure. If threads=1 is not working, it's not the multi-threading, because in that case it's absolutely not used, that's why i've also asked you to make this test.

[real.finder]

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]

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]

Maybe you can try warpsharp is very good for animation.

It sounds so 2006

btw awarpsharp/awarpsharp2 thresh=1/255 ≈ warpsharp

[ryrynz]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

New version, see first post.

[jpsdr]

Is the chroma issue of post #22 fixed with this new version ?

[real.finder]

Is the chroma issue of post #22 fixed with this new version ?

yes, thank you

[jpsdr]

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]

I have not tried it but also thank you very much!

[real.finder]

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]

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]

I've spent some more time on this.. the x86 version is okay it's just the x64 that crashes.

[jpsdr]

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]

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]

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]

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]

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]

New version, see first post.

[ryrynz]

Still crashing when I use type=1 on 1.0.2, tested with W7 build.

[jpsdr]

Ah... I think i've found out what i've missed grrr...:sly:

[jpsdr]

New version, see first post.

[ryrynz]

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]

Good, but... Differences were not realy expected....

[real.finder]

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]

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]

Ah... Yes, i see... I've forgotten to adapt the default setting value.

[real.finder]

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]

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]

NULL is 0... Meaning you can't set 0. I'm not Ok with it.
HBD... Another time.

[real.finder]

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]

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]

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]

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]

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]

New version, see first post.

[ryrynz]

Working as expected, I can now upgrade to this, thanks.

[jpsdr]

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]

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]

Ok, thanks.

[jpsdr]

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.

[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

[jpsdr]

I don't know when i'll be able to take a better look, but there is 2 issues it seems.
One with multi-threading and 16 bits, as if you put "threads=1" you'll get the bottom of the bars, and with "threads=2" they're gone...
Another with 16bits and YV12.

[real.finder]

I don't know when i'll be able to take a better look, but there is 2 issues it seems.
One with multi-threading and 16 bits, as if you put "threads=1" you'll get the bottom of the bars, and with "threads=2" they're gone...
Another with 16bits and YV12.

yes, I note that

also I did try SetMaxCPU("none") to use the c code only but it say it need sse2 cpu now, that mean you didn't add the c code from VS port? maybe it need to add opt parameter like the one in nnedi3

[jpsdr]

Didn't take any code from VS port.

[real.finder]

I got some strange case

using dvd VOB and nnedi3_rpow2(rfactor=2) with awarp4
LWLibavVideoSource("VTS_01_4.VOB")
awarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2),asobel(thresh=255).ablur(),depth=6)

https://i.postimg.cc/44cpFBzG/Untitled.png (https://postimages.org/)
ffms2 show same problem, but DirectShowSource work! replace nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2) with Spline36Resize(width*4, height*4, 0.375, 0.375) also work!

[jpsdr]

I think i've found the MT issue with aWarp4.
There is C code for the aWarp part, but (i don't remember for now and didn't search) it's possible that in all the aWarp4 chain, there is still some parts without C code. I'll check (i don't know when), to see if the "SSE2 minimal CPU" is still necessary.

For the others check...

Your last issue is with 8 bit data so ?

And out of curisity with :

a=LWLibavVideoSource("VTS_01_4.VOB")
b=nnedi3_rpow2(a,rfactor=2).nnedi3_rpow2(rfactor=2)
c=asobel(a,thresh=255).ablur()
awarp4(b,c,depth=6,threads=[1 or 2])

[real.finder]

For the others check...

Your last issue is with 8 bit data so ?

And out of curisity with :

a=LWLibavVideoSource("VTS_01_4.VOB")
b=nnedi3_rpow2(a,rfactor=2).nnedi3_rpow2(rfactor=2)
c=asobel(a,thresh=255).ablur()
awarp4(b,c,depth=6,threads=[1 or 2])


yes it's 8bit, and this code give same error

in case someone need .vob sample I find this http://download4.dvdloc8.com/trailers/dolbydts/dolbyrain.zip from https://dvdloc8.com/dolbydtsclip.php?clipid=7

[StvG]

I got some strange case

using dvd VOB and nnedi3_rpow2(rfactor=2) with awarp4
LWLibavVideoSource("VTS_01_4.VOB")
awarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2),asobel(thresh=255).ablur(),depth=6)

https://i.postimg.cc/44cpFBzG/Untitled.png (https://postimages.org/)
ffms2 show same problem, but DirectShowSource work! replace nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2) with Spline36Resize(width*4, height*4, 0.375, 0.375) also work!
It seems awarp4 doesn't accept colorspace i420 (returned by ffms2/lsmash).
Adding something like z_convertformat(pixel_type="yv12") will return yv12 and awarp4 is ok.

[jpsdr]

Euh... What am i missing...????

if (!(vi.IsYUV() && vi.IsPlanar() && vi2.IsYUV() && vi2.IsPlanar()))
{
if (threads>1) poolInterface->DeAllocateAllThreads(true);
env->ThrowError("aWarp4: Planar YUV input is required");
}

[StvG]

Euh... What am i missing...????

if (!(vi.IsYUV() && vi.IsPlanar() && vi2.IsYUV() && vi2.IsPlanar()))
{
if (threads>1) poolInterface->DeAllocateAllThreads(true);
env->ThrowError("aWarp4: Planar YUV input is required");
}

nnedi3_rpow2(a,rfactor=2).nnedi3_rpow2(rfactor=2) returns YV12.
asobel(a,thresh=255).ablur() returns i420. It seems asobel doesn't convert i420 to YV12.
That's why awarp4 is complaining.
This works:a=LWLibavVideoSource(".\dolbyrain\dolbyrain.vob")
b=nnedi3_rpow2(a,rfactor=2).nnedi3_rpow2(rfactor=2)
c=asobel(a,thresh=255).propset("_FieldBased", 0).z_ConvertFormat(pixel_type="yv12").ablur()
awarp4(b,c,depth=6,threads=1)

[jpsdr]

Ok... I've never checked what i420 is exactly...
So, if i understand, from avisynth filter chain data access point of view, YV12 or i420 are the same thing. When i access data and get width, height, pointers or other picture stuff i don't see the difference (and maybe there is not within the avs filter chain), but the "pixel_type" is not the same, and maybe the format storage data outside avs is also not the same.
Inside avs, they are the same, but not outside so...

[real.finder]

nnedi3_rpow2(a,rfactor=2).nnedi3_rpow2(rfactor=2) returns YV12.
asobel(a,thresh=255).ablur() returns i420. It seems asobel doesn't convert i420 to YV12.
That's why awarp4 is complaining.
This works:a=LWLibavVideoSource(".\dolbyrain\dolbyrain.vob")
b=nnedi3_rpow2(a,rfactor=2).nnedi3_rpow2(rfactor=2)
c=asobel(a,thresh=255).propset("_FieldBased", 0).z_ConvertFormat(pixel_type="yv12").ablur()
awarp4(b,c,depth=6,threads=1)

so I think nnedi3_rpow2 need to change in this case to not convert i420 to YV12

[jpsdr]

nnedi3_rpow2 splits and process the channels in "Y only", and after recomb using "YtoUV".
You can even if you want write an avs script using "PlaneToY", "nnedi3" and "YtoUV". So when "YtoUV" is used to "regroup" output data when inpiut data was checked Is420(), i think it's automaticaly tagged to YV12.
The nnedi3_rpow2 function is like an avs script.
I don't know if there is a function to put back original vi.pixel_type...

[pinterf]

For Avisynth it is all the same, YV12 or I420.
That's why VideoInfo::IsSameColorspace has a second test for colorspace. Both formats report "true" on IsYV12().
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/interface.cpp#L332

[jpsdr]

So, the proper way is not

if (vi.pixel_type!=vi2.pixel_type)

but

if (!vi.IsSameColorspace(vi2))

That's... logical... I'll change that.
I mean, if there is a IsSameColorspace function, using it is the proper way...;)
:thanks:

[StainlessS]

It is sometimes nice to be able to see the Baked code in the original v2.58 header, to give a clue about what its gonna do.
I'm not suggesting that you use same as v2.58 header, just taking a peek into the black box is sometimes informative.
Here is from v2.58 header

// Test for same colorspace
bool IsSameColorspace(const VideoInfo& vi) const {
if (vi.pixel_type == pixel_type) return TRUE;
if (IsYV12() && vi.IsYV12()) return TRUE;
return FALSE;
}


EDIT: Oops, shoulda posted this too.

bool IsYV12() const { return ((pixel_type & CS_YV12) == CS_YV12)||((pixel_type & CS_I420) == CS_I420); }

[jpsdr]

Begin to investigate.
First thought ChromaPlacement was the issue, but it seems not. cplace parameter has no effet.
Put configuration to be on "C" codepath only (this is why "MPEG2").
This also has issue :

SetMaxCPU("SSE2")
ColorBars(width=640, height=480, pixel_type="yv24").PlaneToY("Y")
convertbits(16)
awarp4(Spline36Resize(640*4,480*4),asobel(thresh=255).ablur(),depth=6,threads=1,cplace="MPEG2")

So it seems that the warp_c function has issue with both 16 bits and SMAGL=2.
What is the unit of depth, how should it be changed (or not) accordinb bit depth...
Still investigatig.

[jpsdr]

New version, see first post.

[real.finder]

awarp4 bug with HBD seems fixed, thanks

[jpsdr]

I'll continue the aWarpsharp (well Sobel) issues here. I'll push something latter, i'll try to think at something a little different.

Edit
I'm working on something different, having a specific code for the first and last pixel, but keeping alignment.

[jpsdr]

I've pushed a possible fix. Pinterf, can you build and test if it's still crashing ?

[pinterf]

I've pushed a possible fix. Pinterf, can you build and test if it's still crashing ?
PM sent with the issue.

[jpsdr]

New version, see first post.

[GMJCZP]

New version, see first post.

Thank you very much.

[jpsdr]

Finaly sooner than expected, new version, see first post.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[real.finder]

I got some strange case

using dvd VOB and nnedi3_rpow2(rfactor=2) with awarp4
LWLibavVideoSource("VTS_01_4.VOB")
awarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2),asobel(thresh=255).ablur(),depth=6)

https://i.postimg.cc/44cpFBzG/Untitled.png (https://postimages.org/)
ffms2 show same problem, but DirectShowSource work! replace nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2) with Spline36Resize(width*4, height*4, 0.375, 0.375) also work!

There are same problem with awarp awarp(z_convertformat(pixel_type="yv12"),asobel(thresh=255).ablur(),depth=6)

As a reminder, awarp4 was fixed back then https://github.com/jpsdr/aWarpSharpMT/commit/3cbb888d6004f748cf4a620092f2990bf0a00cc9

[jpsdr]

Thanks, i've pushed a fix, don't know when i'll do a new build.

[jpsdr]

New version, see first post.

[LigH]

yes, there are bug in chroma=6 or 5 or 2


ColorBars(pixel_type="yv12")
aWarp4(nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2), aSobel().aBlur(), depth=2,chroma=6)


Does anyone remember why you prefer a sequence of nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2) over nnedi3_rpow2(rfactor=4) ?

[DTL]

Compare performance and quality ?

[real.finder]

Does anyone remember why you prefer a sequence of nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2) over nnedi3_rpow2(rfactor=4) ?

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.

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

[LigH]

:thanks:
Exactly what I wanted to know.
Seems I just caught the wrong thread.

[jpsdr]

First post updated, minor changes.

[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.

It's finished and your hard work is not forgotten my friend. I will reach out to you in PM

[rgr]

Awarsharp2 makes objects smaller (letters on keyboard):

org vs awarpsharp2: https://www.diffchecker.com/image-compare/KrM6LOCz/
awarpsharp2 vs lsfplus(preset slow): https://www.diffchecker.com/image-compare/i3Eur9Oj/

[LigH]

AFAIR, that is how the "warping" works; it was designed to improve upscaled cartoons (as one example) by thinning the black outlines, if I'm not completely wrong.

[ChaosKing]

Awarsharp2 makes objects smaller (letters on keyboard):

org vs awarpsharp2: https://www.diffchecker.com/image-compare/KrM6LOCz/
awarpsharp2 vs lsfplus(preset slow): https://www.diffchecker.com/image-compare/i3Eur9Oj/

Not a good filter for real life content. Better suited for animation / cartoons, high values destroys line art!

[Sharc]

It is very useful to sharpen the blurry chroma of VHS.

[tormento]

Unfortunately it shrinks areas too, not lines only, and sometimes it's really evident, above all in line art animes.

That's the only "issue" preventing me from using.

If someone has solutions, they are welcome.

[real.finder]

Awarsharp2 makes objects smaller (letters on keyboard):

org vs awarpsharp2: https://www.diffchecker.com/image-compare/KrM6LOCz/
awarpsharp2 vs lsfplus(preset slow): https://www.diffchecker.com/image-compare/i3Eur9Oj/

AFAIR, that is how the "warping" works; it was designed to improve upscaled cartoons (as one example) by thinning the black outlines, if I'm not completely wrong.

Not a good filter for real life content. Better suited for animation / cartoons, high values destroys line art!

Unfortunately it shrinks areas too, not lines only, and sometimes it's really evident, above all in line art animes.

That's the only "issue" preventing me from using.

If someone has solutions, they are welcome.

that why there are yahr() function, also maybe aWarpSharp4xx can help

It is very useful to sharpen the blurry chroma of VHS.

yes, with chroma=6, also it kinda better to be used as
aWarpSharp2(depth=0,depthv=16,chroma=6) #vertical
aWarpSharp2(thresh=255,depth=16,depthv=0,chroma=6,cplace="MPEG2") #horizontal

[tormento]

that why there are yahr() function, also maybe aWarpSharp4xx can help
AFAIK yahr is a dehalo function.

What do you mean with aWarpSharp4xx? Never saw it anywhere.

[real.finder]

AFAIK yahr is a dehalo function.

What do you mean with aWarpSharp4xx? Never saw it anywhere.

yahr is a dehalo function, yes, but I think it can be used in other things

I mean with my mod of aWarpSharp4xx which can use aWarp4 https://pastebin.com/qLkBTbiF with useaWarp4=true

[tormento]

yahr is a dehalo function, yes, but I think it can be used in other things
Perhaps I am too noob to see its utility in this case.
I mean with my mod of aWarpSharp4xx which can use aWarp4
Thanks, is there any thread around about it?

[hello_hello]

Unfortunately it shrinks areas too, not lines only, and sometimes it's really evident, above all in line art animes.

That's the only "issue" preventing me from using.

If someone has solutions, they are welcome.

A trick I picked up from jagabo at VideoHelp might help you.

Clip = Last
MergeChroma(Clip.aWarpSharp2(Depth=5), Clip.aWarpSharp2(Depth=20))

Or whatever values for Depth might float your boat.
That way you can sharpen the chroma quite a bit without thinning the lines much (or not at all if you prefer). It can help when the chroma doesn't quite meet up with the lines properly.

I invariably precede and/or follow that with FastLineDarkenMod4(thinning=0) anyway, although it can sometimes create a small amount of aliasing, but following it with a mild anti-aliasing filter tends to do the trick. :)

[real.finder]

Perhaps I am too noob to see its utility in this case.

Thanks, is there any thread around about it?

I think SEt was made aWarpSharp2 because he want to use it as "halo removing" as he said https://forum.doom9.org/showthread.php?t=147285

anyway, the point is, yahr() IIRC will still do aWarpSharp2 work but will not "makes objects smaller" or at least the change will not be that big, maybe you can use the idea of yahr() to make a limited aWarpSharp2 sharpening filter

the original of aWarpSharp4xx is https://forum.doom9.se/showthread.php?t=171488 but its not work similar to aWarpSharp2() because Reel.Deel didn't set the default of "type" to "0" as I said in the 2nd post their

A trick I picked up from jagabo at VideoHelp might help you.

Clip = Last
MergeChroma(Clip.aWarpSharp2(Depth=5), Clip.aWarpSharp2(Depth=20))


there are depthC already in the OP of this Thread which is jpsdr update of aWarpSharp2, so aWarpSharp2(Depth=5, depthC=20) should work without using that "trick"

[rgr]

OK, but how and when will aWarpSharp2 be better than lsfplus?

[jpsdr]

There is no bug or issue with aWarpSharp2, it works as it's intended to, so there will be no change. If there is no parameters setting that can satisfy you, it's just that aWarpSharp2 is not the tool you need. if lsplus produces results that suit you more, then use it.