Video Upscaling and Resizing [Archive]

Seraphic-

6th February 2007, 04:59

Hi,

I'm hoping to get an interesting discussion going on the cost/benefit of upscaling PS2 16x9 console video to wide-screen definition.

For a long time now, I have been unwilling to resize video from it's default resolution. Which, in my case, would be a capture at 720x480 and then just a crop down to 636x444 to remove the black box outline. But, over the past few days, I've really become interested in trying upscaling video to wide-screen. I would really like to see what could be done with minimal video artifacts.

For the below wide-screen demo video I used VirtualDub's Lanczos3 resize filter. However, I posted here because I'm interested to know what I might be able to do with Avisynth that I couldn't do with VirtualDub.

I think the wide-screen demo turned out really well. But I'm really interested in getting some feedback on what other people think on it. Along with suggestions on improvements as at this time, I haven't experimented too much with upscaling video.

Thanks

Guest

6th February 2007, 05:05

Do a search; there are several vibrant threads about upconversion. Why do you have to start another one?

*.mp4 guy

6th February 2007, 05:29

Also you should post samples compressed with a high quality avi codec or mpeg2 compressor, dealing with RMVB files is a pain in the ass, and people are less likely to help you if you make it a pain in the ass to do it.

Seraphic-

6th February 2007, 05:48

*.mp4 guy

6th February 2007, 06:25

RV10 is high quality, but it is hard to work with, the only way is to decode it to a lossless file via a directshow filter graph then work on the lossless file and pray that the RV10 file wasn't vfr.

HeadBangeR77

7th February 2007, 00:46

@neuron2, didn't mean to cause any problems. This is my first post in several months and even though there are a few other posts, I didn't want to crowd them with my specific issues and questions. Rather, thought it would have been best to start my own. I guess not.
Don't worry - the most "vibrant" ones seem to have ended in one large discussion about ITU vs generic resizing, instead of sticking to the main matter. In one of them the discussion was sooo hot, that they even accused the thread's founder of hijacking their "own thread" :D

I'm for upscaling, if one has enough time and hdd space, though I'm doing it just for fun, and for a better presentation of my really favourite movies - otherweise that wouldn't make much sense to me. ;)

Seraphic-

7th February 2007, 04:27

RV10 is high quality, but it is hard to work with, the only way is to decode it to a lossless file via a directshow filter graph then work on the lossless file and pray that the RV10 file wasn't vfr.

I didn't know you were trying to decode the video. It was posted only to view the difference between the default and wide-screen versions.

Don't worry - the most "vibrant" ones seem to have ended in one large discussion about ITU vs generic resizing, instead of sticking to the main matter. In one of them the discussion was sooo hot, that they even accused the thread's founder of hijacking their "own thread" :D

I'm for upscaling, if one has enough time and hdd space, though I'm doing it just for fun, and for a better presentation of my really favourite movies - otherweise that wouldn't make much sense to me. ;)

Thanks :)

I've become really interested in upscaling to wide-screen just to see what can be done before there are too many artifacts. I mean, after all, you are in fact stretching the video a fair amount. My question is how far is too far and to resize before or after cropping out black outline boxes. Also, what size the standard for wide-screen and if it must be in multiples of 16. I mean, would it be better to crop first it I.E - 636x444 => 848x480 or to resize 720x480 => to a much higher resolution and then crop down to 848x480. That is, if 848x480, is the optimal resolution.

I'm sure I'll have more questions, but that is good start.

Thanks

HeadBangeR77

7th February 2007, 04:43

I've become really interested in upscaling to wide-screen just to see what can be done before there are too many artifacts. I mean, after all, you are in fact stretching the video a fair amount. My question is how far is too far and to resize before or after cropping out black outline boxes. Also, what size the standard for wide-screen and if it must be in multiples of 16. I mean, would it be better to crop first it I.E - 636x444 => 848x480 or to resize 720x480 => to a much higher resolution and then crop down to 848x480. That is, if 848x480, is the optimal resolution.

I'm sure I'll have more questions, but that is good start.

Thanks
There are some folks out there, who think such a small upsizing doesn't make much sense. ;)
In your case I don't think you would get any artifacts, but I'm not sure which resizing method (e.g. bicubic, Lanczos3, Lanczos4, Spline16/32 etc.) would be the best for your type of contenct, since I don't encode anything apart from regular movies and videoclips.

