Log in

View Full Version : MeGUI cropping and resizing


yetanotherid
20th May 2010, 14:38
I'm trying to find a way to get MeGUI's clever anamorphic encoding to work the same way as the cropping and resizing works when using AutoGK, as I think it's resizing is particularly clever.

An example the AutoGK way....
I'm converting a DVD. There's a need to crop off a couple of extra pixels from the top and bottom of the picture. AutoGK resizes the entire video (width and height together) and, if necessary, crops a little extra from each side to keep the whole thing MOD16. Using AutoGK it's virtually impossible to change the aspect ratio of the picture as such, even though the extra cropping at the sides might change the DAR a little. I like this as I don't like video which is stretched or squished in any way and using AutoGK I don't even have to think about it.

MeGUI will either crop some more to keep the encode MOD16 or it'll resize the height to take it back to MOD16.
I don't like the extra cropping top and bottom and I really don't like the picture being stretched at all. It's also hard to calculate how much extra to crop from the sides in order to keep the image undistorted.

It'd be nice if there was an option to get MeGUI's "resize to mod 16" encoding method to resize the entire image when either the top or bottom is being cropped, rather than to just stretch the height, which seems kind of sloppy to me.

Or is there another MPEG-4 Encoder GUI which crops and resizes the AutoGK way and is fairly easy to use?

Thanks.

Inspector.Gadget
20th May 2010, 15:14
It'd be nice if there was an option to get MeGUI's "resize to mod 16" encoding method to resize the entire image when either the top or bottom is being cropped, rather than to just stretch the height, which seems kind of sloppy to me.

Why? In either case, you're discarding data. If you need cropping and resizing to approximately mirror what goes on in AutoGK, don't use anamorphism. That way your MeGUI encodes are a straight crop -> resize and some minor deviations in DAR arise during resizing but you're not throwing out good pixels. On the other hand, resizing causes you to discard video data whenever you do it, so I usually crop as close to mod16 as I can and then use non-square pixels.

yetanotherid
20th May 2010, 15:54
Why? In either case, you're discarding data.

I don't mind that so much, I'd prefer to lose a little of it than to distort all of it.

If you need cropping and resizing to approximately mirror what goes on in AutoGK, don't use anamorphism.

Yeah, I've slowly started to realise that's the solution, but it's just that AutoGK is so old, and it's way of doing it seems so logical to me, that it kind of surprises me the newer encoder GUI's seem to make it harder.

That way your MeGUI encodes are a straight crop -> resize and some minor deviations in DAR arise during resizing but you're not throwing out good pixels.

That's what I'm looking for I guess, but there's the MOD16 problem. Which I assume you addressed below.

On the other hand, resizing causes you to discard video data whenever you do it, so I usually crop as close to mod16 as I can and then use non-square pixels.

Okay, that sounds like what I've been missing. I just finished messing about with a trial DVD conversion, 1.33 DAR. To trim a couple of pixels from the bottom I had to crop ten from each side. I worked that out after loading the original video in a player and comparing it to the output preview as I went. It also gave me a nice 1.33 DAR output. Clever anamorphic encoding stretched it every time so I gave up on it.

Couple of questions....
The MOD16 thing is mainly for encoding efficiency, yes? Non-square pixels don't change that do they?

I assume using your example I'd be cropping only what I need to, then using the correct shaped pixels to fit the DAR while still keeping it MOD16? Or something like that?

Could I be so bold as to enquire how I do so, and if I can using MeGUI? And if so will the correct DAR then display in MeGUI's preview window? Or is there a better GUI to use for that sort of thing?
I'm just migrating from the old world of XviD, so it's all new to me. I kind of like MeGUI though....

Thanks.

Inspector.Gadget
20th May 2010, 17:24
The MOD16 thing is mainly for encoding efficiency, yes? Non-square pixels don't change that do they?

Yes. Non-square pixels are irrelevant to the encoded dimensions of a clip; they only affect the display dimensions.

I assume using your example I'd be cropping only what I need to, then using the correct shaped pixels to fit the DAR while still keeping it MOD16? Or something like that?

Yes. Suppose you had your typical NTSC DVD with 704 content pixels out of 720 horizontal pixels. Cropping 8 from each side would eliminate black bars, and using the same PAR as the original DVD would then give you the correct display dimensions of the content.

