Spline Resize vs. Lanczos Resize

[Typhoon859]

Believe it or not, I'm actually asking a question... More specifically though, what are the real differences between Spline16Resize for example vs. LanczosResize? What are the pros and cons of one as opposed to the other?

-I'm just looking for the one resize that I can permanently use to upscale. I want to just find and use one. Or... is that stupid just mentioning? Like, I don't understand what the different situations are to use one resizer vs. another...

[TheRyuu]

There's a massive spline vs lanczos thread somewhere.

IMO, spline is definitely better at downsizing (less halos, blackman fixes this as far as tap resizers), as for other stuff, it's whatever.

[Typhoon859]

Maybe somebody can direct me to a thread or a page that explains the differences between Spline16, Spline36, etc... And then maybe another or the same page which describes lanczos. I used all possible resizes and compared the same frame with each of them and it was hard to tell specifically what the differences were in most cases. I did end up liking regular lanczos and Spline16 the best though.

[Video Dude]

LanczosResize is an alternative to BicubicResize with high values of c about 0.6 ... 0.75 which produces quite strong sharpening. It usually offers better quality (fewer artifacts) and a sharp image.

Lanczos was created for AviSynth because it retained so much detail, more so even than BicubicResize(x,y,0,0.75). As you might know, the more detail a frame has, the more difficult it is to compress it. This means that Lanczos is NOT suited for low bitrate video, the various Bicubic flavours are much better for this.


Spline16Resize & Spline36Resize & Spline64Resize

Three Spline based resizers. The rational for Spline is to be as sharp as possible with less ringing artefacts as LanczosResize produces. Spline16Resize uses sqrt(16)=4 sample points, Spline36Resize uses 6 sample points, etc ... The more sample points is used, the sharper your clip will get.


http://avisynth.org/mediawiki/Resize

[Sagekilla]

Try downsampling a high detail 1080p frame to 480p using the Spline and Lanczos resizers ;) Interleave + AvsP make for a very useful combo for seeing the differences between the two.

[Typhoon859]

Try downsampling a high detail 1080p frame to 480p using the Spline and Lanczos resizers ;) Interleave + AvsP make for a very useful combo for seeing the differences between the two.

Well, I don't have a blu-ray player on my PC but I'm more interested in upscaling. I'm convinced Spline16 is the best for downsampling.

[Sagekilla]

You don't need a blu-ray player. Try downloading a nice high resolution image with a good level of detail off google, that works just as good. Personally, I prefer Spline36 because I tend to denoise after downsampling (1080p -> 720p).

But, remember it's your eyes: If spline16 is what looks best stick with it :)

[Typhoon859]

You don't need a blu-ray player. Try downloading a nice high resolution image with a good level of detail off google, that works just as good. Personally, I prefer Spline36 because I tend to denoise after downsampling (1080p -> 720p).

But, remember it's your eyes: If spline16 is what looks best stick with it :)

Alright, I'll try that. Meanwhile, it'd be cool to hear people's opinions on upscaling. To truly understand what even just I consider best, I need to comprehend the differences and at least the basics of what's going on with one resizer as opposed to another, more specifically the ones I mentioned..

[*.mp4 guy]

IIRC spline26's[edit:spline16's] kernel is slightly unbalanced. That said, people apear to like it anyway.

eedi2 and nnedi both work well on cartoons, eedi being better for heavily damaged sources, and nnedi being better for high quality sources. However eedi2 or nnedi alone aren't really enough to justify upscaling beofre encoding.

[Sagekilla]

@M4G: How is the Spline36 kernel unbalanced (out of curiosity)? What kind of a difference does that make?

[Typhoon859]

IIRC spline26's kernel is slightly unbalanced. That said, people apear to like it anyway.

eedi2 and nnedi both work well on cartoons, eedi being better for heavily damaged sources, and nnedi being better for high quality sources. However eedi2 or nnedi alone aren't really enough to justify upscaling beofre encoding.

As I've proven to myself with comparisons, upscaling helps a lot with the picture because then, a higher bitrate is justifiable. Here's one example. (These frames are captured with Print Screen - all decoded by FFDShow.)

Original
http://www.mybloop.com/get/3545427/Original.png


Import("C:\Program Files (x86)\AviSynth 2.5\plugins\LimitedSharpen.avs")

crop(2,2,-2,-2,true)