I'm a sample-freak, but it's worth the time imo: whatever you do, just encode a few samples (for instance with your favourite scenes), one pass, the same settings, to analyze them and to come to conclusion, which one looks the best for you (since those are your eyes, and nobody's elses ;)).

As to cropping and resizing - I always crop at the very beginning. That's the first thing I do, since then it's easier for me to choose the apropriate resolution, so that proportions will look ok. The only thing I could think of before cropping, is deblocking, if it's needed.
I know it's considered to be outdated, but Gordian Knot it's a good tool for cropping /resizing /getting the proper aspect ratio. If you're into avisynth, you could just copy and paste the values from GK into your own script. Plus there's a preview window, so that you can see the proportions etc.

Sorry, it's 4 AM by me, so good night ;)

*.mp4 guy

7th February 2007, 06:22

There isn't going to be much harm done upsizing the video's aslong as you don't overcompress them. You would get better looking video if you ran it through a good antialiaser (before resizing).

lanczos based resizers preserve the most of the sources detail, but leave behind the most artifacts.

Spline based resizers preserve the second highest amount of detail, and have the least artifacts of any "simple" resizer.

Bicubic has no ringing artifacts (unlike spline which has a very small amount, and lanczos which has a very large amount) but has much worse aliasing, and preserves the least detail of any resizer besides bilinear.

lanczos has less aliasing and less bluring the more taps you use, but has more ringing and overemphasized frequencies aswell (looks like oversharpening).

Spline only benefits from higher taps settings, but is also very slow with them.

Bicubic does not have adjustable taps, neither does bilinear, but thats doesn't really matter since they are both crap anyway.

Seraphic-

7th February 2007, 07:25

Hmmm, why would I need "Anti-aliasing" before resizing? Wouldn't it need it after, since the video was captured correctly at 720x480? Also, I take it when you say "lanczos", it's the same as Lanczos3?

A video a friend of mine posted (sample image below), in which he was showing his 720x480/16x9 wide-screen/upscaling test results is what got me interested in this (it looks really good, as text and the overall detail remain sharp ~ mine looks kind of blurry, but I'm still new to this). I have also just captured video at 720x480 and cropped out black-bars down to 636x444.
http://www.seraphicgate.com/temp/demo.png

*.mp4 guy

7th February 2007, 08:29

The reason for the antialiaser is because your source is aliased (because its from a video game), this will make the interpolators job harder and make it cause more artifacts then if the source didn't have aliasing, which is why I suggested using an antialiaser before you resize. However an antialiaser will soften the picture (which I'm guessing now would bother you more then the aliasing) so if your goal is to get the sharpest results possible you don't need to worry about antialiasing. It looks like your friend might have used a sharpener after he resized, you could try limitedsharpenfaster to get similarly sharp results.

lanczos3, lanczos4, etc. are all just alternative names for lanczos(taps=3/4/8/256/whatever).

Ð.Sp!dér

7th February 2007, 09:05

Chainmax

7th February 2007, 14:34

One thing I'd do before using antialiasing is to upsize the cropped image with EEDI2 in this manner:

EEDI2().TurnRight().EEDI2().TurnLeft()

which would bring it from 636x444 to 1272x888 and eliminate most (and probably all) of the aliasing. Then I'd use Spline36Resize and bring it down to the final resolution. This way, you are basically doing two antialiasing procedures (EEDI2 and upsizing+downsizing) with almost no blurring :).

Seraphic-

7th February 2007, 17:14

If I were you, I would consider using AA (Antialiasing). This is a common problem in video games where you can clearly see the edges being choppy MS Paint-style. :) Even though it could result in a small loss of detail, more like in the background and such, at a far away distance, but this will considerably improve the overall visual quality. http://img208.imageshack.us/img208/3137/untitledke9.jpg

Wouldn't you agree that most, if not all, of that aliasing in that image would be caused or worsened from the sharpening filter? I mean, if you take a look at my 636x444 image, you don't find anything too bad in relation to the edges (or maybe some scenes could just have edges that way).

