Resizing (Upscaling) is Removing Details?!...

[Typhoon859]

At first, when I noticed the problem by comparing it to the original, I thought it was one of my grain/noise removing/reducing filters. I went through all of them and the problem didn't seem to go away. I stripped it down to just the 720p resize that I had and the problem was still there.

After that, I tried it with just the mpeg2stream identifying line and the problem was gone. I then tried the Bicubic resize that VirtualDubMod has and the problem wasn't as prominent. I don't really understand how the resizing affects anything at all but I captured frames for comparison. In the pictures, notice the details on the sticking out roof above the bottom-left window, and how they mostly disappear when resized with AVISynth. I recommend that it is viewed by opening the pictures in separate tabs, maximizing them, scrolling to the bottom left, and switching between them. Maybe somebody can sort out the issue?

Original VOB
http://www.mybloop.com/get/3435212/Original.png

Encoded without any filters to h264 using the x264 codec at 3000 kbps - Single Pass
http://fs10.mybloop.com/image-handler/optimized/48/3430619

VirtualDubMod Bicubic Resize
http://fs10.mybloop.com/image-handler/optimized/48/3430648

AVISynth Lanczos4/Lanczos/Bicubic Resize (All gave the same negative effect - at least in the area that I pointed out)
http://fs10.mybloop.com/image-handler/optimized/48/3430614

-Thanks in advance for any of your responses.


UPDATE: When using the resizing method real-time, using FFDShow, the details don't disappear. It could be a combination of what happens with the x264 codec/with VirtualDubMod/some other reasons... The problem isn't in the AVISynth resizing methods themselves (though this was probably obvious to most).

[Sagekilla]

This is from a DVD? If so that means it's encoded @ 720x480. Sounds like you're upsizing, and since you are, you're trying to create detail that was never present in the 720x480 frame. Resizing doesn't "remove" details at all. Unless you're downsizing, in which case you are removing details. But upsizing, you're just interpolating data that never existed in the first place.

Try NNEDI for animated content:
NNEDI(1, dh=true).TurnLeft().NNEDI(1, dh=true).TurnRight()

[Typhoon859]

This is from a DVD? If so that means it's encoded @ 720x480. Sounds like you're upsizing, and since you are, you're trying to create detail that was never present in the 720x480 frame. Resizing doesn't "remove" details at all. Unless you're downsizing, in which case you are removing details. But upsizing, you're just interpolating data that never existed in the first place.

Try NNEDI for animated content:
NNEDI(1, dh=true).TurnLeft().NNEDI(1, dh=true).TurnRight()

Yeah. This is from a DVD - 720x480. And as I said, I'm resizing to 720p. And that's exactly what I'm saying - data shouldn't be lost but it is. Look at the comparisons at the place that I mentioned in the post. I'll try that code you gave me. Where should I put it (though I doubt it'll help)?

[Adub]

Those details are barely there in the first place. However, resizing, either up or down, will cause you to lose video information and thus quality. So, yes, when you resize, small details will disappear. The better a resizer you use, the less details you lose.

And encoding to a lossy format just compounds the problems.

In short, this is exactly what's supposed to happen. DVD's weren't made to be upsized. Resize algorithms are only so good. And lossy video compression works by throwing away details.

[Typhoon859]

Those details are barely there in the first place. However, resizing, either up or down, will cause you to lose video information and thus quality. So, yes, when you resize, small details will disappear. The better a resizer you use, the less details you lose.

And encoding to a lossy format just compounds the problems.

In short, this is exactly what's supposed to happen. DVD's weren't made to be upsized. Resize algorithms are only so good. And lossy video compression works by throwing away details.

See, here's the thing... The x264 codec barely effects those details. The second picture is of exactly that. The loss happens after the resize. Now, you say that the resizer is supposed to do that - that resizers end up getting rid of minor details. Okay, I dunno if that's true but if it is, how come the bicubic resizer in VirtualDubMod works so much better than the bicubic resizer used in the AVS script? It's the same algorithm, no? Besides that, if you're saying it's the resizer, how come there isn't any loss in details when I put the script in FFDShow to process the video?.. To top that off, a guy named Triforce made an encode of this same thing from the same exact VOB, also upscaling to 720p, not to mention that he used much more cleaning filters, and the details were still there.

In any case, h264 is the best compression out there in terms of quality. In many respects, it's better than the MPEG-2 compression. The only thing left would be to go uncompressed but then that defeats the whole purpose of an encode, unless it's for video editing.

