View Full Version : About resizing and cropping
sirt
14th April 2012, 10:15
Hi everybody,
I have some technical questions : as from I read around, when encoding with x264 my resolution should be at least mod 4. In the past, I cropped the video then resized it with Lanczos resize but I read it would blur and provoke ringing (especially Lanczos4) so I decided not to use it anymore. Here are the questions :
1) Should I just crop with the crop(x,x,x,x) function and that's all ? Will that maybe result in blurring anyway ? Is there another way to crop ?
2) What if, for some reason, I have a potential source that has black bars ; after cropping, let's say one of width or height is divisible by 2. Should I keep it like that or intentionally cut more pixels in order to have a weft divisible by 4 ?
3) I'm still not sure of what mod4 is : does that just mean 4 is the largest divisor of width or height ? How to be sure to systematically do mod4 at the cost of cutting some extra pixels ?
sneaker_ger
14th April 2012, 12:22
1.) Just crop (and then resize if desired)
2.) keep it like that
3.) mod4 resolution means that both the width and the height are divisible by 4 without any remainder.
Example:
width: 1920 / 4 = 480, remainder 0
height: 1080 / 4 = 270, remainder 0
=> 1920x1080 is mod4
mod16:
width: 1920 / 16 = 120, remainder 0
height: 1080 / 16 = 67, remainder 8 (67.5)
=> 1920x1080 is not mod16
sirt
14th April 2012, 21:45
Thanks sneaker_ger, it is much clear now.
EDIT : I only resize when encoding and HD Full source an Heavy one (1280x720), I use spline16resize(1280,720) before cropping in fact ; otherwize, cropping then resizing seems to distord the video because it forces it to come back at 1280x720 again. Did you perhaps made a lapsus ? Anyway do you think that spline16resize is enough rafinate or would you suggest another resizer ? As you probably know I want to avoid blurring and ringing and I know some resizers can cause that.
Groucho2004
14th April 2012, 22:13
I use spline16resize(1280,720) before cropping in fact ; otherwize, cropping then resizing seems to distord the video
Obviously you have to resize properly after cropping.
For example:
- Crop 1920x1080 to 1920x816
- Resize to 1280x544
Now figure out the mindblowing math I used there.
Anyway do you think that spline16resize is enough rafinate or would you suggest another resizer ? As you probably know I want to avoid blurring and ringing and I know some resizers can cause that.
I like Spline36 for downscaling, Spline16 is also nice. A matter of taste.
sirt
14th April 2012, 22:25
Yes thanks, I was dumb sorry. But there the divising factor is 1.5 (1920/1280=816/544=1.5) but let's say I crop from 1920x1080 to 1916x816, then - according to your method - I will need to use that 1.5 factor ; let's call x the width and y the lenght, so 1916/x=1.5 and 816/y=1.5 which gives you x=1277,333333 and y=544 ; all that may imply spline16resize(1277,544) but it seems weird in so far 1277 is not mod 4, I may be appealed to try 1276 instead, so something like that :
crop(2,132,-2,-132)
Spline16Resize(1276,544)
What do you think ?
Groucho2004
14th April 2012, 22:38
Yes thanks, I was dumb sorry. But there the divising factor is 1.5 (1920/1280=816/544=1.5) but let's say I crop from 1920x1080 to 1916x816, then - according to your method - I will need to use that 1.5 factor ; let's call x the width and y the lenght, so 1916/x=1.5 and 816/y=1.5 which gives you x=1277,333333 and y=544 ; all that may imply spline16resize(1277,544) but it seems weird in so far 1277 is not mod 4, I may be appealed to try 1276 instead, so something like that :
crop(2,132,-2,-132)
Spline16Resize(1276,544)
What do you think ?
Why would you not stick with a width of 1280 and simply adjust the height accordingly (and round to mod4 if you want)? I only gave you an example.
sirt
14th April 2012, 22:52
In my example there are annoying vertical black bars, that's why I cropped from 1280 to 1276.
Groucho2004
14th April 2012, 22:55
In my example there are annoying vertical black bars, that's why I cropped from 1280 to 1276.
I thought your source is 1920x1080.
sirt
14th April 2012, 23:03
Well sorry my brain is completly down...I was meaning 1920x1080 --->1916x816 with the cropping line (in order to remove the black bars) then I wanted to resize by keeping the 1.5 factor correctly that's why I said I should do spline(1277,544) but it looks incorrect to me so I choose spline(1276,544) (i just followed your method below)
sneaker_ger
14th April 2012, 23:07
Why are you still sticking to mod4? I told you that mod2 is sufficient (for progressive 4:2:0).
To pick up your example:
Source: 1920x1080
1.) crop(2,132,-2,-132) #result: 1916x816
2.) resize to a width of 1280, while keeping the aspect ratio (using simple math (http://en.wikipedia.org/wiki/Cross-multiplication)):
816 / 1916 = x / 1280
=>
x = (816 * 1280)/1916 ~= 545.1
Round to nearest mod2 resolution:
Spline16Resize(1280, 546)
Groucho2004
14th April 2012, 23:12
Well sorry my brain is completly down...I was meaning 1920x1080 --->1916x816 with the cropping line (in order to remove the black bars) then I wanted to resize by keeping the 1.5 factor correctly that's why I said I should do spline(1277,544) but it looks incorrect to me so I choose spline(1276,544) (i just followed your method below)
How about this:
- Crop to 1916x816
- The scaling factor for a target width of 1280 is 1916/1280 = 1.496875
- Your target height would then be 816/1.496875 = 545.13569937369519832985386221294
- Round to mod4: 544
Of course you can use a target width of 1276. It's up to you.
sirt
14th April 2012, 23:17
Why are you still sticking to mod4? I told you that mod2 is sufficient (for progressive 4:2:0).
Thanks for your advise and method. So the 1.5 factor is not absolutely needed, is it ? 1920/1280=1.5 but 1080/546=1.9, I think - perhaps undeservedly - that I should have the same dividing factor between both (such as 1920/1280=1.5 and 1080/720=1.5) that's why I wanted to use spline(1276,544) ; I know I am finical but resizing to 1280 the 1920 weft whereas I cropped it to 1916 should result in theorical blurring, shouldn't it ?
About mod2 : in spite of the fact I've read last builds implemented in the x264 should offer the possibility to use mod2, I've also read it may be problematic with some decoders, especially when you play the video trough a blu ray player. Am I wrong ? That's why I'm after mod4.
Groucho2004
14th April 2012, 23:23
1920/1280=1.5 but 1080/546=1.9, I think - perhaps undeservedly - that I should have the same dividing factor between both (such as 1920/1280=1.5 and 1080/720=1.5) that's why I wanted to use spline(1276,544) ; I know I am finical but resizing to 1280 the 1920 weft whereas I cropped it to 1916 should result in theorical blurring, shouldn't it ?
I give up, sorry.
sirt
14th April 2012, 23:28
lol Why ? You should never give up...I am punctilious that's a fact but I don't want any blur, either ringing, nothing that is NOT from the source. Then resizing to 1280 even thought I have cropped 4 pixels from the source is iqual to a distorsion in my mind and in your second approach above you are respecting the 1.5 scaling factor too.
sneaker_ger
14th April 2012, 23:36
Thanks for your advise and method. So the 1.5 factor is not absolutely needed, is it ? 1920/1280=1.5 but 1080/546=1.9, I think - perhaps undeservedly - that I should have the same dividing factor between both (such as 1920/1280=1.5 and 1080/720=1.5) that's why I wanted to use spline(1276,544)
Of course keeping the AR means a constant factor, and it will check out if you follow the simple math posted above:
1916 / 816 ~= 2.348
1280 / 546 ~= 2.344
(Error ~= 0.16 %)
I know I am finical but resizing to 1280 the 1920 weft whereas I cropped it to 1916 should result in theorical blurring, shouldn't it ?
I'm no expert on the spline function, but seeing that you can't do cross-multiplying: no, not really.
About mod2 : in spite of the fact I've read last builds implemented in the x264 should offer the possibility to use mod2, I've also read it may be problematic with some decoders, especially when you play the video trough a blu ray player. Am I wrong ? That's why I'm after mod4.
I don't know where you've read that, but I've never came across any such issues. (Also, internally H.264 works with mod16, so mod4 is just as "bad" as mod2.)
sneaker_ger
14th April 2012, 23:47
Just wanted to add:
The factor you can choose is arbitrary, so 1280x546 is just as wrong or right as your 1276x544. I just pick 1280 as I'm used to that and since it resembles the common 720p resolution, but you don't have to stick to that.
sirt
14th April 2012, 23:59
Okay thanks for those precious precisions. Now, you can certainly guess what I wonder about...what will be the theorical difference between the 1280x546 and the 1276x544 encode one ? It sound like we won't be able to see any difference between each one but I am curious as you know...
I was referring to that thread http://forum.doom9.org/showthread.php?t=101195 ; but I have another reason to avoid mod2 ; sometimes I experience deinterlacers (you can especially check my thread with the "test.mkv" file) and a large amount of deinterlacers don't support mod2, mostly when you have to crop and cut the frame in separate segments to deinterlace (such as Tdeint to name one) and I don't even tell you about the bob based ones.
sneaker_ger
15th April 2012, 00:21
Okay thanks for those precious precisions. Now, you can certainly guess what I wonder about...what will be the theorical difference between the 1280x546 and the 1276x544 encode one ? It sound like we won't be able to see any difference between each one but I am curious as you know...
:confused:
The difference is the resolution.
I was referring to that thread http://forum.doom9.org/showthread.php?t=101195
Nowhere in that thread does it say that mod4 is more compatible with decoders than mod2. And even if x264 did not support mod2 and mod4 encoding many many years ago, this does not have anything to do with decoder compatibility.
but I have another reason to avoid mod2 ; sometimes I experience deinterlacers (you can especially check my thread with the "test.mkv" file) and a large amount of deinterlacers don't support mod2, mostly when you have to crop and cut the frame in separate segments to deinterlace (such as Tdeint to name one) and I don't even tell you about the bob based ones.
Interlaced YV12 must indeed be at least mod4. mod2 is not allowed in that case.
sirt
15th April 2012, 00:33
:confused:
The difference is the resolution.
Sure but I was thinking of which one would be the most accurate i.e. the less blurry ; I foretell my 1276x544 would be clear-cut but I think it is just splitting hairs...
I was playing around with a 1080i source, that's why I was reluctant with mod2, but it's all clear now.
sneaker_ger
15th April 2012, 00:45
Sure but I was thinking of which one would be the most accurate i.e. the less blurry ; I foretell my 1276x544 would be clear-cut but I think it is just splitting hairs...
What makes you assume that? (rhetorical question)
The differences between those two will be negligible. 1276x544 will not be "less blurry" than 1280x546.
sirt
15th April 2012, 13:08
I assume that because I cropped by 4 pixels (1916) and I just divide 1916 by a constant factor (1.5) which means 1276 (approxiamtely) whereas you have resized to 1280, which I think may cause some blurring. But I can be wrong. I mean you could have used 1280 if I hadn't crop from the start.
sneaker_ger
15th April 2012, 13:41
Why "1.5" and not "1.4", "1.6" or "3.14"? The factor is totally arbitrary.
And how is 1.496875 (=1916/1280) not constant, while 1,501567 (~=1916/1276) is?
sirt
15th April 2012, 15:20
I don't know but I keep on thinking I should not resize to 1280 (in this example) in view of I cropped 4 pixel from the source ; that's why I think I have to divide by a constant factor the 1916x816 file ; 1.5 is a good choise because 1276x544 are mod4 ; If I choose 3.14 then I won't be able to get a HD Ready output (as I'm expecting), I would have to use 610x260 which I don't want (I plan to do HD Full--->HD Ready) and 1.5 seems to be the divding divisr to use in that case
sneaker_ger
15th April 2012, 15:34
I don't know but I keep on thinking I should not resize to 1280 (in this example) in view of I cropped 4 pixel from the source
You keep "thinking", but cannot provide any mathematical reason. It's a totally baseless gut feeling.
that's why I think I have to divide by a constant factor the 1916x816 file
You are talking about "constant" factors, but don't seem to know what that means.
1.5 is a good choise because 1276x544 are mod4
Again: why 1.5? Where does that number come from? I can choose ANY factor and then round to the nearest mod2/mod4 resolution.
If I choose 3.14 then I won't be able to get a HD Ready output (as I'm expecting), I would have to use 610x260 which I don't want (I plan to do HD Full--->HD Ready)
I just choose 3.14 (~= Pi) to show you that you can choose any factor. There is no reason as to why 1.5 would be any better or "more constant" than any other factor.
and 1.5 seems to be the divding divisr to use in that case
Again, you fail to provide any reason as to why "1.5 seems to be the divding divisr to use in that case".
sirt
15th April 2012, 16:03
So what do you call a "constant factor" ? Of course I could choose anyone but not 3 for example, I don't want to reduce too much the resolution if you prefer.
Didée
15th April 2012, 16:27
What has been explained to you is this:
Regarding "quality", it is 99.999% irrelevant if you resize to 1280, or 1196, or 1202. It does not matter.
And if it doesn't matter anyway, then it is good practice to use a "standard" resolution. 1280 is very standard.
pbristow
16th April 2012, 01:07
So what do you call a "constant factor" ? Of course I could choose anyone but not 3 for example, I don't want to reduce too much the resolution if you prefer.
"Constant" simply means "not changing".
If I start a job with 1.3397, continue with 1.3397 and finish with 1.3397, then 1.3397 is constant.
If I start with 1.5, drift upwards after a while to 1.5000001, and then jump up briefly to 3.987 before dropping back eventually to 1.5, then that's *not* constant, it's varying.
If I do all my resizing jobs using the ratio of 1.42536, then the ratio is constant across all my jobs. If I do just one job with any other value, then the value is *not* constant across those jobs.
Clear?
I'm really curious though as to what *you* meant by constant. Did you mean it's a more "simple" ratio (i.e. one that equates to a ratio of two short integers, such as 3/2 = 1.5, as opposed to, say, 3690/2461 = 1.49939...)?
sirt
16th April 2012, 14:31
Yes, thank you for those explanations, it is clear now : there is not a "accurante" dividing factor but it is accurate to use same factor for both length and width.
By constant I was just meaning I should divide both resolution parameters by the same number (such as 1.5 ) which is consistent with your speech. Then I'm not sure if it is a good idea to choose your 1.49939...shouldn't I just use 1.5 in that case ?
If you consider my example : 1920 x 1080 ----> cropping : 1916 x 816 , then I want to use 1.5 as dividing factor because it is the "theorical" number to make an HD Ready output (1280 x 720) which means I should just divide my 1920 x 1080 file by 1.5 to obtain the 1280 x 720 output. But in this case I apply it to the 1916 x 816 cropped input and 1916/1.5=1277,33 and 816/1.5=544 so I choosed to resize like that: spline(1276,544) and I don't know if I'm wrong or if there is a sense to talk about "being wrong". As from I understood, I could divide by 1.6 or 1.4 (or whatever) and it will be "correct" in so far as I would just reduce the resolution without any distorsion, but if I use 4 then 1916/4=479 and 816/4=204 so - in that case - I would use spline(479,204). But it's stupid : the final output wont ve a 720p encode anymore. So that's why I'm still wondering if I should always use 1.5 even if I crop or not to achieve a 720p output. In this case if you consider 1920---(/1.5)---> 1280
1916---(/x)-----> 1280 ---> (1916/x) x 1280 = 1920/1.5 x 1280 ----> x=1.496875
Then if I want my output to be 1280 I should divide 1916 by 1.496875 and same for 816 : 816/1.496875=545.1 so I should use 544 instead and spline(1280,544). Well I understand how it works but I am not what I should choose between those too methods or if it really matters. It seems not because you said the difference won't be noticable but is there anyway some "theorical" reason or dividing ratio to use when you crop ? It's clear 1.5 has to be chosen to pas from a Full HD source to a HD Ready source but what about a Full HD which is cropped ?
Guest
16th April 2012, 15:00
If you don't believe us when we tell you that such small differences are insignificant, then just do what you think is best! Repeating the same questions about "theorical" differences is not going to get different answers than the ones you have already received.
sirt
16th April 2012, 15:16
I understood the differences are insignificant but I'm after "theorical" differences...I don't know how to develop more. It's like asking when a number is prime or not : you will answer "a number is prime when it's common divisors are 1 and itself" ; that is what I call a "theorical" explanation. In my case, all I'm sure now is that dividing by the same number will result in a correct AR but I still ignore (or I am unable to understand) what would be the "theorical" number to use in such-and-such case : as I said several times the "theorical" number for a Full HD video (to obtain an HD Ready one) will be 1.5. I think that is correct : it will resize it to a HD Ready (1280 x 720). Without cropping, the problem is solved but if I crop I am not sure if I should divide by 1.5 to achieve a 720p encode. That is my question. We can approximate as long developped before but what should be the "right" factor is still not clear to me. Please don't blame me for being redundant.
Gavino
16th April 2012, 15:38
There is no theoretically correct number.
You choose either the width or height that you want, and then alter the other one (height or width respectively) by the same ratio. That's all.
Groucho2004
16th April 2012, 17:29
Wow, this is still going on. Someone should draw some pretty pictures to explain it. :D
sirt
16th April 2012, 17:43
Well it's clear now, I am probably too finicky. Thanks to everybody for your patience !
ajp_anton
16th April 2012, 19:41
Wouldn't 1280 in fact be "less blurry" than 1276, because it has 0.3% more pixels?
The difference is of course basically zero, but since you're stuck in a placebo world where 1276 is better, I'm just countering it with another placebo.
A factor of 1.5 is not magically better than 1.496875 just because it has less decimals.
Groucho2004
16th April 2012, 22:24
Wouldn't 1280 in fact be "less blurry" than 1276, because it has 0.3% more pixels?
The difference is of course basically zero, but since you're stuck in a placebo world where 1276 is better, I'm just countering it with another placebo.
A factor of 1.5 is not magically better than 1.496875 just because it has less decimals.
Haha - Bazinga, as Sheldon Cooper would say. :D:D:D
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.