I propose a new resizing algorithm

[Katie Boundary]

I admit, I know very little about how resizing filters work. However, from what I've been able to gather, the most common resizing methods (nearest neighbor, bilinear, bicubic, lanczos) all have the same fundamental flaw: they treat pixels as points, rather than as cells. I'd like to propose a new way of doing things, which I am tentatively calling Grid Overlay resizing. It works like this: first, a grid is drawn with dimensions equal to the new resolution. Then, the original bitmap is painted over it, stretching and squooshing the pixels as necessary. Then, each cell in the grid is assigned a color value equal to the average of the colors in it, weighted by the percentage of that color's share of the cell's area. Then each cell becomes a pixel of that color in the new bitmap.

Example: let's say I want to resize a 6x4 image to 4x3.

Here's the original 6x4 image:

http://img.photobucket.com/albums/v415/DWJohnson/6x4_zpsvae0ikvv.jpg

Here's a 4x3 grid:

http://img.photobucket.com/albums/v415/DWJohnson/4x3grid_zpswmeiwsna.jpg

Here's the image painted onto the grid:

http://img.photobucket.com/albums/v415/DWJohnson/4x3overlay_zpsbqjfvymn.jpg

And then new pixels would be generated according to the average color within each cell. In the upper left cell, for example, total blackness (r0b0g0) accounts for 50% of its area, r51b0g0 accounts for 25% of its area, r0b0g85 accounts for 16.67% of its area, and r51b0g85 accounts for 8.33%, so the uppermost leftmost pixel in the new 4x3 image would be r17b0g22.

Does something like this exist? If not, who would I talk to about making it a reality?

[Asmodian]

If I understand it correctly this method is mathematically equivalent to bilinear (http://en.wikipedia.org/wiki/Bilinear_interpolation).

[feisty2]

what you are saying are basically the common steps of any typical resizer, the only difference between bilinear/cubic/sinc family/spline... is the convolution step (how you average the colors within one cell)
EDIT: there're a lot of alternative methods besides this, like vectorize (for CG contents), fractal, EDI (edge directed interpolation), AI (artificial intelligence, try to fill in imaginary details based on a trained neural network when upscaling, still a legend yet :))... and so many others, but most of them are not so practical, they are there like some theories, you got the idea, but you got no idea how to bring it to real life

[LoRd_MuldeR]

With all these considerations, you need to keep in mind that we are dealing with sampled signals here!

So while you screen shows "square" pixels and it fills the entire pixel area with the same color, as in your first picture, actually each color value (sample) only applies to an infinitely small point, located (e.g.) in the center of the pixel.

There is a very good explanation of "sampled" signals in this video, in the stairsteps chapter (he starts talking about audio, but goes on the images soon):
http://xiph.org/video/vid2.shtml

Nonetheless, what your "new resizing algorithm" actually does is:

It takes the existing sample points that are adjacent to the "new" sample point and weights them according to their distance from the "new" sample point. That's simple linear interpolation (http://en.wikipedia.org/wiki/Bilinear_interpolation) in the 2D space. And it's probably not that new ;)

[Katie Boundary]

If I understand it correctly this method is mathematically equivalent to bilinear (http://en.wikipedia.org/wiki/Bilinear_interpolation).

Then you're not understanding it correctly.

It takes the existing sample points that are adjacent to the "new" sample point and weights them according to their distance from the "new" sample point. That's simple linear interpolation (http://en.wikipedia.org/wiki/Bilinear_interpolation) in the 2D space. And it's probably not that new ;)

Nope. Imagine taking the 6x4 image and blowing it up to 60x40. The result would look a lot more like nearest neighbor resizing than bilinear.

[LoRd_MuldeR]

Nope. Imagine taking the 6x4 image and blowing it up to 60x40. The result would look a lot more like nearest neighbor resizing than bilinear.

I don't think so.

