The new CropResize should be as easy to use as the previous version (2018-03-17), at least for everyday cropping and resizing, while now covering any typical cropping/resizing scenario. It's not completely backwards compatible with the old version though, as some of the argument names have changed and new arguments have been added.
The main goal hasn't changed though......
To crop and resize without having to worry about calculating aspect error or distorting the picture.
The pictures in post #2 illustrate CropResize usage.
Some of the changes for version 2019-07-17
Anamorphic Output Support
An Output Display Aspect Ratio (OutDAR) or Output Sample Aspect Ratio (OutSAR) can now be specified.
CropResize is compatible with Avisynth 2.6 and Avisynth+.
Avisynth 2.5.8 is no longer supported, officially from CropResize version 2019-09-02, but it's been using a couple of functions that aren't available in Avisynth 2.58 for quite a while, and I didn't realise until recently.
I think it'll work for Avisynth 2.5.8 if MeGUI support is disabled and the ColorCorrect option isn't enabled, but I haven't tested it.
Color Correction Removed - (restored with version 2019-08-10)
CropResize no longer converts the colors when upscaling or downscaling.
It previously only converted between rec.601 and rec.709, and color conversion isn't technically the job of a cropping/resizing script, so color correction has been removed entirely.
Specified cropping can now be Mod1 for any source. CropResize will increase the cropping to the correct mod when it's not resizing, or hand off any non-mod cropping to the resizer when it is.
Cropping is now split between Avisynth's Crop() function and resizer cropping more intelligently, and the cropping split can now be controlled by the CSplit argument.
Right and bottom cropping can be a positive or negative integer, applied in the same way as Avisynth's Crop() function.
Global GCropResize Function
There's a new GCropResize function for configuring the CropResize options globally when there's more than one
instance of CropResize in a script. The options can be over-ridden by individual instances of CropResize.
The GCropResize function only outputs an unmodified version of the source clip (except when global auto-cropping
is enabled). GCropResize can be used to create two sets of global variables, but as an example of usage with a
single set of global variables:
GCropResize(720,480, 8,2,-8,-4, InDAR=4.0/3.0, OutDAR=15.0/11.0)
If there's a previous global MeGUI DAR in a script, for example:
global MeGUI_darx = 4
global MeGUI_dary = 3
CropResize will automatically use it as it's Input DAR.
CropResize also creates the appropriate global MeGUI DAR variables for MeGUI to use when loading a script. MeGUI can then calculate the correct sample aspect ratio automatically and add it to the command line for encoding.
Any compatible resizer can be specified via the Resizer argument, not just Avisynth's resizers (or the Resize8 script as was the case with the previous version).
There are wrapper functions included for specifying options when resizng with the Resize8 or ResizeX scripts, the ResampleHQ plugin, and for each of the Avisynth resizers with optional arguments.
+ Reply to Thread
Results 1 to 30 of 72
Last edited by hello_hello; 19th Sep 2019 at 22:24.
The easiest way to demonstrate CropResize usage is with some pictures.
01 - The (home made) PAL 16:9 source (mpeg4 DAR) used for the following examples.
02 - Simply specify a width (or height) and let CropResize take care of the rest, resizing to "square pixel" dimensions.
CropResize(832,0, 14,2,-16,-4, InDAR=20.0/11.0, Info=true)
03 - When specifying both an output width and height, the script crops accordingly to prevent aspect error
(although specifying an OutDAR takes precedence over the cropping and output display aspect ratio).
Simply to demonstrate, here 4:3 output dimensions are specified for the 16:9 source.
CropResize(704,528, 14,2,-16,-4, InDAR=20.0/11.0, Info=true)
04 - MeGUI support.
MeGUI was used to crop the source, adding it's global DAR variables and cropping to the script.
CropResize then takes care of the resizing and any extra cropping required to prevent aspect error.
global MeGUI_darx = 368
global MeGUI_dary = 209
05 - Cropping and resizing to NTSC dimensions with a 16:9 display aspect ratio.
CropResize(720,480, 14,2,-16,-4, InDAR=20.0/11.0, OutDAR=16.0/9.0, Info=true)
06 - Cropping and resizing to NTSC dimensions, this time with an mpeg4 display aspect ratio and 8 pixel borders each side.
CropResize(720,480, 14,2,-16,-4, CropDAR=16.0/9.0, InDAR=20.0/11.0, OutDAR=20.0/11.0, Info=true)
07 - Resizing for a PAL 4:3 frame with an mpeg4 DAR, and adding borders.
Cropped extra from the sides by specifying a CropDAR of 16:10 to reduce the size of the top/bottom borders.
CropResize(704,576, 14,2,-16,-4, CropDAR=16.0/10.0, InDAR=20.0/11.0, OutDAR=4.0/3.0)
CropResize(720,576, InDAR=4.0/3.0, NoResize=true, Borders=true, Info=true)
08 - For the purists, there's a "Resize Width Only" mode that prevents height resizing.
It supports anamorphic input/output.
CropResize(720,0, 14,2,-16,-4, InDAR=20.0/11.0, OutDAR=16.0/9.0, ResizeWO=true, Info=true)
09 - CleanBorders is much like Avisynth's LetterBox function, only it centres the picture.
CropResize(0,0, 33,4,-16,-47, InDAR=20.0/11.0, CleanBorders=true, Info=true)
10 - FrostyBorders.
CropResize(832,468, 14,2,-16,-4, CropDAR=4.0/3.0, InDAR=20.0/11.0, Borders=true, Frosty=true)
Increasing the cropping to demonstrate the cropping previews.
The yellow lines show the cropping specified by the user.
The blue lines show any additional cropping applied by the script to prevent aspect error.
11 - Cropping preview #1.
CropResize(960,540, 35,4,-16,-5, InSAR=16.0/11.0, CPreview=1)
12 - Cropping preview #2 with Info=true.
CropResize(960,540, 35,4,-16,-5, InSAR=16.0/11.0, CPreview=2, Info=true)
13 - Cropping preview #3.
CropResize(720,576, 35,4,-16,-5, InSAR=16.0/11.0, OutDAR=16.0/9.0, CPreview=3)
Last edited by hello_hello; 12th Sep 2019 at 09:17. Reason: Forgot to update some of the CropResize arguments when updating the screenshots
There's a new version of CropResize (2019-08-08). The link in the opening post has been updated.
The changes are aimed at making the script's behaviour more predictable, although there's not a lot of them. The cropping and resizing functionality remains the same. There's a list of changes in the zip file.
Another update. I've added back automatic color conversion when upscaling/downsaling between SD, HD and UHD. It's disabled by default, but it can be enabled by default so there's no need to use the ColorCorrect argument. Details in the help file.
ColorCorrect=0 is disabled, ColorCorrect=1 converts with the ColorMatrix plugin, and ColorCorrect=2 converts with DitherTools. Currently only 8 bit video is supported for color conversion.
I don't think there's a 64 bit version of ColorMatrix with Rec.2020 support, but the included 32 bit version has it. It supports YV12 & YUY2.
DitherTools supports Rec.2020 and YV12, YV16, YV24, YV411, and Y8.
The new version is dated 2019-08-10. The link in the opening post has been updated.
I was hoping I'd uploaded the last version, aside from maybe updating the color correction to support all native Avisyth+ bitdepths, but a bug managed to slip past the keeper.
Fixed an incorrect output display aspect ratio calculation when NoResize=true and an input sample aspect ratio was specified. The script was still cropping correctly, but the output display aspect ratio calculation was wrong.
New version in the opening post dated 2019-08-12.
Unfortunately I've had to upload a new version of CropResize sooner than I'd planned. The new version in the opening post is dated 2019-08-17.
While doing some testing for (hopefully) the upcoming version with the ColorCorrect option supporting Avisynth+ native bitdepths (greater than 8 bit), I discovered the version of ColorMatrix that was included in the zip file doesn't convert UHD colorimetry correctly (Rec.2020). As a result, the new version of the script will output an error if ColorCorrect=1, the source or destination resolution is UHD, and the script needs to color correct due to upscaling or downscaling. If you have DitherTools, ColorCorrect=2 can be used instead.
For the record, ColorMatrix seemed to be getting "Rec.709->Rec.2020" conversions right, but no other conversions involving Rec.2020 are correct (they don't match HDRTools & DitherTools).
ColorMatrix is still fine for conversions between HD and SD colorimetry. The standsrd version without Rec.2020 support has been around for years.
Last edited by hello_hello; 16th Aug 2019 at 18:28.
Hey, nice script you got there, do you mind to help me out with some questions.
This is the source that I'm using with your script:
This is the script:
ImageSource("ssf-source.png") CropResize(0,480, 0,0,0,0, InDAR=12.0/7.0, Info=true)
It tries to resize keeping the AR 12:7 but if I try to force a resize it to a 4:3 resolution like 640x480, the result still looks stretched horizontally and cropped:
CropResize(640,480, 0,0,0,0, InDAR=12.0/7.0, OutDAR=4.0/3.0, Info=true)
I'm looking to get something like this:
What do I have to do to make your script to resize like that with the correct proportions?
Now I use a spreadsheet to calculate the Horizontal or Vertical resolution manually + jagabo's script, your script it's all in one solution, very handy. Arcade resolutions are a pain in the butt, specially CAPCOM's, this guy cover this matter in great detail.
Got the script working:
To make it work I set InDAR with desired DAR 4:3 instead of SAR 12:7.
CropResize(0,480, 0,0,0,0, InDAR=4.0/3.0, Info=true)
There is an input sample aspect ratio option. It's InSAR, as opposed to InDAR, so you can specify either, but....
So you know, the video you linked to possibly makes it sound more complicated than it is. Each game has to display as 4:3, no matter what the storage aspect ratio (resolution), and the game in your screenshot has a resolution of 384x242. To determine the (input) sample/pixel aspect ratio:
storage height × display aspect ratio = display width
display width / storage width = sample aspect ratio
Doing it in a single equation: 224 × (4 / 3) / 384 = 0.777778 or (7:9)
So InSAR=7.0/9.0 is the same as InDAR=4.0/3.0 for that one. If the resolution changes the sample/pixel aspect ratio probably will too, so it'd be simplest to use InDAR=4.0/3.0 all the time and let the script do the math.
The 12:7 aspect ratio he refers to is the resolution (storage aspect ratio), although it'd be easy to think he was referring to a sample/pixel aspect ratio. I did at first.
By the way... keep an eye out for the new version of CropResize with additional color conversion options. It'll also convert with HDRTools, support all the native AVisynth+ bitdepths.
Edit: I planned to include AVSResize as a color conversion option too, but decided against it to keep things as simple as possible, plus it's not compatible with XP.
Last edited by hello_hello; 3rd Sep 2019 at 22:32.
I'll look forward to it.
Last edited by amaipaipai; 23rd Aug 2019 at 04:19.
There's an updated version of CropResize in the opening post, dated 2019-09-02. With any luck that'll be it for quite a while, as the script's color correction (converting the colorimetry when upscaling/downscaling) was the only thing left to sort.
Under "ColorCorrect" in the help file, there's a mini essay on my current understanding of color conversion, when to convert and how to do it.
There's now four conversion choices.
3. HDRTools (170m for SD)
4. HDRTools (470bg for SD)
DitherTools can no longer be used for Rec.2020 conversions, but if it's converting the colors, DitherTools will do the resizing too (when a compatible resizer is specified). Only standard dynamic range is supported. I don't think HDR to SDR conversions can be done automatically, I've almost no experience with HDR, and I've no interest in HDR anyway.
Some other changes -
- Avisynth 2.5.8 is no longer supported. As it turns out, the script was already using a couple of functions not available in Avisynth 2.5.8.
- Added a PicDim argument for adjusting how much the picture is dimmed when Info=true. The default is -75. The range is -255 to 0.
- Tweaked Info=true. The displayed info scales a little better with resolution. The source color format and bitdepth are now displayed.
I also noticed an Avisynth+ oddity that causes negative zero (such as a right or bottom cropping of zero) to be displayed with the negative sign under some circumstances. I added a workaround to prevent zero from displaying as a negative, because it was annoying me.
For anyone interested, Avisynth+ displays this as 0
zz = float(-0)
but displays this as -0
zz = float(0)
Avisynth 2.6 doesn't display the negative sign either way.
In case I did a stupid, there's still a link for the 2019-08-17 version in the opening post, but the new version should be fine.
Last edited by hello_hello; 3rd Sep 2019 at 22:47.
It works like a charm.
This isn't an update to the script itself, as it's exactly the same as the version dated 2019-09-02, but I've update the help file a little. There's no longer any optional plugins included with the script, but there's still links for them at the top of the help file. Including plugins in the zip file was only supposed to be a temporary thing as they'll become outdated.
Even though the script itself is unchanged, I've updated the version to 2019-09-10. There's a new link in the opening post.
Is possible to make the script to print out the script name + version (or release date) at the bottom of the screen with "info"? It makes easy to have control of what release version/date we are using.
Thank you again, amazing script!
I added PAR and DAR macros and made some other related changes.
CropResize(%target_width%, %target_height%, \ %crop_left%, %crop_top%, -%crop_right%, -%crop_bottom%, \ InDAR=%source_dar%, OutDAR=%target_dar%, Info=true)
Only the "CropResize.avsi" script is required.
The "CropResize Resizer Functions.avsi" script just contains wrapper functions for some Avisynth & external resizers, so the user can configure their various options that way. It seemed more practical than trying to add arguments for various resizers to the CropResize function itself, and less restricting. If the user wishes to use BicubicResize (for example) with specific settings it's easy enough to make a copy of the CR_Bicubic() wrapper function while specifying different defaults and giving it a unique name. Once that's done you can use BicubicResize and the new defaults with
or whatever you call it.
The "CropResize Wrapper Functions.avsi" script just contains wrapper functions to act as shortcuts for enabling a cropping preview, setting Info=true or enabling an alternative default resizer, because I'm lazy when it comes to typing.
ie pCropResize() enables the default cropping preview and pCropResizeX() does the same while enabling the alternative default resizer. None of that's required to use CropResize() though, which is why I kept them as separate avsi files.
If you think it's a good idea I could create a StaxRip version for you without the stuff that probably wouldn't be used. The function for specifying options globally, MeGUI DAR support etc... whatever you think isn't needed for StaxRip, or anything you'd like me to add for StaxRip. You could check out the options and let me know what to change, or you could do it yourself, but I imagine it'd be easier for me.
Last edited by hello_hello; 12th Sep 2019 at 09:21.
For StaxRip Win 10 is ideal but Win 7 probably works too, one issue I'm aware is the TaskDialog API which StaxRip uses a lot has broken support for very high DPI like 288 DPI, it's out of my control. I hope there won't be more issue like this and Win 7 can be supported for many more years.
A single file version would be fantastic and a default preset.
The way CropResize currently is, a single file version would simply require copying the contents of the "CropResize Wrapper Functions" and "CropResize Resizer Functions" scripts and pasting them into the bottom of the main CropResize script. Or at the top. There's no reason why they need to be separate scripts. I did it that way so the wrapper functions wouldn't have to be loaded for anyone not interested in using them, plus the idea behind the "CropResize Resizer Functions" was to make it easy for the user to change any default options for each resizer wrapper, and without having to modify the main CropResize script. If you don't need the wrapper functions, just ignore the other two scripts.
I'm not sure what a "default preset" would involve.
For a non-anamorphic source, the default OutWidth and OutHeight are the source width and height, after any cropping, and reduced for mod4 if necessary, so if a source was 1278x718 (before or after cropping), a CropResize() output would be the same as CropResize(1276,716) and something like an extra pixel would be cropped from the height so as to resize to 1276x716 without aspect error. If there's no cropping for a non-anamorphic source and it's mod4, the script won't do anything if you don't specify a different OutWidth or OutHeight. Or make Mod=2 the default so it won't do anything for a mod2 non-anamorphic source either.
For an anamorphic source it's pretty much the same principle, but the width is resized for "square pixel" dimensions. For an NTSC 16:9 DVD source, the default of CropResize(InDAR=16.0/9.0) would be the same as CropResize(852,480,InDAR=16.0/9.0).
You can specify zero for either (or both) the OutWidth and OutHeight, so that way the script can crop without needing to type the argument names and the defaults would still work as I explained.
ie CropResize(0,0, 2,0,-2,-4)
If anything, you might want to set a default OutWidth, and let the script take care of the rest. ie CropResize(1280), but I'm not sure if there's a need for that. If you specify just an OutWidth, then the height is resized accordingly. Or you can specify just an OutHeight and the width is resized accordingly.
Last edited by hello_hello; 12th Sep 2019 at 13:39.
I have only a moderate interest in video processing, so I'm not sure about good defaults. Maybe it's not so important because the user must know what he is doing. Next StaxRip build has it included, feature requests on the issue tracker are welcome but I don't always work on staxrip.
Every time I say I'm done updating.....
I assume nobody is using the global GCropResize function, given nobody's complained about it not working and the last version broke it.
I'll update the link in the opening post shorty. The new version is dated 2019-09-20.
- Fiddled with Info=true again. The Avisynth and CropResize versions are now displayed.
For an anamorphic source and/or output, the source and/or output "display dimensions" are included (right column). The height is the source/output height. The width is the source/output width, as it would be when resized to "square pixel" dimensions on playback. If necessary, "display width" is rounded to an integer (a whole pixel).
- Avisynth Neo probably didn't work correctly with CropResize. Added a check for Neo, although the script doesn't do anything "Neo specific". It now assumes Avisynth+ is being used when Neo is detected.
- The GCropResize function was completely broken after the last update. If GCropResize was used, an error message displayed (due to a typo).
I should have an old PC running Win7 or Win10 next week, and I intend to play around with AVSResize. If AVSResize for color correction offers an advantage, I'll probably add it as an option in the near future. I haven't been able to do it until now because AVSResize doesn't play with XP.
Last edited by hello_hello; 19th Sep 2019 at 22:33.
Thank you for the update!
If anyone has downloaded the 2019-09-20 version before reading this, or before the 21st, please download it again. I haven't change the version date but I somehow broke Info=true, despite being positive I checked it before uploading the script. Sigh....
Last edited by hello_hello; 20th Sep 2019 at 04:25.
Working like a charm!
I'm glad it's working, but now I'm confused. I noticed the screenshot in your earlier post showed the negative sign for right and bottom cropping of zero. After a bit of investigating I discovered Avisynth+ was doing that, but not Avisynth 2.6, so I added a workaround for Avisynth+.
I can't seem to convince Avisynth 2.6 to do the same, yet it appears you're not using Avisynth+ as I assumed. I've created an input that matches yours, but it's still fine. I'd like to discover the cause, so if you don't know what it might be, could I get you to upload a short sample of the source and the exact CropResize syntax you're using?
Thumbnail 1 is Avisynth 2.60 (obviously).
Thumbnail 2 is Avisynth+.
Thumbnail 3 is Avisynth+ with the "negative zero" workaround disabled. I can't imagine it'd make any difference to Avisynth 2.6 as the workaround is bypassed unless Avisynth+ is used. It doesn't make any difference to Avisynth 2.6 for me. Mysterious....
I'm using the standard Avisynth 2.6 (installed) and MeGUI's portable Avisynth+ (running XP).
This is not a problem with the script, but I've noticed that when using 'PointResize' lines run across the image when upscale. I came up with two fixes that works as standalone avisynth script, don't know if this is the best option but it get rid of that lines.
PointResize(width*4, height*4) BilinearResize(960, 720)
PointResize(width*4, height*4) BilinearResize(960, 720) Sharpen(0.4)
I've run some tests and overall, it's doing a great job.
Listening to Mariah Carey makes me want to punch something....
Maybe I'm going blind but I can't see any lines. All I can see is the blocky PointResize upscaling which looks like it's being softened by Bilinear resizing, but I can't see lines running across the picture as such. I might have to get you to point out what I can't see.
So you've no idea why CropResize is displaying zero as negative for some of the cropping?
But it doesn't affect anything, all the test that I ran so far are precise like a clock.