FFT3DFilter(sigma=2.5)
UnDot()
FluxSmoothST(7,7)

Toon(.6)

Tweak(sat=1.12, cont=1.02)

Spline16Resize(704,396)

LimitedSharpen(ss_x=1.0,ss_y=1.0,Smode=3,strength=20)

x264 @ 1500 kbps
http://fs10.mybloop.com/image-handler/optimized/48/3545423


Import("C:\Program Files (x86)\AviSynth 2.5\plugins\LimitedSharpen.avs")

ColorMatrix(mode="Rec.601->Rec.709")

crop(2,2,-2,-2,true)

FFT3DFilter(sigma=2.5)
UnDot()
FluxSmoothST(7,7)

Toon(.3)
LimitedSharpen(ss_x=1.0,ss_y=1.0,Smode=3,strength=30)
WarpSharp(25,1)

Tweak(sat=1.12, cont=1.02)

LanczosResize(1280,720)

x264 @ 3000 kbps
http://www.mybloop.com/get/3545429/Typhoon859_(HD).png

Yes, obviously if I made the bitrate higher for the Non-HD encode, the quality of it would've been better but then, same goes for the HD one. The higher bitrate is justified for it and it isn't unreasonable.

-BTW, NNEDI isn't a resizer.. right?.. I'm not too sure what it does actually although I've heard about it at least 20 times, honestly. But, I'm pretty sure it doesn't have anything to do with resizing which is what I was talking about. I might be saying something stupid though, idk...

[*.mp4 guy]

@M4G: How is the Spline36 kernel unbalanced (out of curiosity)? What kind of a difference does that make?

spline36 is balanced, spline16 (which is what I meant to type) is not. It oversharpens the image, if you iterate it it will quickly do far more damage then any other balanced linear interpolator in avisynth.

[leeperry]

I'd swear that I read that bilinear was the best for dowscaling..

[2Bdecided]

I think it's worth pointing out that the differences aren't really that great - especially where there isn't that much high frequency content in your original.

I know there are differences, but you've got to put it in perspective.

Cheers,
David.

[Typhoon859]

I think it's worth pointing out that the differences aren't really that great - especially where there isn't that much high frequency content in your original.

I know there are differences, but you've got to put it in perspective.

Cheers,
David.

Well, the reason I posted this frame in particular is because the x264 codec always has trouble with details in really dark areas. I wanted to show how it dealt with it in the HD encode as opposed to the 704x396 one. Obviously, it's the higher bitrate that allowed more details to be captured in the encode, but there was a significant amount of extra pixels to work with... So, I dunno, I guess this also boils down to opinion. I feel that it is worth it, though I still doubt I will be encoding in HD, lol.

EDIT: If you compare the actually video footage, you'd also see how much smoother the HD encode looks due to the fact of how much less jittery lines there are. Practically none compared to the non-HD encode.

[Typhoon859]

spline36 is balanced, spline16 (which is what I meant to type) is not. It oversharpens the image, if you iterate it it will quickly do far more damage then any other balanced linear interpolator in avisynth.

There seriously wasn't that much a difference. I made comparisons of different resizers. What I noticed was that when I upscaled with Spline16, more details were left in-tact. The sharpness was identical. If you want, I can post those frames.

[Typhoon859]

I'd swear that I read that bilinear was the best for dowscaling..

Lol, ok, I'll check it out. That's one resizer I never actually checked out. I just felt that it really sucked as opposed to most others. Maybe not for downsizing though.

[2Bdecided]

I feel that it is worth it, though I still doubt I will be encoding in HD, lol.Sorry, I meant the different resizers only cause a very small difference from each other - not that resizing itself only causes a small difference vs not resizing.

I was replying to the thread title, not the previous post - sorry, I should have quoted!

Cheers,
David.

[Typhoon859]

Sorry, I meant the different resizers only cause a very small difference from each other - not that resizing itself only causes a small difference vs not resizing.

I was replying to the thread title, not the previous post - sorry, I should have quoted!

Cheers,
David.

Oh, alright. Well yeah, you're certainly right. Some resizers have a big difference but to what I was asking for, yeah, I know. I mainly wanted to know the differences between how they work. No matter how subtle the difference, I like to be sure that I'm doing the best thing.

[Sagekilla]