Of course, there's the whole ITU-vs-non ITU debate over the proper display size of an NTSC DVD, but that's not anything that's unique to re-encoding: if the original DVD looks good in Media Player Classic at the non-ITU ~853px display width, then you can safely use the corresponding non-ITU PAR (designated simply 4:3 or 16:9 in MeGUI's anamorphism selector). If, on the other hand, you have a DVD that you know was created from content that was meant to display at the ITU size, then use the ITU designated anamorphism. Most people are in the habit of using non-ITU widths, but it's solely down to personal perception of which width looks right for the DVD: it's unrelated to whether an encoded size is mod16.

To trim a couple of pixels from the bottom I had to crop ten from each side.

That shouldn't happen. At worst, you'd need to overcrop the top and bottom slightly; whether a clip is mod16 vertically is independent of whether it's mod16 horizontally. You shouldn't, for example, worry about cropping consistently relative to the original encoded dimensions so long as you crop to a mod16 resolution and apply the original PAR (so every pixel will always be the same shape and you'll just be dumping black bars and maybe a few edge pixels of content).

Could I be so bold as to enquire how I do so, and if I can using MeGUI?

I typically load the content into MeGUI, seek to a bright frame in the preview window, and let autocrop do its thing. Then I figure out which direction will be best to get to mod16 (or at worst mod8): I'd rather have, say, 3px of black bars and try to crop on playback or when muxing to Matroska then lose 13px of content. So, I start with undercrop and then move to undercrop and compare. Then I eyeball the dimensions (ITU or not) that MeGUI has selected by dropping Spline36Resize(width,height) in the text part of the script window manually and see whether ~852px or ~874px for non-horizontally cropped 16:9 content) makes round objects look rounder. If the wider width looks right, I know it's an ITU-authored disc. If the narrowed width looks right, I know it's a non-ITU disc. Then I pick the anamorphic type in the dropdown. That's way more intervention then I think most people do, but I like to check the things that software can't figure out/decide on its own.

yetanotherid
21st May 2010, 04:32
Inspector.Gadget,
Thank you very much for all of the info. I'll play around a little (or a lot) more until I've got my head around it.
I think I might have misunderstood the purpose of the clever anamorphic encoding... I assumed it's purpose is to create an encode using non-square pixels regardless of the source.... which it seems to do, depending on the resizing and cropping etc... but now I assume it's main function is to correctly encode an anamorphic DVD source. I'm possibly looking at it the wrong way due to not having to think about the input DAR when using AutoGK.

I think I also picked the wrong DVD to convert for my first attempt. Or maybe the best one, as it's forced me to learn... I might look at it that way.
My video has a 1.33 aspect ratio, which isn't a type I convert very often these days. Using AutoGK, unless I do some severe cropping, my output video is also 1.33. AutoGK automatically does whatever resizing and extra cropping that's required to produce an output DAR of 1.33 and I was trying to duplicate this using MeGUI. Hence the need to crop ten extra pixels from each side, and then resize correctly. For any other DAR it doesn't really matter if the output aspect ratio is slightly different to the input aspect ratio, as long as the image isn't stretched or distorted.

I've done a few more conversions and it seems MeGUI does in fact generally convert without distorting the image (although I've not got the the ITU, non-ITU comparison stage yet). At least with anaphoric encoding disabled. I've always converted using non-ITU resizing with AutoGK as every time I've compared the output to the input, that's given me the closest result. There's probably some video which would have benefited from ITU resizing but I just never noticed it.

I converted the same video several times last night using different settings and with the same cropping, and generally MeGUI gave me non-distorted output if I resized and used the "suggest mod16" option. The output just didn't have a 1.33 DAR unless I cropped the sides manually and got it right. Mostly it seemed to produce an image using square pixels. A couple of times though it gave me the original DAR for my output but the pixel aspect ratio was what I thought I'd resized to. For example according to Media Player Classic one conversion had a DAR of (I think) 784x528 but the pixel aspect ratio was 576x 528. I assume that's the anamorphic function at work. I'll have to run a few more conversions until I fully understand the cause and effect of each setting I guess, but I think I'm slowly getting there.

Thanks very much for your help.

teimutm
16th January 2011, 23:04
Great thread guys. Very insightful, and after a few hours of digesting it, I'm definitely a bit more aware.

However I had been running into problems with AR. But lately, blindly, I've been just picking the right input DAR, auto-cropping, and then resizing with suggest resolution for mod 16. Then, I've been comparing the auto preview with the original VOBs in my media player, and it's been working pretty well. Not more than a few pixels off. (To compare, I just do some window resizing on VLC till I get one dimension even with auto preview's, and then look for difference in the other dimension. Sloppy, I know)