I think those are enough points to justify that the reason for the loss in quality is something else - something that doesn't quite make sense, to me anyway...

[@Tron@]

What is the best way (script or plugin) for Upscaling to 720 and 1080 ??????? In fact, there are different scripts and a variety of Resizing as a better way???

[*.mp4 guy]

Interpolation does inevitably remove some information from the source, but that is not what is causing problems here. What is happening is that, X264 is removing some details from the source, and it is more obvious on the interpolated-then-encoded stream, because x264 had to apply more compression to that stream then the uninterpolated one.

[Fizick]

there is no BEST way (beside dont upscaling it ;) ).

[@Tron@]

there is no BEST way (beside dont upscaling it ;) ).



Then reformulated the question - what the script (plugin, Resiz ...) better than another??? Indeed, the difference is and I just want to know how best to use and all ... I hope all the same to get an answer ))))))) :helpful::rolleyes::script:

[Jeremy Duncan]

Sharpener
Resizer

limitedsharpenfaster()
Spline64resize(1920,1080)

Resizing before sharpenign ruins the effect.

[Guest]

What is the best way Please read and obey forum rule 12.

[Typhoon859]

Sharpener
Resizer

limitedsharpenfaster()
Spline64resize(1920,1080)

Resizing before sharpenign ruins the effect.

Well, I've tried resizing after and the same thing happens. I think the resize should be done before because then, all the other applied filters work on the full 720p picture. The sharpness looks better that way. I haven't tried Spline64resize so I'll try that and see what happens.\

EDIT: I tried it and the same thing happens.

[Typhoon859]

Interpolation does inevitably remove some information from the source, but that is not what is causing problems here. What is happening is that, X264 is removing some details from the source, and it is more obvious on the interpolated-then-encoded stream, because x264 had to apply more compression to that stream then the uninterpolated one.

But as I've mentioned, a fellow encoder is able to do this without the loss in quality. In fact, I'll post his result.. This was also upscaled to 720p.
http://fs10.mybloop.com/image-handler/optimized/48/3439549

[Didée]

There's no way that "just resizing" in Avisynth would lead to that kind of softening which you're showing.

You need to give us the *exact* way how the source was loaded, which filters were used, etc. Most probably there's some filter acting in the background that you're not aware of.

Quickly guessing for an explanation, it could be you're loading the VOB source with DGDecode (or a variant) with activated deblocking ("PP=1/2/4/6", or something). The deblocking could easily lead to detail loss like seen e.g. on those roofs.

[Typhoon859]

There's no way that "just resizing" in Avisynth would lead to that kind of softening which you're showing.

You need to give us the *exact* way how the source was loaded, which filters were used, etc. Most probably there's some filter acting in the background that you're not aware of.

Quickly guessing for an explanation, it could be you're loading the VOB source with DGDecode (or a variant) with activated deblocking ("PP=1/2/4/6", or something). The deblocking could easily lead to detail loss like seen e.g. on those roofs.

Nope. I'm not doing that. I just index the VOB with DGIndex, include that as the mpeg2source in the AVS script and encode it.

Yeah, I know that wasn't achieved with just resizing. Of course - there are many added filters. The point is that resizing is one of them and it didn't cause that effect. I put softening, noise, and grain filters in mine as well but no matter what, the filters aren't going to give you any added details which were or will be lost by the resize...

[Didée]

I'm not referring to the picture two posts above. That obviously used much of filtering (one of them being [a]WarpSharp, look at the rounded shingles on the big roof.)

In the OP you present a pic "original VOB" (which isn't original, since it's already resized), and two pics "VirtualDub resized" and "Avisynth resized", both of which show detail loss that *can not* be caused by the standard resizing algorithms, but could be caused e.g. by the deblocking filter of mpeg2source(), if activated.

To find the cause, I asked you to post your exact settings, most importantly the *exact script*.

[Typhoon859]

I'm not referring to the picture two posts above. That obviously used much of filtering (one of them being [a]WarpSharp, look at the rounded shingles on the big roof.)

In the OP you present a pic "original VOB" (which isn't original, since it's already resized), and two pics "VirtualDub resized" and "Avisynth resized", both of which show detail loss that *can not* be caused by the standard resizing algorithms, but could be caused e.g. by the deblocking filter of mpeg2source(), if activated.

To find the cause, I asked you to post your exact settings, most importantly the *exact script*.

