Hi Steinar,
We are using the resize processor which doesn't appear to be honouring either the pixel aspect ratio or the image proportions. How do we perform proportional scaling? Would I need to pad the source file first?
Any suggestion on improving our workflow diagram would also be appreciated.
Thank you heaps for all your work.
Mark
image proportions in resize
-
- Posts: 54
- Joined: Thu Sep 22, 2016 7:12 am
Re: image proportions in resize
I've done a bunch of reading about avisynth. And it does not support pixel aspect ratios and assumes everything is using square pixels. This seems to be more of a problem than the avisynth people realise. I'm asking in the avisynth forum how to handle this correctly.
Mark
Mark
-
- Posts: 54
- Joined: Thu Sep 22, 2016 7:12 am
Re: image proportions in resize
It appears that avisynth does not handle pixel aspect ratios (bit of an oversight in my mind) So all resizing calculations must be done external to avisynth.
I need to get the pixel aspect ratio from FFASTrans, I can find the variables %s_disp_aspect% and %s_pix_aspect%. What are the specifics for these variables?
is disp_aspect = width / height
or is it width * pix_aspect / height
and what values are being used in pix_aspect?
would a 720x576 16:9 SD video have a pix aspect of 64:45 or 118:81 or 512:351 ?
Pixel aspect ratio is something many programmers get wrong. I found this page invaluable when it comes to pixel aspects;
http://www.mir.com/DMG/aspect.html
I've come up with this custom resizer, but there is a syntax error somewhere, I can't spot it...
I need to get the pixel aspect ratio from FFASTrans, I can find the variables %s_disp_aspect% and %s_pix_aspect%. What are the specifics for these variables?
is disp_aspect = width / height
or is it width * pix_aspect / height
and what values are being used in pix_aspect?
would a 720x576 16:9 SD video have a pix aspect of 64:45 or 118:81 or 512:351 ?
Pixel aspect ratio is something many programmers get wrong. I found this page invaluable when it comes to pixel aspects;
http://www.mir.com/DMG/aspect.html
I've come up with this custom resizer, but there is a syntax error somewhere, I can't spot it...
Code: Select all
cpos = Findstr(%s_disp_aspect%,":")
num = Value(LeftStr(%s_disp_aspect%,cpos-1))
den = Value(MidStr(%s_disp_aspect%,cpos+1))
dar = Float(num) / Float(den)
width = dar > 1 ? 1920 : Round(dar * 1080)
height = dar > 1 ? Round(1920 / dar) : 1080
padh = (1080 - height) / 2
padw = (1920 - width) / 2
m_clip = BicubicResize(m_clip,width,height)
m_clip = AddBorders(m_clip,padw,padh,padw,padh)
# The following MUST be the last line of your script
Return m_clip
-
- Posts: 54
- Joined: Thu Sep 22, 2016 7:12 am
Re: image proportions in resize
OK I've determined that the problem with my script is that I'm unable to read an FFAStrans variable in an avisynth script.
I can't seem to find a way to read these variables into the script.
Or could I do the calculation externally and use the resize and pad filters?
I can't seem to find a way to read these variables into the script.
Or could I do the calculation externally and use the resize and pad filters?
-
- Posts: 54
- Joined: Thu Sep 22, 2016 7:12 am
Re: image proportions in resize
I've worked out what I was doing wrong. This is my working smart resizer.
I'd just like to know if s_disp_aspect takes the pixel aspect ratio into account and what values are being used for media which has an implied PAR (such as .dv and .mpeg)
I'd just like to know if s_disp_aspect takes the pixel aspect ratio into account and what values are being used for media which has an implied PAR (such as .dv and .mpeg)
Code: Select all
s_dar = "%s_disp_aspect%"
cpos = FindStr(s_dar,":")
lpos = cpos - 1
rpos = cpos + 1
s_num = LeftStr(s_dar,lpos)
s_den = MidStr(s_dar,rpos)
i_num = Value(s_num)
i_den = Value(s_den)
f_dar = Float(i_num) / Float(i_den)
n_width = Round(f_dar * 1080.0)
n_height = Round(1920.0 / f_dar)
i_width = f_dar > 1.0 ? 1920 : n_width
i_height = f_dar > 1.0 ? n_height : 1080
i_width = i_width / 2 * 2
i_height = i_height / 2 * 2
i_padh = (1080 - i_height) / 2
i_padw = (1920 - i_width) / 2
m_clip = "%i_interlace%" == "0" ? m_clip : SeparateFields(m_clip)
m_clip = BicubicResize(m_clip,i_width,i_height)
m_clip = AddBorders(m_clip,i_padw,i_padh,i_padw,i_padh)
m_clip = "%i_interlace%" == "0" ? m_clip : Weave(m_clip)
# The following MUST be the last line of your script
Return m_clip
Re: image proportions in resize
Pixel aspect ratio is derived from the "sample_aspect_ratio" flag in ffprobe. Note that ffmpeg calls it SAR and some call it PAR. Tomayto-tomahto...
Display aspect ratio is derived from the "display_aspect_ratio" flag in ffprobe. If the SAR (or PAR) is 1:1 then the DAR is calculated from width/height.
To be honest, I haven't looked very deeply into this but I assume that the smart developers of ffmpeg knows what they are doing. So, FFAStans get most of its media data through ffmpeg. If they get it wrong, FFAStrans will also probably get it wrong. The problem with aspect ratios is that they're just metadata. If that data is supplied then fine. But if it's not then you don't automatically get an ought from an is. F.ex. if you have 720x576, 25 fps one can assume that it is a digital PAL video that ought to be stretched by some ratio, but it can also be that someone has created a square pixel video.
But now that you brought it to my attention I will take closer look at the topic. Thanks! And if you find some anomalies in FFAStrans on this issue then please let me know. But you can always correct consistent incorrect values using FFAStrans conditional and populate nodes.
-steinar
Display aspect ratio is derived from the "display_aspect_ratio" flag in ffprobe. If the SAR (or PAR) is 1:1 then the DAR is calculated from width/height.
To be honest, I haven't looked very deeply into this but I assume that the smart developers of ffmpeg knows what they are doing. So, FFAStans get most of its media data through ffmpeg. If they get it wrong, FFAStrans will also probably get it wrong. The problem with aspect ratios is that they're just metadata. If that data is supplied then fine. But if it's not then you don't automatically get an ought from an is. F.ex. if you have 720x576, 25 fps one can assume that it is a digital PAL video that ought to be stretched by some ratio, but it can also be that someone has created a square pixel video.
But now that you brought it to my attention I will take closer look at the topic. Thanks! And if you find some anomalies in FFAStrans on this issue then please let me know. But you can always correct consistent incorrect values using FFAStrans conditional and populate nodes.
-steinar