ImageBorders & FrostyBorders Scripts

[dunt]

The best aspect ratio is stretch video to fullscreed

Personally I don't like stretching, even warped stretching, but you could try the Avisynth SimpleResize plugin. It includes a function called WarpedResize.

http://avisynth.nl/index.php/SimpleResize

Hello
Warped resize is what was looking for .thankyou

[rgr]

Also, I am curious, could you provide a model number of the panasonic TV's you are referring to? I want to look into those TV's if they offer such an option for what you described.

I had this mode on an old Thomson TV (Cinerama mode). It cut off the image a bit from the bottom and top, expanded the center of the image slightly, but stronger at the edges.

[hello_hello]

There's a link to a new version of FrostyBorders dated 2023-06-02 in the opening post.

- Added a StaticT argument for changing the texture of FrostyBorders to non-static (grain). The default is StaticT=true, the same as for previous versions (grain is added as a static texture). StaticT=false only works for non-static borders, as static borders always have a static texture.

- Fixed an error when neo_f3kdb was specified for adding border texture (GPlugin=2) instead of AddGrainC.

- Fixed an error when no output width/height were specified, or when FrostyBorders was cropping and/or resizing without needing to add borders.

As a side note, I was watching a video yesterday and there was a scene with a TV in the background showing a picture containing some very FrostyBorder-like borders. No doubt there's several professional programs with similar border functionality built in, but I guess it means the script's doing something right. The borders on the picture on the TV had quite a lot of grain and the picture itself was grainy, so no doubt the borders were added to the sides before grain was added to the whole picture, but it's what inspired me to add the StaticT argument to FrostyBorders. That way when adding borders to a grainy picture there's now an option to make the borders grainy too, instead of always having a static texture.

Simulating the borders on the picture on the TV in the video

FrostyBorders(1280,720, 200,0,-200,0, Clone=3, Blur=10, Texture=50, TSoft=1, StaticT=false)


[Attachment 71434 - Click to enlarge]


[Attachment 71435 - Click to enlarge]

[thebib62]

Your latest addition to the script is much appreciated. Having the grain be dynamic rather than static is a huge bonus! I think I've mentioned before that I use a stripped down version of Windows 10, which eliminates the windows store. Unfortunately, intel only distributes the Intel utility control panel through the Windows store. It is no longer packaged within a native win32 program. Since I'm on a stripped down version of Windows 10, there's no way for me to make any adjustments to my Intel CPU which unfortunately has the noise removal option enabled by default. This noise removal option conflicts with the grain that is applied while using Frostyborders. I was able to bypass this by downgrading to an older driver version for my Intel cpu. But I recently switched to a newer Intel CPU which doesn't offer the legacy control panel without the use of the windows store. Because your script allows for dynamic grain, I believe it tricks the noise removal option that's enabled by default and actually is not applied to the video. It seems to only be applied if the grain option is set to static. This is a huge win! It's a feature that I didn't know I wanted until running into this issue again.

Also, I'm convinced I saw your script being used by other media outlets as well. 😂 That's got to feel good. It is an excellent script!

[hello_hello]

You'd think it'd be the other way around, that the player would only try to denoise non-static grain, because by definition noise isn't static.
If I remember correctly, wasn't the problem one of banding, caused by the noise removal being active? Maybe the noise removal function also includes some debanding, but whatever's going on, at the change to the script is useful to you.

[hello_hello]

There's a link to a new version of FrostyBorders dated 2023-09-25 in the opening post.

- There's now a native VapourSynth version of the FrostyBorders function.

- Support for resizing based on a sample aspect ratio in frame properties has been added to both versions.

- A CropDAR argument has been added (Cropping Display Aspect Ratio).

- A TCRatio argument has been added (Top Cropping Ratio).