But since this has been brought up, it has made me wonder if I've been missing a step this whole time. I take it you this isn't the same as aligning the fields to remove interlacing, as seen below?

http://www.michaeldvd.com.au/Articles/VideoArtefacts/AliasingInterlacedImage.gifhttp://www.michaeldvd.com.au/Articles/VideoArtefacts/AliasingOriginalFrame.gif

One thing I'd do before using anti-aliasing is to upsize the cropped image with EEDI2 in this manner:

EEDI2().TurnRight().EEDI2().TurnLeft()

which would bring it from 636x444 to 1272x888 and eliminate most (and probably all) of the aliasing. Then I'd use Spline36Resize and bring it down to the final resolution. This way, you are basically doing two anti-aliasing procedures (EEDI2 and upsizing+downsizing) with almost no blurring :).

So 636x444 to 1272x888 (with EEDI2) and the back down to 848x480 (or is there another recommended resolution)? Also, do you have a script code for the Spline36Resize downsizing?

check

7th February 2007, 17:52

spline36resize(destx,desty) ;)

Aliasing is where the edges are not straight, but jagged. Since everyone is having fun with paint I'll get in on the action.
http://files.project357.com/uploads/aliasing.jpg
The left line is not aliased, the right line is aliased (ie, jaggy). As you can see, while the left line is 'the real thing', the right line is just a bunch of blocks lined up to approximate a real line.
The encoder will be trying to encode an approximation, rather than the real thing, which is bad because the aliased version will prove to be less compressible than the original.

Chainmax

7th February 2007, 18:17

...
So 636x444 to 1272x888 (with EEDI2) and the back down to 848x480 (or is there another recommended resolution)? Also, do you have a script code for the Spline36Resize downsizing?

There isn't really a recommended resolution, it all depends on what you want and/or need.

Seraphic-

7th February 2007, 19:03

There isn't really a recommended resolution, it all depends on what you want and/or need.

Doesn't it and shouldn't it be in multiples of 16? I mean, there must be a recommended one if you're going down from 1272x888 to keep the correct ratio. The reason I said 848x480, was because it was in multiples of 16.

spline36resize(destx,desty) ;)

Aliasing is where the edges are not straight, but jagged. Since everyone is having fun with paint I'll get in on the action.
http://files.project357.com/uploads/aliasing.jpg
The left line is not aliased, the right line is aliased (ie, jaggy). As you can see, while the left line is 'the real thing', the right line is just a bunch of blocks lined up to approximate a real line.
The encoder will be trying to encode an approximation, rather than the real thing, which is bad because the aliased version will prove to be less compressible than the original.

I was wondering why there is some in one part of my below test image, but not in another.

http://www.seraphicgate.com/temp/636x4442.png

-----------------------------

