Aspect ratio as a number rather than a ratio

[pooksahib]

Sometimes, mediainfo tells me the aspect ratio of a video is, e.g., 1.300 as opposed to the more commonly used 4:3, 16:9. Is there a table anywhere which gives the equivalent AR? Or is there a conversion formula?

Thank you.

[teodz1984]

They just fractions or ratios expressed as a decimal number
The aspect ratio of a geometric shape is the ratio of its sizes in different dimensions. For example, the aspect ratio of a rectangle is the ratio of its longer side to its shorter side – the ratio of width to height, when the rectangle is oriented as a "landscape".
The aspect ratio is expressed as two numbers separated by a colon (x:y). The values x and y do not represent actual widths and heights but, rather, the relationship between width and height. As an example, 8:5, 16:10 and 1.6:1 are three ways of representing the same aspect ratio.
In objects of more than two dimensions, such as hyperrectangles, the aspect ratio can still be defined as the ratio of the longest side to the shortest side.


FORMULA
AR: LONG SIDE / SHORT SIDE

Hence:
4 /3 is 1.33333333333
16/9 is 1.77777777778

Source
https://en.wikipedia.org/wiki/Aspect_ratio
Examples:
4:3 = 1.3: Some (not all) 20th century computer monitors (VGA, XGA, etc.), standard-definition television
√2:1 = 1.414…: International paper sizes (ISO 216)
3:2 = 1.5: 35mm still camera film, iPhone (until iPhone 5) displays
16:10 = 1.6 (not shown above): Commonly used widescreen computer displays (WXGA)
Φ:1 = 1.618…: Golden ratio, close to 16:10
5:3 = 1.6: Super 16 mm, a standard film gauge in many European countries
16:9 = 1.7: Widescreen TV
2:1 = 2: dominoes

[netmask56]

Easy enough to just remember 1.333 is 4:3 1.77777 is 16:9 ie 16 divided by 9 = 1.77777

[pooksahib]

Thanks to you both.

[hello_hello]

How do you convert numbers to the smallest possible fraction? I've never known.
ie How do you convert an aspect ratio of 2.76:1 to a fraction smaller than 267:100, assuming it's possible?
When creating a custom aspect ratio in MeGUI, either fractions or numbers can be entered, but when the custom aspect ratio is saved, MeGUI displays both. I wouldn't mind knowing how to convert decimal numbers to the smallest possible fraction myself.

For example, I know an aspect ratio of 2.172 is 215/99 because I started with 215/99, entered it into MeGUI, and out came an aspect ratio of 2.172. Of course I could have divided 215 by 99 with a calculator, but if I started with 2.172 I could easily convert that to 2172/1000, but how to get it down to 215/99 from there? It's probably simple enough that I'll feel silly, but I asked Google and couldn't find the answer.

PS. For the record, 215/99 is actually 2.171717171717171717171717............. but for reasons only known to whoever added the feature to the program, MeGUI displays custom aspect ratios rounded to three decimal places. The permanent DVD aspect ratios are allowed 6 decimal places, and it's not as though there's a lack of space.

[johnmeyer]

How do you convert numbers to the smallest possible fraction? I've never known.
ie How do you convert an aspect ratio of 2.76:1 to a fraction smaller than 267:100, assuming it's possible?

You write a computer program to iterate and compare. Like many math problems, there is no "closed"solution.

You can approximate this iterative process by following the steps here:

http://www.webmath.com/dec2fract.html

Enter "1.33333" and then read the answer.

P.S. The "trick" used doesn't always work.

[JVRaines]

How do you convert numbers to the smallest possible fraction? I've never known.

You find the greatest factor that the numerator and denominator have in common, then divide both by that factor.

[hello_hello]

How do you convert numbers to the smallest possible fraction? I've never known.

You find the greatest factor that the numerator and denominator have in common, then divide both by that factor.

I worked that much out myself, but aside from trial and error.... unfortunately the example I offered wasn't the best one to use because the aspect ratio requires an infinite number of decimal places, but assuming 2.717171717 is exactly 215/99, I'd start by converting it to 2717171717/1000000000 (was that enough zeros?) and go from there, but it seems potentially time consuming. And when I did try it using trial and error on a few occassions, MeGUI told me a couple of the fractions could have been reduced further.
As I said, my original example was a bad one, because it'd be like starting off with 1777777777777777777/1000000000000000 (was that enough zeros?) and finding the smallest fraction it converts to is 16:9, which it couldn't be, but it seems to be one of those things for which life might be too short to work it out manually.

[hello_hello]

Enter "1.33333" and then read the answer.

P.S. The "trick" used doesn't always work.

Your link doesn't seem to work, but it doesn't matter. I hadn't thought about the infinite decimal place problem until I write my previous post, but I understand why converting 1.33333 to 4:3 mightn't always happen. Cheers.

[_Al_]

If you just use decimal point transferring a fraction into a number with decimal point, creating an error with decimal point, there is no way back to be exact again.