If we stick with your way of thinking of pixels as something that has an area (which is not quite correct, as it's actually a sampled signal), then the suggested "averaging" within each "cell" is equivalent a linear interpolation in 2D space.

Conversely, in order to get the equivalent to a "nearest neighbor" method, you would exclusively pick the color that has the biggest area within each "cell" - and totally ignore all other colors that may also appear in that "cell".

[Katie Boundary]

Okay, let's say we wanted to take a 2x2 image and resize it to 4x3.

Original image:

http://img.photobucket.com/albums/v415/DWJohnson/2x2_zpszdogbeqv.jpg

Painted onto a 4x3 grid:

http://img.photobucket.com/albums/v415/DWJohnson/4x3gridupfirst_zpskudtx8pb.jpg

Final 4x3 image:

http://img.photobucket.com/albums/v415/DWJohnson/4x3gridupfinal_zpsqvcpv0r1.jpg

Obviously not bilinear.

[LoRd_MuldeR]

Obviously not bilinear.

Not exactly. But only because you are still ignoring that Bitmap images actually are a sampled signal.

Actually, each color value (sample) applies only to an infinitely small point in the center of the pixel (regardless of how big or small you show the pixel) - not to the whole pixel area. See the video I linked above for details.

So the "blow up" that you are showing like this...
http://i.imgur.com/JsUYjIX.png

...actually it needs to look more like this - where the "white" area is not actually white but means "color not stored/known":
http://i.imgur.com/w04NBC4.png

(Yes, the second image is still not entirely correct. That's because the sample points actually would have to be infinitely small and thus would not actually be visible at all. But I think you get the idea ^^)

[vivan]

I think it's equal to upscaling using nearest neighbor by 2 times till resolution will be not lower than target, then bilinear downscaling. Which is even worse than bilinear.

Anyway, consider upscaling diagonal line - and you'll see why your method is bad.

[Katie Boundary]

you are still ignoring that Bitmap images actually are a sampled signal.

I'm ignoring it because it's neither relevant nor always true.

Anyway, consider upscaling diagonal line - and you'll see why your method is bad.

Okay, I'm considering it, and I'm not seeing why it's bad.

[LoRd_MuldeR]

I'm ignoring it because it's neither relevant nor always true.

It's in the nature of Bitmap images. So, in that sense, it is "always" true.

"Resizing" your original 2×2 image to 3×4 means that, originally, what we have are samples at red locations. And what we are interpolating (because this infomration is not present in the original image) are the samples at the green locations:

http://i.imgur.com/kWx5NPZ.png

[vivan]

Okay, I'm considering it, and I'm not seeing why it's bad.

http://i.imgur.com/Y9Nkcjq.png source
http://i.imgur.com/umzr90V.png nn to 80x40, then bilinear to 60x40. "your method"
http://i.imgur.com/TEjlfyp.png bilinear

[Katie Boundary]

It's in the nature of Bitmap images. So, in that sense, it is "always" true.

No, it isn't. Sampling is a method for producing digital data, NOT storing it, and bitmaps aren't waveforms, which is why thinking of pixels as samples is stupid and wrong. Pixels can represent samples/points, or they can represent areas, or they can represent LEGO blocks or anything else. But regardless of where pixels come from, once they exist, they are squares, which is why I'm treating them as such.

By the way, this would be a good time to admit that you were wrong about Grid Overlay being functionally the same as bilinear.

http://i.imgur.com/Y9Nkcjq.png source
http://i.imgur.com/umzr90V.png nn to 80x40, then bilinear to 60x40. "your method"
http://i.imgur.com/TEjlfyp.png bilinear

That's not my method, so your point is invalid.

[LoRd_MuldeR]

Sampling is a method for producing digital data

the method for producing digital data.

NOT storing it

Of course samples are not a method of storing data (and I never said that). They are that data that is stored.

and bitmaps aren't waveforms

Correct. But again, I never said that.

which is why thinking of pixels as samples is stupid and wrong.

Digital (raster) images are a sampled signal. Just like digital audio is a sampled signal too. There a different types of samples, my friend ;)

Heck, did you at least watch the video by Xiph.org that I linked above? It explains those fundamental things quite nicely, so I think I would be a good starting point.

A pixel, on the other hand, is the smallest area on your screen that can be filled with a distinct color.

It is important to understand that while a pixel does have an area, a sample does not! Assuming that a sample's color value applies to the entire pixel area (regardless of how small or large that pixel is) would "stupid and wrong".

[Groucho2004]

Just like digital audio is a sampled signal too.
Digital audio can just as well be synthesized.

[Katie Boundary]

the method for producing digital data.

ummm no. That's just wrong. When I write in a .txt file, that's not "sampling", but it's still digital data.

...which is irrelevant to the fact that you were wrong about bilinear resizing.

Of course samples are not a method of storing data (and I never said that). They are that data that is stored.

Only if the data was produced by sampling in the first place, which isn't always true...

...which is irrelevant to the fact that you were wrong about bilinear resizing.

Digital (raster) images are a sampled signal. Just like digital audio is a sampled signal too.

Again, not always. MIDI files, for example, aren't sampled :)

...which is irrelevant to the fact that you were wrong about bilinear resizing.

Heck, did you at least watch the video by Xiph.org that I linked above?

Yes, and he's wrong too.

Assuming that a sample's color value applies to the entire pixel area (regardless of how small or large that pixel is) would "stupid and wrong".

It certainly would be if we knew for sure that we were dealing with infinitely small sample points. In the real world, however, nothing is infinitely small... not even film grains or the little color-detectors in a digital camera.

...which is irrelevant to the fact that you were wrong about bilinear resizing.

[vivan]

That's not my method, so your point is invalid.It is.
1) For 2x upscaling factors it's nearest neighbor.
2) Then you average color by area, which is the definition of bilinear.