All of the Spline and Lanczos resizers are very sharp. The differences between Spline16, 36, and 64 are minute. Likewise, for Lanczos(taps=0-10). There's not much comparison to be done between Spline16 and Spline36, but vs the other resizers like Bicubic, Bilinear, etc there is a worthwhile comparison to be made.

IMO:
Spline64 > Spline36 > Spline 16 > Bicubic ~= Gauss >= Bilinear
Spline >= Blackman > Lanczos

Bilinear is the softest I know of, while Gauss* has adjustable sharpness. Bicubic is sort of like Gauss except you can make it absurdly sharp and ringy, or very blurry (by adjusting b and c). IIRC, at c=0.6 or higher, Bicubic rings too much and Lanczos does better. Spline is sharp like Lanczos, but doesn't ring from what I've seen. Blackman on the other hand, I haven't used much but it seems to be very similar to Spline.


*Gauss is interesting, if you use too low of a p the image is completed blurred. Otherwise, it's like a slightly softer bicubic to me.

[Typhoon859]

All of the Spline and Lanczos resizers are very sharp. The differences between Spline16, 36, and 64 are minute. Likewise, for Lanczos(taps=0-10). There's not much comparison to be done between Spline16 and Spline36, but vs the other resizers like Bicubic, Bilinear, etc there is a worthwhile comparison to be made.

IMO:
Spline64 > Spline36 > Spline 16 > Bicubic ~= Gauss >= Bilinear
Spline >= Blackman > Lanczos

Bilinear is the softest I know of, while Gauss* has adjustable sharpness. Bicubic is sort of like Gauss except you can make it absurdly sharp and ringy, or very blurry (by adjusting b and c). IIRC, at c=0.6 or higher, Bicubic rings too much and Lanczos does better. Spline is sharp like Lanczos, but doesn't ring from what I've seen. Blackman on the other hand, I haven't used much but it seems to be very similar to Spline.


*Gauss is interesting, if you use too low of a p the image is completed blurred. Otherwise, it's like a slightly softer bicubic to me.

"Spline64 > Spline36 > Spline 16 > Bicubic ~= Gauss >= Bilinear
Spline >= Blackman > Lanczos" - That's in terms of sharpness right?

Umm, in terms of sharpness, the default for Spline and Lanczos are pretty identical.. The differences I see are how it effects minor details, especially blurry details. That's actually why I prefer Spline16 over 36/64. It seems to preserve minor details better with almost identical sharpness.

-Thanks

[Sagekilla]

Yes, in terms of sharpness. Spline and Lanczos are pretty much identical for all intents and purposes. The biggest difference is spline tends to ring a lot less than lanczos. Also, Spline64 should retain more fine detail than Spline16 when downscaling, and do a better job when upscaling too.

4096x2304 -> 768x432 -> 1920x1080:

Lanczos4
http://img15.imageshack.us/img15/9646/lanczos4es4.png
Spline64
http://img16.imageshack.us/img16/9894/spline64io5.png

Both have ringing around the pole. But the spline is more controlled. (Zooming 200% or 300% helps a bit here)

[Typhoon859]

Yes, in terms of sharpness. Spline and Lanczos are pretty much identical for all intents and purposes. The biggest difference is spline tends to ring a lot less than lanczos. Also, Spline64 should retain more fine detail than Spline16 when downscaling, and do a better job when upscaling too.

4096x2304 -> 768x432 -> 1920x1080:

Lanczos4
http://img15.imageshack.us/img15/9646/lanczos4es4.png
Spline64
http://img16.imageshack.us/img16/9894/spline64io5.png

Both have ringing around the pole. But the spline is more controlled. (Zooming 200% or 300% helps a bit here)

Hmmm, well actually, when I zoom in, I can see that Lanczos4 produces a bit sharper image. There's more ringing from the resize probably because of the extra sharpness. The ringing is sharpened as well XD

In the end, it just narrows down to what is your preference. Comparing such subtle differences can drive a person crazy, with your face all up in the screen, lol

[Seraphic-]

How does Spline64 compare to Spline36 for upscaling (and some downscaling)?

[Typhoon859]

How does Spline64 compare to Spline36 for upscaling (and some downscaling)?

