AreaResize

[Aktan]

Hello people! I really liked Chikuzen's AreaResize plugin but I found the performance to be lacking, so I took it upon myself to improve it! I also added gamma corrected downscaling to RGB32/RGB24. Here is the result:

(copy paste of the readme)

AreaResize

AreaResize is an area (average) downscaler plugin for AviSynth. Downscaling in RGB32/RGB24 is also gamma corrected.

Usage

AreaResize(int width, int height)

Supported Colorspaces

- 8-bit Planar (YV24/YV16/YV12/YV411/Y8) (YUY2 is not supported; use YV12)
- 8-bit Interleaved (RGB32/RGB24) (gamma corrected)

Features

- Gamma corrected downscaling to RGB32/RGB24 (gamma scale of 2.2)
- Significant performance increase due to multithreading and optimized code

Credits

Based on Oka Motofumi(https://github.com/chikuzen)'s version of AreaResize(https://github.com/chikuzen/AreaResize).

Download: https://github.com/Aktanusa/AreaResize/releases

Let me know what you think :thanks:.

[real.finder]

thanks for the update

I see it before but didn't test it since I didn't see any compiled dll's

it will be nice if someone did comparisons between AreaResize and others resizes

[Aktan]

I see it before but didn't test it since I didn't see any compiled dll's

Maybe I'm misunderstanding but the download link has the compiled DLLs in AreaResize1.0.zip. Did you mean something else?

[real.finder]

Maybe I'm misunderstanding but the download link has the compiled DLLs in AreaResize1.0.zip. Did you mean something else?

I was mean the Chikuzen one, I see it before in github but without the dll :)

[Aktan]

I was mean the Chikuzen one, I see it before in github but without the dll :)

Ah okay :). I got the original DLL from http://avisynth.nl/index.php/External_filters, I believe.

[pinterf]

Thanks for the update.

I recommend you to use a fresh avisynth header (https://github.com/pinterf/AviSynthPlus/tree/MT/avs_core/include) set and drop the obsolate 2.5x interface support. This header is compatible with classic Avisynth as well and is used by the x86/x64 interface of Avisynth+ (x64 support with old interface versions is sometimes troublesome) . (And a resource file with version info would also welcome)

[Aktan]

Thanks for the update.

I recommend you to use a fresh avisynth header (https://github.com/pinterf/AviSynthPlus/tree/MT/avs_core/include) set and drop the obsolate 2.5x interface support. This header is compatible with classic Avisynth as well and is used by the x86/x64 interface of Avisynth+ (x64 support with old interface versions is sometimes troublesome) . (And a resource file with version info would also welcome)

Oh, I didn't know how backwards compatible the new header is. I was worried I would be limiting people from using the plugin if I used the latest headers. I'll update to the newest headers soon. I'll also attempt to optimize it more. Thanks for the kind words.

[Yanak]

Seeing this reminded me this old (but still true nowadays sadly) article : http://www.ericbrasseur.org/gamma.html?i=2

Using AreaResize on the first picture of the Dalai Lama seems to gives the right result, most resizers i tested before were giving incorrect results as shown in the article, even a lot of gfx dedicated programs still give wrong results nowadays...

If i recall correctly the only avisynth filter i tested giving correct results was ResizeShader(width,height) , but ResizeShader(width,height,Kernel="SSim") used to give some strange outlines on some parts of this picture, not sure if normal or not when using "SSIM", have not tested this since a while tho and will have to get back to resize shader thread and read more on this great tool, either for upscaling or downscaling, haven't updated my scripts since a while and i'm not sure i use the most correct and efficient syntaxes :p.

Thanks for the plugin :)

[Aktan]

Seeing this reminded me this old (but still true nowadays sadly) article : http://www.ericbrasseur.org/gamma.html?i=2

Using AreaResize on the first picture of the Dalai Lama seems to gives the right result, most resizers i tested before were giving incorrect results as shown in the article, even a lot of gfx dedicated programs still give wrong results nowadays...

If i recall correctly the only avisynth filter i tested giving correct results was ResizeShader(width,height) , but ResizeShader(width,height,Kernel="SSim") used to give some strange outlines on some parts of this picture, not sure if normal or not when using "SSIM", have not tested this since a while tho and will have to get back to resize shader thread and read more on this great tool, either for upscaling or downscaling, haven't updated my scripts since a while and i'm not sure i use the most correct and efficient syntaxes :p.

Thanks for the plugin :)

No problem. And yep, I used the same exact test while developing to make sure it's correct. I'm in process of trying to optimize it more.

[poisondeathray]

If i recall correctly the only avisynth filter i tested giving correct results was

for gamma aware scaling, also resamplehq for sure, and I think dither tools had the capability. I think rr42 had some image utilities too

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