You measure something with not going into smallest Planck distance anyway. So you have an error even measuring 16/9 in the first place. Measuring that distance. To use it as a theoretical distance , that is exact.
Decimal system is exact number science too, measuring things, like fractions it is the same thing. Depending how deep you decide to label your measurements, it could be microns, millimeters or measuring distances on Earth in kilometers. If I build a porch I'm good calculating in millimeters, engineer would go much deeper. We might choose to transfer between those "labels" adding zeros or including decimal point. Point is, starting calculating we always have to choose what lever of error we are going with. Mathematicians, physicians, engineers might introduce weird things that are exact, (not needing it for our real practical World not needing exact values) like differentials , submerging into infinitely small parts for calculations in "analog" world and at the end you emerge into digital world again and give out some humanly understandable digital expression. Or not doing that, building calculations upon calculations to realizing that things can cancel itself out even those not definitive and getting some definite easy readable result again. Like a strict fraction calculations do, using common denominator etc.

[johnmeyer]

Enter "1.33333" and then read the answer.

P.S. The "trick" used doesn't always work.

Your link doesn't seem to work, but it doesn't matter. I hadn't thought about the infinite decimal place problem until I write my previous post, but I understand why converting 1.33333 to 4:3 mightn't always happen. Cheers.

I fixed the link. If you now click on it, you can see how it works not only for 1.33333, but also for 1.77777.

Here's the corrected link again, so you don't have to scroll up to find it:

http://www.webmath.com/dec2fract.html

[hello_hello]

If you just use decimal point transferring a fraction into a number with decimal point, creating an error with decimal point, there is no way back to be exact again.

Most aspect ratios aren't like that though, because they have a finite number of decimal places. It's only the industry standard 4:3 and 16:9 etc.
I've always thought 16:9 was a little dumb anyway. 2:1 would have been better, IMO.

I know this because I created a 2.35:1 custom aspect ratio in MeGUI and 47/20 came out, so 2.35 is exactly 235/100, which is exactly 47/20, which is exactly 2.35.

Even though it rounds to three decimal places when displaying a custom aspect ratio, MeGUI seems to convert and/or save them accurately up to six decimal places. That's something I haven't complained about in the doom9 MeGUI thread yet, and I haven't had a good complain since yesterday. Programs should never tell you they're doing one thing when they're really doing something else, and for me displaying different aspect ratio rounding in the GUI to the rounding actually being used is an example of that.

[hello_hello]

I fixed the link. If you now click on it, you can see how it works not only for 1.33333, but also for 1.77777.

Here's the corrected link again, so you don't have to scroll up to find it:

http://www.webmath.com/dec2fract.html

Thanks.

[_Al_]

If you just use decimal point transferring a fraction into a number with decimal point, creating an error with decimal point, there is no way back to be exact again.

Most aspect ratios aren't like that though, because they have a finite number of decimal places. It's only the industry standard 4:3 and 16:9 etc.
I've always thought 16:9 was a little dumb anyway. 2:1 would have been better, IMO.

I know this because I created a 2.35:1 custom aspect ratio in MeGUI and 47/20 came out, so 2.35 is exactly 235/100, which is exactly 47/20, which is exactly 2.35.

Even though it rounds to three decimal places when displaying a custom aspect ratio, MeGUI seems to convert and/or save them accurately up to six decimal places. That's something I haven't complained about in the doom9 MeGUI thread yet, and I haven't had a good complain since yesterday. Programs should never tell you they're doing one thing when they're really doing something else, and for me displaying different aspect ratio rounding in the GUI to the rounding actually being used is an example of that.

I would not let MeGui doing stuff like that, it needs for some Avisynth calculations right? Just setting proper modes (cropping) you can Resize and autocrop at the same time even using batch scripts, if not doing it quickly in the head. Just remember resizing first (same ratio as original, for example 1980x1080 to 1280 and calculating 720), then autocroping, that is the principle, this proper sequence makes a hell of a difference. Doing it other way brings you this AR nonsense calculations, maybe Megui programmer fell for it. Try it. Talking here about non anamorphic videos.

[pandy]

https://en.wikipedia.org/wiki/Greatest_common_divisor

[raffriff42]

Is there really a need for such large fractions in video?
If an image is 1920x1078, it's basically 16:9 for my purposes, not 960:539

[_Al_]

Yes, not really, I do lots of things with scripts and never needed to calculate or work with AR at all. Basically only picking certain values if working with anamorphic video, not square pixel, but that is not the case here.
basically op asked: What fraction 1.3 is? I'm sure he realized pretty fast that it is 1.3= 1.3/1=13/10

Those values seam to be good only as for comparison , for some reason, to compare decimal numbers seems much easier as oppose comparing fraction sometimes, so common denominator and such a thing is pushed back. I know perhaps US user might tend to go with it , compare fraction, but perhaps guy from Europe , as a habit, prefers to compare decimal numbers, you know the other way comparing 16/9 makes it 1.777 and compares to 1.3 or realizing that 1.3 is really close to 1.3333 (4/3) that original ar should perhaps be it, who knows.