These are upscales from 720x480 to 1280x720. Try to see the difference for yourself. What I see is that Spline64 is a bit sharper but at the same time, if you look at the roof on the bottom left corner of the picture (the one above the window), it removes a bit of details. On the top right section of that section of the roof XD Open the two pictures in two different tabs and switch between them after you maximized them. Scroll both to the bottom-left so that you can see that roof area first though. Maybe it'd be more apparent if I resized it even more.

Spline36
http://fs10.mybloop.com/image-handler/optimized/48/3550595

Spline64
http://fs10.mybloop.com/image-handler/optimized/48/3550599

[Sagekilla]

Wait, did you upscale it then encode it? Because it looks like you did (and that's the wrong thing to do). Those two images should look nearly identical, but in the bottom left corner there's a lot of differences. If you're comparing resizers, don't encode. Just save the raw frame directly out of AvsP or your GUI of choice as a png.


What you just did is compare how whatever encoder handles spline36 vs spline64, not the actual sharpness.

[Typhoon859]

Wait, did you upscale it then encode it? Because it looks like you did (and that's the wrong thing to do). Those two images should look nearly identical, but in the bottom left corner there's a lot of differences. If you're comparing resizers, don't encode. Just save the raw frame directly out of AvsP or your GUI of choice as a png.


What you just did is compare how whatever encoder handles spline36 vs spline64, not the actual sharpness.

Well, yeah. That's the point. I did the resize from 720x480 to 1280x720, then used the x264 codec to encode the clip @ 5000kbps. x264 is what I'm always going to use so this particular comparison I actually made for myself. I want to see how differently each one works with the codec. What's the point of testing it without the effect that the codec you're going to use has? You might get the exact opposite results in terms of what's better/worse..

[Sagekilla]

You're missing my point. If you're comparing the sharpness of one resizer to another, you need to do so based on the raw output from the resizers.

What if we decided to sharpen a 720p image with two different resizers, then compressed them as jpgs @ 100 KB for both files? How could you tell that one sharpener does a better job at sharpening? In this case, it would be the one that comes out the crappiest looking, because sharp images tend to take more bits than softer images. If you keep the bitrate the same, then the sharper one is going to lose sharpness and generally turn into a horrible mess compared to the soft one, which will compress nicer.


That's fine if you want to compare it when you're encoding, but if you're talking about the properties of the resizers themselves then you shouldn't be encoding them. Plus, if you take into account sharpness/complexity determines image size, the fact that Spline64 "has less details" is completely logical when you consider you're using a fixed bitrate.

[Typhoon859]

You're missing my point. If you're comparing the sharpness of one resizer to another, you need to do so based on the raw output from the resizers.

What if we decided to sharpen a 720p image with two different resizers, then compressed them as jpgs @ 100 KB for both files? How could you tell that one sharpener does a better job at sharpening? In this case, it would be the one that comes out the crappiest looking, because sharp images tend to take more bits than softer images. If you keep the bitrate the same, then the sharper one is going to lose sharpness and generally turn into a horrible mess compared to the soft one, which will compress nicer.


That's fine if you want to compare it when you're encoding, but if you're talking about the properties of the resizers themselves then you shouldn't be encoding them. Plus, if you take into account sharpness/complexity determines image size, the fact that Spline64 "has less details" is completely logical when you consider you're using a fixed bitrate.

Wow. That made so much sense. Just from that, I feel like I know twice as much. Really, thanks. Good stuff, good stuff ;)

[Sagekilla]

I mean, if you want to compare how well a resizer does when you're encoding, you're doing it absolutely the right way. I'm just saying that for sharpness comparisons you have to be careful how you do that ;)

[naughty21]

thanks for the info but i have a doubt that for below 720x320 which is good and for 480p and 720p which one is good

[JohannesL]

www.sm64.org/div/Bilinear0.png
www.sm64.org/div/Spline360.png

640x480 to 320x240
Spline36 is sharper, but both look good to me.

[unix_sansei]

why don't you try using wavelets for resizing? sometimes they ring a bit but they are fast to implement, easy up and downscaling.

[leeperry]

www.sm64.org/div/Bilinear0.png
www.sm64.org/div/Spline360.png

640x480 to 320x240
Spline36 is sharper, but both look good to me.
so whatever upscaling/downscaling, spline36 is your best option? I think that's what ffdshow is using?

w/ CoreAVC CUDA doing the decoding, I can spline anything I'd like now :D

mostly SD>720p and 1080p>720p

[*.mp4 guy]

why don't you try using wavelets for resizing? sometimes they ring a bit but they are fast to implement, easy up and downscaling.

Unless you are using overcomplete wavelets and some sort of nonlinear coefficient filtering, the results are going to be equivelent to a FIR filter, just as lanczos/spline/etc. are equivelent to FIR filters.

[unix_sansei]

Unless you are using overcomplete wavelets and some sort of nonlinear coefficient filtering, the results are going to be equivelent to a FIR filter, just as lanczos/spline/etc. are equivelent to FIR filters.

well yes, non-linear coefficients are the way to go. you can throw a myriad of different weightings and basis functions at the image with wavelet. you can also reuse similar code for resize as well as noise reduction, deblurring etc without the high frequency filtering of DCT.

i don't particularly like them because for big images 4k x 6k they get 'lost' in the complex wilderness but for small DVD images they seem to work well.

[halsboss]

Spline64 should retain more fine detail than Spline16 when downscaling, and do a better job when upscaling too.Is Spline64 available in the current MT version of avisynth (2.5.7 I think) ? Blackman ? If not, is there a plugin ?

[buletti]

Is Spline64 available in the current MT version of avisynth (2.5.7 I think) ? Blackman ? If not, is there a plugin ?

in 2.5.7 spline64 is not avaialble (also in the MT version). About blackman I'm not sure.
However, there is a modded 2.5.8 MT (http://forum.doom9.org/showthread.php?t=144852) version now which is capable of both.

[Betsy25]

I think Spline is recommended at downsizing resolution-wise.
but Lanczos is definatelly recommended at downsizing filesize-wise.

[cogman]

I don't get it. Why would you upscale the image before encoding it? If it is to justify the large bitrate, well, tell the encoder to use more bits rather then throw more at the image.

Yeah, I could see it if you are targeting a specific device that doesn't support upscaling/does a crappy job at it. However, most are generally pretty good at it.

[Typhoon859]

I don't get it. Why would you upscale the image before encoding it? If it is to justify the large bitrate, well, tell the encoder to use more bits rather then throw more at the image.

Yeah, I could see it if you are targeting a specific device that doesn't support upscaling/does a crappy job at it. However, most are generally pretty good at it.

Yeah. It's pretty much to justify the larger bitrate. @3500kbps for a 1280x720 resolution, you get less detail loss than @1400kbps for a 704x396 resolution. Anything above that bitrate for a non-HD video is just unreasonable. Plus, the lines are very obviously less jittery and the sharpening seems to work more effectively. Overall, the video looks better, even with a bitrate that makes just as much detail loss at the HD resolution vs. the SD one.

[cogman]

Well, use 2000 kbps instead of 1400 kbps on the video then. Heck use 3500 kbps on the source rather then upscaling the image, and you'll get a better quality video then if you where to use 3500 kbps on the upscaled image.

I don't see why a bitrate higher then 1400 is unreasonable for a non HD source, Very often I will use somewhere around 2000 on non-hd material (CRF is awesome that way).

If getting rid of jitters and better sharpening is the goal, I would suggest this. Upscale the image, do whatever processing you are doing now, and then downscale the image to its original resolution. Just make sure that when you upscale it you do it by an evenly divisible number (preferably a power of 2) to keep it from loosing data from the scaling. (this technique is somewhat the same as what your video cards do when they do anti-aliasing)

For example, your 704x396 image could go up to 1408x792, and shouldn't loose any data from the scaling.

[Typhoon859]

Well, use 2000 kbps instead of 1400 kbps on the video then. Heck use 3500 kbps on the source rather then upscaling the image, and you'll get a better quality video then if you where to use 3500 kbps on the upscaled image.

I don't see why a bitrate higher then 1400 is unreasonable for a non HD source, Very often I will use somewhere around 2000 on non-hd material (CRF is awesome that way).

If getting rid of jitters and better sharpening is the goal, I would suggest this. Upscale the image, do whatever processing you are doing now, and then downscale the image to its original resolution. Just make sure that when you upscale it you do it by an evenly divisible number (preferably a power of 2) to keep it from loosing data from the scaling. (this technique is somewhat the same as what your video cards do when they do anti-aliasing)

For example, your 704x396 image could go up to 1408x792, and shouldn't loose any data from the scaling.

I say that more than 1400kbps is unreasonable because it just is... The size of the 24 min video ends up being a size like no other SD video I've ever seen encoded. In terms of your suggestion, it sounds interesting and very plausible though I'm not too sure how to do it. I upscale the video at the very end. If right after that, I downscale it, I don't see how it will make a difference. The actual encoding will take place on the latest resolution set. I will try it though. I sorta understand how it could help though based on your description of most video cards. I just downsize it back to it's original resolution at the end, right after I upscale?

[Sagekilla]

@cogman: When you're working with real life type content, there's no real point in trying to upscale content (Unless you're doing something like combining HD and SD content). In Typhoon's case, where he's working with animated video, you can take advantage of nice resizers like NNEDI and get very good results.

I've done a few SD -> HD conversions on animated video, and it can come out very nicely, especially when displayed on a high res screen. Since I have the advantage of using high quality (but slow) filters to produce that HD output, I don't have to deal with the lower quality resizer built into many software players.

[Typhoon859]

@cogman: When you're working with real life type content, there's no real point in trying to upscale content (Unless you're doing something like combining HD and SD content). In Typhoon's case, where he's working with animated video, you can take advantage of nice resizers like NNEDI and get very good results.

I've done a few SD -> HD conversions on animated video, and it can come out very nicely, especially when displayed on a high res screen. Since I have the advantage of using high quality (but slow) filters to produce that HD output, I don't have to deal with the lower quality resizer built into many software players.

So you also think it is worth upscaling to produce better quality? And yeah, especially on a high resolution screen - the difference is there.

[Jeremy Duncan]

[QUOTE=Typhoon859;1253463]Believe it or not, I'm actually asking a question... More specifically though, what are the real differences between Spline16Resize for example vs. LanczosResize? QUOTE]

Play my test disks with either resizer and see which result you like better: http://forum.doom9.org/showthread.php?t=140747

[Typhoon859]

[QUOTE=Typhoon859;1253463]Believe it or not, I'm actually asking a question... More specifically though, what are the real differences between Spline16Resize for example vs. LanczosResize? QUOTE]

Play my test disks with either resizer and see which result you like better: http://forum.doom9.org/showthread.php?t=140747

I will, thanks.

[*.mp4 guy]

Just make sure that when you upscale it you do it by an evenly divisible number (preferably a power of 2) to keep it from loosing data from the scaling. (this technique is somewhat the same as what your video cards do when they do anti-aliasing)

For example, your 704x396 image could go up to 1408x792, and shouldn't loose any data from the scaling.

unless you are pointresizing up and boxresizing, or pointresizing down, you are losing data.

Interpolation with anything other then an integer power upscale with pixel duplication IE pointresize is lossy. Downscaling is always lossy, unless you are downsizing a previously pixel duplicated/pointresized image, by a factor of the original upscale integer, using either box or pointresize/pixel decimation.

For all practical purposes interpolation is always lossy, but the loss is of managable size and very rarely easily noticible after only one or two interpolation operations with good linear interpolation.

[Gavino]

Interpolation with anything other then an integer power upscale with pixel duplication IE pointresize is lossy.
That's right. Naively, one might think that upscaling by a factor of 2 would at least preserve the original pixels, but that's only true for PointResize. All the other resizers preserve the image center position, so all output pixels end up being interpolated.

(If we number the original pixels 0, 1, 2, ..., then the output pixels correspond to positions -0.25, 0.25, 0.75, 1.25, ...)

Interestingly (or maybe not :)), it turns out that upscaling by an odd integer factor actually does preserve the original pixels amongst the interpolated ones. For example, for x3, we get pixels corresponding to -1/3, 0, 1/3, 2/3, 1, ...

[*.mp4 guy]

iirc, even for 3x, 5x, etc. upscales, the center pixel is stil processed by some of the taps of the filter, IE, for 3x, the center pixel does not get processed by the main blurring lobe, but it gets hit by the following sharpening, and bluring lobes (assuming 3 tap interpolation), I'm not sure how the internals of the functions work, so the center pixels may be bypassed, but otherwise, it is as good as impossible to preserve any of the original pixels. Furthermore, even for 3x, etc. upscaling, you would have to use pointresize downscaling, selecting only the unprocessed pixel positions to get back to where you started, and If you do that instead of at least using box downsizing, their isn't any point in upscaling at all.