PointSize: A collection of pixel scaling filters

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

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?

[`Orum]

Originally Posted by 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 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.

Originally Posted by Katie Boundary

Would this plugin be a good place to add pixel mixing?

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.

Thanks for the reply! I started a thread 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 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).

Ah, apologies for my misread. I stand corrected!

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]

Originally Posted by 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 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.

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.

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]

Originally Posted by Ghostlamer

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.

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-sha...ee/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.