Oh. Actually, the script is just the resize. What I did was do a Print Screen of the frame fullscreen for each one. They're all decoded by FFDShow with none of its filters applied. It's not FFDShow that's creating the issue.

[Didée]

You sound contradicting.

Nope [...] I just index the VOB with DGIndex, include that as the mpeg2source in the AVS script and encode it.
vs.

They're all decoded by FFDShow with none of its filters applied.

Unclear to me. [Decoded by mpeg2source] isn't the same as [decoded by ffdshow].

In case of doubt, feel free to upload a small sample of your source. It will be easy to show that Avisynth's resizers are not the cause of that detail loss.

[Typhoon859]

You sound contradicting.


vs.



Unclear to me. [Decoded by mpeg2source] isn't the same as [decoded by ffdshow].

In case of doubt, feel free to upload a small sample of your source. It will be easy to show that Avisynth's resizers are not the cause of that detail loss.

No.. I mean, lol.. The VOB is the MPEG-2 Source. So the last three pictures are h264 encodes, encoded in VirtualDubMod by importing the following AVS script - which I then played back in MPC with FFDShow as the decoder for the stream. The original wasn't encoded but rather was the original VOB that I just opened in MPC, also decoded by FFDShow.

LoadPlugin("C:\Program Files (x86)\DGMPGDec 1.5.2\DGDecode.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\Warpsharp.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\UnDot.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\MaskTools.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\ColorMatrix.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\hqdn3d.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\FluxSmooth.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RemoveGrain.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\TCPDeliver.dll")

mpeg2source("C:\Users\Typhoon859\Desktop\Dragon Ball Z - Movies 7 & 9 Double Feature Remastered Trailer.d2v")

Lanczos4Resize(1280,720)

-The loading of the plugins doesn't really do anything...

EDIT: Oh, well actually, yeah, the plugins are necessary for the filters I plan to use to work and for the mpeg2source to be able to be decoded. Yeah, you were right - DGDecode. But, as I showed, without the resize in place, with purely the h264 encode, the problem isn't as prominent and just as much is removed as in the encode of the other guy that I showed. The little bit removed by the h264 isn't the problem.

[Sagekilla]

If you want to upscale it to 720p without it looking like complete crap you need to do a couple of things:

1) Darken those lines up a bit (Toon or fastlinedarken)
2) Denoise it
3) do edge enhancement (LSF with it's edge-only mode)
4) Use NNEDI to upscale to 1440x960, then scale down to 1280x720 with Spline16Resize or something like that.

My try with a generic script I had for an anime encode I did a long time ago:
http://img11.imageshack.us/img11/4676/myscriptsm7.png

Script for attempt #3:

# Disclaimer: Absurdly slow.
Imagereader("original.png")
ConvertToYV12()
Spline16Resize(720,480)


Toon(0.25)
dfttest(sigma=1.6, tbsize=3)
AAA(chroma=true)
NNEDI(1,dh=true).TurnLeft().NNEDI(1,dh=true).TurnRight()
aWarpSharp(24,4,0.3,1)
LimitedSharpenfaster(edgemode=1,strength=200,ss_x=1,ss_y=1)
spline36Resize(1360,768)
Tweak(sat=1.1)


Only difference between this image and my attempt #3 script is this one didn't have Tweak(sat=1.1) applied.
http://img167.imageshack.us/img167/2700/attempt2fi0.png

[Typhoon859]

If you want to upscale it to 720p without it looking like complete crap you need to do a couple of things:

1) Darken those lines up a bit (Toon or fastlinedarken)
2) Denoise it
3) do edge enhancement (LSF with it's edge-only mode)
4) Use NNEDI to upscale to 1440x960, then scale down to 1280x720 with Spline16Resize or something like that.

My try with a generic script I had for an anime encode I did a long time ago:

http://img11.imageshack.us/img11/4676/myscriptsm7.png

Lol, woa... Besides denoise it, I don't know how to do any of that. Umm, but, you have that trailer VOB? The picture you added was resized to 720p and was done just the way you said?

[Sagekilla]

Yes, I took your "original.png" frame, loaded it up + did YV12 conversion and resize to 720x480 DVD dimensions. Then I processed it with my script.


Edit: I made an edit two or three times, check my post once more and you'll see the full script.

[Didée]

So the last three pictures are h264 encodes, encoded in VirtualDubMod by importing the following AVS script - which I then played back in MPC with FFDShow as the decoder for the stream. The original wasn't encoded but rather was the original VOB that I just opened in MPC, also decoded by FFDShow.
Okay, now I got it.