[Aktan]

...and I think dither tools had the capability...

Yep, it does, in fact it has different gamma curve per standard too. It's because of all the different gamma curves in YUV that stopped me from implementing gamma corrected downscale in YUV.

[Yanak]

I should have said that "among all resizers i tested/used", obviously i did not tested everything possible ^^

ResampleHQ is mentioned at the bottom of the old article as doing the things correctly yes, but I never used it as when i searched for it there was no x64 version, but was long time ago and i maybe overlooked when i done my searches, I see there is a x64 on the las page from poisondeathray's link, something I'll try, will take a look when possible at raffriff42 stuff, and need to explore dither tools a bit more too. There is too much stuff to spend time on with avisynth, way too much :)

And good to know that you are still working on AreaResize :)

[real.finder]

speaking of gamma things, I did small edit for dither functions https://pastebin.com/mkcMsvDj


ImageSource("E:\gamma-1.0-or-2.2.png (http://www.ericbrasseur.org/gamma-1.0-or-2.2.png)")
converttoyv24
convertbits(16)
y_gamma_to_linear
Spline36Resize(256,128)
y_linear_to_gamma
convertbits(8)


it work, maybe latter will try make it work with other bit depth if possible but that will be in another place to not get more off-topic here :)

[Aktan]

speaking of gamma things, I did small edit for dither functions https://pastebin.com/mkcMsvDj


ImageSource("E:\gamma-1.0-or-2.2.png (http://www.ericbrasseur.org/gamma-1.0-or-2.2.png)")
converttoyv24
convertbits(16)
y_gamma_to_linear
Spline36Resize(256,128)
y_linear_to_gamma
convertbits(8)


it work, maybe latter will try make it work with other bit depth if possible but that will be in another place to not get more off-topic here :)

Nice work, I may steal parts of it to do gamma correction in YUV, lol.

[poisondeathray]

Also z.lib/zimg can do linear transfer and scaling too in vpy (as the built in resize) and avs (as Z_ConvertFormat) , at different bit depths, YUV and RGB . (But technically gamma error only refers to RGB)

But enough thread highjacking! :)

[Aktan]