[LoRd_MuldeR]

ummm no. That's just wrong. When I write in a .txt file, that's not "sampling", but it's still digital data.

We were talking about multi-media data here and now you bring in something completely unrelated.

Anyway, text can be understood as a sampled signal just as well, because text is a sequence of discrete characters - just like audio is a sequence of discrete signal values and (raster) images are a sequence of discrete color values.

Only if the data was produced by sampling in the first place, which isn't always true...

Nope.

Again, not always. MIDI files, for example, aren't sampled :)

Sure it is! MIDI is a sequence of discrete notes, where each note (sample) has a distinct frequency value. And between two notes (samples) there is no information.

Is MIDI necessarily regularly sampled? Probably not, because the duration of notes may vary. But who said it is?

Yes, and he's wrong too.

So, Monty from Xiph.org, recognized Codec developer for many years, is wrong. But of course you are right. Nice try Troll :D

It certainly would be if we knew for sure that we were dealing with infinitely small sample points. In the real world, however, nothing is infinitely small... not even film grains or the little color-detectors in a digital camera.

Just like audio samples are discrete in time and thus have no duration (i.e they apply to an infinitely short time interval), image samples are discrete in location and thus have no area (i.e they a apply to an infinitely small points). Unless you understand and accept this simple fact, all further discussion is pointless...

Pixels, may it be on your screen or in the sensor of you camera, do have an area, yes! Still, the color value that is used to fill the pixel area is valid only in an infinitely small point, located usually (but not necessarily) in the center of that pixel.

[Katie Boundary]

It is.
1) For 2x upscaling factors it's nearest neighbor.
2) Then you average color by area, which is the definition of bilinear.

LOL nope. Go re-read the original description until you understand it :)

We were talking about multi-media data here and now you bring in something completely unrelated.

Does it matter whether I'm dicking around in Notepad or MS Paint? Either way, nothing is being sampled.

...which is irrelevant to the fact that you were wrong about bilinear resizing.

Anyway, text can be understood as a sampled signal just as well

...

Sure it is! MIDI is a sequence of discrete notes, where each note (sample) has a distinct frequency value. And between two notes (samples) there is no information.

...

Just like audio samples are discrete in time and thus have no duration (i.e they apply to an infinitely short time interval), image samples are discrete in location and thus have no area

Okay, I don't know what you think a "sample" is, but you're clearly not using the word the same way the rest of the English-speaking world does.

...which is irrelevant to the fact that you were wrong about bilinear resizing.

[vivan]

LOL nope. Go re-read the original description until you understand it :)1) show how scaling by 2x factor is done. That means from W x H to 2W x H. Then try to find any difference from nearest neighbor.
2) show how scaling from 2W x H to 1.5W x H is done. Then try to find any difference from (bi)linear.

[Katie Boundary]

1) show how scaling by 2x factor is done. That means from W x H to 2W x H. Then try to find any difference from nearest neighbor.
2) show how scaling from 2W x H to 1.5W x H is done. Then try to find any difference from (bi)linear.

Why should I bother with either of those things? Grid Overlay DOES. NOT. WORK. THAT. WAY.

[LoRd_MuldeR]

Okay, I don't know what you think a "sample" is, but you're clearly not using the word the same way the rest of the English-speaking world does.

So you are the person who defines what the "English-speaking world" does? (I'm glad that this is actually not the case)

Does it matter whether I'm dicking around in Notepad or MS Paint? Either way, nothing is being sampled.

MS Paint exclusively works with raster images, so it's all sampled data, obviously!


Anyway, since I'm getting tired of correcting all you pointless claims and factoids, I'm just switching to "don't feed the troll" mode for now ;)

[vivan]

Why should I bother with either of those things? Grid Overlay DOES. NOT. WORK. THAT. WAY.So, you don't even want to understand how your own method works? That's looks more like trolling instead of trying to understand anything.

[Katie Boundary]

So you are the person who defines what the "English-speaking world" does?

That's not even remotely close to what I said. you really LOVE strawman arguments, don't you?

https://yourlogicalfallacyis.com/strawman

MS Paint exclusively works with raster images, so it's all sampled data, obviously!

Wrong. Sampling is not the only way to get raster data!

I'm getting tired of correcting all you pointless claims and factoids

You haven't done that even once yet. Actually, it's your own pointless claims and factoids that have been getting corrected.

So, you don't even want to understand how your own method works?

I understand quite well how it works. You're the one who apparently doesn't want to understand it.

Here's a hint: if you were to actually resize a 20x20 image to 60x40 using Grid Overlay, the results would be the same as straight-up nearest neighbor resizing.

[Asmodian]

