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

[Typhoon859]

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

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]

Originally Posted by Typhoon859

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]

Originally Posted by Didée

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]

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

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]

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

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]

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

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]

Originally Posted by Sagekilla

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]

Originally Posted by Sagekilla

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]

Originally Posted by Didée

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]

Originally Posted by Typhoon859

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]

Originally Posted by Jeremy Duncan

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]

Originally Posted by Typhoon859

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.

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]

Originally Posted by Typhoon859

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]

Originally Posted by neuron2

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]

Originally Posted by Typhoon859

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]

Originally Posted by 2Bdecided

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.