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. |
|
14th May 2014, 02:40 | #1 | Link | |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
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:
Thanks for all information Last edited by zerowalker; 16th May 2014 at 03:03. |
|
14th May 2014, 03:09 | #2 | Link |
Registered User
Join Date: Apr 2002
Posts: 74
|
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 |
14th May 2014, 03:23 | #3 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
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.
|
14th May 2014, 04:04 | #4 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
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? |
|
14th May 2014, 04:16 | #5 | Link | ||
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Quote:
Quote:
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. |
||
14th May 2014, 05:46 | #6 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
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. |
|
14th May 2014, 21:10 | #7 | Link | |
Registered User
Join Date: Mar 2014
Posts: 308
|
Quote:
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. |
|
14th May 2014, 17:18 | #8 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
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 |
14th May 2014, 18:00 | #9 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
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. |
14th May 2014, 21:24 | #11 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
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 |
14th May 2014, 21:35 | #12 | Link |
Registered User
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. |
14th May 2014, 23:59 | #13 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
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). |
|
14th May 2014, 21:42 | #14 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
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 |
15th May 2014, 00:10 | #15 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
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 |
15th May 2014, 01:42 | #16 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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 ??? |
16th May 2014, 19:09 | #18 | Link |
Registered User
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) } Last edited by colours; 20th May 2014 at 01:03. Reason: edited to add link + fixed for RGB + really fixed for RGB |
16th May 2014, 23:11 | #19 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
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). |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|