CropDAR can be used to ensure the picture is cropped to a certain DAR to minimize the size of any borders being added.
When CropDAR is causing the video height to be cropped, TCRatio determines how much of the height cropping is taken from the top in relation to the bottom.
The new CropDAR and TCRatio arguments should make it possible to control the cropping in a way that previously required a separate function (making it easier to add FrostyBorders via ffdshow's Avisynth filter or as a video filter for MPV player (Vapoursynth version).

Post #2 has been updated with an example script showing the intended CropDAR and TCRatio usage.
Post #3 contains a similar script for the VapourSynth version, with instructions for using it as a video filter with SMPlayer or MVP Player (in a similar way to running the Avisynth version via ffdshow's Avisynth filter).

For anyone using CropResize, I'll be uploading a new version soon with the same TCRatio argument added, and also in a VapourSynth flavour.

[thebib62]

Hello again, thanks for the update. However, when I tried using the newest version, I get this error.

script error: there is no function named 'propGetAny'... line 145.

[hello_hello]

thebib62, which version of Avisynth are you using?
http://avisynth.nl/index.php/Internal_functions#propGetAny

I completely forgot to bypass the check for a SAR in frame properties for older versions of Avisynth+ and Avisynth 2.6. The new version of CropResize will have the same problem until I fix it.

I'm using Avisynth+ 3.7.2 (there was an issue with 3.7.3 that made me revert to 3.7.2, but I've forgotten what it was).
I'm not sure exactly when the frame properties stuff was added (I'll have to work it out before I can update FrostyBorders). The various frame property functions probably weren't all added at the same time anyway.

Until I upload a fixed version, you should able to bypass the frame properties check by commenting out lines 145 & 146 in the script (the first two lines under the Aspect & Dimensions section):

# PropsNum = Source.propGetAny("_SARNum")
# PropsDen = Source.propGetAny("_SARDen")

Should that result in a different error, instead of commenting them out, change them to this:

PropsNum = 0
PropsDen = 0

You'll also need to comment out line 989. It's the first line in the FrostyBorders Output section.

# FrostyOut = FrostyOut.propSet("_SARNum", 1).propSet("_SARDen", 1)

I'll upload a new version sometime soon, although I assume you'll have updated Avisynth+ by then.

[thebib62]

I am using Avisynth 2.6.0. I could never get AviSynth+ to work...
Looking forward to your fix... In the meantime, would you happen to know why AviSynth+ wouldn't work with Frosty]Boarders and Potplayer?
Maybe I am doing something wrong. Just seems strange I can get Avisynth 2.6.0 working but not +.

[hello_hello]

I am using Avisynth 2.6.0. I could never get AviSynth+ to work...
Looking forward to your fix... In the meantime, would you happen to know why AviSynth+ wouldn't work with Frosty]Boarders and Potplayer?
Maybe I am doing something wrong. Just seems strange I can get Avisynth 2.6.0 working but not +.

None that I can think of off the top of my head, aside from Avisynth+ possibly requiring some runtime files, but there's a version of the installer at github that includes them.
https://github.com/AviSynth/AviSynthPlus/releases
Was there any sort of error message and was Avisynth+ working outside of PotPlayer? You weren't mixing 64 and 32 bit versions of Avisynth and the player or anything like that?

While I was updating FrostyBorders and CropResize this time I was tempted to remove all the Avisynth version checks and switch to Avisynth+ syntax is places, as I didn't think anyone would be using Avisynth 2.6 any more. Just as well I didn't.

When I first built this computer earlier in the year, I ran some Avisynth+ 32 bit and 64 bit comparisons. 64 bit Avisynth+ can potentially run quite a bit faster if you have lots of RAM (at least for encoding). All the commonly used plugins come in 64 bit flavors now, so you shouldn't have to sacrifice anything there to switch.
Enabling muti-threading didn't seem to speed things up when running FrostyBorders in ffdshow (if anything it was the opposite), but it certainly can for encoding. I dread the times I need to hard-code subtitles now, as the subtitle filter is at the end of the chain and it's single threaded so it slows encoding down to Avisynth 2.6 speeds.