Also, if anyone wants to do some testing, here is a raw avi clip from the above scene (ten seconds long). What was done: Cropped down from 720x480 to 636x444 to remove black bars and field alignment to remove interlacing. Download Here (http://www.seraphicgate.com/temp/demo.rar)

Chainmax

7th February 2007, 19:30

Doesn't it and shouldn't it be in multiples of 16? I mean, there must be a recommended one if you're going down from 1272x888 to keep the correct ratio. The reason I said 848x480, was because it was in multiples of 16.
...

Other than keeping width and height multiples of 16 (which has to do with MPEGx shortcomings IIRC), there is not an ideal resolution. The suggestion to use EEDI2 was based on the fact that it does some pretty good antialiasing without blurring the picture too much. Upon using it, you end up with 2x the original framesize which in your case would be 1272x888. Since that's a higher resolution than the one you intended, I suggested a downsize. If it's any help, the closest exact 16:9 resolution to your source's is 768x432.

Seraphic-

7th February 2007, 19:40

Other than keeping width and height multiples of 16 (which has to do with MPEGx shortcomings IIRC), there is not an ideal resolution. The suggestion to use EEDI2 was based on the fact that it does some pretty good antialiasing without blurring the picture too much. Upon using it, you end up with 2x the original framesize which in your case would be 1272x888. Since that's a higher resolution than the one you intended, I suggested a downsize. If it's any help, the closest exact 16:9 resolution to your source's is 768x432.

Alright, thanks, I'll give that a try. Also, when you say "6:9 resolution to your source's is 768x432": Do mean 636x444 to 768x432 or 1272x888 down to 636x444?

Check, is "spline36resize(destx,desty)" part of a .dll plugin? If yes, could I have the link please?

------------------------------------

For those interested in testing on their end:

Cropped down from 720x480 to 636x444 to remove black bars and field alignment to remove interlacing.
Download HERE ~ 206MB (http://www.seraphicgate.com/temp/demo.rar)

Raw capture at 720x480, no cropping and no field alignment.
Download HERE ~ 115MB (http://www.seraphicgate.com/temp/noedit.rar)

Ð.Sp!dér

7th February 2007, 23:02

is "spline36resize(destx,desty)" part of a .dll plugin? If yes, could I have the link please?
It's part of the AviSynth script. You know, those .avs files...
Wich you can Edit in Notepad to see some really cool magical rainbows. ;)

The 6th (sixth) line in a normal AviSynth scripts is:
#resize

Wich you can replace with:
Spline36Resize(768,432)

After a # symbol you can add as many lines as you wish and it won't make a difference.
It would just be skipped by AviSynth.

check

8th February 2007, 01:25

The 6th (sixth) line in a normal AviSynth scripts is:
#resize

Oh, it is, is it? :P

@sera: Spline36resize is an inbuilt filter, which you would've seen had you tried the script :devil:
The reasons for the 'sometimes jaggy sometimes smooth' is simply a crude approximation of AA has been attempted by the PS2, which only runs in some places (an artifact of the machine's limited power I suppose).

HeadBangeR77

8th February 2007, 03:13

The reasons for the 'sometimes jaggy sometimes smooth' is simply a crude approximation of AA has been attempted by the PS2, which only runs in some places (an artifact of the machine's limited power I suppose).

OT : Just from curiosity - do you happen to know what kind of AA the PS2 uses? I mean there are whole lot of them, including ATI-specific and Nvidia-specific, normal, supersampling etc.

Chainmax

8th February 2007, 03:29

Alright, thanks, I'll give that a try. Also, when you say "6:9 resolution to your source's is 768x432": Do mean 636x444 to 768x432 or 1272x888 down to 636x444?

Check, is "spline36resize(destx,desty)" part of a .dll plugin? If yes, could I have the link please?
...

What I meant was that you want to make an encode with a 16:9 aspect ratio, and the closest exact 16:9 resolution to 636x444 is 768x432. As for Spline36Resize, it's included in Avisynth. So, my suggestion would be something like this:

extra filters loading
LoadPlugin("X:\wherever\EEDI2.dll")

Source loading

EEDI2().TurnRight().EEDI2().TurnLeft()
Spline36Resize(768,432)

check

8th February 2007, 05:07

OT : Just from curiosity - do you happen to know what kind of AA the PS2 uses? I mean there are whole lot of them, including ATI-specific and Nvidia-specific, normal, supersampling etc.
From what I recall, the PS2 had no standard AA capabilities, so every engine had to roll its own. This particular case looks like selective edge AA (aka "edge AA" on some nvidia cores), which is basically where selected edges are antialised based on what they are occluding and their position in the 'z stack' (I forget the right term).

Seraphic-

8th February 2007, 09:07

Oh, it is, is it? :P

@sera: Spline36resize is an inbuilt filter, which you would've seen had you tried the script :devil:
The reasons for the 'sometimes jaggy sometimes smooth' is simply a crude approximation of AA has been attempted by the PS2, which only runs in some places (an artifact of the machine's limited power I suppose).

I did try the script, but it came up with an error. So I thought I might have been missing the needed plug-in.

http://www.seraphicgate.com/temp/636x4442.png

Also, about the above image I posted: Viewed that same event using the PS2s out-put and display on a normal T.V. And that sharp/smooth area is the same as seen in the image. So in that case, at least, it wasn't just created from the capture process on a computer.

What I meant was that you want to make an encode with a 16:9 aspect ratio, and the closest exact 16:9 resolution to 636x444 is 768x432. As for Spline36Resize, it's included in Avisynth. So, my suggestion would be something like this:

extra filters loading
LoadPlugin("X:\wherever\EEDI2.dll")

Source loading

EEDI2().TurnRight().EEDI2().TurnLeft()
Spline36Resize(768,432)

Sorry about that Chainmax. I meant to say "Do mean 636x444 to 768x432 or 1272x888 down to 768x432". But yeah, I get what you are saying.

Seraphic-

11th February 2007, 02:11

Thanks for everyone's help.

If it's any help, the closest exact 16:9 resolution to your source's is 768x432.

Chainmax (or anyone else who knows),

In interested to know, what method did you use to determine that 768x432 was the valid 16:9 resolution for 636x444? (I would like to know so I can use the same formula for other resolutions)

*.mp4 guy

11th February 2007, 02:54

In linear form the equation is (width / 16)*9=height, which for any given width will give you the proper height for a 16/9 aspect ratio frame. You can reverse it to (height / 9)*16=width. So basically what you do is pick either a width or a height that you want your video to have, and that equation will give you the other dimension to make your destination resolution 16/9.

IanB

11th February 2007, 10:10

And the other constraint is that width and height both be multiples of 16

768 = 48 * 16
432 = 27 * 16

also

48 = 3 * 16
27 = 3 * 9

Other "Golden" exact 16:9 sizes are
1536 x 864, 1280 x 720, 1024 x 576, 512 x 288, 256 x 144
given by Width=n*16*16 & Height=n*16*9

some very close approximations are

624 x 352(351), 656 x 368(369)

Seraphic-

1st March 2007, 16:02

I haven't had a chance to do a lot of testing on the resizing until just to past few days. What I've found is that the image becomes slightly out of focus after using Spline36Resize. I wonder, could anyone offer some suggestions on an avisynth sharping filter that would work well to re-focus/sharpen the image (in my case) back near the original? Any help that would be really appreciated.

Before
http://www.seraphicgate.com/1.png

After
http://www.seraphicgate.com/2.png

Chainmax, I also have a question about your script. If in the end, I just wanted to anti-alias/smooth some of the edges, what quality consequences would I be looking at if I was to resize up to 768x432 and then back down to 636x444? (I would have to consider time, however, as the process takes quite awhile; as just the 1:18 sample clip took near and hour to resize).

Terranigma

1st March 2007, 16:18

uhmm, would'nt Pointresize work on that image?

foxyshadis

1st March 2007, 20:14

(I would have to consider time, however, as the process takes quite awhile; as just the 1:18 sample clip took near and hour to resize).

Are you using a 386? I can't believe the resizing could be so slow - you're probably seeing the re-encoding speed and confusing it with resize. You can resize in realtime with pretty much anything newer than a P2. Or do you mean you included EEDI2? Now that one is a CPU killer, and it already does double the size of the original.

You can speed it up a little with:

EEDI2().Resize(width,final_y).TurnRight()
EEDI2().Resize(width,final_x).TurnLeft()

Which keeps it from having to work with so much extra at once.

If Spline is too soft for you, try Lanczos. Simply using two resizes is an ineffective AA, don't bother, and you won't ever be able to fully AA this material.

Seraphic-

2nd March 2007, 03:35

Are you using a 386? I can't believe the resizing could be so slow - you're probably seeing the re-encoding speed and confusing it with resize. You can resize in realtime with pretty much anything newer than a P2. Or do you mean you included EEDI2? Now that one is a CPU killer, and it already does double the size of the original.

You can speed it up a little with:

EEDI2().Resize(width,final_y).TurnRight()
EEDI2().Resize(width,final_x).TurnLeft()

Which keeps it from having to work with so much extra at once.

If Spline is too soft for you, try Lanczos. Simply using two resizes is an ineffective AA, don't bother, and you won't ever be able to fully AA this material.

Yeah, it does resize the video instantly and allows me to view the results, etc. What took near and hour, and what I didn't make clear, was that to re-save the video after is what took near and hour. As my CPU, I have an AMD 64 4000+ (2.6 GHz ~ 2GB DDR Ram) and used the below:

EEDI2().TurnRight().EEDI2().TurnLeft()
Spline36Resize(768,432)

Up to the above point, the video must remain YUY2. Would saving it as 24 bit RGB at this point lower the encode time?

And as for what you said about Spline/Lanczos. Isn't there a sharpening filter that I could add to the above script that might help to re-crisp the video back near the original? (I didn't want to use the default sharpen filter within VBDub) Also, could you go into a little of the differences between Spline and Lanczos?

Thanks

foxyshadis

2nd March 2007, 08:49

For a simple sharpen, give LimitedSharpenFaster or SeeSaw a shot. It's not immediately obvious which is better, you'll have to experiment.

The docs probably need to be expanded on the resizer differences, since there's a lot of good quotes to pull from now. :D Lanczos is similar to a sharp bicubic, without as much ringing (light and dark halos) and diagonal breakup; spline36 is a little less sharp than lanczos but removes almost all the ringing.

And no, RGB vs YUV is nearly instantaneous.

I meant that the spline36 half is negligible on the output speed; EEDI is what sucks up perhaps more than 90% of the total time, which is why I posted the faster variant. I was just correcting the misconception that spline36 had anything to do with that slow speed.

You have single-core, not an X2, right? So multithreaded variants won't help. Ah well. The version I posted in the TIVTC thread should still be somewhat more optimized than the basic one, though.

Seraphic-

2nd March 2007, 10:02

Back when I was building this computer (four years ago), I debated to go with the AMD 64 4000+ or the AMD X2 3800+ (back then both were about the same price). As you can see I went with the AMD 64 4000+, mainly because not many applications used more then one core back then. Now that I look back, the AMD X2 3800+ would have been a better choice. At some point I plan to build a new system with a E6600 C2D.

Anyway, looking at the above two images I posted (near the lower right of the four buttons), would you also say that looks blurred compared to same area of the original image? Is sharpening something that would correct that or is it just inevitable from the resize (image be stretched from 636x444 to 768x432)?

When you change EEDI2().TurnRight().EEDI2().TurnLeft() to EEDI2().Resize(width,final_y).TurnRight() and EEDI2().Resize(width,final_x).TurnLeft(), what is it doing different and is there any quality consequences?

Thanks

foxyshadis

2nd March 2007, 12:15

I think it looks a little less sharp, probably mostly a consequence of eedi2's antialiasing. Sharpening or using lanczos might help, might not. Try it!

To understand what I did, you have to understand what EEDI2 does. It doubles the height - by turning and running again, it effectively doubles the image area, in a smooth way that when sized back down acts like antialiasing. It takes exponentially longer as you increase the original size. Yet you double the height, only to size back down afterward; what's the point of spending all the time on the second EEDI, when this extra isn't critical to the process? That's the magic of the intermediate resize. I'm not sure I'm explaining this, but it's basically just removing unnecessary stuff before it becomes a hindrance - like you don't render every frame of a bob if you're going to 30fps, unless there's some reason you need it.

You won't get bit-identical results, but you won't get worse and there's a small chance you'll even get better results.

Seraphic-

2nd March 2007, 12:40

I think it looks a little less sharp, probably mostly a consequence of eedi2's antialiasing. Sharpening or using lanczos might help, might not. Try it!

Yeah, I agree. It only needs a little correction, it isn't anything major. I would like to do some more testing, but I'm not sure what .dll files are needed for LimitedSharpenFaster or SeeSaw and lanczos. Along with the correct Avisynth Script needed to use them. I'll have to try and find that out.

Also, from what you said, let me see if I got this right. Are you saying it isn't intended to keep the video at 768x432 but to got from 636x444 to 768x432 and then back down to 636x444? I'll wait until you reply, but I was thinking of keeping it at 768x432. I kind of like the wide-screen look and it really doesn't look that bad, other then the small loss of sharpness (or is there also some other quality loss when you resize in this manner). I mean, yes it kind of looks stretched, but it also doesn't look that bad. I don't know, maybe I should just keep it a 636x444. :confused:

HeadBangeR77

2nd March 2007, 12:49

Yeah, I agree. It only needs a little correction, it isn't anything major. I would like to do some more testing, but I'm not sure what .dll files are needed for LimitedSharpenFaster or SeeSaw and lanczos. Along with the correct Avisynth Script needed to use them. I'll have to try and find that out.

1) LimitedSharpenFaster:
You will need this script:
http://forum.doom9.org/showthread.php?p=933768#post933768

and the following plugins:
LoadPlugin(... MaskTools.dll")
LoadPlugin(... RemoveGrain.dll")
LoadPlugin(... WarpSharp.dll")

As to different versions of those plugins, I will write some info later on.

EDIT:
MaskTools package 2.0a30
RemoveGrain 1.0 & some files from 0.9 - a tip here. (http://forum.doom9.org/showthread.php?p=856000#post856000)
WarpSharp - sorry, I can't recall atm - you will surely find tips in the LSF's thread. You won't need this particular one, unless you choose the UnsharpMask method (known from digital photography). This has just reminded me, the above WarpSharp is a package-dll with various sharpeners.

2) SeeSaw:
http://forum.doom9.org/showthread.php?t=104701

Here I can't help you much, since I'm not very familiar with this particular script (hope Didee won't take it as a blasphemy ;)).

3) LanczosResize is a built-in function in AviSynth, so you won't need any additional plug-ins.

good luck!

PS. A bunch a screenshots with different resizing methods (there's hardly any difference visible by so small resizing factors): http://forum.doom9.org/showthread.php?p=950227#post950227

Seraphic-

14th March 2007, 02:34

Was wondering about something and wanted to maybe get some feedback. I've been alternating between the below methods, and had some good results with both, but I wanted to know, is one my methods flawed here? And by that I mean, in keeping with valid 16:9 aspect ratio and lessen artifacts. Or is there a re-worked method someone could suggest? Thanks for any replies.

Method One
Set PS2 Display Mode to 16:9
Capture at 720x480
Deinterlace/Field Alignment
Crop down to 636x444 (removed black-bars)
Resize to 768x432 (to remove aliasing) (Spline36Resize)

Method Two
Set PS2 Display Mode to 16:9
Capture at 720x480
Deinterlace/Field Alignment
Resize to 848x480 (to remove aliasing) (Spline36Resize) (853x480 was not accepted due to it being odd)
Crop down to 752x444 (removed black-bars)

Method Three
Set PS2 Display Mode to 16:9
Capture at 720x480
Deinterlace/Field Alignment
Crop down to 636x444 (removed black-bars)
Resize up to 1272x888 (to remove aliasing) "EEDI2().TurnRight().EEDI2().TurnLeft()"
Resize down to 768x432 (Spline36Resize)

Method Four
Set PS2 Display Mode to 16:9
Capture at 720x480
Deinterlace/Field Alignment
Resize up to 1440x960 (to remove aliasing) "EEDI2().TurnRight().EEDI2().TurnLeft()"
Resize down to 848x480 (Spline36Resize)
Crop down to 752x444 (removed black-bars)

You can speed it up a little with:

EEDI2().Resize(width,final_y).TurnRight()
EEDI2().Resize(width,final_x).TurnLeft()

Which keeps it from having to work with so much extra at once.

Didn't try this until today, but it comes back with "I don't know what "final y" means"?

foxyshadis

14th March 2007, 04:18

That was supposed to be a placeholder for the numeric height of your video, sorry. ;) Same with x. Or you could define final_y = 360 at the top of the script.

I don't think any of your methods are flawed, the only real difference between 1 & 2 and 3 & 4 are the speed they'll run at, and the odd way you have different final sizes. Processing more pixels takes longer, whether it gives a better result or not; that's the same idea behind my little mod above - process the minimum necessary.

(mf takes the opposite tack, process the maximum possible. xD)

Nitpicking: You may notice a very slight lightening or darkening of the furthest edge pixels if you leave the black borders, because they still have some influence, but it's likely on the order of ±2 values, unnoticeable. Also, for a very small speed gain, you could crop during the resize instead of as two discrete actions.

Seraphic-

14th March 2007, 12:28

In method two/four the reason I went with 848x480 is because, if I'm not mistaken, 853x480 is the most valid 16:9 resolution for DVD wide-screen. When PS2 is set to 16:9 mode for a DVD game, I thought it might/should be the same, no? But since 853x480 is odd, I tried 848x480 and then cropped down, however, I guess I should really use 852x480 as 854x480 would be too wide. My only uncertainty with this method though is if the final resolution of the video should be 852x480 after cropping, be a upsize/downsize directly to 852x480, or be 852x480 and then use the final size after cropping out the black-bars (around 758x444).