CropResize - Cropping & resizing function (Avisynth & VapourSynth versions)

[hello_hello]

bruno321,
Thinking about it, another reason for not fussing over a couple of pixels resizing for the width, is the way CropResize works in full resizing mode, it can sometimes crop in a non-intuative way, which is why ResizeWO mode exists.

It's been a while since I've played with the guts of this part of the script, so I'd have to look through it to give myself a refresher course but...
Even after setting everything to mod2 I only had to adjust the cropping you mentioned previously by a couple of pixels to show you an example.

Crop(10, 2, -8, -2)
iCropResize(UpSizeMe(Mod=2), Mod=2, InSAR=8.0/9.0)

The input width is 702, but as you can see from the screenshot, even though the output width is 702, the script cropped just a little from the width and resized it back up again.



The alternative would be to manually reduce the output height so the script has to crop the picture height instead of the width, but even though it's a very small difference here due to the mod2 dimensions, there's now more cropped from the height than there was from the width, because left to it's own devices, the script chose the path of "least extra picture cropping".

Crop(10, 2, -8, -2)
iCropResize(UpSizeMe(Mod=2),534, InSAR=8.0/9.0)



So.... you might be resizing the width a bit anyway....

Maybe I could add some extra checking so if the specified OutWidth is the same as the cropped width and there's no OutHeight specified, the script will choose a height that won't require the width to be cropped any further. I think there was a reason I had start to from scratch to get ResizeWO mode to work rather than use the same resizing as for normal resizing mode though, but I'll give it some thought.

[hello_hello]

bruno321,

I'd almost finished typing this post and I thought the new CropResize, with some changes for you, was ready to go, but I discovered a resizing problem during the final testing. I'll come back to it tomorrow when my brain's fresh, because the cause is alluding me right now, but rather than have to start this post from scratch again then....

I've added the ability to resize NTSC 4:3 DVDs "up", and as a side effect, also to automatically resize other DVD types "down". There's info in the new changelog explaining how it works, but for the new CropResize, there's a special value of -1 for OutWidth and OutHeight.

When OutWidth=-1 and OutHeight=0, the script automatically takes care of the resizing as before when both were zero, however OutWidth=-1 forces CropResize to use the width of the cropped video as the OutWidth, and it won't be cropped any further to prevent aspect error, and therefore won't be resized
The magic value of -1 can also be used for OutHeight, although not at the same time. It forces CropResize to use the height of the source after cropping for the output, once again without cropping or resizing it further.
There's limitations to when specifying -1 can make a difference. Those details are in the new changelog (or will be).

Here's the results from an earlier test, before I broke something in the script, to show you what -1 does.

16:9 PAL initially cropped to 700x572		Output dimensions & extra cropping

Crop(10, 2, -10, -2)
CropResize(0, 0, InSAR=64.0/65.0)		996x572  (0.00, 0.13, 0.00, -0.13)
CropResize(0, -1, InSAR=64.0/65.0)		992x572  (1.25, 0.00, -1.25, 0.00)
CropResize(-1, 0, InSAR=64.0/65.0)		700x400  (0.00, 0.96, 0.00, -0.96)

4:3 NTSC initially cropped to 700x476		Output dimensions & extra cropping

Crop(10, 2, -10, -2)
CropResize(0, 0, InSAR=8.0/9.0)			624x476  (0.00, 0.68, 0.00, -0.68)
CropResize(0, -1, InSAR=8.0/9.0)		620x476  (1.25, 0.00, -1.25, 0.00)
CropResize(-1, 0, InSAR=8.0/9.0)		700x532  (0.00, 1.56, 0.00, -1.56)

So.... OutWidth=-1 will make the UpSizeMe function obsolete. Once I find the bug (hopefully tomorrow), you'll be able to crop and resize your 4:3 NTSC DVDs the following way. Mod4 is still the default so if you want mod2 you have to tell CropResize about it.

Crop(10,4,-6,-6)
CropResize(-1, Mod=2, InSAR=8.0/9.0)

[bruno321]

Thanks, hello_hello. But FWIW I have no problem with using CropResize for, e.g, mpeg4 "4:3" NTSC DVDs as CropResize(UpsizeMe(),Mod=2,InSAR=10.0/11.0). I have that in a macro in avspmod so I don't have to think about it.

[hello_hello]

I had a new version on the way anyway, mainly to fix a couple of very minor bugs (nothing effecting the cropping/resizing calculations) and to make some changes to the included "frosty borders" function, and I figured the new options could also be used to prevent the width/height resizing I mentioned a few posts back, so while I was at it....

I've just been lazy about looking for the silly I did in the process. Soon...

Cheers.

[hello_hello]