I'm pretty sure the Avisynth+ installer offers to install both 32 bit and 64 bit versions (assuming you're running 64 bit Windows). Theoretically that should allow to keep using your current setup while you hunt down 64 bit versions of your plugins. The 32 bit version looks for plugins and scripts in the original Avisynth plugins folder and (from memory) also in plugins32 and plugins32+ folders. The 64 bit version looks for them in the plugins64 and plugins64+ folders. That's handy because it makes it easy to keep functions and plugins in separate folders.

This is why I reverted to Avisynth+ 3.7.2. I still haven't replaced GradFun3 from DitherTools with something else.
https://forum.doom9.org/showthread.php?t=185021

[hello_hello]

There's a link for a new version dated 2023-10-02 in the opening post.

Hopefully I've stomped on the gremlins that made their way into into the last update.

[thebib62]

Thank you for attempting to fix the issue that I was experiencing but now I'm experiencing another error.
"CR_IsEqual (Height from width resizing eval, line 9) (Frostyboarders 2023-10-02.avsi, line 215 (ffdshow_filter_avisynth_script, line 2)

I'm on AVIsynth 2.6 and using the portable version of potplayer. I am trying to use the example you provided in the help file

FrostyBorders(1280,720, CropDAR=1.5, TCRatio=0.3)

Although I am curious, what benefits or differences come with using the above string of text versus the previous way of cropping with Frosty borders?
For example,

960,540, 10,0,-20,-30

[hello_hello]

Thank you for attempting to fix the issue that I was experiencing but now I'm experiencing another error.
"CR_IsEqual (Height from width resizing eval, line 9) (Frostyboarders 2023-10-02.avsi, line 215 (ffdshow_filter_avisynth_script, line 2)

I'm on AVIsynth 2.6 and using the portable version of potplayer. I am trying to use the example you provided in the help file

FrostyBorders(1280,720, CropDAR=1.5, TCRatio=0.3)

Damn! If you're interested to know why....

There's now a small helper function used in places called FB_IsEqual(). It's to account for inaccuracies in floating point math (floating point math is often only accurate to 4 or 5 decimal places). The function checks whether a resulting calculation, when rounded to an integer, is less than 0.00005 from the calculated value, and if so, the rounded value is assumed to be correct. It's to stop the script doing something unexpected or unnecessary when, for example, the width calculation is 699.9999949564738 when it should be exactly 700, so instead of applying more cropping to make the width 696 (assuming mod4 dimensions), the result is assumed to be exactly 700.

There's a version of the function included with CropResize called CR_IsEqual. When I changed some of the resizing stuff I copied the syntax from CropResize. Obviously I forgot to change the name of the function and didn't realize because CropResize was always loaded, so the FrostyBorders script was able to use the CropResize function instead.

I'll upload a fixed version very shortly.

Although I am curious, what benefits or differences come with using the above string of text versus the previous way of cropping with Frosty borders?
For example, 960,540, 10,0,-20,-30

They're different things. The cropping applied using FrostyBorders(960,540, 10,0,-20,-30) is effectively the minimum cropping.
When you use something like:
FrostyBorders(960,540, 10,0,-20,-30, CropDAR=1.5, TCRatio=0.3)
the specified cropping is applied first, then CropDAR crops the remaining picture to an aspect ratio of 1.5, minimizing the size of any pillarbox borders. When TCRatio is less than 0.5, less of the height cropping is taken from the top than it is from the bottom. The default is TCRatio=0.5, which means the top/bottom cropping ratio is 50:50.

The syntax below, added to the ffdshow Avisynth filter, should now do the same job as the separate ffdshow function we were using previously (I think that was uploaded to the CropResize thread rather than here). I'd probably have to update the ffdshow function to use it with the new CropResize, but it shouldn't be necessary now.
Obviously you don't want every video cropped to an aspect ratio of 1.5 (or whatever aspect ratio you prefer) so the syntax is used to configure the CropDAR argument. Now I think about it, I think you preferred a range close to 16:9 where the FrostyBorders function was bypassed, so it could be modified to do the same thing as the example for VapourSynth.

clip = last

VideoDAR = float(width(clip)) / float(height(clip))
# if the source is anamorphic the correct display aspect ratio must be specified manually

