Upscaling bug with SimpleResize

[LigH]

Hi there,

although both the original and the final dimensions use width and height dividable by 4, the last SimpleResize (0.3.2.0) has a bug when used for tremendous upscaling, like in the example I'm presenting here:

http://www.ligh.de/software/Simple/Original.gif

This image is upscaled with the following script (part of it; I used that to compare different resizing functions):


LoadPlugin("SimpleResize.dll")
clip = AviSource("Upscale.avi")
clip.IsRGB ? clip.ConvertToYUY2 : clip
SimpleResize(160,120)


The result looks like that (please note the green bar at the right edge):

http://www.ligh.de/software/Simple/Simple.gif

To verify this, you can download a package containing everything I used (I discovered it using AviSynth 2.06):

http://www.ligh.de/software/Simple/Upscale.zip

The author of SimpleResize is already contacted by email.

BTW: After fixing that, how about taking SimpleResize over into the next AviSynth? And I'm missing a PixelResize which uses the nearest neighbour, just for completeness...

[int 21h]

Originally posted by LigH

BTW: After fixing that, how about taking SimpleResize over into the next AviSynth?

The combining developing plugins with Avisynth is excessively discussed here: http://forum.doom9.org/showthread.php?s=&threadid=33387

Most of the developers of plugins specifically oppose such a move because it makes their development cycle much more difficult. (i.e. updating Avisynth CVS, notifying appropriate people, etc.)

[Guest]

Yes, and now that dividee has added the plugin directory support, the reason for integrating filters into the core is not so compelling.

[trbarry]

LigH -

It does indeed seem you have found a new bug in SimpleResize. From your first email it sounded like the old fixed div-by-4 green line problem and I thought you just needed a newer release, but not so.

I'll take a look at it.

But even when fixed I don't really recommend using SimpleResize for upscaling, at least not by that much. It is an unfiltered Bilinear and I don't think it can project smooth gradients when upscaling by more than about 2:1 or so.

- Tom

[sh0dan]

Filters "in development" or special filters should never be a part of the core. Simpleresize is a basic filter, which I wouldn't mind having as a core filter, if it justifies iteself - and if tom is interested. Updating filters in CVS is not a big deal, and there is no need of notifying anybody - CVS handles all that automatically.

Oh - and regarding "nearest neighbour", I have a version that also contains this. I haven't committed it yet, but I probably will (just for completeness - it's also a good filter for debugging purposes).

[trbarry]

sh0dan -

Notwithstanding the above bug I think SimpleResize is mostly stable now and I'm not currently working on it much, with no plans for special enhancements in the near future.

So I'd have no problem if it was added to the core, as long as I don't have to fix this upscaling bug first, since I'm currently working on some other stuff. ;)

When I'm working on newer things where I'm still tinkering and adding new stuff I often prefer to play in my own sandbox, but past a certain point I tend to drift away from it. If it's stable at point then it is probably better to turn it over and let other folks continue to improve it.

You could say Ben RG did basically the same thing with Avisynth.

So go ahead and add it if you think it's a good idea.

- Tom

[SILICON]

There is some advantage in incorporating the filters to the core? Gains speed?

If the answer is not, I think thas is better not add its to the core.
In this way we have lees memory use and less complex code.

And the improvements can be done more easy, with no need to change or recompile the core.

[sh0dan]

Less memory? Unless 16-32k of memory is a problem, I can't see why it would have any influence on your machine.

Code complexity is not that big a deal, when handling completely seperate filters. They are not interdependant, so a (theoretical) bug in SimpleResize will only show, when SimpleResize is used.

Regarding improvements: That's why only stable, established filters are included. Recompliling the core only takes a few seconds more than an individual filter.

The advantage of having basic filters as internal are not huge, but they are there. First of all AviSynth-newbies do not have to search the net to find them, if they got Avs from a friend, videotools.net, etc. Second of all, documentation is easy to find, since it follows the rest.

[SILICON]

Originally posted by sh0dan
Code complexity is not that big a deal, when handling completely seperate filters. They are not interdependant, so a (theoretical) bug in SimpleResize will only show, when SimpleResize is used.
When the autor discover a bug in one filter, or look for a improvement, can change the filter without anyoning you. The develoment process speed up. The user can chose several vesions of this filter.


The advantage of having basic filters as internal are not huge, but they are there. First of all AviSynth-newbies do not have to search the net to find them, if they got Avs from a friend, videotools.net, etc. Second of all, documentation is easy to find, since it follows the rest.

You can include the most usefull filters in your install. The documentation can include the documentation of this filter.