So, what you are finding is that after encoding with x264 you have detail loss compared to the not-encoded upscaled source. Congratulations for finding that encoding with a lossy codec may cause losses.

Not a problem with Avisynth's resizers.

[Typhoon859]

Okay, now I got it.

So, what you are finding is that after encoding with x264 you have detail loss compared to the not-encoded upscaled source. Congratulations for finding that encoding with a lossy codec may cause losses.

Not a problem with Avisynth's resizers.

... Did I not just say "without the resize in place, with purely the h264 encode, the problem isn't as prominent and just as much is removed as in the encode of the other guy that I showed. The little bit removed by the h264 isn't the problem."? If you're going to be a smart-ass, then don't respond at all. The x264 codec didn't create any problems. It is only after the video is processed with the resize that the problem occurs.

[Typhoon859]

Yes, I took your "original.png" frame, loaded it up + did YV12 conversion and resize to 720x480 DVD dimensions. Then I processed it with my script.


Edit: I made an edit two or three times, check my post once more and you'll see the full script.

I will try with your script and post later what happens. Do I need any addition dlls besides the ones that I should I loaded in my script?

[Sagekilla]

What Didee is pointing out is that it's pointless to resize before encoding unless you're doing it in a smart way (See my script before: NNEDI is -MUCH- better for upscaling anime than any built in resizer.) Only reason you should upscale is if you're planning on doing high quality upconvert, like NNEDI, which is too slow for real time.

Edit: By the way for that script you need: NNEDI, Toon, aWarpSharp, LimitedSharpenFaster (and MaskTools, RemoveGrain), AAA, and dfttest.

[Typhoon859]

What Didee is pointing out is that it's pointless to resize before encoding unless you're doing it in a smart way (See my script before: NNEDI is -MUCH- better for upscaling anime than any built in resizer.) Only reason you should upscale is if you're planning on doing high quality upconvert, like NNEDI, which is too slow for real time.

He didn't say that but whatever... It's not pointless at all because it does in fact look better visually besides that problem I mentioned. In any case, I'm finding the necessary dll files for your script right now. When I try it out, I'll tell you the result.

[Sagekilla]

If you read what I said, I'm saying doing a straight resize (MPEG2Source("...").Spline16Resize(1360,768)) is pointless. Unless you do processing, keep it at 720x480. If you use the script I posted, which actually cleans it up and does a proper resize, then yes it is worthwhile. But if you're doing 720x480 --> 1360x768, don't even bother. You're just wasting bits.

[Typhoon859]

If you read what I said, I'm saying doing a straight resize (MPEG2Source("...").Spline16Resize(1360,768)) is pointless. Unless you do processing, keep it at 720x480. If you use the script I posted, which actually cleans it up and does a proper resize, then yes it is worthwhile. But if you're doing 720x480 --> 1360x768, don't even bother. You're just wasting bits.

I see. Well, I've tried the resize after the applied filters and yet it was still an epic failure. Meanwhile, I'm still finding all the extra dll files I need for your script to work...

[Sagekilla]

This page should help: http://avisynth.org/warpenterprises/

I listed necessary plugins in my post a few clicks up.

[Typhoon859]

This page should help: http://avisynth.org/warpenterprises/

I listed necessary plugins in my post a few clicks up.

I don't understand. How do I install FFTW? I can't get dfttest to work because of this.

[Didée]

What Didee is pointing out is that it's pointless to resize before encoding unless you're doing it in a smart way
Really, that's not what I said. I was merely trying to make sure how exactly each of the example pictures were created.


Puzzling together:

Picture#1:
DVD source 720x480, resized to 1360x768 in mpc

Picture#2:
DVD source 720x480 -> encoded @ 720x480 by x264vfw, single pass @ 3000kbps -> resized to 1360x768 in mpc

Picture#3:
DVD source 720x480 -> resized to 1360x768 in Vdub -> encoded @ 1360x768 by x264vfw, single pass @ 3000kbps -> displayed in mpc

Picture#4:
DVD source 720x480 -> resized to 1360x768 in Avisynth -> encoded @ 1360x768 by x264vfw, single pass @ 3000kbps -> displayed in mpc


Reason why #2 looks better than #3 and #4:
The upscales #3 and #4 have three times as much pixels as #2. With 3000kbüs, x264 can retain much more detail when encoding the 720x480 source. When encoding the upscales at 3000kbps, more detail is lost because of the lower relative bitrate.