Here's a hint: if you were to actually resize a 20x20 image to 60x40 using Grid Overlay, the results would be the same as straight-up nearest neighbor resizing.

So point resize 1x, 2x, 3x, etc. in either dimension as needed to get to or above the target resolution and then bilinear resize down to the target if needed.

That is all it is.

[vivan]

I understand quite well how it works. You're the one who apparently doesn't want to understand it.

Here's a hint: if you were to actually resize a 20x20 image to 60x40 using Grid Overlay, the results would be the same as straight-up nearest neighbor resizing.Yeap. And so will "upscale to 80x40 using nn and then downscale to 60x40 using bilinear".
Time to shit bricks? ;)

[Asmodian]

Yeap. And so will "upscale to 80x40 using nn and then downscale to 60x40 using bilinear".
Time to shit bricks? ;)

It is actually just nn 20x20 to 60x40, no bilinear needed. It looks bad too but that is a different argument.

[StainlessS]

Katie Boundary,
Methinks tis time for you to take to the compiler and show those so-called-experts how to do it, it may take you some time, but twould be worth it,
and just think of the benefit to humankind, people would wrote odes about you and your quest to inform.
Just take care, there be big nasty dragons in them there woods, and poor little raptors could get gobbled right up.

[vivan]

It is actually just nn 20x20 to 60x40, no bilinear needed.Well... actually I'm thinking that for integer scaling factor those 2 ways might be equivalent (for the same reason his grid align, bilinear will sample only samples produced from 1 source pixel). I'm trying to find counter-example but I can't :rolleyes:

[Katie Boundary]

So point resize 1x, 2x, 3x, etc. in either dimension as needed to get to or above the target resolution and then bilinear resize down to the target if needed.

That is all it is.

I ran a quick test - taking a 2x2 image, point-resizing up to 6x6, and then bilinear resizing down to 5x5 - and the result was the same as Grid Overlay would have given... so it looks as though what you say might be true.

It is actually just nn 20x20 to 60x40, no bilinear needed.

Didn't I already say that?

It looks bad too but that is a different argument.

Your opinion of how it looks is irrelevant. It is the most mathematically correct representation of the original data. That's actually the one and only good thing about nearest neighbor resizing - it gives the most mathematically correct results when you're just multiplying each dimension by a whole number.

EDIT: oh wait, now I see what vivian was trying to say. And yes, there are some cases in which that gives the same results. However, it's still not quite the same. Extreme downsizing, for example, should look quite a bit different because bilinear is still only interpolating between four pixels whereas overlay would be averaging out much larger areas to generate each new pixel.

[feisty2]

Is dat so, y not just stick 2 point resize den, point resize is ALWAYS lossless wen upscaling
It does not suffer from inter factor limit at all

[vivan]

That's actually the one and only good thing about nearest neighbor resizing - it gives the most mathematically correct results when you're just multiplying each dimension by a whole number.Now take you unfounded belief about "mathematically correct results" away and you end up with the worst possible scaler.

[Katie Boundary]

Is dat so, y not just stick 2 point resize den

Because I'm not always upscaling by whole numbers, herp derp :rolleyes:

[feisty2]

Well... U actually can upscale decimal factors with point resize, try it urself

[Katie Boundary]

Well... U actually can upscale decimal factors with point resize, try it urself

You can, but then the results look like ass.

[feisty2]

gonna look like ass anyways if stays lossless...
what's the point

[Katie Boundary]

gonna look like ass anyways

Not if you multiply by a whole number

[Asmodian]

Your opinion of how it looks is irrelevant. It is the most mathematically correct representation of the original data. That's actually the one and only good thing about nearest neighbor resizing - it gives the most mathematically correct results when you're just multiplying each dimension by a whole number.

Are we are starting this argument again? :rolleyes:

Try this thought experiment: You take a 1280x960 image, resize it to 320x240, then resize it back to 1280x960. The most mathematically correct method would be the one that looks the most like the original 1280x960 image, wouldn't it?

[feisty2]

Your method and pointresize result da same wen upscaling inter factors like u said earlier
And still looks like ass...

[Katie Boundary]

Are we are starting this argument again? :rolleyes:

Try this thought experiment: You take a 1280x960 image, resize it to 320x240, then resize it back to 1280x960. The most mathematically correct method would be the one that looks the most like the original 1280x960 image, wouldn't it?

If by "looks the most like" you mean "deviates the least from the information of"...

Your method and pointresize result da same wen upscaling inter factors like u said earlier

What the hell does "upscaling inter factors" mean? Use English, please.

[Asmodian]

If by "looks the most like" you mean "deviates the least from the information of"...

Exactly. Hint: it isn't NN.

[Katie Boundary]

Exactly. Hint: it isn't NN.

Well anyone who uses nn for downsizing is an idiot. What's your point?

[feisty2]