EDIT: I have to add this, those AR numbers might be nonsense anyway or not really exact if downloading already cropped image. And that is what is happening all the time, resizing and cropping is done to a mode, like 4 for example and Blu-Ray image height (not including pillarbox) has height not divisible by 4, only 2 for example, or video height in letterbox does not really follows released Blu-ray AR to the last line anyway, basically video image is cropped. And imagine processing already processed image again (folks do it all the time) If processing again of already processed image that video you just need to follow H/W ratio and if you resize or crop to lower mode that H/W is again ar gets shifted somewhere else yet again to some weirder number and real world ar might be even shifted resizing, some negligible amount, one must ignore those numbers calculating or use common sense.

[hello_hello]

Even though it rounds to three decimal places when displaying a custom aspect ratio, MeGUI seems to convert and/or save them accurately up to six decimal places. That's something I haven't complained about in the doom9 MeGUI thread yet, and I haven't had a good complain since yesterday. Programs should never tell you they're doing one thing when they're really doing something else, and for me displaying different aspect ratio rounding in the GUI to the rounding actually being used is an example of that.
I would not let MeGui doing stuff like that, it needs for some Avisynth calculations right? Just setting proper modes (cropping) you can Resize and autocrop at the same time even using batch scripts, if not doing it quickly in the head. Just remember resizing first (same ratio as original, for example 1980x1080 to 1280 and calculating 720), then autocroping, that is the principle, this proper sequence makes a hell of a difference. Doing it other way brings you this AR nonsense calculations, maybe Megui programmer fell for it. Try it. Talking here about non anamorphic videos.

You do it backwards to the rest of the world. The reason for cropping first is if you want to resize (for example) 1920x1080 to 1280 by something, the something is easy enough to work out, but when if you need to crop, but still want 1280 by something. Do you resize, crop and resize again. That's the main reason for cropping fist.
The secondary reason is the resizers include all the pixels when doing their thing. If you have a single line of black down one side, it won't have the potential to effect several lines while resizing, because it's not there any more.
The aspect error calculator built into the script creator was my idea. A few years ago, MeGUI would only resize for encoding in the dark ages. Everything was mod16. So I'd work it all out using the Yoda Resize Calculator quite a bit, then adjust the resizing manually to something that wasn't mod16 if need be. After convincing Zathor to drag the resizing into the 21st century, he agreed to make the script creator Yoda-like. Which by the way calculates the same way as MeGUI and everyone else. Crop first, resize what's left. It's easier if you want to choose the final resolution (width or height).
The aspect error calculations still apply either way. If the source was 1916x1074, resizing to 1280x720 would produce a small aspect error. Resizing to 1280x718 would be more accurate, but I want 1280x720. So I change the resizing to 1280x720 and crop a few pixels from each side until the aspect error displayed is down to almost nothing. How would you get to 1280x720? Or would you just resize and not worry about the aspect error?

I rarely use anamorphic encoding myself but if the Input aspect ratio is wrong, so will everything else. The resizing aspect error calculation are based on the input aspect ratio for anamorphic sources. When anamorphic encoding is enabled, the script creator shows everything as a display aspect ratio. That's more intuitive than using PARs. The aspect ratio added to the top of an anamorphic script is calculated from the Input Display Aspect ratio, then taking any cropping and resizing into account. Finally, you add the job to the queue and MeGUI uses the display aspect ratio at the top of the script, along with the scripts output resolution to calculate the PAR it needs to add to the x264 command line. When I was using anamorphic encoding myself, that always worked as it should. There's an option in the AVisynth profile configuration to tell how much aspect ratio fudging is permissible for anamorphic encoding. You can change it to none (0%). MeGUI gave me a couple of unexpected aspect ratios a long time ago. Eventually I discovered you can't change the resizing in a script after it's been put in the job queue. All the checking has been done by then and for some reason MeGUI will try to correct the changed aspect ratio by adjusting the pixel aspect ratio. Even for non-anamorphic encoding. So I learned my lesson. If you change the resizing, delete the script from the queue and reload it.

Sometime the aspect of the source is wrong. I find it easier to correct that by adjusting the Input Display Aspect ratio. That way the resizing and aspect error calculations work correctly. For instance if you crop and resize a 4:3 DVD but set the input aspect ratio to 16:9, MeGUI obligingly assumes it's 16:9 and calculates from there.

MeGUI doesn't always get it right. If a source has a DVD resolution and it's fairly close to 4:3 or 16:9, it just uses 4:3 or 16:9. I'm too OCD about aspect ratio not to correct it. Here's an example:



MeGUI uses retarded ITU aspect ratios for DVD calculations. They're retarded because they're the least accurate, I think MeGUI is the only currently maintained GUI using them, and if you encode for Bluray compatibility, the ITU aspect ratios used by the script creator have to be adjusted to mpeg4 aspect ratios for encoding. I've gone on about a few times in the MeGUI thead at doom9. Surprisingly, the only response has been to tell me I'm wrong because it doesn't matter. I'm not. The mpeg4 aspect ratios are closer to the real ITU aspect ratios than the ITU aspect ratios used by MeGUI, if the script creator used them they wouldn't need fiddling with for Bluray, and they'd be the same as the aspect ratios you can set in the x264 encoder configuration. And there's another nice little side effect. If you use the mpeg4 pixel aspect ratios, you only need two custom display aspect ratios. PAL 4:3 and NTSC 4:3 have the same display aspect ratio, as does 16:9. and the two display aspect ratios are so easy to remember even I can do it. 20:11 and 15:9. Can you recite the ITU aspect ratios without checking?

If I create custom aspect ratios for no other reason, it's at least to use mpeg4 aspect ratios for DVDs rather than retarded ITU, assuming I'm not using the generic PARs. Unfortunately though, deleting custom aspect ratios is an all or nothing deal, which is a bit annoying. I've mentioned that a few times, but I think I'll return to harping on about an anamorphic encoding option called "encode non mod16" even though it's perfectly capable of encoding mod16.



By the way, I think the anamorphic situation broke at some stage. I rarely use anamorphic encoding, but I was testing video muxing for Bluray, which has issues. MeGUI is using a different PAR for muxing than it's specifying for encoding, and it's not setting the frame rate precisely when muxing. That's just what I discovered before I gave up testing to retain a little sanity, there's no doubt more.
Fortunately I invariably mux with MKVToolNixGUI so I don't have to try to work out exactly how broken it is, when it broke, and then check every encode since it broke..... this time.
https://forum.doom9.org/showthread.php?p=1796331#post1796331

Here's a list of the commonly used pixel aspect ratios, MeGUI still uses the second lot for calculating DVD aspect ratios.
https://forum.doom9.org/showthread.php?p=1058927#post1058927

Also... when you load a script for encoding and open the preview there's a check box for seeing the correct aspect ratio for anamorphic encode. There's a drop down list of aspect ratios to the left. Until recently if you changed the aspect ratio there before adding a job to the queue, that's the aspect ratio MeGUI would use, ignoring any aspect ratio in the script. Not that it's something you'd need to do often, but it was handy now and then. The list is still there but it no longer sets the aspect ratio for encoding. I don't know when that broke.

[pandy]

I know perhaps US user might tend to go with it , compare fraction, but perhaps guy from Europe , as a habit, prefers to compare decimal numbers, you know the other way comparing 16/9 makes it 1.777 and compares to 1.3 or realizing that 1.3 is really close to 1.3333 (4/3) that original ar should perhaps be it, who knows.

Which one is correct - 29.97 or 30000/1001 ?

[Cornucopia]

Both may be considered correct, but 30000/1001 is more accurate.

Btw to work out ratios by hand you use factorization to only the constituent prime numbers and then remove items common to both numerator and denominator.
So 235:100 = 47 * 5 : 10 * 10 or 2 * 5 * 2 * 5. Take out 5 from top & bottom... 47 : 2*5*2 or 47:20. Done.

Scott

[_Al_]

pandy, guy needed a comparison, that AR could be most likely even wrong if slightly off. So how good for is 13/10 exactness if it is wrong anyway sort of. If it is nice number like 2.40/1 mediainfo reports that, not sure how it operates and what marging of error it rounds up and reports 4/3=1.333333, perhaps not for 1.3. You can easily introduce slight AR error if resizing already resized image and cropping, which is happening all the time, folks just love to crop SD anamorphic videos like crazy (more below)

