PointSize: A collection of pixel scaling filters

[`Orum]

PointSize is a collection of specialized resizers for pixel-art and other low resolution graphics (e.g. old or portable video game captures).

Download v0.2 (https://www.dropbox.com/s/2uvflijgrngvi7x/PointSize_0.2.zip?dl=0) (or scroll down to download it from the attached files)
Note: Requires Visual C++ Redistributable for Visual Studio 2015 (https://www.microsoft.com/en-us/download/details.aspx?id=48145) if you don't already have it installed.

The readme:
+-----------------------------------------------------------------------------+
| PointSize v0.2 - A collection of resiziers for AviSynth 2.6 / AviSynth+ |
+-----------------------------------------------------------------------------+

Filters
-----------------
PointSize contains the following filters:
scalex(clip c, int scale=2) - Scale (e.g. Scale2x) resize
LQx( clip c, int scale=2) - LQ (e.g. LQ2x) resize
HQx( clip c, int scale=2) - HQ (e.g. HQ2x) resize
xBRZ( clip c, int scale=2, float Yweight=1, float EqColorTol=30, \
float DomDirThresh=3.6, float SteepDirThresh=2.2) - xBRZ resize

Supported "scale" values for various filters (inclusive):
scalex(): 2 to 3
LQx(): 2 to 4
HQx(): 2 to 4
xBRZ(): 2 to 6

ALL filters take ONLY RGB32 input and produce ONLY RGB32 output.

For an explanation of the various filters, please see:
https://en.wikipedia.org/wiki/Image_scaling


FAQ
-----------------
Q: Do you plan to support more color spaces (e.g. YV12)?
A: No. Use the various converting functions in AviSynth (e.g. ConvertToRGB32()
and ConvertToYV12()) if you need to use other source/destination spaces.

Q: Do you plan to support more algorithms?
A: Yes. However, I am limiting myself to those that already have at least some
working C/C++ or assembly (must support x86 and x64) implementation. While
HLSL and GLSL versions of algorithms are fast, they require a graphics card
and I don't want that to be a prerequisite to use this filter. If you know
of an implementation of an algorithm that is not included, and it works and
is license compatible, or you'd like to write your own for this purpose,
don't hesitate to contact me and I can include it in a new release. In
particular, I'm looking to support the following algorithms, license
permitting: EPX, AdvMAME2/3, [Super]Eagle, [Super]2xSaI, xBR, and Kopf-
Lischinski.


License
-----------------
PointSize is licensed under the GPLv3, which is included along with the source
code for the program.

Change log:
v0.2
Restructured so that each algorithm family has only a single function, with a scale parameter
Added support for the xBRZ algorithm, including support for tweaking its parameters
License changed to GPLv3 due to inclusion of the xBRZ algorithm
Resource added to include file version information within the DLL
Plugin is now updated for AviSynth 2.6 / AviSynth+
64-bit binaries are now included in the release (in addition to x86)
Binaries are built with a newer version of MSVS (2015)
Cleaned up code a bit (negligible or no effect on the binary)

v0.1
Initial release
Please let me know what you think below.

[Guest]

Attaching for easier access. Thank you for your contribution.

Any plans for other color spaces?

[`Orum]

I was thinking about it...I don't see any reason why it couldn't work, but I don't know if the interpolation will work as well in something like 4:2:0. I might have to adjust it or maybe it will work right off the bat--but, I imagine most things scaled with these filters will at least be captured in RGB24/32 to begin with, so it's low priority.

First I want to try and understand how the SaI family of resizers is supposed to work without accessing invalid memory :confused:...

[Terka]

how to load the plugin?

[Guest]

loadplugin("pointsize.dll")

[wonkey_monkey]

Hey, excellent, I looked into implementing these algorithms in AviSynth a while ago but didn't get around to it... so thanks for saving me the trouble ;)

David