Wow, partys getting a little bit tense now
I mean, "upscale by whole numbers" in ur word, like 2x 3x 4x...

[Katie Boundary]

Wow, partys getting a little bit tense now
I mean, "upscale by whole numbers" in ur word, like 2x 3x 4x...

Ah. Yes, in such cases, grid overlay and nearest neighbor both produce mathematically correct results. What's your point?

[Asmodian]

Ok, you use Grid Overlay (bilinear) to downscale. Now pick an upscaling method that gives an image most mathematically similar to the original. It isn't NN.

[vivan]

Extreme downsizing, for example, should look quite a bit different because bilinear is still only interpolating between four pixels whereas overlay would be averaging out much larger areas to generate each new pixel.That's how wrong downscaling works. With any scaler you should either increase number of taps (radius, aka the number of samples it reads), to cover the size of the resulting pixel or run it several times (google "mipmap"), each time with downscaling factor 2, till the factor is 2 or less. Of course proper implementations do that for you.

[feisty2]

Let's get this thing str8
First, u wanna lossless upscale algorithm
I said, pointresize is always lossless, upscale by whole numbers or not
You said the result will look like ass if upscale by decimal numbers
I said ur algorithm or pointresize, both gonna look like ass anyways
You said the result wouldn't look like ass if upscale by whole numbers
I said ur algorithm is equal to pointresize when upscale by whole numbers

Conclusion: why not just pick pointresize and everything would be alright

[Katie Boundary]

Ok, you use Grid Overlay (bilinear) to downscale.

LOL no, if you shrink both sides to 1/4 of their original length, then bilinear and grid overlay will give you different results. I already pointed that out earlier in the thread. Please try to pay attention! Grid overlay would use SIXTEEN pixels in the original image to calculate the value of each pixel in the reduced image. Bilinear would only take four into account.

But if you ran the original image through virtualdub's "2x2 non-overlapping matrix" twice, that WOULD give the same results as Grid Overlay. So let's do that.

Now pick an upscaling method that gives an image most mathematically similar to the original. It isn't NN.

I'll believe that when I see the signal-to-noise data.

That's how wrong downscaling works.

I think that was kind of my point.

str8

ENGLISH! DO YOU SPEAK IT?

[feisty2]

Str8=straight
I speak English indeed...

[vivan]

But if you ran the original image through virtualdub's "2x2 non-overlapping matrix" twice, that WOULD give the same results as Grid Overlay. So let's do that.Which is how proper bilinear downscaling works, so we are back to bilinear, second-to-worst scaler.

I'll believe that when I see the signal-to-noise data.You either reading or doing it wrong. On any frame any scaler (even bilinear!) gives higher PSNR than PointResize. It's really easy to check using avisynth: s = ffvideosource ("whatever.mp4")
d = s.BilinearResize (960, 540)
s1 = d.Lanczos4Resize (1920, 1080)
s2 = d.PointResize (1920, 1080)
r1 = Compare (s, s1).Crop (0, 0, 0, 200)
r2 = Compare (s, s2).Crop (0, 0, 0, 200)
StackVertical (r1, r2)You can use any scaler for downscaling, I've choosed bilinear because you like it. With better downscaler you'll get higher PSNR too.
It should be noted that PSNR is a bad metric, SSIM is a better one and the best one is human eye (that's why psnr/ssim optimised encoders are terrible, hello vp*).

ENGLISH! DO YOU SPEAK IT?He can't.

[StainlessS]

Never could.
Punk ass adolescent. :)

[Katie Boundary]

When Asmodian first proposed the 1280x960 thought experiment, I thought to myself "bilinear will only subjectively look better because humans tolerate blurriness much better than we tolerate blockiness. Mathematically, you might as well just be taking the point-resized image and smearing vaseline all over it. That's not going to result in more accurate data".

Last night, I decided to actually try the comparison. I didn't have my DVDs with me, so I had to use what was already on my drive, and I had only one thing that was non-interlaced and less than 40 minutes long: the final chapter of the theatrical cut of Alien 3. Why is this important? Because it has shots like these:

http://img.photobucket.com/albums/v415/DWJohnson/chainlink1_zpsw7bymoqn.jpg
http://img.photobucket.com/albums/v415/DWJohnson/chainlink2_zpsfzid4bky.jpg
http://img.photobucket.com/albums/v415/DWJohnson/chainlink3_zps49jemrnu.jpg
http://img.photobucket.com/albums/v415/DWJohnson/chainlink4_zps6lmszxac.jpg
http://img.photobucket.com/albums/v415/DWJohnson/chainlink5_zpsln2gq0ot.jpg
http://img.photobucket.com/albums/v415/DWJohnson/chainlink6_zpsfiakjz9e.jpg
http://img.photobucket.com/albums/v415/DWJohnson/chainlink7_zpsv4t2epfx.jpg