sure for example: Convertfps(NTSC_video") (not sure if syntax is correct now), or Convertfps(30000/1001) is better as I said you choose margin of error, if calculating something in our head we just in an instant deside if we need a ballpark, margin of error or exact number

[_Al_]

hello-hello
MeGUi cannot tackle it all, especially SD anamorps, all videos allresolutions, fixing AR's, how? How do you know how was video cropped before , if that was a case and AR got slightly distorted? Guy takes away 4 pixels because he does not like 2pixel bar, resizes again and how do you know that?

First of all, cropping black bars is most overrated thing ever. Who cares about couple of tiny , couple of pixels, black bars in any video. It is happening all the time, I ignore those and nothing happens, nobody even notices, I would not allow to autocrop to remove anything below 12 pixels, it is sorted out in the script, it is not letterbox, so who cares, if those black bars (not letterbox or pillarbox) gets resized , it doesn't matter as well, you just resize nice modes to nice modes. BD sources, DVD sources. In this case resizing and cropping afterwards is alright, not even messing up with real AR. It is exactly the same, no AR error is introduced. That error would be introduced if someone decided to resize resized and cropped image again to exact 16:9 Or your method crop first, then resized, even BD source.

If resolution is weird, like 1916x1076 btw., not dealing with those at all, how big is AR error there, it does not help guessing what original was, because you do not know how big that error is, how much was cropped, was it resized again, how can you guess original AR and be sure, it sounds all quite weird to me. Applying other resize you might make AR error slightly larger or if you are lucky, the other way.

Anamorphic video sure, but the same thing how can you know better that user what to do with it, folks like to crop the hell away in Avisynth, all 4 dimensions, perhaps resizing back instead of padding black for heights. Original sources sure, there is an array of SAR's for x264 cmd line and you go with it, no problem, but again, for already processed SD video, how do you know what was done before and correct AR? Even that, why would I need to crop and mess up those AR's . I do not mind black bars (if not letterbox) it is most overated thing ever to get rid of them just because. Pro's keep it, nobody can see it practically, it is introducing an error if resizing afterwards.

Other thing about that SAR in Megui, that's it , guis have those things going in the background, sometimes it is very counterproductive, some settings are forgotten and messing it up, not seing that, doing lots of things for an easy task. You suppose to know some things using a gui. It is quite a task to encode everything to everything. Those GUI's could be , as a paradox, great teachers, you use them to understand how things work, the authors put a lot in it, so after that one can go on its own.

[awgie]

If resolution is weird, like 1916x1076 btw., not dealing with those at all, how big is AR error there, it does not help guessing what original was, because you do not know how big that error is, how much was cropped, was it resized again, how can you guess original AR and be sure, it sounds all quite weird to me. Applying other resize you might make AR error slightly larger or if you are lucky, the other way.

Prime example: I am presently working with a set of videos I downloaded that are 680x480, which struck me as odd before I even looked at any of them. And they do indeed look squashed. I took a screenshot and resized the image to 640x480 and it looks a lot better.

They were recorded from broadcast — that much is certain — looks like probably on VHS and then converted to digital. So I don't know what was cropped off them before, but if I had to guess, I'd say someone meant to resize them back to 640x480, but typed in the wrong number and never caught their mistake. But that's really all I'd be doing: guessing.

[pandy]

Both may be considered correct, but 30000/1001 is more accurate.

On Some areas it must be accurate to be correct and in other areas approximation is correct sufficiently - IMHO aspect ratio is such area.

[hello_hello]

hello-hello
MeGUi cannot tackle it all, especially SD anamorps, all videos allresolutions, fixing AR's, how? How do you know how was video cropped before , if that was a case and AR got slightly distorted? Guy takes away 4 pixels because he does not like 2pixel bar, resizes again and how do you know that?

I'm not saying MeGUI has second sight, but if you have a source that's 16:9 but should be 4:3, or even if it's "something" and it should be "something else", you can tell MeGUI to assume the input aspect ratio you believe is correct, even if you only worked it out by reading tarot cards. From there it's business as usual. You can crop and resize to produce a whole different output display aspect ratio if you want to, but the aspect error calculations will be based in the input aspect ratio you told MeGUI to use, not the input aspect ratio that's obviously wrong.

First of all, cropping black bars is most overrated thing ever. Who cares about couple of tiny , couple of pixels, black bars in any video. It is happening all the time, I ignore those and nothing happens, nobody even notices, I would not allow to autocrop to remove anything below 12 pixels, it is sorted out in the script, it is not letterbox, so who cares, if those black bars (not letterbox or pillarbox) gets resized , it doesn't matter as well, you just resize nice modes to nice modes. BD sources, DVD sources. In this case resizing and cropping afterwards is alright, not even messing up with real AR. It is exactly the same, no AR error is introduced. That error would be introduced if someone decided to resize resized and cropped image again to exact 16:9 Or your method crop first, then resized, even BD source.

I thought were were discussing the apparent advantages of cropping after resizing, not how important the cropping is. If we must though.... I like nice clean edges. Nice sources to nice sources would never be considered. even itunes doesn't care. I've seen enough widescreen video on a 4:3 DVD, displayed on a 16:9 TV to know keeping the black isn't always a good idea. How many portable devices such as tablets have screens with exact 16:9 dimensions these days? Unless the answer is all of them, why would you unessessarily limit your encodes to 16:9 by encoding unneeded black? The only time I care about a specific resolution or aspect ratio is if the source is virtually 16:9 to begin with, or to ensure a bunch of related encodes are the same. I don't see a point in drawing a line, so the black goes no matter how much there isn't.

I'm not ever going to auto-crop or resize. If I encode a series of episodes from a TV show, they all come out the same resolution and aspect ratio with clean borders and virtually no aspect distortion. Sometimes, when the black borders change in size by a significant amount in places, I'll crop those parts differently to remove it so I can resize to the same resolution as the rest without distortion. That's all personal preference though.

If resolution is weird, like 1916x1076 btw., not dealing with those at all, how big is AR error there, it does not help guessing what original was, because you do not know how big that error is, how much was cropped, was it resized again, how can you guess original AR and be sure, it sounds all quite weird to me. Applying other resize you might make AR error slightly larger or if you are lucky, the other way.

No aspect error. I picked that example simply because I had a video on my hard drive from itunes, which is very often not exactly 1920x1080 or 1280x720. I don't know why. I mentioned a more correct resizing would be 1280x718 instead of 1280x720, so I thought a lack of aspect error was implied, but if you wanted to resize that example to exactly 1280x720, and resize before cropping, how would you go about it?

Anamorphic video sure, but the same thing how can you know better that user what to do with it, folks like to crop the hell away in Avisynth, all 4 dimensions, perhaps resizing back instead of padding black for heights.

That was my point. I don't know, but the far more likely scenario is it started life as 4:3 or ITU 4:3 and was cropped a little, resized back to the original resolution and the aspect adjusted to 107:80 instead of 4:3 to compensate. All I know is that the source had a 720x480 resolution with a specified aspect ratio of 107:80, so not knowing better, that's the aspect ratio I want to use, not the 4:3 MeGUI assumes because it's 720x480.

Original sources sure, there is an array of SAR's for x264 cmd line and you go with it, no problem, but again, for already processed SD video, how do you know what was done before and correct AR? Even that, why would I need to crop and mess up those AR's . I do not mind black bars (if not letterbox) it is most overated thing ever to get rid of them just because. Pro's keep it, nobody can see it practically, it is introducing an error if resizing afterwards.

I'm not trying to correct anything, but you have to start with something. Even if you never crop, you have choose an input aspect ratio in order to have MeGUI set the desired output display aspect ratio, or you can let it decide, or you can flip a coin. For me it's generally an ITU 4:3 input DAR for 4:3 and an exact 16:9 input display aspect ratio for 16:9, except I'd probably use a custom 4:3 input DAR ratio (MPEG4 pixel aspect ratio) instead of MeGUI's ITU.

Other thing about that SAR in Megui, that's it , guis have those things going in the background, sometimes it is very counterproductive, some settings are forgotten and messing it up, not seing that, doing lots of things for an easy task. You suppose to know some things using a gui. It is quite a task to encode everything to everything. Those GUI's could be , as a paradox, great teachers, you use them to understand how things work, the authors put a lot in it, so after that one can go on its own.

MeGUI has worked perfectly for a long time in respect to aspect ratios. It's currently working fine for non-anamorphic output. The calculations are correct for aspect error and resizing and SAR 1:1 is always used.
Anamorphic seems to have some issues, but it's not typical. I used it for years without a problem, and despite the odd resizing currently displaying in the script creator GUI on occasions, the scripts it's creating still seem okay. I specified a 20:11 display aspect ratio for testing because it's the Bluray compliant 16:9 aspect ratio (MPEG4 SARs) and I was doing some testing for Bluray earlier. 32:27 is the generic NTSC 16:9 SAR for an exact 16:9 display aspect ratio.

I'd be surprised if the calculations aren't correct when cropping or resizing, because then MeGUI would be off the industry standard reservation and doing the math. There's no way MeGUI took a MPEG4 DAR as input and miscalculated a SAR that just happened to be the SAR required for generic 16:9. It's too coincidental. I'd be astounded if it's not painting by industry standard numbers behind the scenes and getting it right, except for the fact someone mixed up the colours and it doesn't know. One or two missing "standard" SARs were added to the encoder configuration a little while ago. The problem probably started there.

Anyway.... if you crop first, the resize formula is exactly the same as without cropping, you're just calculating from the post-crop resolution. Nothing gets distorted and if you know how much you're cropping before-hand, you can resize to a particular output resolution or aspect ratio. If you resize first, it's harder.
I don't see a problem with calculating the aspect error. Probably the original purpose was to reduce picture distortion when mod16 resizing was mandatory. You had to effectively resize to a particular resolution, which means the source resolution had to be appropriate, which means you needed to know how much to crop.
For an anamorphic example, I'll go with 720x576 PAL and cropping four pixels from one side. Without cropping I'd normally resize to 1024x576. For 716x576 the new resize is 1018x576, but what if you're wanting a particular output aspect ratio, such as 16:9 after cropping? Five seconds with a resize calculator told me cropping a total of three pixels from the height would give me 16:9 with an aspect error of 0.035%. Easy.
Crop(4,0,0-2)
Spline36Resize(1024,576,0,1,0,0)

[_Al_]

I do not encode unneeded black, I just resize it and crop it after keeping mode, so even if you crop "live" 4 lines or so, AR is kept 100%, not the other way, AND it could be automatized, that is my whole point, if you crop first and resize you do not know what to resize it to. Unless you start to pile up errors yet again, if you for example introduced errors cutting "live" video lines because of a chosen mode. Try it.
Talking about BD, DVD source that was not messed up already.

If you work with source that was already processed and not by you, none can be certain what it was, if not exact, to guess AR etc., that is my point also, even working with say, 1280x720 because fella might just crop something and resize, whatever.

So why all of this? We talk about aspect ratios, I try to say that that information is human info, not for software, and you mentioned MeGui operates with those.

[hello_hello]

I do not encode unneeded black, I just resize it and crop it after keeping mode, so even if you crop "live" 4 lines or so, AR is kept 100%, not the other way, AND it could be automatized, that is my whole point, if you crop first and resize you do not know what to resize it to. Unless you start to pile up errors yet again, if you for example introduced errors cutting "live" video lines because of a chosen mode. Try it.
Talking about BD, DVD source that was not messed up already.

I don't know why you keep saying aspect is not kept because it's simply not true. If you crop, the aspect is kept because every GUI I've ever used bases the resize calculations on the resolution after cropping. They've all cropped first and resized second.
There's no reason why it can't be automated, and it probably makes little difference which way you do it. The auto-cropper will crop what needs to be cropped and it'll be resized based on what's left. Your way it's resized to the same aspect ratio as the source and the auto-cropper crops what needs to be cropped. If it's the same auto-cropping each time, how different can the end result be?
The way you do it, you can't resize to anything but the original aspect ratio, because you're doing it first, then after cropping what you get is what you get. If you crop first, you can pick any display aspect ratio you want for resizing, then it's simply a matter of working backward to make sure the source has the same display aspect ratio. To do that, you'd adjust the cropping if need be.
It's not as easy to work out as it's sounds though, especially when resizing anamorphic to square pixels, and that makes the aspect error calculations handy.

I've no idea what errors are piling up or accumulating given it's a single crop and resize. I've never done it more than once. I have no idea what "cutting live video lines because of a chosen mode" means either. If you're referring to cropping pixels containing picture to achieve the desired aspect ratio, then yes, it's either that or stretch the picture to achieve the desired aspect ratio.

If you work with source that was already processed and not by you, none can be certain what it was, if not exact, to guess AR etc., that is my point also, even working with say, 1280x720 because fella might just crop something and resize, whatever.

I have a 720x480 source with a 107:80 aspect ratio. I wasn't guessing. MeGUI assumed it was 4:3 because it's 720x480. I wanted to use the aspect ratio written to the video instead. It was a simple point. Of course there's a chance the aspect ratio could have been set wrong after cropping or residing but there's no way to know, and it's more likely it was correct.

ISo why all of this? We talk about aspect ratios, I try to say that that information is human info, not for software, and you mentioned MeGui operates with those.

I have no way to make sense of that. Aspect ratios are numbers.

[_Al_]

Example,
cropping letterbox 1920x1080 to 1920x800, then resizing to what? You want 1280x X so I ask you to what you resize to keep proportions correct , no error? And resize it say with mode 4.

What that X is going to be?

If resizing 1920x1080 to 1280x720 I have things still exact, then cropping to whatever 1280x whatever, using automaton to autocrop with a mode 4 whatever (not that important cropping I guess, you can use 2 and be even closer in more cases), I still have same proportions on screen, 100%. Nothing is wrong with anything.

We both have real with/height not equal to 2.4:1 anymore error introduced, but it is just imaginary ratio, perhaps even smaller error with second case and resizing with mode 8 (only 1080 cannot resize to 16 mode) but I have proportions correct.

Now, someone decides to get this 1280x X , made by you and by me as well, and tries to resize it in MeGUi. Megui guesses 2.4:1 that is fine, but what for, there is an error made by you and me, in both cases a different error, and MeGui cannot do anything about it to correct it, because it does not know what the margin of error is. In this case pretty negligible, but folks can forge that one pretty good. I simply do not get what is that AR info good for, except just an info for quick orientation what dimension the movie is.

[hello_hello]

Example,
cropping letterbox 1920x1080 to 1920x800, then resizing to what? You want 1280x X so I ask you to what you resize to keep proportions correct , no error? And resize it say with mode 4.

What that X is going to be?

It' exactly the same formula for resizing as if you hadn't cropped, so the resizing is 1280x534. The aspect error is 0.12%
For mod4 there's an extra 2 pixels from the height to be cropped, so you have 1920x798, the resizing would be 1280x532 and the aspect error would be exactly zero. For that I'd be pedantic and crop one extra pixel from both top and bottom of the source to even it out. Like this:

Crop(0,140,0,-140)
Spline36Resize(1280,532,0,1,0,-1)

That's another thing. Resizing after cropping gives me the opportunely to crop single pixels using the resizer so I'm not limited to cropping in multiples of two. It allows for less aspect error but obviously you need to know what the aspect error is.

There's no law stating I have to use a width of 1280, so for mod4 there's no reason not to resize 1920x800 to 1276x532 if you wanted to. No extra pixels cropped, it's mod4 and the aspect error is now down to 0.06%. 1296x540 drops it to zero.
Chances are I'd aim for 1280x? first, and maybe experiment from there, and chances are I'd stick with 1280x? most of the time as any aspect error is generally too small to matter. All those options are ones you don't have when you resize first and auto crop second. Well they're not choices you can make yourself. The auto-crop decides the final resolution.

If resizing 1920x1080 to 1280x720 I have things still exact, then cropping to whatever 1280x whatever, using automaton to autocrop with a mode 4 whatever (not that important cropping I guess, you can use 2 and be even closer in more cases), I still have same proportions on screen, 100%. Nothing is wrong with anything.

I'll admit the aspect error mightn't be exactly zero when you crop first, although for it to be zero when resizing first it still depends on the source resolution and resizing, but it's not an issue even if you're fussy like me. I aim to keep the aspect error to a maximum of 0.1%. It's not something you'd see, and the advantage is the ability to determine the output size exactly beforehand.

You possibly will have the same proportions if you don't resize on playback, but video has to be resized using whole pixel dimensions, so it'll be rounded to the nearest pixel when upscaling if need be.

We both have real with/height not equal to 2.4:1 anymore error introduced, but it is just imaginary ratio, perhaps even smaller error with second case and resizing with mode 8 (only 1080 cannot resize to 16 mode) but I have proportions correct.

There's no aspect error if you don't distort the picture. At least that's my definition. You can remove half of it for all I care, but if the remaining half hasn't been stretched in any way, the aspect error is zero. Not that you would, but that's my definition. So I don't care if I run the 1920x1080 source on the TV, run the encoded version at the same time, and switch between them to see the source picture extends to an extra few pixels top or bottom. If nothing in between has been stretched in any way, there's no aspect error, and if you auto-crop, you're likely to have that happen anyway, or it might go the other way and you're left with a little black top and bottom. No magic there.

Now, someone decides to get this 1280x X , made by you and by me as well, and tries to resize it in MeGUi. Megui guesses 2.4:1 that is fine, but what for, there is an error made by you and me, in both cases a different error, and MeGui cannot do anything about it to correct it, because it does not know what the margin of error is. In this case pretty negligible, but folks can forge that one pretty good. I simply do not get what is that AR info good for, except just an info for quick orientation what dimension the movie is.

If the argument's extending to having to encode something in a certain way in case someone else encodes it later, I think I'll give up. You can only go with what you've got. I've seen DVDs that've had hideous things done to them. Aspect ratios, luminance levels. Should I not re-encode them? Some PAL DVDs of Buffy were 16:9, but the show was really shot and framed for 4:3. I have no issue with a 16:9 version if it's done properly and there's no important information cropped (I'm not a purist) but in this case it was lazy and sloppy. In quite a few places there was stuff at the edge of the frame that didn't belong. I cropped that out where I saw it and resized back to the same resolution as the rest. Sure, some picture top and bottom needs to go too if you want to remove some from the sides etc, as it's effectively zooming in a bit, but you're not doing that unless you crop first and you're not doing it with auto-crop.

