CropResize Script

[hello_hello]

Just include the text of the new function in your script and call it when needed.

I wish I'd thought of that.

I'll have another go at getting it to work later.
This is my first function, so nothing works the first 317 ways I expect it to.

Newer version to fix an error.

[hello_hello]

I made a change to the way the height is resized to achieve a particular mod. It really only makes a difference when specifying larger mods such as mod16 or mod 8.

The upshot of it is, when the specified Output DAR (or the Output DAR after cropping) is less than 16:9, and a large adjustment to the height is needed to achieve a mod (ie more than 4 pixels for mod16) the height will be adjusted down, resulting in a little extra picture being cropped top and bottom if necessary. As a result the Output DAR becomes wider.

ie When specifying a width of 720 and a height of mod16, the exact dimensions would be 720x540, but for mod16 is must be either 720x528 or 720x544.
Anything from 720x529 to 720x539 would be resized down to 720x528, cropping extra picture top and bottom as required and making the Output DAR a little wider.
Anything from 720x540 to 720x543 would be resized up to 720x544, cropping a little picture from the sides to compensate and making the Output DAR a little narrower.
Therefore, when randomly copping and resizing, it'd be more likely the height would be decreased to achieve mod16, a little extra picture cropped from the top and bottom, and the Output DAR would become a little wider as a result.

When the Output DAR is 16:9 or wider it works the opposite way. Randomly copping and resizing is more likely to result in the height being increased to achieve mod16, making the Output DAR a little narrower as a result.

AutoGK (and previously CropResize) always used the first method, which was fine when watching widescreen video on a 4:3 screen. If any more than a small amount of extra picture needed to be cropped for mod16, cropping it from the sides rather than the top and bottom made sense. These days though, we all have 16:9 TVs so the method now used by the CropResize script changes according to the Output DAR.

[hello_hello]

I fiddled a bit and ended up with a new version and an additional function CropResize8().

Everything works as before, only there's two additional options.
CLR, CTB (defaults, 0)
Cropping amounts in addition to the autocropping for left and right (CLR) or top and bottom (CTB). It's just an easier way to crop the same additional amount from left and right, or top and bottom, without having to specify them individually. Combined with the existing left, top, right and bottom cropping options, the cropping applied is now the following:

Left cropping = Autocropping + CL + CLR
Top cropping = Autocropping + CT + CTB
Right cropping = Autocropping + CR + CLR
Bottom cropping = Autocropping + CB + CTB

CropResize8()
It works in exactly the same way as CropResize(), but instead of always resizing with Avisynth's Spline36Resize, it resizes using the Resize8 script. It has two additional options:

Resizer (defaults, "Lanczos4" for luma upscaling, "Spline36" for luma downscaling, the same as the defaults for Resize8)
Specifies any resizer supported by the Resize8 script for luma scaling. ie Resizer="Spline36" or Resizer="Bilinear" etc (it corresponds to the "kernel" option for the Resize8 script).
ResizerC (defaults, "Lanczos" for chroma upscaling, "Spline36" for chroma downscaling, the same as the defaults for Resize8)
Specifies any resizer supported by the Resize8 script for chroma scaling. ie ResizerC="Spline36" or ResizerC="Bilinear" etc (it corresponds to the "kernel_c" option for the Resize8 script).
If "Resizer" is specified, but "ResizerC" is not, the scaling specified with the "Resizer" option is also applied to "ResizerC" (unlike the Resize8 script where specifying a luma resizer has no effect on the resizer used for chroma scaling).

CropResize8() requires the Resize8 script which in turn requires RGTools. RGTools also requires the Microsoft Visual C++ 2015 Redistributable.

[hello_hello]

IsFloat(2) = true # ints are considered to be floats by this function

That is strange, man. I think I found a workaround though:

function IsReallyFloat(val v)
{
    s = ""
    try { 
        s = Hex(v) [* fails on float arguments! *]
    }
    catch(err_msg) { 
        s = "true"
    }
    return (IsFloat(v)) 
    \ ? (s=="true") [* s<>"true" if Hex succeeds *]
    \ : false       [* eliminate clips, strings, booleans  *]
}

If someone could show me how to add this to the script I'd be grateful. I'm probably missing the obvious but I've tried to get it to work in combination with Assert() without any luck. Either Assert always produces it's error message or it doesn't, regardless of whether in the value is float or not. I'm probably missing something very obvious but I'd like to understand how to get it to work, even if it's just for future reference.

[hello_hello]

Damn! I fixed the way the height is adjusted for a specified mod (changes 2017-03-01). I cleverly had it working the wrong way around.

[jagabo]

If someone could show me how to add this to the script I'd be grateful.

function IsReallyFloat(val v)
{
    s = ""
    try { 
        s = Hex(v) [* fails on float arguments! *]
    }
    catch(err_msg) { 
        s = "true"
    }
    return (IsFloat(v)) 
    \ ? (s=="true") [* s<>"true" if Hex succeeds *]
    \ : false       [* eliminate clips, strings, booleans  *]
}