HOLY GOD, have you ever seen so many diagonal lines? LOL. That was when vivian's comment about diagonal lines finally clicked with Asmodian's comments about looking like the original image and I realized what you guys were talking about. Smearing vaseline on the point-resized images basically cuts corners off of pixels, which really DOES make those diagonal lines look more like they did in the original image :) There are tradeoffs elsewhere, of course (for example, sharp horizontal and vertical lines are better-preserved under nearest neighbor), but I get what you're saying now.

[colours]

I admit, I know very little about how resizing filters work.

It shows.

This is hardly a new idea; see http://entropymine.com/imageworsener/pixelmixing/. (I also came up with this independently circa 2011, fwiw.)

Anyway, it's not hard to show that while this grid overlay method is effectively a convolution of two box filters, just as the triangular kernel (aka bilinear resize) is, the triangular kernel always has the two box filters being of identical width, while grid overlay doesn't. In other words, it's not obvious that you should be able to emulate grid overlay with a nearest-neighbour up followed by a bilinear down, and indeed it's not always possible.

To modify an earlier example slightly, consider resampling from three samples to five. I'm not going to write out the calculations in detail, but take my word for it that if you label the three input samples x_0, x_1, x_2 and the five output samples y_0, y_1, y_2, y_3, y_4, we have the following.

Grid overlay:
y_0 = x_0
y_1 = (2x_0+x_1)/3
y_2 = x_1
y_3 = (x_1+2x_2)/3
y_4 = x_2

Nearest neighbour to six samples, then bilinear down to five:
y_0 = (x_{-1}+14x_0)/15
y_1 = (9x_0+5x_1)/14
y_2 = x_1
y_3 = (5x_1+9x_2)/14
y_4 = (14x_2+x_3)/15

Note that the boundary points actually also sample outside the original range, but even if you adopt the convention of extending the border pixels (as Avisynth, Imagemagick, etc. do), the second and fourth output samples will still differ between the two methods.

[vivan]

Dunno how/why avisynth calculates it that way, but shader sample centers of pixels.
Coordinates for texture with width of x pixels lie in range [0.5 / x, 1 - 0.5 / x]. Multiply by x and you'll be in range [0.5 .. x - 0.5].

For 6 to 5 (destination -> source (distance to centers)):
0.5 -> 0.6 (0.1, 0.9)
1.5 -> 1.8 (0.3, 0.7)
2.5 -> 3.0 (0.5, 0.5)
3.5 -> 4.2 (0.7, 0.3)
4.5 -> 5.4 (0.9, 0.1)

Then sampling is done:
y0 = x0 * 0.9 + x0 * 0.1
y1 = x0 * 0.7 + x1 * 0.3
y2 = x1 * 0.5 + x1 * 0.5
y3 = x1 * 0.3 + x2 * 0.7
y4 = x2 * 0.1 + x2 * 0.9

... and this is exactly what I'm getting in Paint.NET
http://i.imgur.com/SjXSSjx.png

Here's a visualization of weights:
http://i.imgur.com/J77hULO.png

Top ones are distances from the borders of source pixels to destination pixels (~area)
Middle ones are distances from centers to centers (like how shader samples stuff)
Bottom ones are rescaled destination coordinates for results to match top row (just plain stretch). Here's a formula
double recalc (double x, double y, double dst) {
double factor = (1.5 - y / x) * y / x;
return (dst - 0.5) * (y - 2.0 * factor) / (y - 1.0) + factor;
}(x and y are source and destination sizes, dst is coordinate of the destination to be rescaled)
I've checked and it works on other factors... So, well, it's still bilinear, but stretched by a fraction of pixel.

[colours]

Dunno how/why avisynth calculates it that way, but shader sample centers of pixels.

I didn't refer to what Avisynth did; the calculations were done by hand, also assuming centred sampling. You seem to be forgetting that the kernel should be enlarged to account for the fact that you're downsampling.

Alternatively, I could have made a dumb mistake somewhere.

But still, neither of our calculations for nearest neighbour → bilinear agree with grid overlay, which was kind of my point.

[Katie Boundary]

This is hardly a new idea; see http://entropymine.com/imageworsener/pixelmixing/.

It's new until someone actually implements it. I don't suppose you could point me to a plugin for AVIsynth or Vdub?

[colours]

It's new until someone actually implements it.

You are trolling, aren't you?