[`Orum]

New release out, v0.2, with the main changes being AviSynth 2.6 / AviSynth+ support (with 64 bit binaries to boot), as well as support for another algorithm: xBRZ.

[filler56789]

^ Many thanks for the update :thanks:

[MysteryX]

How about providing image comparison samples?

[TheFluff]

How about providing image comparison samples?
hq2x/xbrz and friends are very well known algorithms, comparison images are just a google search away (or you can just check wikipedia like the readme suggests, hqx even has its own article)

that said, if you haven't heard of them you're probably not in the target audience for this filter

[MysteryX]

hq2x/xbrz and friends are very well known algorithms, comparison images are just a google search away (or you can just check wikipedia like the readme suggests, hqx even has its own article)

that said, if you haven't heard of them you're probably not in the target audience for this filter
It does make old video games look a LOT better!

[Bloax]

That highly depends on the content of said game.

https://dl.dropboxusercontent.com/u/63152810/gee1.pnghttps://dl.dropboxusercontent.com/u/63152810/gee2.png
Shit like this will get butchered to high hell.

[raffriff42]

...will get butchered to high hell.
I dunno, bloax, depends on what you are looking for.

https://www.dropbox.com/s/cykomkfghqt1sk5/gee1-compare-2xc.png?raw=1

https://www.dropbox.com/s/m04c1wsidok62yr/gee2-compare-2xc.png?raw=1

(PS, a simple BicubicResize has a look somewhere between LQ2x and scale2x)

[Bloax]

Well yes, there we go. None of them look any better than straight-up pointresize due to ruining the shapes and barely doing anything else (unless it's hq2x, in which case it also blurs very detailed bits to make them not detailed).

They only manage to look worse, and even bigshot XBR that works wonders on a lot of things completely botches this stuff.

I'm simply making too detailed and too complicated things for these low-detail pixel art upscalers to survive.

[raffriff42]

I'm simply making too detailed and too complicated things for these low-detail pixel art upscalers to survive.You are indeed, and they are lovely too.

[`Orum]

I dunno, bloax, depends on what you are looking for.

<snip>

You have LQ2x in there twice, and no xBRZ?

Anyway, yes, there will never be a "one resizer fits all", and different people have different tastes. I'd love to include some more algorithms to provide more options, but my time is quite limited (in case you couldn't tell by the > 5.5 years between releases).

I'm mostly looking at other programs that already implement the filters (e.g. MAME) and trying to get them into AviSynth, but there are often challenges in doing so, as they'll often lack support for things like input/output pitch. It shouldn't be too hard to fix for the older algorithms, but some of the newer ones are still under active development, like xBR. In addition, xBR is written in HLSL, and the only port to C++ that I know of is an old version of the algorithm. If I ever get through updating the multitude of other software/hardware projects I'm working on (hah!), maybe I'll even port it myself.

[MysteryX]

In addition, xBR is written in HLSL, and the only port to C++ that I know of is an old version of the algorithm. If I ever get through updating the multitude of other software/hardware projects I'm working on (hah!), maybe I'll even port it myself.
Until then, it can run with AviSynthShader

[raffriff42]

You have LQ2x in there twice, and no xBRZ?Whoa, so I do. I also forgot to download version 0.2. So to make good, here are some new images.