CropDAR = (VideoDAR > 2.0) ? 2.0 : (VideoDAR < 1.5) ? 1.5 : 0

clip = (1.72 <= VideoDAR <= 1.88) ? clip : \
FrostyBorders(960,540, 10,0,-20,-30, InDAR=VideoDAR, CropDAR=CropDAR, TCRatio=0.3)

return clip

Using the above syntax, video with an aspect ratio between 1.72 and 1.88 would be passed through untouched, bypassing the FrostyBorders function. For all other aspect ratios, a cropping of 10,0,-20,-30 would be applied. For video with an aspect ratio between 2.0 and 1.5, CropDAR would not apply any extra cropping. For video with an aspect ratio greater than 2.0, CropDAR would crop the sides (evenly) for an aspect ratio of 2.0, adding top and bottom borders for 960x540. For video with an aspect ratio less than 1.5, CropDAR will crop the height to make it 1.5, reducing the size of the pillarbox borders. TCRatio controls the ratio of top and bottom cropping. Hopefully that makes sense. Edit: There's example screenshots below.

If you wanted to specify different cropping for video with an aspect ratio wider than 1.88 (as an example), than the cropping for video with an aspect ratio less than 1.5 you could do something like this, and in fact you could use it to configure pillarbox and letterbox borders differently.

clip = last

VideoDAR = float(width(clip)) / float(height(clip))
# if the source is anamorphic the correct display aspect ratio must be specified manually

CropDAR = (VideoDAR > 2.0) ? 2.0 : (VideoDAR < 1.5) ? 1.5 : 0

clip = (1.72 <= VideoDAR <= 1.88) ? clip : \
(VideoDAR > 1.88) ? \
FrostyBorders(960,540, 2,0,-2,-0, InDAR=VideoDAR, CropDAR=CropDAR, Clone=2, Texture=1) : \
FrostyBorders(960,540, InDAR=VideoDAR, CropDAR=CropDAR, TCRatio=0.3, Clone=1, Feather=16)

return clip

CropResize has had a CropDAR argument for a long time, but it's new to FrostyBorders. The TCRatio argument is new to both functions.
In case you haven't noticed though, the function for specifying border options when Frosty=true for CropResize has had a name change. It was called FCropResize() but I changed the name to FrostyB(). You can still use CropResize with the FrostyB function to achieve the same thing.

clip = last

VideoDAR = float(width(clip)) / float(height(clip))
# if the source is anamorphic the correct display aspect ratio must be specified manually

CropDAR = (VideoDAR > 2.0) ? 2.0 : (VideoDAR < 1.5) ? 1.5 : 0

clip = (1.72 <= VideoDAR <= 1.88) ? clip : \
(VideoDAR > 1.88) ? \
FrostyB(Clone=2, Texture=1).CropResize(960,540, 2,0,-2,-0, InDAR=VideoDAR, CropDAR=CropDAR, Frosty=true) : \
FrostyB(Clone=1, Feather=16).CropResize(960,540, InDAR=VideoDAR, CropDAR=CropDAR, TCRatio=0.3, Frosty=true)

return clip

Here's some examples for you using similar syntax (I just changed the border options compared to the above syntax)

clip = last

VideoDAR = float(width(clip)) / float(height(clip))
# if the source is anamorphic the correct display aspect ratio must be specified manually

CropDAR = (VideoDAR > 2.0) ? 2.0 : (VideoDAR < 1.5) ? 1.5 : 0

clip = (1.72 <= VideoDAR <= 1.88) ? clip : \
(VideoDAR > 1.88) ? \
FrostyBorders(960,540, 2,0,-2,-0, InDAR=VideoDAR, CropDAR=CropDAR) : \
FrostyBorders(960,540, InDAR=VideoDAR, CropDAR=CropDAR, TCRatio=0.3, Feather=16)

return clip

Assuming this (fake) 2.4:1 image was the source.


[Attachment 74201 - Click to enlarge]

The above syntax would crop it to 2:1 before adding borders for 16:9.


[Attachment 74202 - Click to enlarge]

