Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 14th May 2014, 02:40   #1  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,116
When is PointResize NOT Reversible?

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:

Quote:
Originally Posted by Gavino View Post

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

Last edited by zerowalker; 16th May 2014 at 03:03.
zerowalker is offline   Reply With Quote
Old 14th May 2014, 03:09   #2  |  Link
JReiginsei
Registered User
 
Join Date: Apr 2002
Posts: 75
Upscale then downscale

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.
__________________
Intel Core i5-4250U, 8 GB Ram, Intel HD 5000
JReiginsei is offline   Reply With Quote
Old 14th May 2014, 03:23   #3  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,116
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.
zerowalker is offline   Reply With Quote
Old 14th May 2014, 04:04   #4  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
Quote:
Originally Posted by zerowalker View Post
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?
Guest is offline   Reply With Quote
Old 14th May 2014, 04:16   #5  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,116
Quote:
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.

Quote:
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.
zerowalker is offline   Reply With Quote
Old 14th May 2014, 05:46   #6  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
Quote:
Originally Posted by zerowalker View Post
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.

Last edited by Guest; 14th May 2014 at 05:51.
Guest is offline   Reply With Quote
Old 14th May 2014, 17:10   #7  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,922
Please remain on topic for the thread title. OT posts were removed.

You can change the thread title if you want to broaden the discussion, but we expect thread content to match the thread title. Followup to PM if needed. Thank you.
Guest is offline   Reply With Quote
Old 14th May 2014, 17:18   #8  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,116
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
zerowalker is offline   Reply With Quote
Old 14th May 2014, 18:00   #9  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,414
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.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 14th May 2014, 18:06   #10  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,116
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 is offline   Reply With Quote
Old 14th May 2014, 21:10   #11  |  Link
colours
Registered User
 
colours's Avatar
 
Join Date: Mar 2014
Posts: 308
Quote:
Originally Posted by neuron2 View Post
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.

Last edited by colours; 14th May 2014 at 21:13.
colours is offline   Reply With Quote
Old 14th May 2014, 21:24   #12  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,116
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
zerowalker is offline   Reply With Quote
Old 14th May 2014, 21:35   #13  |  Link
colours
Registered User
 
colours's Avatar
 
Join Date: Mar 2014
Posts: 308
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.
colours is offline   Reply With Quote
Old 14th May 2014, 21:42   #14  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,116
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 is offline   Reply With Quote
Old 14th May 2014, 23:59   #15  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,414
Quote:
Originally Posted by colours View Post
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).
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 15th May 2014, 00:10   #16  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,116
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
zerowalker is offline   Reply With Quote
Old 15th May 2014, 01:42   #17  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 9,629
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.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 16th May 2014, 03:00   #18  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,116
Probably, easier that way never the less.

(Updated the Thread Opening Post with the "Answer" of the Topic)
zerowalker is offline   Reply With Quote
Old 16th May 2014, 19:09   #19  |  Link
colours
Registered User
 
colours's Avatar
 
Join Date: Mar 2014
Posts: 308
No manual calculation is needed if the original size is known and src_top/left/width/height aren't used in PointResize.

Code:
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.

Last edited by colours; 20th May 2014 at 01:03. Reason: edited to add link + fixed for RGB + really fixed for RGB
colours is offline   Reply With Quote
Old 16th May 2014, 19:33   #20  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 9,629
@Colors,

Debilinea sound interesting, got a link for it ?
I got no hits on D9 and only about 5 hits in Google (all in what looks like it might be in Italian or similar [Latin maybe])
and none of them look to be related.

Thank you for your time.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:49.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.