Also included are Bicubic (http://avisynth.nl/index.php/Resize), nnedi3_rpow2 (http://avisynth.nl/index.php/Nnedi3), and my function, which I can't take full credit for, pow2Qt (http://forum.doom9.org/showthread.php?p=1737201#post1737201).

https://www.dropbox.com/s/06nrk5rqe5cckiu/gee1-compare-8.png?raw=1

https://www.dropbox.com/s/39br2uaowo5nc8c/gee2-compare-8.png?raw=1

xBRZ is pretty great, but it does go crazy sometimes.

Thx Bloax for your images.

Here's another one from the old video game "F117A" running on DOSBOx.
It puts a premium on antialiasing diagonal lines.
https://www.dropbox.com/s/81cv2hrs5gf97py/compare-2x%20F117A%20frm313.png?raw=1

[Hyllian]

For fun:

http://abload.de/img/retroarch-0107-072402suu18.png

[Bloax]

If you guys want to have fun with that thing without the limited palette fucking things up to some degree,
https://dl.dropboxusercontent.com/u/63152810/n/xcom/piratez/xeno_unpaletted.png
here you go. (Just make sure to scale it down to its original resolution, obviously.)

Some of the little details get wiped out due to the obviously limited amount of shades a certain tone has.

https://dl.dropboxusercontent.com/u/63152810/n/xcom/piratez/Witch2.gif
And here's a more kind image.
https://dl.dropboxusercontent.com/u/63152810/a3.png
Looks quite nice when run through 4xbrlv4 and pointresized to halve the resolution.

The blue armored one is hardly news - the main offender among the scaling algorithms is that heavy dithering makes them fall apart.
The other one showcases that a ton of very intricate details and line flows also makes them take a dump on the quality, since they're there for a reason.

[Ghostlamer]

I'm doing something wrong or not?.
Upscaled from 320x240 to 1920x1440 with xbrz from PointSize vs Original xbrz from modified ScummVM:

http://screenshotcomparison.com/comparison/158252

After some tweaks with Thresh:

http://screenshotcomparison.com/comparison/158253

[`Orum]

Hrm, interesting. I assume you are using the ScummVM builds from here: http://sourceforge.net/projects/xbrz/files/ScummVM/?

Also, if you could provide the original (unscaled) image, I'll see what's going on. Thanks.

[Ghostlamer]

I assume you are using the ScummVM builds from here
Yes.

Also, if you could provide the original (unscaled) image
Here http://imgur.com/q8iE3nS .

[`Orum]

Okay, I'm 99% sure I know what's going on here. This looks to be from the remake of Space Quest II, which should have a resolution of 320x200, as in this PNG screenshot (http://www.hardcoregaming101.net/spacequest/sq1-vga1.png) I found on the web. However, your capture appears to be resized (outside of xBRZ), namely stretched in the Y-axis to a different aspect ratio. The important thing to note here is that it appears to be happening on both of your images, but the order of the resizers is different. In the original screenshot (no mouse-over), xBRZ is being applied first, and it is then being stretched to the different aspect ratio (and resolution, of course) via this other resizer. However, in the source image you sent me, this stretching to the other aspect ratio is happening first, and then you are feeding that data to xBRZ, when this should be done in the reverse order to get quality results (or better yet, never rescaled outside of xBRZ if possible).

So I would find out what is doing the resizing before your source is fed to xBRZ in AviSynth[+], and why the aspect ratio would even be changed in the first place.

EDIT: To see what I'm talking about, save that screenshot (http://www.hardcoregaming101.net/spacequest/sq1-vga1.png) somewhere and look at the difference in the two frames in the output of this script:
src = ImageSource("sq1-vga1.png", 0, 0, pixel_type="rgb32")

src.BicubicResize(320, 240, b=0, c=0.3).xBRZ(6) ++ \
src.xBRZ(6).BicubicResize(1920, 1440, b=0, c=0.3)
The difference is immediately apparent.

[Ghostlamer]

To see what I'm talking about, save that screenshot somewhere and look at the difference in the two frames in the output of this script
Oк, understood, i'll try it.

320x200 - correct resolution, but in these old days proportion of pixels were not square, so on modern monitor looks stretched horizontally, that's why i do aspect ratio correction to 4:3.

UPD: You were right, first we do xbrz upscale, and only then the AR.
Many thanks for advice.

[thecoreyburton]

Would it be possible to get the xBRZ filter to scale up to 8 times as opposed to the regular 6 times max?

I know 6x is the highest implementation in most emulation-oriented software and it's been a while since I've played around with the filters outside AVISynth, but I remember the regular xBRZ filter being stackable on itself to ridiculous resolutions and I'm curious if this logic can be applied to xBRZ on a programming level or not.

[Katie Boundary]

Would this plugin be a good place to add pixel mixing (http://entropymine.com/imageworsener/pixelmixing/)?

[`Orum]

Would it be possible to get the xBRZ filter to scale up to 8 times as opposed to the regular 6 times max?

...I remember the regular XBR filter being stackable on itself to ridiculous resolutions...
While there's nothing inherently wrong with an 8x resampling for xBRZ, it would be an extension of the algorithm. As such, the change should be done upsteam (to the reference xBRZ algo), and if it's made there, I'll happily update this filter to include it.

I'm also not entirely sure what you mean by stackable. Do you mean simply calling the algorithm several times? If so, you can get an 8x resample by doing:
clip.xBRZ(4).xBRZ(2) # 2*4 = 8, or...
clip.xBRZ(2).xBRZ(4) # 4*2 = 8
This, of course, won't be as good as an actual 8x if it were added to the algorithm, but it might be better than doing a xBRZ @ 6x followed by a bicubic or similar to bring you up to 8x. I'm also not sure if a 4x followed by a 2x would be better than vice-versa, but I suspect the former. YMMV, but I'm curious what you find, so report back if you experiment.

Would this plugin be a good place to add pixel mixing (http://entropymine.com/imageworsener/pixelmixing/)?
Probably, as this technique looks to be in-line with this filter's goals. I'll have to experiment with it some to know for sure, but right now, the little free time I have to work on DSP is consumed with a new, experimental filter I'm working on unrelated to resizing.

If you have an implementation of pixel mixing and it's compatible with this filter's license, let me know. I'm always open to patches, or if it only requires a little glue to make it work, I can do that.

[thecoreyburton]

Thanks for the reply! I started a thread (https://sourceforge.net/p/xbrz/forums/general/thread/294ae81f/) on the xBRZ page in an attempt to see if an 8x algorithm can be made. In the meantime, another user over there directed me to ScaleFX (http://libretro.com/forums/showthread.php?t=1655) which looks like it might do the trick (and has presets for up to 9x scaling, from what I can tell. Would you be able to implement that into PointSize? It'll either do the trick, or still be a both a handy and relevant implementation. Of course, I'll still regularly check back on xBRZ in case 8x comes along either way!

[Ghostlamer]

(and has presets for up to 9x scaling
It is not 9x, because scalefx has 4 passes, 0 pass - 1x scaling, 1 pass - 1x scaling, 2 pass - 1x scaling, 3 pass - 3x scaling = 6x scaling.
So 9x preset = 12x scaling (6x2).

[thecoreyburton]

Ah, apologies for my misread. I stand corrected!

[thecoreyburton]

It's been six months so I thought I'd resurrect this thread. It looks like Zenju doesn't plan on expanding the XBRz filter beyond 6x at this point so ScaleFX is probably my best option. Is porting it into this a possibility?

[`Orum]

It's been six months so I thought I'd resurrect this thread. It looks like Zenju doesn't plan on expanding the XBRz filter to 6x at this point so ScaleFX is probably my best option. Is porting it into this a possibility?

Sure, as long as license permits, and the results are solid, I'm happy to add additional algorithms.

That said, I've been terribly busy with work/obligations in meatspace, so I haven't had a lot of time to work on this or any of the other software I've released that is now out of date. Things usually clear up over the coming months (June/July), so I should be able to release an update then, but right now this is second in my development queue.

If you'd like though, you can submit a patch to me and after I've verified everything is copacetic I can put out a new release sooner. At some point (next few days, I hope) I will put up a github project for this so it'll be much easier to contribute.

[thecoreyburton]

That's alright, I assumed you were busy! No rush, if anything I'm thankful this exists at all - this is just something for extensive personal use so I'll check back here from time to time for any updates.

Regarding the patch, this kind of development's not my strong suit but I'll have a look and see if it's something I can do. If not, I could potentially look in to donating a small sum or something as a thank you for your efforts. After a few personal tests, I can vouch for the results - it has a similar result to xBRZ and HQx (although these tests were confined to Super Mario World). I personally prefer the results of xBRZ at the same multiplier, but ScaleFX can be used for significantly higher output resolutions and that's where it looks to really shine. It's definitely something subjective, but it at least seems worth the effort given it covers that bit of ground the others currently do not. I'm not sure about licensing, either.

Thank you for replying and best of luck with your busy few months!

[`Orum]

Alright, it's quite belated, but the github project is finally up. I'll update the original post. (edit: It's now updated)

As for donations, I'm sorry, but I don't accept monetary donations--code patches only! However, if you'd still like to give money to someone, might I suggest asking the authors of the resizing algorithms instead? They did all of the "heavy lifting" of the filter, I basically just "glued" everything together to make it work with AviSynth, which is pretty minimal code (and time)-wise.

Lastly, I should have some time in the coming weeks to work on this as well as my other projects. I do have one higher priority project I want to fix up before I work on this again, and I have another filter I've written from scratch that I still have yet to release (but is close) that I'd like to get out. We'll see what I can get done.

[thecoreyburton]

Thanks for the update, I really appreciate the response and any time you've taken! I'm following the Github project now so I'll get notified of any changes.

[Sp00kyFox]

It is not 9x, because scalefx has 4 passes, 0 pass - 1x scaling, 1 pass - 1x scaling, 2 pass - 1x scaling, 3 pass - 3x scaling = 6x scaling.
So 9x preset = 12x scaling (6x2).
that's not correct. mhmm, seems I've confused people with the naming choice. ScaleFX triples the resolution so it's 3x. yes, there are multiple passes but the only one that actually changes the resolution is the last one with factor 3x. the preset for 9x just applies this filter twice so the result is 3x3 = 9. this is not a special version of the filter. you can easily do it as well with other pixel filter by applying them twice in a row.

[thecoreyburton]

It looks like there's a new GLSL shader titled "xBRZ freescale" which should be able to achieve any desired scale value. You can find it here: https://github.com/libretro/glsl-shaders/tree/master/xbrz

I'd love to see this implemented into PointSize, but I'm not sure how much it varies by in contrast to the regular xBRZ, nor even if this is a possible or practical feat (I recall you were explicitly looking for c/c++ shaders and I know this is not one).

[`Orum]

Sorry, I know it's been forever, but I had notifications going to an old email address so I wasn't seeing them. Mea culpa, it's fixed now though.

Anyway, to get back on topic, I definitely want to get an update to this soon. I'm fine with adding xBRZ Freescale/ScaleFX (license permitting), as new resizers are long overdue. The main issue with porting new resizers is that most are implemented as shaders. This isn't an inherently "bad" thing by any means; it's actually quite good for performance. However, I never wanted, and still don't want to require a GPU to use this filter, as I myself run avisynth on servers without GPUs sometimes. But there's good news, as I've been teaching myself OpenCL, which is in some respects the best of both worlds. The GPU shaders should be relatively easy to port over to OpenCL, and then they can run on either a CPU or a GPU.

It's not all roses though, as the kernels (the OpenCL analog of a shader) would almost certainly have to be optimized separately for CPUs and GPUs to hit their optimal performance. However, I'll concede that it's more important to have the resizers available, even if they run slowly on a CPU. They're quite slow right now, after all! So my plans for the next release will be to have at least one new resizer, official Linux support (as I'm no longer running Windows, except for a dual-boot machine that I only boot to Windows to test AviSynth filters), and if it won't delay the release long I may port some of the existing filters to OpenCL implementations. The last item should give gains even on CPUs, as it can make much better use of multi-core systems. About the only downside to this is machines that don't have hardware/software support for OpenCL will be left in the dust, but those PCs are getting very long in the tooth by now, and the old versions will still be available if they need them.

Oh, and this update will have to wait until after I finish an update for my other filter, as an update for that is almost done and even more critical IMHO.