When is PointResize NOT Reversible?

[zerowalker]

Not sure if this only rules for Pixel games, but as you may know, PointResize can be used to increase the size, and then if you want you can decrease it and it will be identical.

However, to do this you must follow certain rules, and i am not completely sure of those rules, though i think i know it, but rather ask here.

For example, if i want a resolution from 240x160 to come as close to a height of 1200, do i have to take 160 and simply multiply it until it get's close?

Meaning it can never reach 1200 exactly, and i can only choose from 1120/1280?

Or is there some workaround?


Conclusion Below:

PointResize is Only reversible when it's multiplied by an integer. 120x1.5 = Wrong, 120x2 = Correct.

However there is a way to bypass that according to Gavino:

Originally Posted by Gavino

PointResize can also be reversed (as all the original pixels are still there), but it requires using the 'offset' parameters src_top and src_left.

For example, starting with a 320x240 clip,
PointResize(800, 600) # 2.5x upscale, AB->AAABB
is not recovered by
PointResize(320, 240) # AAABB->AA
but can be losslessly reversed by
PointResize(320, 240, 1, 1) # AAABB->AB

The actual offsets required are different for each case and can be tricky to work out.
For RGB inputs, you also have to remember that Avisynth stores them upside down, so the vertical offset may be different.

Leaving PointResize to be quite Flexible, though you would need to do the manual calculation to reverse it, (perhaps it could be made Automatic if it knew the Original Size?).


Thanks for all information

[JReiginsei]

Maybe you can use the technique from this post:

http://www.libretro.com/forums/viewt...hp?f=31&t=1712

PointResize to 1280 and then downscale to 1200 with Bilinear or another resizer.

[zerowalker]

That isn't exactly what i am looking for, any resize besides Point will break the pixels causing a huge difference in compression, and also cause a blurriness to the eyes, even though that site talks about using 2 resizes to minimal loss, but still a loss is a loss.

[Guest]

Originally Posted by zerowalker

For example, if i want a resolution from 240x160 to come as close to a height of 1200, do i have to take 160 and simply multiply it until it get's close?

Meaning it can never reach 1200 exactly, and i can only choose from 1120/1280?

Or is there some workaround?

For point resize you need an integer ratio. 1200 / 160 is not an integer.

But you could have a metapattern of point replication, i.e, alternate repeating 7 pixels and repeating 8 pixels. Why do you need reversibility?

[zerowalker]

For point resize you need an integer ratio. 1200 / 160 is not an integer.

Came to that conclusion, and this proves it, which sadly limit things.

But you could have a metapattern of point replication, i.e, alternate repeating 7 pixels and repeating 8 pixels. Why do you need reversibility?

Have no idea what you mean with the metapattern and repeating pixels, could you explain it simplier?
I am guessing you mean something like, i can only explain it with Framerate, where you repeat frames differently to keep a certain rate, 3:2 and such things, but with pixels?

Why do i need reversibility?
Good question, it's more of a way to keep it lossless and knowing it's correct.

Till now, i though that, as long as i follow the Aspect Ratio, Pixel Games etc will be showing correctly, lossless so to speak, as i noticed Pixels and PointResize go hand in hand (probably easy to know, but didn't think of it before to long ago).

So that means, i have seen games wrong, luckily the difference it minimal, and pretty much just means that some pixels may be 2 width instead of 3, and such things, but an error is an error nevertheless.

As for the reversibility, it's pretty much a thing that adds to the equation, if i want to show the pixels correct, i need to have reversibility, so both points towards the same goal.

[Guest]

Originally Posted by zerowalker

Have no idea what you mean with the metapattern and repeating pixels, could you explain it simpler?

Point resize is implemented by repeating pixels. A resize factor of 7.5 in the horizontal dimension can be achieved by:

AB -> AAAAAAABBBBBBBB

It's like telecine but in the spatial domain.

I do not know of any filters that implement this idea. It might be fun to make one. Large upscaling is always going to look blocky, however. That is why point resize is not used much.

[colours]

Originally Posted by neuron2

Point resize is implemented by repeating pixels. A resize factor of 7.5 in the horizontal dimension can be achieved by:

AB -> AAAAAAABBBBBBBB

It's like telecine but in the spatial domain.

I do not know of any filters that implement this idea. It might be fun to make one. Large upscaling is always going to look blocky, however. That is why point resize is not used much.

SeparateRows/WeaveRows (along with the column versions) and SelectEvery could be used for this, but it'd be slow and doing exactly the same thing as PointResize.

Also, I want to add that while all the other core resizers treat the pixels as being sampled at half-integers, PointResize is the one exception, treating them as being sampled at the integers. (In other words, it's wrong and it can't be changed because I'm sure there's someone relying on this broken behaviour.) As Gavino stated, reversing a box upscale is possible, but doing so with Avisynth's PointResize requires a fudge factor for this reason.

[zerowalker]

The Topic is pretty much done at this point i think.

The answer is as following:

Pointresize can Only be lossless/reversible If it's increased in size that's a multiple Integer (x2,x3,x4) etc.
In other cases, it will fail. However if you use some pattern or specialize method as neuron2 pointed out, there is probably a way, it will however look different on upscale but my be reversible if you use the same transformation,
this is however not common and you would probably have to do it yourself, i myself so no real point to it as it breaks the looks, but it may be of use for someone

[Gavino]

Although not useful for zerowalker's purpose here, non-integer upsizing with PointResize can also be reversed (as all the original pixels are still there), but it requires using the 'offset' parameters src_top and src_left.

For example, starting with a 320x240 clip,
PointResize(800, 600) # 2.5x upscale, AB->AAABB
is not recovered by
PointResize(320, 240) # AAABB->AA
but can be losslessly reversed by
PointResize(320, 240, 1, 1) # AAABB->AB

The actual offsets required are different for each case and can be tricky to work out.
For RGB inputs, you also have to remember that Avisynth stores them upside down, so the vertical offset may be different.

[zerowalker]

Ah, that's indeed useful, it explains how to reverse even when it's "illegal".
Thought it would be harder than that, not that it looks easy though.

[zerowalker]

I am not sure i understand, are you saying that PointResize doesn't work as intended by treating them as being sampled at the integers?
I thought that was the idea, it treats is as an integer, so it would always have the pixel there, so it's reversible and all that (as long as you don't break the structure, reducing the resolution beyond the original).