There's a new version of CropResize in the opening post dated 2021-01-31. Compared to the previous version there's just a few minor improvements and bug fixes, along with the addition of an ability to specify negative values for OutWidth and OutHeight, to prevent resizing of the width or height when possible. Details in the help file.
There's also new wrapper functions labelled "CRCrop Functions". Usage details can be found at the top of that script.

There's still a link for CropResize 2020-06-23 in the opening post. It's now labelled version 2 as it contains all the changes applied to the function up to 2021-01-31, with the exception of the old color conversion methods. I thought I'd update the old version to keep it alive for anyone who might still be using it.

[hello_hello]

Sorry folks, but I discovered a mistake that was causing an error when the Frosty argument was enabled. I fixed it and updated the version numbers in the opening post to 2021-02-01 for the current CropResize and 2020-06-23 v3 for the older version.

[hello_hello]

I'm surprised nobody has mentioned it, but I just realised that for a while at least, I haven't been including the full wrapper functions script in the zip file, so even though the second post in this thread advertises the use of CR() rather than having to type CropResize(), with the wrong wrapper functions script the abbreviated function names couldn't have worked.

I haven't changed the version dates, but for anyone who's downloaded CropResize 2021-02-01 or 2020-06-23 v3 from the opening post prior to my submitting this one (those versions were only uploaded about 8 hours ago), if you download the zip file again you'll find the full wrapper functions script is now included, and the help file has been updated under the "Wrapper Functions" sections near the end. The CropResize function itself is exactly the same.

Sorry about that.

[hello_hello]

I've updated the link for CropResize in the opening post. The new version is dated 2021-10-15.

There's a few improvements, amongst them the ability to specify float values for cropping. I hadn't seen the need for it until now, as the script does it's own sub-pixel cropping to prevent aspect error, but after playing around a bit with Avisynth's Animate function (due to a discussion on panning and scanning recently) it seemed like a good idea.

The CropResize cropping previews animate nicely, and if nothing else it makes simulating the "Ken Burns Effect" less of a chore, as there's no need to worry about distorting the picture. Here's a couple of quick samples, if anyone's interested.

CropResize(1280,720)

v = Last.Trim(18900,18900).Loop(190)
Animate(v, 10, 179, "pCropResize", 
\    960,720, 0.0, 40.0, -400.0, -40.0,
\  960,720, 745.0, 120.0, -250.0, -310.0)

Animated Cropping Preview.mkv (996 kB)
Animate - The Ken Burns Effect.mkv (2.9 MB)

[hello_hello]

Fixed an unnecessary error message when using the Blend or TSoft arguments with FCropResize (adding frosty borders).

There's a link for CropResize 2021-10-20 in the opening post.

[hello_hello]

Fixed another unnecessary error message when using Clone=3 with FCropResize (adding frosty borders) and the ResampleMT plugin wasn't loaded.
Made Clone=3 play nice with YV411.

There's a link for CropResize 2021-10-22 in the opening post.

[hello_hello]

I've updated both versions of CropResize in the opening post. There's no functional change aside from fixing an error the script produced when Borders=true and the border dimensions weren't identical.

New versions CropResize 2022-01-28 and CropResize 2020-06-23 v7

Hopefully the next update will eliminate the need for two versions as I intend to add the old color conversion methods back so there's only one script to update.

[Danette]

I’m trying to decide whether or not to abandon dithertools and colormatrix, assuming that these aren’t dependencies for something unforeseen. I’m willing to try to do so, if CropResize 2022-01-28 is truly superior to 2020-06-23 v7 ...or is it better to wait for your newer version designed to eliminate the two separate versions? Do you believe that the 2022 version is worth the effort?

Also, are you still adding GradFun3 to the end of your scripts? I’ve been finding others that seem to prefer GradFun2b and/or flash3kyuu_deband to GradFun3, especially given their inclusions of these in their “Universal” plugins offerings, which don’t include GradFun3. What is your opinion on this?

[hello_hello]

CropResize 2022-01-28 and CropResize 2020-06-23 v7 should be exactly the same, with the exception of the color conversion plugins they support.
I'm only just getting back to working on the new version. The real world got in the way and I haven't been on the computer much during the last few months.