MeGUI doesn't guess the aspect ratio. It uses the aspect ratio for the same reason a player does. The only exception I've found is when the resolution happens to be exactly 720x576 or exactly 720x480. I assume somebody decided that was a good idea. Fortunately, you can create custom aspect ratios in order to use the aspect ratio written to the video stream instead, but for everything else there's no need.



For the record the above video is 1280x536 worth of square pixels.
1280/536 = 2.3880597014925373134328358208955
and.....
160/67 = 2.3880597014925373134328358208955

[_Al_]

How did you come up with that 534, how can MeGui come up with that (getting 800)? Does it use autocrop for that (800)? Assuming it does it correctly (does it always?) and finds that 800 value. Then second, how does it it calculate those 534, what that sophisticated resize does actually , forget 1296, you say yourself you would not resize to it, so you have 1280, can you give me an equation how to get 534?

In case of cropping to 1920x800, is it 1280/(1920/800)=533.3333 ~ mode 2: 533.333 round up to 533, is it divisible by 2, no, add 1, it is, we got 534
if cropping to 1920x798, is it 1280/(1920/798)=532 ~ mode 4: 532/4=133 133x4=532
Where is that guessed aspect ratio involved? In our case 2.4:1. It would messed up those 798 calculations, is it looking ahead and checking that 798 would bring exact 532 later on? Thus shooting all outcomes around autocrop value and guessing the best? Is that what that Yoda resize does and that is what is implemented in MeGui? Or does it all at once go back to 1920x800 and offers resize to 1280x532 or crop to 1920x798 and resize 1296x532 ?

Vs. Resizing value : 1280/(1920/1080) = 720 nice number you'd come up with those resizing BD, DVD to known 4:3 or 16:9 videos, you include them in Avisynth scripts, so you do not need to calculate those in the first place. This outcome is expected. 4:3 or 16:9. So no calculation is really happening. Then just mode cropping 2,4, or 8 whatever, 2 is fine I guess. Why don't you admit it, I do not understand. You say that weird resolutions we should exclude because as we know all could be in error already so you might round up, not knowing if up or down both could be worse or better.