But why does this work? In auto preview, the difference between checking and unchecking the mod 16 is usually more than 16 pixels. What is the nature of the suggestion that MeGUI is making?

And also, what's this focus on mod 16, or even mod 8 as Inspector.Gadget stated to sometimes use. Is there some standard for encoding or decoding or something that likes heights to be in multiples of powers of two? (2, 4, 8, 16, and even 1 I suppose). What's the concept here?

Thanks!

yetanotherid
19th January 2011, 05:42
Well, hopefully my understanding of how it all works is a lot better then when I originally started this thread.....


But why does this work? In auto preview, the difference between checking and unchecking the mod 16 is usually more than 16 pixels. What is the nature of the suggestion that MeGUI is making?

It's just taking you to the closest mod16 height to match the width you've chosen (according to the width and height of the video after resizing of course).
For instance if you've got a 16:9 DVD and you resize down to a width of 704, MeGUI would probably suggest 400 as the height. As best as I can tell though it's about as clever as the resizing gets. So if (for example) after cropping, the resized dimensions should have been 704x406, the picture will be squished down a little. That's one reason why I pretty much always use anamorphic encoding for DVDs.... now that I understand it.

You can go into MeGUIs options and set the allowed aspect ratio error to zero (I'm pretty sure it only applies to anamorphic encoding) if you like. Then you can choose the anamorphic "cleverness" you'd like to use and you should get an output without any aspect ratio distortion at all. Plus, when encoding DVDs to square pixels (DVDs don't have square pixels) it's customary to resize "down" to square pixels so you lose a bit of definition in the process.
I'm just making numbers up but a 720x480 DVD which has it's width stretched to display the correct aspect ratio might display as 1080x480 (in square pixel dimensions), however if you decrease the height instead, which is the usual practice when encoding to AVIs etc, it'll display as 720x400.
By using anamorphic encoding you're using the same shaped pixels as the original DVD (depending on the anamorphic method you choose) so you're not losing definition by resizing "down" or needing to use more pixels than the original DVD to resize "up". The way MeGUIs preview... errr..... previewed, seemed to be what was confusing me originally but I think I've got my head around it now. So if you encode anamorphically using any of the options aside from the "resize to mod16" one you'll be using the same shaped pixels as the original DVD. The "resize to mod16" option will basically change the shape of the encoded pixels to give you mod16 without having to crop extra from the video etc.

And also, what's this focus on mod 16, or even mod 8 as Inspector.Gadget stated to sometimes use. Is there some standard for encoding or decoding or something that likes heights to be in multiples of powers of two? (2, 4, 8, 16, and even 1 I suppose). What's the concept here?

I don't understand it properly, but I believe it relates to computers being binary and the efficiency of encoded data. Traditionally you don't usually have a choice as you're forced to use mod16 dimensions by many tools used for encoding (notice how without anamorphic encoding enabled the resize dimensions can only be changed in multiples of 16?) but apparently with x264 it's no longer an issue. Being set in my ways I tend to encode to mod16 dimensions anyway... just in case it causes an unexpected problem with playback... although I've only ever found one. When using the overlay mixer to render the video, and with the video card doing the decoding, the mod16 "empty space" is replaced with a green bar when viewing full screen (at least on my PC), but all the other renderers I've tried don't have that annoyance. So these days I pretty much always use anamorphic encoding for DVDs (most other sources use square pixels so you don't need it) either using the "overcrop" method or the "resize" method. Which one I use really depends on how much extra over-cropping the first method needs to do to achieve mod16. Generally it's not enough to worry about, but sometimes after you've cropped it's necessary to overcrop by nearly a whole multiple of 16 to get to the next mod16 dimension, so then I resize instead.

I hope all that makes sense.

PS. MeGUI defaults to the ITU resize method for DVDs and unfortunately I've not been able to find a way to tell it not to. There's two different pixel aspect ratios (pixels dimensions) which are used on DVDs. The official ITU PAR which very few DVDs seem to use, and the non-ITU PAR which most seem to use. The aspect ratio of the picture will be a little different depending on the pixel resizing method you choose, although if you're using anamorphic encoding it's not a big deal because it's easy enough to change the encoded video's pixel aspect ratio later on if you decide the method chosen when encoding was the wrong one. I always change the Input Display aspect ratio for each MeGUI encode from the default ITU one (ITU 16:9 NTSC, for example) to the non-ITU one (straight 16:9). 95% of the time, that will be the correct one.