The new version won't be much different to the current ones in respect to functionality. There's a couple of obscure bug fixes (obscure because they don't involve typical usage), but the main change is native support for the FMTConv plugin for resizing and color conversion, and breaking backwards compatibility with previous versions in respect to color conversion.

After adding FMTConv and combining the color conversion methods from the two scripts, specifying a plugin with an number, ie ColorCorrect=2 was starting to become confusing (at least for me), so the argument name has changed and it's also a string. It'll be ColorConvert="ColorMatrix" etc instead.

I can't say I've come across any "universal" plugins, but yes I still use GradFun3 because it still does what it's supposed to do, or sometimes I use f3kdb/flash3kyuu_deband instead to also add grain for stronger banding prevention. There's also a neo version with HBD support.
Edit: Just be aware that by default f3kdb/Neo_f3kdb adds grain too (much like following GradFun3 with AddGrainC would do) so if you don't want grain added you need to disable it with Neo_f3kdb(grainY=0, grainC=0).

I can't comment on GradFun2db as I really only have it in the plugins folder for a function or two that requires it. There's also scripts such as GradFun2DBmod and F3KDB_3, but I don't know much about them either.

Edit: CropResize always outputs the source bitdepth, so if you convert an 8 bit source to a higher bitdepth before resizing, ie
ConvertBits(16)
CropResize(1280,720)
And follow it with something like Neo_f3kdb that supports HBD and can deband and dither to 8 bit, it means you'll be resizing in 16 bit and still outputting 8 bit instead of resizing in 8 bit and then debanding. I assume Neo_f3kdb converts an 8 bit source to 16 bit for debanding, only in native Avisynth+ 16 bit rather than the stacked 16 bit format DitherTools uses. You can't do a similar thing with GradFun3 as CropResize doesn't support resizing a stacked 16 bit input.
If you're color converting too, you'll have to use the 2022-01-28 version of the script as it uses color conversion plugins supporting native Avisynth+ 16 bit.

[hello_hello]

There's a new version of CropResize dated 2022-09-22 in the opening post.

The main change is to the way a plugin is specified for color correction to hopefully make it easier to use (only standard dynamic range color conversions). There's details of the changes in the zip file, but the highlights are:

------------------------------------------------

A new "ColorConvert" argument has replaced "ColorCorrect" and it's a string.
Color conversion now supports the AVSResize, ColorMatrix, DitherTools, FMTConv, HDRMatrix and HDRTools plugins.

CropResize(1280,720, ColorConvert="FMTConv", ColorMode="601-709")

The default conversions between HD and SD colorimetry are all matrix-only, except for HDRTools. Specifying "NTSC" or "PAL" primaries for SD forces the color primaries to be converted too. Conversions to/from rec.2020 always convert the color primaries.

CropResize(1280,720, ColorConvert="AVSResize", ColorMode="601N-709")

------------------------------------------------

FMTConv added as a "native" resizer, selected by preceding the resize kernel with "F_".

CropResize(1280,720, Resizer="F_Spline36")

------------------------------------------------

CropResize now includes ringing repair (taken from the Resize8 script). Unlike Resize8 though, it's disabled by default (partly because I use Resize8 quite a lot and there's no need to enable ringing repair twice).

CropResize(1280,720, RingRepair=true)

or to specify a fixed strength for ringing repair rather than the script calculating it based on the degree of resizing (range zero to one).

CropResize(1280,720, RingRepair=0.75)

------------------------------------------------

New wrapper functions added to the "Resizer Functions" script for linear light resizing.
CR_AVSResizeLinear(), CR_DitherToolsLinear() and CR_FMTConvLinear().

CropResize(960,540, Resizer="CR_DitherToolsLinear")

------------------------------------------------

Plus a couple of obscure bug fixes and some other minor changes.

[hello_hello]

There's a new version of CropResize dated 2022-09-29 in the opening post.

A minor update. See the Changes text file for details.

[hello_hello]

There's a new version of CropResize dated 2022-10-04 in the opening post.

Just a minor regression fix.

[hello_hello]

There's a new version of CropResize dated 2022-11-01 in the opening post.

Fixed packed RGB cropping (RGB24, RGB32 etc) when the AVSResize and FMTConv plugins are resizing (the video was being resized without any cropping being applied).

Fixed AutoDAR=true ignoring the specified mod width or height (default Mod=4).

[hello_hello]

There's a link for a new version of CropResize dated 2022-11-19 in the opening post.

The pictures demonstrating CropResize usage in the 2nd post have also been updated.

-------------------------------

Fixed a 2022-09-22 regression when NoResize=true or ResizeWO=true and CSplit=1 (the default).
Specifying non-mod cropping (ie not mod2 for YV12) could result in an error message or the cropping
being adjusted slightly incorrectly.
The display and sample aspect ratios shown when Info=true should still have been correct though.

Changed the displayed info when a cropping preview is enabled, mainly to show the display and
sample aspect ratios as float (ie 1.777778) as well as a fraction (ie 16:9).

[hello_hello]

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

The new version updates the built-in frosty borders function to match the latest update to the standalone FrostyBorders script. There's no other changes.

[hello_hello]

There's a link for new a version dated 2023-07-14 in the opening post. Just a couple of minor gremlin fixes.