Hi Folks,
I'm just ripping Lawrence Of Arabia BR to 720, and haven't come across 2.20:1 aspect ratio before. I've a sheet saved of popular resolutions for 1080/720 but nothing for 2.20:1
Obviously I could guess after cropping and looking at it, but for such a long movie 03:47:00 I'd like it to be correct.
1280x??? After cropping black bars off.
Thank you.
![]()
+ Reply to Thread
Results 1 to 30 of 34
-
Last edited by Nu始eus; 31st Jan 2020 at 08:36.
-
2.20/1 means it's 2.2 times as wide as tall. so 2.2x720=1584
--
"a lot of people are better dead" - prisoner KSC2-303 -
If your source is blu-ray you will get after ripping 1920x1080, including the top and bottom borders.
Now you can resize to 1280x720 and leave the bordes (they do no harm), or crop them off and end up with a picture of 1280 x 580.
Or crop the borders of the 1920 x 1080 original off, and resize to 1584 x 720. -
Thank you. I know that but it doesn't help me with frame height after cropping black bars.
Using this calculator I've arrived at 1280x582? But would appreciate anyone advising what they use for a 720 encode with an AR of 2.20:1
-
-
1280 / 2.2 = 581.82. I suggested to crop slightly into the picture, so 580 as a rounded figure on the safe side. 582 could leave a tiny black border which is inefficient for encoding.
-
-
Just ignore what it says on the box, crop the black and resize to a width of 1280. MeGUI will calculate the correct height if the "suggest resolution" option is checked in the script creator, and tell you if there's any aspect error. I'd set the mod setting to mod4 before specifying a 1280 width, and if after MeGUI resizes the height there's still some aspect error, crop a few more pixels from the width or height as required to reduce the error as much as possible.
Sometimes it's better to uncheck the "suggest resolution" box before fine tuning the cropping otherwise MeGUI can adjust the height again.
If you end up with 1280x596 or some other height, it just means the info on the box isn't terribly accurate, and/or you had to crop an extra few pixels somewhere to resize with minimum aspect error. You won't see any aspect error under 1%, and something like 0.02% in the screenshot below is virtually perfect.
582 isn't mod4 (height evenly devisable by 4), and while it's not vital, it's probably best to aim for 1280x584 instead, assuming 2.2:1 is accurate. Something like these screenshots. Just adjust the cropping as required for as little aspect error as possible. Crop a few more pixels of picture if need be rather than reduce the cropping and not end up cropping all the black. There's always at least a couple of pixels of crud down each side anyway.Last edited by hello_hello; 31st Jan 2020 at 19:13.
-
Resize to 1280x720, then crop top and bottom black bars (mode 2,4 or 8 whatever you prefer), even if some tiny black bars left, no one cares, encode, no calculations even needed and zero aspect ratio error is introduced.
As soon you start to crop first, then you need something, god knows what to get things correctly. Had this discussion times before, really heated ones, but for some reason, some just insist to get to resolution involving floating points and all kind of math adventures. -
Thread title:
Correct 720p Resolution (Height) For 2.20:1 AR?
Of course, once you crop anything away from the resized 1280x720 height, it's no longer 720p. Other changes might need to be made, like the colorimetry.
They? Who is "they"? If you mean the film's owners or the studios, they don't release 720p videos. If you mean the warez thieves, why not ask them? Or use some third grade math and figure it out yourself. -
Who's this no-one who doesn't care you refer to, because obviously some people do.
Of course if there's nothing to be cropped from the sides your method would be fine in this case, but why not just offer your method like I offered mine? I didn't feel the need to suggest your method too just so I could then point out it's completely useless if you want to crop from the sides and resize to a specific width. -
Yeah, but.... if you crop the black and encode without it, the player will add it back when the video is displayed on a 16:9 screen, making it 720p again.
You could argue that if a large portion of the picture was black it wasn't 720 or 1080p to begin with, but really 584p or 870p etc with padding. -
It'll make it the resolution of the screen, 1080p, 2160p, whatever. It'll be resized and have the appropriate amount of black bars added. Most (many, some?) players decode anything less than 720p as std-def and rec.601 and it won't automatically be turned into rec.709 just from being upscaled. Your same argument can be made about the 640x272 XviD videos I used to make, and it won't work for them either.
You could argue that if a large portion of the picture was black it wasn't 720 or 1080p to begin with...
The AviSynth Colorimetry page has info about this. Among other things:
Windowed/renderless VMR7 and VMR9 use BT.601 for video < 720p (720 vertical lines)
Windowed/renderless VMR7 and VMR9 use BT.709 for video >= 720p (720 vertical lines) -
Every forum has them! Jeeze! I asked a a civil question while always being polite! Been on the beer before posting your condescending sneering reply!? I'll take a guess it's your natural aggressive mannerism towards ppl you consider beneath you or your opinion. What an aggressive jerk!
My thanks to all others who gave pointers, help and advice, genuinely appreciated. Cheers.
Edit: Scrolled down a few of his other posts, yep confirmed. The forums Mr Nasty to anyone who doesn't match up to his perceived superiority. Where's the Ignore List feature?
Edit: Fixed. Forum idiots like that are always best ignored. Now he can knock himself out posting all the bile he likes.
Last edited by Nu始eus; 1st Feb 2020 at 02:48.
-
Last edited by Nu始eus; 1st Feb 2020 at 02:49.
-
-
It's a standard thing to refer to anything with a width of 1280 as 720p and anything with a width of 1920 as 1080p, even though the height is not determining the naming as such, but it does follow the silly "industry standard" naming convention in a way, by indirectly describing the width.
If you refer to a video as 528p there's no way to know if it's 1024x528 or 1280x528, so the former is often referred to as 576p, assuming it's PAL. Once you start wandering away from the standard widths though, I guess anything goes.
I intended to ask if someone with a wiki account could change that a long time ago (at doom9) because it's wrong. The colorimetry used is also determined by the width, similar to the way ffdshow does it when outputting RGB. Only the way ffdshow does it is sensible. The Microsoft way ensures the colorimetery is more likely to be wrong. Unfortunately though, I think the couple of times I bought it up, Ghitulescu stuck his nose in and probably accused me of trolling him for disagreeing, even though I'd started the thread, and then of course neuron2 would've seized on the opportunity to mod-troll me for picking on Ghitulescu, so I didn't get far.
For ffdshow, when it's converting to RGB and there's no colorimetry information saved to the video, anything with a width greater than 1024 is rec.709, or anything with a height greater than or equal to 600 is rec.709, so it'd display pretty much any HD resolution correctly.
For Microsoft, and I just tested it again (see the screenshots), as well as picking odd resolutions, they chose an "and" method rather than "or", so the way they do it, the width must be greater than 1152 and the height must be greater than 576 to display as rec.709. Thanks Microsoft, I have to remember to correct the colorimetry for any 4:3 720p, and for any "720p" with a height under 578, or decode and convert to RGB with ffdshow.
The EVR renderer does pay attention to any colorimetry written to the video stream, although I can't remember if that also applies to XP, or only to newer Windows. Without any colorimetry info, I think it uses the same rules.
Here's some screenshots to demonstrate. It's a DVD encode upscaled to 720p with the colorimetery converted to rec.709 for encoding. For playback, I normally use a pixel shader to convert the colorimetry to rec.709, otherwise it displays using rec.601, but MPC-HC doesn't save the color change when saving screenshots, so the first screenshot is definitely displaying incorrectly. The second screenshot shows how it displays correctly after changing the colorimetry with a pixel shader. For the remaining screenshots, I decoded the video with ffdshow and used it to resize until I found the point where the renderer switched to the correct colors. ffdshow is not doing a conversion to RGB. Naturally the aspect ratio is all wrong as I was simply resizing the width and height with ffdshow, but the screenshots clearly show where the colorimetry changes. I'm using XP and WMR9.
Gallery: https://postimg.cc/gallery/xioowvoq/
Thumbnails:
Incorrect 960x720
Correct
I'd zoomed in on the picture and forgotten to reset it for the first image here. It's not relevant to the colorimetry but I've added an un-zoomed version too. The two images were taken via the print screen button to show how the colors look to me after using a pixel shader to correct them. All other screenshots are via the MPC-HC "File/Save Image" menu. Images saved that way don't include any pixel shader colorimetry change, although I'd disabled that for the other images anyway.
Incorrect 1280 x 576
Correct 1280 x 578
Incorrect 1152 x 720
Correct 1154 x 720
PS. For anyone who wants it, here's the MPC-HC pixel shader I use for correcting the colors. It's a modified version of a pixel shader that comes with MPC-HC. I removed the limitation preventing it from working with standard definition video, so AVIs encoded from HD sources and resized to SD without converting the colors to rec.601 can be made to display correctly. If a video is being converted to RGB on playback using rec.601 when it should be rec.709, this shader can correct the colors.Last edited by hello_hello; 2nd Feb 2020 at 13:17.
-
LOL. you asked for 720p video, did you not? that means the end result has to be 720p. as in 1584x720.
--
"a lot of people are better dead" - prisoner KSC2-303 -
Why don't you avoid all the ambiguity and state the actual width or height of what you want? Like: I want a frame that's 1280 pixels wide -- what's the correct height? Or, I want a frame that 720 pixels tall -- what's the correct width?
-
-
--
"a lot of people are better dead" - prisoner KSC2-303 -
The first screenshot was saved by MPC-HC (File/Save Image) so the colors are definitely incorrect. All the screenshots were saved that way except for the second one. It's a screenshot taken by me, using the print screen button and pasting the clipboard image into Irfanview, to show how the video looks to me after correcting the colors with a pixel shader. I'd zoomed in on the image at one stage using the 9 button on the numeric keypad (probably so it'd fill the entire 16:9 display in fullscreen mode while I was comparing the colors), and I forgot to reset the zoom before taking the screenshot, which is why it looks cropped. I edited the post to add that information. Zooming has no effect on the colorimetry, but I've now added an un-zoomed version.
Last edited by hello_hello; 1st Feb 2020 at 19:48.
-
-
Well that was already answered - you even found the answer yourself.
One talks of conventions such as 1080p,720p,576p,480p. But they all relate to the vertical. Resizing to a horizontal width of 1280 does NOT give you a 720p video.
There is another approach if you really want, which you appear not, to have a conventionally named 720p video.
As has been stated, your BD is 1920*1080 ie 1080p. The active video frame cropped to 2.20:1 is 1920*872. Resize that to a vertical of 720 and you then have 1584*720.
One final thing. Cropped/resized video is fine when viewed in a window (as per your example). You might tire of that and decide to view it full screen. Any screen with a height larger in your sample will then give you letter-box bars. But if your screen only has a vertical definition of 720 pixels the conventionally named approach as I illustrate will not result in any letter-boxing.
Of course, if your screen only has a horizontal definition of 1080 pixels that conventional approach will not work. -
-
My thanks to all for their contributions/tips/advice here, and such detailed answers. All are appreciated and have made for interesting reading - thank you.
Obviously I'm not nearly so techy with this as you more advanced ppl, neither was I aware of the various calculations mentioned, therefore it's sensible to ask and get advice on a forum. I just always adopted the conventions (resolution naming) as mentioned by @DB83 as that's how I've seen them stated, ppl asking how should I encode this/that for my phone/tablet etc - not necessarily warez thieves as was chucked at me.
I had no idea this can be/would be such a detailed subject - wow!
Although I didn't notice it when first searched, I just found a similar thread where finding the correct resolution in MeGUI is discussed. Looks like it got a bit heated and ended up being locked by an admin.
Thanks. -
That whole argument was simply because Al resizes the video first, ie 1920x1080 to 1280x720, and then crops the black, and won't consider doing it another way. It's a terrific way to do it if you're not concerned about the final dimensions because there can't be any aspect error, but if you need to crop a few pixels from the sides too, you'd end up with something like 1274x528 etc, and of course it doesn't always work for non-standard source resolutions. The only practical way to crop and resize multiple sources to a particular resolution each time is to crop first.
If you resize to a particular resolution and want to crop from the sides and height, you have to effectively crop the source to the same aspect ratio as the resizing dimensions. Just as you can resize 1920x1080 to 1280x720 without aspect error, you can crop a 1920x1080 source to 1916x976 and resize it to 1280x652 with so little aspect error you couldn't see it even if you had bionic eyes.
1916 / 976 = 1.96311 and 1280 / 652 = 1.96319
So you pick the resolution and crop to match, or you crop and then resize to match. It's not any more complicated than that, unless a source is anamorphic such as a DVD, but that's another story. Have a play with this resize calculator. It's very similar to MeGUI's script creator, as far as calculating aspect error goes, but it displays more information.
I use MeGUI to apply the cropping now and then, but I haven't resized with anything but this script for quite a while. You don't need to worry about calculating resizing or aspect error as the script takes care of all that, and it's not limited to mod2 cropping. If you want to try it the main thing you need to know is that if you only specify a width, the script will calculate the height for you as MeGUI does, and if you specify just a height the script will calculate the width, but if you specify both the script will crop as much picture as necessary so as not to distort it. Check out the screenshots in the thread I linked to, but if in doubt, don't specify the output height. The examples in the thread all include an input display aspect ratio, but that's only necessary for anamorphic sources such as DVDs.
Using something like my earlier example, you could crop the 1080p source to remove all the black and then resize to 1280 x "whatever" like this:
Crop(2, 104, -2, -104)
CropResize(1280)
Or you can crop with the script instead. The order is "output width", "output height", then the cropping in the same order as Crop(). If you specify zero for the width or height, it's the same as not specifying them at all. To crop with the script while letting it pick the height, it'd be something like:
CropResize(1280,0, 2,104,-2,-104)
The result would be the same as the previous example. The main advantage of cropping with MeGUI's script creator is it's cropping preview is a bit more convenient than the script's preview, but you can still resize with the script after MeGUI has added the cropping rather than use the traditional Avisynth resizing.
Edit: If you don't have Avisynth installed so it can auto-load plugins and functions, you need to import the script before you can use it. ie.
Import("D:\Some Folder\CropResize 2020-01-30.avsi")
Import("D:\Some Folder\CropResize Wrapper Functions 2020-01-30.avsi") # only needed to use the abbreviated function names
Crop(2, 104, -2, -104)
CropResize(1280)Last edited by hello_hello; 2nd Feb 2020 at 13:41.
-
Again a page of something, bla, bla, except op is good with resize, crop without math.
You have legit BD, that is why I included my post here. Not because it is some screwed up video download. Is that clear? Because I do not know what more to say really. Kids out there need to know that. No need for any math or what ifs. -
Again a post about nothing.... blah, blah.....
What part of this did you not understand?
So what happens if the OP needs to crop a few pixels from the sides and still have a width of 1280?
Oh.... I forgot.... nobody cares about that because you don't.Last edited by hello_hello; 2nd Feb 2020 at 13:34.
Similar Threads
-
Does Corel VS support 480 x 720p resolution?
By Djard in forum Newbie / General discussionsReplies: 1Last Post: 11th Dec 2019, 13:55 -
How to find out correct resolution in Megui?
By rudolfp in forum Video ConversionReplies: 44Last Post: 16th Nov 2017, 22:25 -
Best Quality encoding from 1080p to 720p & 720p to 720p in Xvid4PSP?
By Odie111 in forum Video ConversionReplies: 8Last Post: 9th Jan 2016, 16:42 -
Do I need to resize 1080p PGS subs to 720p when making 720p AVCHD ???
By FulciLives in forum Authoring (Blu-ray)Replies: 3Last Post: 20th Aug 2015, 12:26 -
plz plz plz HELP direct show source proplem with megui
By sam samy in forum EditingReplies: 3Last Post: 9th May 2015, 13:06