Assuming this (fake) 4:3 image was the source.


[Attachment 74203 - Click to enlarge]

The above syntax would crop it to 1.5 before adding borders for 16:9.
TCRatio=0.3 means only 30% of the cropping comes from the top.


[Attachment 74204 - Click to enlarge]

Without TCRatio, or the default of TCRatio=0.5, the top and bottom cropping would be the same.
So TCRatio=0.3 effectively moves the picture down a bit when the height is cropped.
I find it's better to crop less from the top than the bottom, as for 4:3 video the important stuff is generally
located slightly above the middle of the frame (admittedly this fake 4:3 video isn't a good example of that).

TCRatio=0.5


[Attachment 74205 - Click to enlarge]

Of course you can change the syntax to adjust the way video is cropped and borders added to whatever you prefer.

You can also use the CropDAR argument to crop the picture to a particular aspect ratio without the function adding borders by specifying zero for either the width or the height.

FrostyBorders(0,540, 2,0,-2,-0, CropDAR=1.5, TCRatio=0.3)


[Attachment 74206 - Click to enlarge]

Edit: re-uploaded the screenshots in the correct order.

[hello_hello]

New version dated 2023-10-06 in the opening post. I've also changed the date of the Vapoursynth FrostyBorders to match the Avisynth version, but the VapourSynth version hasn't changed. It's the same as the version dated 2023-10-02.

[hello_hello]

thebib62,
if you're still around, you might want to try the syntax I added to the script I'm using to run the VapourSynth FrostyBorders in SMPlayer. It changes the resizing according to the input resolution, the idea being the function won't apply as much unnecessary resizing as it might when using a fixed output width and height. If you use a fixed output of 960x540, for example, higher resolutions would be downscaled by the function before being upscaled by the player again when running full screen. An Avisynth version of the syntax would be this (I haven't tested the Avisynth version but it should be okay):
Edit: I also fiddled with the CropDAR configuration a little.

clip = last

W = width(clip)
H = height(clip)

VideoDAR = float(W) / float(H)
# if the source is anamorphic the correct display aspect ratio must be specified manually

CropDAR = \
(VideoDAR > 2.0) ? 2.0 : \
(VideoDAR > (14.0 / 9.0)) ? 0 : \
(VideoDAR > 1.3) ? 14.0 / 9.0 : 7.0 / 5.0

(VideoDAR < (16.0 / 9.0)) ? Eval("""

NewH = (H > 900) ? 1080 : (H > 720) ? 900 : (H > 540) ? 720 : (H > 396) ? 540 : 396
NewW = round(float(NewH) * 16.0 / 9.0)

""") : Eval("""

NewW = (W > 1600) ? 1920 : (W > 1280) ? 1600 : (W > 960) ? 1280 : (W > 704) ? 960 : 704
NewH = round(float(NewW) / 16.0 * 9.0)

""")

clip = (1.7 <= VideoDAR <= 1.9) ? clip : \
FrostyBorders(clip, NewW,NewH, 2,0,-2,0, InDAR=VideoDAR, CropDAR=CropDAR, TCRatio=0.3)

return clip

VapourSynth version (script to use as an MPV video filter):

import vapoursynth as vs
core = vs.core
import FrostyBorders as fb

clip = video_in

W = clip.width
H = clip.height

VideoDAR = W / H
# if the source is anamorphic the correct display aspect ratio must be specified manually

CropDAR = \
2 if (VideoDAR > 2) else \
0 if (VideoDAR > (14 / 9)) else \
14 / 9 if (VideoDAR > 1.3) else 7 / 5

if (VideoDAR < (16 / 9)):

    NewH = \
    1080 if (H > 900) else \
    900 if (H > 720) else \
    720 if (H > 540) else \
    540 if (H > 396) else 396

    NewW = round(NewH * 16 / 9)

else:

    NewW = \
    1920 if (W > 1600) else \
    1600 if (W > 1280) else \
    1280 if (W > 960) else \
    960 if (W > 704) else 704

    NewH = round(NewW / 16 * 9)

