![]() |
Avisynth, Vapoursynth crop aspect ratio calculation?
I digitized several VHS tapes (720x576 PAL 5:4 SAR, 4:3 DAR) and they have different edge noise positions, so crop left,right,top,bottom varies per tape.
I'm trying to do this: 1. crop left/right/top(sometimes)/bottom 2. de-interlace 3. resize to 1440x1080 HD MINUS the borders added afterwards 4. add borders in HD (values calculated from crop in SD to keep aspect ratio) left + right What I have so far is this but the calculation is incomplete and propably totally wrong, I can't get my head around this :wall1: Code:
# crop vars |
This has always been a confusing topic for me anyway - If I understand correctly, (in NTSC terms, I realize you have PAL there) you'd want to crop the 720x480 to 704x480 FIRST and then resize to a 4:3 aspect ratio. With NTSC, there's an equivalent of 16 horizontal pixels in total are added (or technically displayed from the horizontal blanking area) as black bars on the sides. My understanding is that DVD's, can be encoded not to have those black bars, but then the actual DVD player will add them to the output if the encoded resolution is 704x480. These would typically have been off screen on most consumer CRTs due to overscan, so this isn't something that was usually observed at the time it was commonly used.
The issue that then leaves is having to deal with head switching noise at the bottom which technically should be masked rather than cropped as I believe that is part of the final 4:3 aspect ratio. Theoretically, for every 3 lines you take off at the bottom for head switching noise or any top line noise, I suppose you could clip something like 4 or 5 total horizontal pixels off of the sides (someone else that is better at math would need to comment about the specific ratio of lines to remove). So you'd end up with something like 696x474 or 694x474 prior to the resize (maybe) if aspect ratio preservation is the primary goal without any sort of black bars. Doing any sort of side cropping is data loss though, so purists would always recommend masking top and bottom rather than cropping. From a symmetry standpoint, I could also see splitting the lower black bar and padding the top with half of those black lines from the bottom. Curious what others do for their cropping/masking. I take it most just crop and resize without really thinking too much about if the final aspect ratio is a little off which is most likely to be imperceptible to the average viewer. |
But isn't NTSC DVD 720x480 SAR 3:2 non-square pixels that needs to be stretched to 720x540 DAR 4:3 (when not 16:9 widescreen that is) square pixels for proper viewing so cropping would only lose data?
In my PAL case it would be 720x576 SAR 5:4 non-square to 768x576 DAR 4:3 square, but instead upscaling directly to 1440x1080, also 4:3 DAR. But that's the easy part :) What I'm trying to achieve here is cropping the VHS noise left,right,bottom,top zooming in(during resize) but stop zooming else I would lose too much of the bottom, instead adding borders left+right. There is never a border needed top or bottom. The borders to be added AFTER resizing or else the left+right border edges are oversharpened during resizing. So it all needs to be automatically calculated to keep the aspect ratio... |
Starting with the following equation:
Quote:
Code:
dar = 4/3Next, adding some variables to yours: Code:
cropped_x = capture_x - (cropleft + cropright)Code:
# DAR = PAR x SARCode:
resized_x = 1440 |
That doesn't seem right, or I'm doing it wrong :screwy:
It resizes to 2150x1080 instead of something like 1350x1080 This is what I've used: Code:
cropleft=14Also I'm not sure why the 16 pixels padding is necessary? |
I think it's doing some or all of its calculations using integers instead of floating point values. So try specifying, for example, "720." with a decimal point instead of "720".
|
If I put it in a calculator it's the same result:
# capture_sar = capture_y / (capture_x - padding_x) 576 ÷ (720 − 16) = 0.818181818 # par = dar / capture_sar (4÷3) ÷ 0.818181818 = 1.62962963 # cropped_x = capture_x - (cropleft + cropright) 720 − (14 + 12) = 694 # cropped_y = capture_y - (croptop + cropbottom) 576 − (0 + 8) = 568 # resized_y = 1080 # resized_x = par * (cropped_x / cropped_y) * resized_y 1.62962963 × (694 ÷ 568) × 1080 = 2150.4225357 |
Oops, it should be:
Code:
capture_sar = (capture_x - padding_x) / capture_y |
Quote:
https://www.digitalfaq.com/forum/vid...-mp4-easy.html Selurs post on aspect ratios has an interesting read at the end of it for anyone new to anamorphic pixels. https://forum.selur.net/thread-597.html |
Quote:
And indeed when comparing, the output image is stretched too wide... I still don't have a clue how many pixels I should subtract from this 1439 to shrink the width (and add to the borders afterwards) |
Actually it's 1439.539 pixels across, which is then rounded to 1440.
By cropping out 14+12-16=10 pixels from the x axis that count against (and reduce) the 4:3 DAR, and 8 pixels from the bottom that then increase the DAR, you've returned the image back to nearly the same 4:3 DAR. It's a happy coincidence, as Bob Ross might say. |
---------------------------------
|
2 Attachment(s)
Yes, nearly 4:3, but not quite.
If you compare both screenshots fullscreen, the output is a bit stretched too wide horizontally, that's what I'm trying to avoid: (note 1: the input screenshot resolution is 768x576 because I put the player in 4:3 aspect ratio) note 2: the leftcrop is too low for this VHS but I keep the value the same in this example here for consistency) input: Attachment 18082 output: Attachment 18083 |
Site design, images and content © 2002-2026 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2026 Jelsoft Enterprises Ltd.