There're more points when compairing #3 and #4 ... Vdub's default for bicubic resize is 0.0/0.75 ("sharp"), default for Avisynth's bicubicresize is 0.33/0.33 ("soft"), which will surely affect the result. Moreso since Vdub's resize/encoding chain involves colorspace conversions. Moreso since the settings of x264 are unknown.

Endso for thy tone killed my mood.

[Typhoon859]

Really, that's not what I said. I was merely trying to make sure how exactly each of the example pictures were created.


Puzzling together:

Picture#1:
DVD source 720x480, resized to 1360x768 in mpc

Picture#2:
DVD source 720x480 -> encoded @ 720x480 by x264vfw, single pass @ 3000kbps -> resized to 1360x768 in mpc

Picture#3:
DVD source 720x480 -> resized to 1360x768 in Vdub -> encoded @ 1360x768 by x264vfw, single pass @ 3000kbps -> displayed in mpc

Picture#4:
DVD source 720x480 -> resized to 1360x768 in Avisynth -> encoded @ 1360x768 by x264vfw, single pass @ 3000kbps -> displayed in mpc


Reason why #2 looks better than #3 and #4:
The upscales #3 and #4 have three times as much pixels as #2. With 3000kbüs, x264 can retain much more detail when encoding the 720x480 source. When encoding the upscales at 3000kbps, more detail is lost because of the lower relative bitrate.

There're more points when compairing #3 and #4 ... Vdub's default for bicubic resize is 0.0/0.75 ("sharp"), default for Avisynth's bicubicresize is 0.33/0.33 ("soft"), which will surely affect the result. Moreso since Vdub's resize/encoding chain involves colorspace conversions. Moreso since the settings of x264 are unknown.

Endso for thy tone killed my mood.

Hmmm, yeah, well, that's exactly right. The only thing is, when I resized, it was to 1280x720 but not much of a difference.

And thanks, I have a better understanding now of the differences between VDubMod and AVISynth in terms of the bicubic resize. The rest I sorta figured. I'm going to try with a really high bitrate and see what happens. By what you said, it also makes sense now how filtering can help the resize. I guess I'll figure something out. And yeah, sorry for the previous message but you sorta deserved it. You indirectly called me an idiot for no reason... But whatever, doesn't matter. Thanks for the info.

[Jeremy Duncan]

Well, I've tried resizing after and the same thing happens. I think the resize should be done before because then, all the other applied filters work on the full 720p picture. The sharpness looks better that way. I haven't tried Spline64resize so I'll try that and see what happens.\

EDIT: I tried it and the same thing happens.

Nope. Resize before squashes the result after it.

[Typhoon859]

Nope. Resize before squashes the result after it.

Hmm... So then the point of resizing mystifies me, besides the fact the it's a little better than most default resizers in video players. But, it just isn't worth the added bitrate and larger file size then...

[Jeremy Duncan]

Hmm... So then the point of resizing mystifies me, besides the fact the it's a little better than most default resizers in video players. But, it just isn't worth the added bitrate and larger file size then...

Try my test disks: link. (http://forum.doom9.org/showthread.php?t=140747)

It has a hidden pattern in the moving part.
This hidden pattern is revealed by efficient use of resizing and sharpening.
It has a ntsc and pal, and progressive and interlaced version.
Try barious encodes and see which method you try gives you results you like! :)

[Guest]

And yeah, sorry for the previous message but you sorta deserved it. My advice: Don't mess with Didée. He knows his stuff.

[Typhoon859]

My advice: Don't mess with Didée. He knows his stuff.

Yeah. I know. At first, when I saw him reply, I was pretty intimidated. I was like, "Wow, is it really this guy replying to my post?" But either way, I don't take disrespect from anybody, no matter who it's from.

[2Bdecided]

I don't take disrespect from anybody, no matter who it's from.Nobody showed you "disrespect"; but you called him a "Smart Ass". Luckily Didée has a calmer attitude. Try copying it ;)

btw, a "fair" test would be something like const. quality VBR - or just checking the output of AVIsynth in Vdub before encoding to find out where the problem is.

EEDI2 or NNEDI can make great upsizers for animation. With "simple" line drawing style like that, you might be able to get it so good that a casual viewer thinks it started out in HD.

Cheers,
David.

[Typhoon859]

Nobody showed you "disrespect"; but you called him a "Smart Ass". Luckily Didée has a calmer attitude. Try copying it ;)