clip = clip if (1.7 <= VideoDAR <= 1.9) else \
fb.FrostyBorders(clip, NewW,NewH, 2,2,0,0, InDAR=VideoDAR, CropDAR=CropDAR, TCRatio=0.3)

clip.set_output()

[thebib62]

Thank you for those visual examples. Definitely helps me better understand the new features of FrostyBoarders.

clip = last

W = width(clip)
H = height(clip)

VideoDAR = float(W) / float(H)
# if the source is anamorphic the correct display aspect ratio must be specified manually

CropDAR = \
(VideoDAR > 2.0) ? 2.0 : \
(VideoDAR > (14.0 / 9.0)) ? 0 : \
(VideoDAR > 1.3) ? 14.0 / 9.0 : 7.0 / 5.0

(VideoDAR < (16.0 / 9.0)) ? Eval("""

NewH = (H > 900) ? 1080 : (H > 720) ? 900 : (H > 540) ? 720 : (H > 396) ? 540 : 396
NewW = round(float(NewH) * 16.0 / 9.0)

""") : Eval("""

NewW = (W > 1600) ? 1920 : (W > 1280) ? 1600 : (W > 960) ? 1280 : (W > 704) ? 960 : 704
NewH = round(float(NewW) / 16.0 * 9.0)

""")

clip = (1.7 <= VideoDAR <= 1.9) ? clip : \
FrostyBorders(clip, NewW,NewH, 2,0,-2,0, InDAR=VideoDAR, CropDAR=CropDAR, TCRatio=0.3)

return clip

This script looks really promising! I wanted to know if you could change 2 things.
The first being the resolution. I use a low end mini pc and would like the resolution changed from 960x540 to 512x288.
Second, would be to have less cropping. TCRatio=0.3 crops a little too much, IMO. I would prefer larger boarders. Something similar to, 10,0,-20,-30

[hello_hello]

If CropDAR is causing the script to apply extra cropping, changing it's value to whatever you prefer should fix it. TCRatio doesn't change the amount of cropping in any way, it only changes the ratio of top and bottom cropping when CropDAR is causing the height to be cropped. Just remember that CropDAR crops the remaining picture after any manual cropping is applied, so only enough cropping to remove any black around the edges should be needed, and CropDAR and TCRatio will then take care of the rest.

The percentage of picture a manual cropping of 10,0,-20,-30 would crop depends on the source resolution. If the source was 1440x1080 it'd crop very little compared to the percentage of picture it'd crop if the source was only 640x480. On the other hand, the CropDAR argument crops the same percentage of picture regardless of resolution, assuming of course the aspect ratios are the same. For example, if you used CropDAR=1.4 on a 1440x1080 source and a 640x480 source, the output would have a DAR of 1.4 each time, so if the pictures were identical before cropping, aside from the resolution, they'd be identical after cropping, aside from the resolution.

For a picture with a 4:3 aspect ratio (after any manual cropping), CropDAR=4.0/3.0 shouldn't cause any extra picture to be cropped. CropDAR=1.4 would cause the height to be cropped a little, effectively zooming in a bit and reducing the size of the pillarbox borders. CropDAR=1.6 would crop more height and zoom in more, making the pillarbox borders smaller, and CropDAR=16.0/9.0 would crop the height to make the picture 16:9 and there'd be no borders at all (on a 16:9 display). TCRatio controls the ratio of top and bottom cropping when the height is cropped, but it doesn't change the total amount, so use whatever TCRatio you prefer. I find TCRatio=0.3 generally works well.

If you use this syntax:

clip = last

W = width(clip)
H = height(clip)

VideoDAR = float(W) / float(H)
# if the source is anamorphic the correct display aspect ratio must be specified manually

CropDAR = \
(VideoDAR > 2.0) ? 2.0 : \
(VideoDAR > 1.4) ? 0 : \
(VideoDAR > (4.0/3.0)) ? 1.4 : 4.0/3.0

clip = (1.75 <= VideoDAR <= 1.8) ? clip : \
FrostyBorders(clip, 512,288, 2,0,-2,0, InDAR=VideoDAR, CropDAR=CropDAR, TCRatio=0.3)