function ShowValType(clip video, val number)
{
#    Assert(IsReallyFloat(number), "ERROR: 'number' must be floating point!")
    IsReallyFloat(number) ? Subtitle(video, "number is float: "+string(number)) :  Subtitle(video, "number is not float: "+string(number))
}

ColorBars()
ShowValType(4/3)

With this script the colorbars will be subtitled with "number is not float: 1" because values in "4/3" are all integers. If you declare "number" as float instead of val, "4/3" will still be handled as integers but the result, 1, will be passed as floating point, 1.000000.

I'm probably missing the obvious but I've tried to get it to work in combination with Assert() without any luck. Either Assert always produces it's error message or it doesn't, regardless of whether in the value is float or not. I'm probably missing something very obvious but I'd like to understand how to get it to work, even if it's just for future reference.

If you enable the Assert() line in the above script it will terminate with the indicated error message. If you change "4/3" to 4.0/3) you will get colorbars with the subtitle "number is float: 1.333333".

[hello_hello]

Thank you! Once I had a working example it only took about 73 tries before the penny dropped, but now I know why it wasn't working, I hopefully won't have the same problem next time. It's a learning experience. The show stopper, and it hadn't occurred to me until I looked at your example, was this:

function CropResize(clip c, int "OutWidth", float "OutDAR", int "Hmod", float "InDAR", int "CL", int "CT", int "CR", int "CB", int "CLR", int "CTB", int "Cthresh", int "Cstart", int "Csample")

I still don't fully understand why (I'll have to go back and read the manual again) but unless I change "float" to "val' it appears it'll never work, so the 37 hours I spent trying to make what seemed to be a fairly simple function work......

I was trying all sorts of weird and wonderful things, and the only thing I was right about was it was something simple.... I just couldn't find it.

I'll upload a new version with the working error message later, but in the meantime if you have a chance to think about it.....
I think the last thing I'd like to do is force the Hmod value to be either 2, 4, 8 or 16. Just for political correctness, but I'm not fluent enough in Avisynth-speak yet to make it work. Currently the height mod can be any even number and it'll work fine. Odd numbers will be rounded to even numbers, or produce an error regarding the height needing to be mod2, depending on how it's adjusted, but it'd be nice to enforce only the use of "legal mods". Any suggestions?

Thanks.

[jagabo]

restrict mod values:

function CheckMod(int mod)
{
    Assert((mod==2)||(mod==4)||(mod==8)||(mod==16), "ERROR: mod must be 2, 4, 8, or 16.")
}

ColorBars()
mod = 8
CheckMod(mod)
Subtitle("mod is "+string(mod))

You might want to add 32 to the list too.

You can use it inline rather than calling a function:

ColorBars()
mod = 8
Assert((mod==2)||(mod==4)||(mod==8)||(mod==16), "ERROR: mod must be 2, 4, 8, or 16.")
Subtitle("mod is "+string(mod))

[hello_hello]

Odd, because I thought I started with that and it didn't work as expected. Chances are I just did something dumb though. It's working now.

Thanks.

[jagabo]

Maybe you used = instead of == or | instead of ||.

[hello_hello]

Probably.

Cheers.

[jagabo]

Note:

= sets the value of the variable on the left equal to the value on the right, A=5 gives A the value 5

== tests for equality, ie, is the value on the left equal to the value on the right, A==5 asks: is A equal to 5?

| is a bitwise OR of the value on the left with the value on the right, A|5 the 4 and 1 bits of A are set

|| is a logical OR of the value on the left with the value on the right, A||B means: if (A is true) or if (B is true) then...

& is a bitwise AND of the value on the left with the value on the right, A&5 if the 4 and/or 1 bits of A are set they remain set, otherwise they are changed to zero, and all other bits are set to zero.

&& is a logical and of the value in the left and the value on the right, A&&B means: if (A is true) and if (B is true) then...

https://en.wikipedia.org/wiki/Bitwise_operation

[hello_hello]

Thanks for the info jagabo. It's a learning curve but I'm getting there, slowly.

I changed the way CropResize can be used to specify an Output Display Aspect Ratio (with version 2017-03-06). The OutDAR and Hmod settings still work as before, unless an Output Height is specified with the new OutHeight option. If OutHeight is specified it takes precedence and OutDAR and Hmod will have no effect.

As a result, CropResize can now be used much like the standard Avisynth resizers, but instead of the resizing being able to result in an aspect error if the image is resized "incorrectly", CropResize will resize and automatically crop to prevent any aspect error.

The order of the various settings has changed to allow CropResize to be used much like the standard Avisynth resizers. See the opening post for full details and examples.

[hello_hello]

"CropResize 2017-03-09" adds a preview function for the cropping. It's simply the cropping preview displayed by autocrop.dll with resizing disabled, as it doesn't seem to make sense to show a cropping preview if the video is being resized as though it was actually being cropped.

A 4:3 PAL DVD, cropped and resized with the following:

CropResize(640,480, InDAR=15.0/11.0, Cthresh=110)



Here's what you see with the "CPreview=1" setting. Note that it's no longer being resized.

CropResize(640,480, InDAR=15.0/11.0, Cthresh=110, CPreview=1)




Edit: Doh! I spelled CPreview wrong in the script. Fixed.