btw, a "fair" test would be something like const. quality VBR - or just checking the output of AVIsynth in Vdub before encoding to find out where the problem is.

EEDI2 or NNEDI can make great upsizers for animation. With "simple" line drawing style like that, you might be able to get it so good that a casual viewer thinks it started out in HD.

Cheers,
David.

Alright, cool. But unless you read everything, how can you say that he didn't disrespect me, unknowingly? He sarcastically said, "Congratulations for finding that encoding with a lossy codec may cause losses.", especially when the x264 codec was in fact not the problem. My statement was well backed up, and in no way over-exaggerated or anything like that. But whatever, it doesn't matter. Not a big deal.

Umm, but I dunno, I think that the test I did is fair enough. What I can try doing is encoding it with the resize, but now, with a lossless codec. That should prove that the problem is the resize if the issue remains right? But even so, if there ends up not being a problem that way, the issue would be the combination of the resize and the x264 codec, not just the codec itself - considering that the codec itself doesn't create the issue.

[Blue_MiSfit]

Add to the fact that you're doing 1-pass VBR using x264vfw.... which isn't optimal _at all_.

Try a CRF18 encode using the CLI encoder the proper way. MeGUI or any number of GUIs can make this a simpler process :)

~MiSfit

[Didée]

He sarcastically said, "Congratulations for finding that encoding with a lossy codec may cause losses."
Indeed I was in a jolly mood when posting that. :)

especially when the x264 codec was in fact not the problem.
That's where you are wrong. The "problem" is caused mostly by the encoding process.

Basically, upscaling as such doesn't lose any detail. The end result, however, depends on lots of factors that are all correlated to each other: resolution to be encoded, source noise, sharpness/softness, codec settings, available bitrate, etc.

It seems that you don't have full grasp of this meshwork yet. Keep on, experience grows by the day.

But whatever, it doesn't matter. Not a big deal.
Exactly. :)

[*.mp4 guy]

I said something similar on the first page and got completely ignored. I'm just glad Didée got through to everyone by somehow figuring out the details of this mess.

[DJ Bobo]

I'm stunned to see people giving this guy help on upscaling a 4:3 DVD source to 16:9 720p!
Typhoon, what you're doing is the biggest mistake of all times! You want the perfect rip? Encode at 704x480 (by cropping the black side bars), apply a gentle temporal smoother* (eventually a light spatial smoother too) and encode at the highest bitrate you can afford.
Just make sure you specify 4:3 as aspect ratio when muxing to mkv.
Will look 1000 times better than what you're showing here and detail loss will be minimal. Make sure to enable Bicubic Resizing within MPC HC to ensure a sharp look while playback in full screen.

*something like this: TemporalSoften(2,4,8,15,2)

[2Bdecided]

While I'll be impressed if it turns out that way, you can upscale anime far better than a simple bicubic resize!

Did anyone mention EEDI2 or NNEDI yet?

Cheers,
David.

[DJ Bobo]

Upscale to what? He has a 4:3 source! Even Blu-ray does not support 4:3 videos at a higher resolution than 720x480.
Waste of time (and bits as Sagekilla said)

[2Bdecided]

Well, YouTube does, any PC does - and there are plenty of 4x3 BluRay titles available - they are pillarboxed to 16x9.

EDIT: Here's a useful script:
http://forum.doom9.org/showthread.php?t=138285

Cheers,
David.

[Comatose]

If you want to upscale it to 720p without it looking like complete crap you need to do a couple of things:


The lines look really bad...

Will look 1000 times better than what you're showing here and detail loss will be minimal. Make sure to enable Bicubic Resizing within MPC HC to ensure a sharp look while playback in full screen.
The typical anime encoder ignorance about upscaling. For some reason, they all seem to believe that upscaling manually using nnedi or eedi2 and enhancing the video to mitigate the upscaled look is a HORRIBLE, HORRIBLE mistake and that you should always encode anamorphic and let the player or renderer or whatever resize it.

"It blows up the file size", they say. Well, it looks better.

[DJ Bobo]

Pillarboxing huh? Well, I don't recommend it anyway, encoding upscaled videos is superfluous imho. If Bicubic is not good enough for you/him, one could always enable custom resizers and/or filters in ffdshow, no need to "hardcode" the upscaling.

[Comatose]

And most people don't know how to enable those, and/or want to watch it on a PS3 or something.

Not to mention you can do much more when you aren't restricted by realtime filtering.