return clip

- Video with a DAR between 1.75 and 1.8 will be passed through untouched.
- The FrostyBorders output will always be 512 x 288.
- Two pixels will always be cropped from the left and right. I leave it that way as there's often a couple of pixels of crud each side, but change it to whatever is required to remove any black.
- CropDAR will crop a picture wider than 2:1 (after any manual cropping is applied) to 2:1.
- For aspect ratios between 2:1 and 1.4:1 there's no extra cropping applied by CropDAR.
- A source with a DAR between 1.4 and 4:3 will be cropped to 1.4, just zooming in a little, and a source with an aspect ratio less than 4:3 will be cropped to 4:3, zooming in a bit, but change the values to whatever you prefer, including TCRatio.

Or for just two fixed CropDARs you could change it to:

CropDAR = \
(VideoDAR > 2.0) ? 2.0 : \
(VideoDAR > (4.0/3.0)) ? 0 : \
4.0/3.0

So video between 2:1 and 4:3 will have no extra cropping applied, and only video with an aspect ratio less than 4:3 will be cropped to make it 4:3.

Hopefully all that helps, but you can change the values to whatever you prefer.

[hello_hello]

thebib62,
because I have very little anamorphic video or video with borders that need to be cropped, I didn't really worry about that side of it much, but you got me thinking about it so here's some improved syntax. The differences are:

- For an anamorphic source, a sample aspect ratio needs to be specified instead of a DAR.
- Cropping is specified in the middle of the script.
- The aspect ratio calculation includes any specified cropping. Therefore the CropDAR argument is configured taking any specified cropping into account.
- An anamorphic source will always be resized to square pixel dimensions, even if there's no borders added.

clip = last

W = width(clip)
H = height(clip)

# If the source is anamorphic the correct pixel/sample aspect ratio must
# be specified instead of 1.0. For example, 64.0/45.0 for a PAL 16:9 DVD.
# The SAR must be float (not integer).

SAR = 1.0

# Cropping
# CR and CB must be negative (or zero)

CL = 2
CT = 0
CR = -2
CB = 0

VideoDAR = float(W - CL + CR) / float(H - CT + CB) * SAR

CropDAR = \
(VideoDAR > 2.0) ? 2.0 : (VideoDAR > 1.4) ? 0 : (VideoDAR > (4.0 / 3.0)) ? 1.4 : 4.0 / 3.0

return (1.75 <= VideoDAR <= 1.8) && (SAR == 1.0) ? clip : \
(1.75 <= VideoDAR <= 1.8) ? \
FrostyBorders(0,288, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=0.3) : \
FrostyBorders(512,288, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=0.3)

[thebib62]

thebib62,
because I have very little anamorphic video or video with borders that need to be cropped, I didn't really worry about that side of it much, but you got me thinking about it so here's some improved syntax. The differences are:

- For an anamorphic source, a sample aspect ratio needs to be specified instead of a DAR.
- Cropping is specified in the middle of the script.
- The aspect ratio calculation includes any specified cropping. Therefore the CropDAR argument is configured taking any specified cropping into account.
- An anamorphic source will always be resized to square pixel dimensions, even if there's no borders added.

clip = last

W = width(clip)
H = height(clip)

# If the source is anamorphic the correct pixel/sample aspect ratio must
# be specified instead of 1.0. For example, 64.0/45.0 for a PAL 16:9 DVD.
# The SAR must be float (not integer).

SAR = 1.0

# Cropping
# CR and CB must be negative (or zero)

CL = 2
CT = 0
CR = -2
CB = 0

VideoDAR = float(W - CL + CR) / float(H - CT + CB) * SAR

CropDAR = \
(VideoDAR > 2.0) ? 2.0 : (VideoDAR > 1.4) ? 0 : (VideoDAR > (4.0 / 3.0)) ? 1.4 : 4.0 / 3.0