This is the first Google result for "netpbm pixel mixing". (http://netpbm.sourceforge.net/doc/pamscale.html)

It's also implemented in ImageMagick. (http://imagemagick.org/Usage/resize/#pixel_mixing)

In fact, that pixel mixing article I linked was from someone who wrote an image processing utility that implemented it (http://entropymine.com/imageworsener/).

Want it as an Avisynth filter? That's easily done with Dither_resize16(kernel="box").

[Katie Boundary]

This is the first Google result for "netpbm pixel mixing". (http://netpbm.sourceforge.net/doc/pamscale.html)

And I would have googled "netpbm" because...?

Want it as an Avisynth filter? That's easily done with Dither_resize16(kernel="box").

Cool. I assume that documentation related to this filter exists?

[Reel.Deel]

And I would have googled "netpbm" because...?
Because netpbm is quickly mentioned in the article that colours linked.
This document examines a common image resizing algorithm that doesn’t seem to have a standardized name. It’s sometimes called pixel mixing, pixel averaging, or area map, among other things. I’ll follow netpbm’s terminology, and call it pixel mixing.



Cool. I assume that documentation related to this filter exists?

Documentation for this filter does indeed exist.

[Katie Boundary]

Documentation for this filter does indeed exist.

I can has links please?

[TheSkiller]

I can has links please?
Why so lazy, don't you know how to use the board search?

The doc is in the download package of dither.

http://forum.doom9.org/showthread.php?p=1386559#post1386559

[Katie Boundary]

Why so lazy, don't you know how to use the board search?

more like "I had no idea what to search for"

EDIT: I can find nothing in the documentation to indicate that this is how the filter in question works.

[colours]

I don't normally mind spoonfeeding but you seem to think you have an IQ well above all the other posters here, so I'll refrain from that and let you educate yourself.

[…] this grid overlay method is effectively a convolution of two box filters […]

Hint: the key words are "convolution" and "box filters".

Discretisation of the above concepts is left as an exercise for the reader.

[Katie Boundary]

you seem to think you have an IQ well above all the other posters here

I started out humble, but repeated exposure to obvious idiocy changed my attitude somewhat. I'm as sensitive to logical fallacies and semantic dissonance as a shark's nose is to blood, and some of these posters are just hemorrhaging.

[…] this grid overlay method is effectively a convolution of two box filters […]

That's funny, I can't find that phrase anywhere in the Dither documentation.

[colours]

Firstly, it doesn't matter whether it's in Dither's documentation or not because, in case you can't put two and two together, I wrote that post before I even mentioned anything about Avisynth.

Secondly, it still doesn't matter because you're wrong anyway: Dither's documentation does in fact mention "box filter" and "convolution", albeit the discrete versions of them. If you're whining about the whole sentence I wrote not being in there, well duh, why would a sentence I wrote recently be in documentation written by someone else years ago? Since you didn't seem to get the hint earlier, let me make this explicit for you: search those terms on Google yourself.

You say other posters have exhibited "obvious idiocy", but have you ever looked in a mirror?

[Katie Boundary]

Firstly, it doesn't matter whether it's in Dither's documentation or not

It does when you're specifically responding to the statement "I can find nothing in the documentation to indicate that this is how the filter in question works."

[Bloax]

I started out humble, but repeated exposure to obvious idiocy changed my attitude somewhat. I'm as sensitive to logical fallacies and semantic dissonance as a shark's nose is to blood, and some of these posters are just hemorrhaging.
Your very first post wasn't exactly good, and the one after that (http://forum.doom9.org/showthread.php?t=171736) is complete trollbait.
You're the worst shitposter I've seen, but if it's just your autistic fury that flares up at every single post by anyone then you should probably just go away until you calm down.
Because until then everyone is definitely going to treat you like a shitposter.

[colours]

It does when you're specifically responding to the statement "I can find nothing in the documentation to indicate that this is how the filter in question works."

Of course you found nothing; that's just not how the filter in question works, and nobody claimed so. Did I say that implementing a grid overlay filter in Avisynth would involve a Dither_resize16 call and nothing else? (For the record, I wasn't even responding to that statement.)

Do yourself a favour and read up on some basic image processing before making another post in this thread.

[Katie Boundary]

Of course you found nothing; that's just not how the filter in question works, and nobody claimed so. Did I say that implementing a grid overlay filter in Avisynth would involve a Dither_resize16 call and nothing else?

You did. Your exact words were:

Want it as an Avisynth filter? That's easily done with Dither_resize16(kernel="box").

If you meant to say "That's easily done with Dither_resize16(kernel="box") and some other stuff", then you should have said that. For comparison, I have a multi-step process for dealing with hard-telecined content, and one of those steps is resizing, but if I told someone "IVTC is easily done with Dither_resize16(kernel="box")" and left out the separatefields step, they'd have every right to wonder what the hell I was going on about.

[Stereodude]

Your very first post wasn't exactly good, and the one after that (http://forum.doom9.org/showthread.php?t=171736) is complete trollbait.
You're the worst shitposter I've seen, but if it's just your autistic fury that flares up at every single post by anyone then you should probably just go away until you calm down.
Because until then everyone is definitely going to treat you like a shitposter.
Too bad we can't like posts on this forum because this one would gather a lot of them. I sense a lot of ignore lists growing.

[colours]

For comparison, I have a multi-step process for dealing with hard-telecined content, and one of those steps is resizing, but if I told someone "IVTC is easily done with Dither_resize16(kernel="box")" and left out the separatefields step, they'd have every right to wonder what the hell I was going on about.

I'd have every right to wonder why the hell you think that resizing is in any way a core part of inverse telecine.

Maybe this is one of those "strawman" (https://yourlogicalfallacyis.com/strawman) arguments you yourself brought up earlier? :rolleyes:

[Katie Boundary]

I'd have every right to wonder why the hell you think that resizing is in any way a core part of inverse telecine.

lol that too :)

Maybe this is one of those "strawman" (https://yourlogicalfallacyis.com/strawman) arguments you yourself brought up earlier? :rolleyes:

How? Nobody's position has been misrepresented in the past several posts.

EDIT: perhaps we should clarify which definition of convolution (http://en.wikipedia.org/wiki/Convolute) we're using so that the discussion is less opaque. I'm only familiar with the convolution matrices in Vdub and AVIsynth that are used for sharpening, blurring, emboss effects, etc.

[colours]

EDIT: perhaps we should clarify which definition of convolution (http://en.wikipedia.org/wiki/Convolute) we're using so that the discussion is less opaque.

https://en.wikipedia.org/wiki/Convolution#Definition

Take note that the domain we're talking about is ℝ^2, not ℤ^2; in other words, stop thinking about pixels as being square boxes and instead treat them as point samples, like people have been telling you to since the very first page of this thread.

[Katie Boundary]

Take note that the domain we're talking about is ℝ^2, not ℤ^2

Yeah i dunno what that means lol

in other words, stop thinking about pixels as being square boxes and instead treat them as point samples

But they're squares :/

[Katie Boundary]

if it's just your autistic fury that flares up at every single post by anyone

I made this just for you: :cool:
Image removed by mod manono
Clean up your act Miss Boundary or we'll clean it up for you.

[jmac698]

Hmm this thread didn't seem to go anywhere productively, but I read it with interest back when. I was gonna write this filter but then found some programs that already did it, so let me give you the answers you were wondering about.

This has gone by names like pixel mixing or area scaling. Here's places that discuss it:

http://entropymine.com/imageworsener/pixelmixing/
https://tpgit.github.io/UnOfficialLeptDocs/leptonica/scaling.html#area-mapping-or-area-averaging-and-lowpass-filtering
http://netpbm.sourceforge.net/doc/pamscale.html#mixing

In summary:
-keeps overall brightness the same
-good quality for downsizing
-causes a small amount of aliasing/moire and doesn't reduce aliasing
-for large scaling is like a box filter or almost pixel replication
-trapezoidal at 2x or 1/2x
-can be approximated with standard filter kernels (which are chosen depending on scale)
-good at downscaling between .2 and .7

You can download binaries for windows here:
https://onedrive.live.com/?cid=9E7DB242359A93F0&id=9E7DB242359A93F0!28283

use pamscale function.

[pandy]

But they're squares :/

This one bellow should help you to understand basic sampling concepts: http://www.youtube.com/watch?v=cIQ9IXSUzuM
It is for audio but this particular topic (squares) are mentioned as one of the examples - watch carefully especially from 5:15 (squares appears in 8:10).

[jmac698]

She hasn't been active since May, maybe ppl scared her away lol

[Katie Boundary]

I'm resurrecting this topic because, in the past month, I've gained a better understanding of things like the difference between "interpolation" and "filtering" in a signal-processing context, how larger support sizes improve anti-aliasing, etc. and I felt like re-evaluating my approach.

For downscaling, this method really is 100% mathematically perfect in every possible way. It doesn't produce the oversharpening of Simpleresize (approaching Nearest Neighbor-like effects at extreme scaling factors), nor the overblurring of a box or triangle filter. Its suitability for downscaling is reason enough on its own to add it to programs like AVIsynth and Virtualdub.

Upscaling reveals something more interesting. When upscaling, its major advantage is also its biggest downfall: it is content-neutral. Pixel Mixing simply doesn't care whether the image being resized is a photograph, a CAD image, pixel art, or whatever. This makes it by far the best upscaler for images that are expected to look pixelated, but pretty terrible for anything that you're likely to rip from a DVD or Blu-Ray.

[Nevilne]

She hasn't been active since May, maybe ppl scared her away lol

welp, here goes that wish

[Katie Boundary]

It looks like Chikuzen wrote one of these approximately four years ago: http://www.mediafire.com/file/kn56wh7r81vk2rx/AreaResize-0.1.0.zip

However, it didn't get very far. Are there any known bugs or deficiencies?