If that's not the case, and it's broken, that would mean it's not reversible and working to some sense, this would prevent me from using it in this sense,
so could you tell me in easier words what you mean?

Thanks

[colours]

It's reversible, but doing it in Avisynth just needs a fudge factor.

The correct way to map a destination coordinate to a source coordinate is with (x+0.5)*src_width/dst_width-0.5 (which is used by all the core resizers except PointResize), but PointResize uses just x*src_width/dst_width.

It does happen to work as expected for upscaling by an integer factor, if that's what you're worried about.

[Gavino]

Originally Posted by colours

It's reversible, but doing it in Avisynth just needs a fudge factor.

The correct way to map a destination coordinate to a source coordinate is with (x+0.5)*src_width/dst_width-0.5 (which is used by all the core resizers except PointResize), but PointResize uses just x*src_width/dst_width.

To get reversibility, you would also need to make PointResize a true 'nearest neighbour' resizer.
The way it currently works is to use, for each output pixel, the nearest source pixel looking above [below for RGB] and to the left (hence not strictly 'nearest' neighbour, as it ignores nearer pixels below [above for RGB] or to the right).

[zerowalker]

Seems to be out of my league, my mathematical knowledge is close to none;S

But if it work as i expect in the cases i talked about, then it's okay for me.

Still if you think it should change, you probably should take it up with an Avisynth Developer, it's better to notify then ignore it

[zerowalker]

So, pointresize only checks SouthWest pixels?
And if it checked all around it could be more robust to reversibility?

hmm, guess that would need to be it's own resizer, If someone thinks of doing it or have thought on how it can be made, please make a topic on it.
I would clearly be interested in it at the very least

[StainlessS]

If pointresize is to modified in any way, then it needs to be called by another name.
Pointresize works differerent to other reiszers, because it does not do 'area' sampling and aggregation of those sampled results.

[zerowalker]

Probably, easier that way never the less.

(Updated the Thread Opening Post with the "Answer" of the Topic)

[colours]

No manual calculation is needed if the original size is known and src_top/left/width/height aren't used in PointResize.

function depoint(clip c, int target_width, int target_height)
{ # c.PointResize(w, h).depoint(c.width(), c.height()) gives exactly the same pixels as c
	c
	Assert(target_width <= width() && target_height <= height(), "depoint cannot be used for upscaling")
	x = width() == target_width ? 0 : width() / (2.0 * target_width) + 0.5
	y = height() == target_height ? 0 : height() / (2.0 * target_height) + 0.5
	PointResize(target_width, target_height, x, IsRGB() ? -y : y)
}

Like debilinear, but for PointResize. Except not using least-squares, so it's not really anything like debilinear, I guess.

[Gavino]

Originally Posted by colours

	y = height() == target_height ? 0 : height() / (2.0 * target_height) + 0.5

Aren't you forgetting what I said earlier?

Originally Posted by Gavino

For RGB inputs, you also have to remember that Avisynth stores them upside down, so the vertical offset may be different.

I think for RGB you need a negative vertical offset - probably you just have to reverse the sign of y in the RGB case (ie same magnitude but negative).

[colours]

Originally Posted by Gavino

Aren't you forgetting what I said earlier?

I think for RGB you need a negative vertical offset - probably you just have to reverse the sign of y in the RGB case (ie same magnitude but negative).

It still works correctly on RGB. The sampling isn't affected if all you work with are the pixel coordinates without caring about whether the scanning order is right-to-left or bottom-to-top or whatever.