return (1.75 <= VideoDAR <= 1.8) && (SAR == 1.0) ? clip : \
(1.75 <= VideoDAR <= 1.8) ? \
FrostyBorders(0,288, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=0.3) : \
FrostyBorders(512,288, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=0.3)

Thank you for that script/syntax. It works well, but I am curious as to why nothing happens when I change the TCRatio=0.3 value? Is it because there is a cropping value being applied using "CB = " and that overrides TCRatio?

[hello_hello]

It could be. Using the above syntax CropDAR would crop a picture with a DAR less than 4:3 to 4:3, but the source DAR now takes the cropping into account, so if your specified cropping results in the picture being cropped to 4:3, CropDAR=4.0/3.0 won't crop anything, so TCRatio can't adjust the cropping ratio.

Here's an example. I've resized the video to 720x576 while cropping the picture to an aspect ratio of 1.1 and adding borders to the sides for an output DAR of 16:9 and a SAR of 64:45. As you can see there's 138 pixels of black each side. It's the source for the example below. This is one of those instances where cropping the black makes a huge difference to the DAR and why I suggested the new syntax, because the VideoDAR calculation takes the specified cropping into account.

CropResize(720,576, CropDAR=1.1, InDAR=16.0/9.0, OutDAR=16.0/9.0, Info=true)


[Attachment 74402 - Click to enlarge]

Applying the syntax using a SAR of 64:45 and 138 pixels of cropping each side (I also increased the resizing to 704x396 to make the text easier to read). I'm using CropResize at the end instead of FrostyBorders.

clip = last

W = width(clip)
H = height(clip)

# If the source is anamorphic the correct pixel/sample aspect ratio must
# be specified instead of 1.0. For example, 64.0/45.0 for a PAL 16:9 DVD.
# The SAR must be float (not integer).

SAR = 64.0/45.0

# Cropping
# CR and CB must be negative (or zero)

CL = 138
CT = 0
CR = -138
CB = 0

VideoDAR = float(W - CL + CR) / float(H - CT + CB) * SAR
# 444 / 576 * 64 / 45 = 1.096,
# as close to CropDAR=1.1 as the mod4 resizing of the original video allowed

CropDAR = \
(VideoDAR > 2.0) ? 2.0 : (VideoDAR > 1.4) ? 0 : (VideoDAR > (4.0 / 3.0)) ? 1.4 : 4.0 / 3.0

return (1.75 <= VideoDAR <= 1.8) && (SAR == 1.0) ? clip : \
(1.75 <= VideoDAR <= 1.8) ? \
FrostyBorders(0,396, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=0.3) : \
CropResize(704,396, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=0.3, Frosty=true, Info=true)

The "additional script cropping" shows 30.72 pixels cropped from the top and 71.68 from the bottom (using a TCRatio of 0.3) because a total of 102.4 pixels of height has to be cropped to crop the 1.1 image to 4:3.


[Attachment 74403 - Click to enlarge]

If TCRatio was the default of 0.5:
CropResize(704,396, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=0.5, Frosty=true, Info=true)


[Attachment 74405 - Click to enlarge]

So yes, if the specified cropping also included 102 pixels of bottom cropping, or even a total height cropping of 102 pixels split between top and bottom, there's no substantial top and bottom "additional script cropping" for TCRatio to work with.

CL = 138
CT = 0
CR = -138
CB = -102


[Attachment 74407 - Click to enlarge]

FrostyBorders was intended as a more "set and forget" function so Info=true isn't as informative, but it should show the same total cropping and borders for an identical source.

CL = 138
CT = 0
CR = -138
CB = 0

FrostyBorders(704,396, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=0.3, Info=true)
(this should be the same as the first CropResize example with frosty borders above)


[Attachment 74410 - Click to enlarge]

[hello_hello]

New version of FrostyBorders dated 2023-10-28 in the opening post.

The Avisynth version hasn't changed.

Fixed some mistakes in the syntax of the VapourSynth version and added a "FrostyResizeWrappers.py" script containing two resizer wrapper functions. The wrapper functions are examples of how to use a non-native VapourSynth resizer. The FrostyResizeWrappers.py script is not required.