So I just saw this (http://avisynth.nl/index.php/Avisynthplus/Developers) page and apparently I should not be multi-threading it. I'll change this soon, as well as follow the other tips.

[real.finder]

So I just saw this (http://avisynth.nl/index.php/Avisynthplus/Developers) page and apparently I should not be multi-threading it. I'll change this soon, as well as follow the other tips.

you can multi-threading it like this one https://forum.doom9.org/showthread.php?t=173772

iirc it's see if the avs mt is on or not to not use internal mt if avs mt is on

internal mt still useful in these kind of filters, and avs+ mt still not work with some cases like runtime filters, and still has some other problems too

[Aktan]

you can multi-threading it like this one https://forum.doom9.org/showthread.php?t=173772

iirc it's see if the avs mt is on or not to not use internal mt if avs mt is on

internal mt still useful in these kind of filters, and avs+ mt still not work with some cases like runtime filters, and still has some other problems too

Wow, thanks for the link! It's true on big resolutions, MT via rendering multiple frames simultaneously is killer on cache. I've been reading a ton of optimizations lately and one of the biggest hit in performance is a cache miss. I guess the other option is make a big note that no MT mode should be used with this plugin. I'll play around with both ways and see.

[TheFluff]

Wow, thanks for the link! It's true on big resolutions, MT via rendering multiple frames simultaneously is killer on cache. I've been reading a ton of optimizations lately and one of the biggest hit in performance is a cache miss. I guess the other option is make a big note that no MT mode should be used with this plugin. I'll play around with both ways and see.

I'm pretty sure that it's been conclusively demonstrated that jpsdr's argument that slice-based threading improves cache locality in resizers is complete nonsense, but jpsdr isn't exactly known for being receptive to empirical evidence, so I've stopped complaining about it. Try it yourself if you want but IIRC there is effectively no memory reuse and thus no cache hits regardless of how you do it. It's true that the Avisynth+ threading model is pretty bad, but jpsdr's abomination of a threadpool is almost assuredly not any better.

If you really do want slice-based threading and already have frame-based threading, you can get it by simply cropping and stacking.

[jpsdr]

but jpsdr isn't exactly known for being receptive to empirical evidence
That's probably true on several things...:rolleyes:

so I've stopped complaining about it.
Wise choice. :D

[Katie Boundary]

Crap. I've lost my copy of Arearesize, the original DLL is somehow no longer part of Chikuzen's package, and Aktan's rewritten files aren't working for me ("Script error: there is no function named arearesize")!

Does anyone anywhere have a backup copy of Chikuzen's version?

[Groucho2004]

Aktan's rewritten files aren't working for me ("Script error: there is no function named arearesize")!That error is most likely due to not having the 2015/2017 MS runtimes installed.

Anyway, I made a build (https://www.dropbox.com/s/rr29f6jxjeoddmn/AreaResize.7z?dl=1) (32 bit) from Chikuzen's code which does not require any runtimes.

[Aktan]

That error is most likely due to not having the 2015/2017 MS runtimes installed.

Anyway, I made a build (https://www.dropbox.com/s/rr29f6jxjeoddmn/AreaResize.7z?dl=1) (32 bit) from Chikuzen's code which does not require any runtimes.

I doubt it without removing the multi-threaded part, but would it be possible to compile my version that doesn't depend on any runtimes?

Edit: Thanks, btw.

[Groucho2004]

I doubt it without removing the multi-threaded part, but would it be possible to compile my version that doesn't depend on any runtimes?
Sure, just change the runtime library option "MD" to "MT". See also here (https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx).

However, it is not recommended to use static linking, particularly for DLLs, see here (https://forum.doom9.org/showthread.php?p=1787687#post1787687).

[Aktan]

Sure, just change the runtime library option "MD" to "MT". See also here (https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx).

However, it is not recommended to use static linking, particularly for DLLs, see here (https://forum.doom9.org/showthread.php?p=1787687#post1787687).

Thanks for this! I guess I'll keep it MD then, lol.

[wonkey_monkey]

I used to do MD but then everyone complains that your plugins don't work because they haven't got the right runtime installed... can't win!

[Aktan]

I used to do MD but then everyone complains that your plugins don't work because they haven't got the right runtime installed... can't win!

Yea, hard to decide... lol

[StainlessS]

Me is switching to MD if for only one reason, MD is default in VS2008 project and so is less bother in new project :)

[Groucho2004]

Yea, hard to decide... lol
Not really. There are excellent All-In-One runtime installers which solve these problems, see here (https://repacks.net/viewtopic.php?f=6&t=237) (the one I use) and here (https://repacks.net/viewtopic.php?f=6&t=247) (a bit more up-to-date).
There are always plugin coders who use dynamic linking (as recommended) so having all up-to-date runtimes installed is a no-brainer and saves a lot of grief, especially for noobs.

Besides, the footprint of all runtimes (2005, 2008,..., 2017) is just 50-60 MB using these AIO packs.

[Katie Boundary]

Never mind. For reasons that I can neither remember nor guess at, I had backed up a bunch of avisynth filters to the "Ripped" folder on my external hard drive. One of them was the original Arearesize. It still works just fine.

This is one of the advantages of being a disorganized pack rat; I'm always finding random extra copies of stuff that I thought I had lost.

[Katie Boundary]

I think Aktan's rewrite has some bugs...

https://i.imgur.com/q4xpQ9q.jpg

[poisondeathray]

I think Aktan's rewrite has some bugs...
<snip>


If you post more source info other than an output screenshot, script, how to reproduce the issue - someone might address the "bug"

[Katie Boundary]

script, how to reproduce the issue

Here's my bad script:

mpeg2source("startrek02.d2v").converttorgb().arearesize(720,405)

Please tell me how this is my fault and not a bug.

After testing a few target resolutions, it seems that Aktan's rewrite expects rescaling in both directions. If either the vertical or horizontal resolution is kept the same, the bug happens. However, this is just my wild-ass guess.

[poisondeathray]

In the vpy ported version, the target width has to be divisible by 32


Fix bug for special target size

For Gray or YUV 8-16 bit, if the target width can't be divisible by 32, output is abnormal
I haven't found the reason, so add an exception handling


Did the original 32bit version from chikuzen have the bug ?

[Katie Boundary]

In the vpy ported version, the target width has to be divisible by 32



Did the original 32bit version from chikuzen have the bug ?

Doesn't matter, this is RGB colorspace. That note is for "Gray or YUV 8-16 bit".

EDIT: also, the bug I'm describing happens when resizing from 720x480 to 640x480. Both 640 and 480 are evenly divisible by 32. Ergo, different bug.

[Aktan]

Whoa, I must have missed these notifications. It's been a long time since I've worked on this, but I can take a look when I have some time.

[Katie Boundary]

I finally got around to labeling my arearesize.dll files, so I have...

"Arearesize (original).dll"
"Arearesize (Aktan).dll"
"Arearesize (Groucho).dll"

...which means that I can run proper side-by-side tests.

A particular project took ~20 minutes to encode using Aktan's rewrite, ~2.5 hours using Groucho's build, and ~4 hours using Chikuzen's original. However, Groucho's build does not suffer the bug that Aktan's rewrite does.