CropResize script - updated version with sub-pixel cropping

[hello_hello]

For anyone stumbling across this thread, this is an old version of the script.
The new version can be found here.
The links in this thread probably won't continue to work and some of the info is outdated.

New version. See post #14 for details.
CropResize 2018-01-12.zip

One very minor change to the script effecting the cropping preview. As well as displaying the source resolution and cropping it now also displays the eventual output picture resolution (excluding any added borders).
CropResize 2018-02-15.zip

New version due to changes to the cropping preview. See post #15 for details.
The screenshots in post #2 have been updated to show the new cropping preview.
CropResize 2018-03-17.zip

The idea of the script is to allow you to crop and resize without having to use a cropping/resizing calculator ever again. The previous version works as designed but it had a couple of limitations. It used autocrop.dll to do all the cropping, which could make it a bit slow to open a video (this version only uses autocrop when it's specifically enabled) and it was therefore limited to mod2 cropping which aggravated my OCD in respect to cropping/resizing accuracy.

This version can also add borders (I changed the name from CropResizeBorder() to CropResize() because I'm indecisive) but it's also capable of subpixel cropping so it should be virtually 100% accurate. It uses Avisynth's Crop() function to apply any mod2 cropping, then it uses an Avisynth resizer to apply any mod1 or subpixel cropping as required. There's two versions of the script. CropResize() only resizes with Spline36Resize, whereas CropResize8() uses the Resize8 script for resizing and therefore supports any resizer it does. There's links to any additional plugins required in the included help file, although the CropResize() script can be used without them (as long as AutoCrop isn't enabled).

The script automatically color corrects when resizing from HD to SD or from SD to HD with colormatrix.dll, although colormatrix isn't required as if it isn't loaded the color correction is bypassed. It can also be disabled with ColorCorrect=false.

The basic usage is much like using an Avisynth resizer to resize and crop, only if the source aspect ratio and output aspect ratio differ, the script crops extra picture as required for zero aspect error. So for example, to take a source image of any aspect ratio and resize/crop it to 16:9 dimensions, while forcing the script to first crop 10 pixels from around the edges, all you need to specify is something like this:

CropResize(1024, 576, 10, 10, -10, -10)

You can only enter mod2 cropping (or mod1 for RGB) but the script will add sub-pixel cropping as required.

If you set Info=true the script displays detailed information over the video and the result can be compared to a cropping/resizing calculator.

After completing the help file I wondered if it all sounded a little complicated, given the idea was to make cropping and resizing very simple, but the script is quite easy to use once you understand how the various options interact, so the following post contains screenshots to demonstrate. About the only thing it won't do in respect to resizing is resize to an anamorphic display aspect ratio (it's square pixel dimensions or no resizing at all). Would there be much of a demand for that?

[hello_hello]

The following screenshots are examples of normal resizing mode with substantial cropping applied to help demonstrate. The equivalent of:

Crop(30, 4, -24, -4)
Spline36Resize(640, 480)
only without the need to worry about any aspect error.

A 4:3 PAL DVD Source:





The cropping preview - CPreview.
The yellow lines show the manual (specified) cropping, while the light blue lines show any additional cropping applied by the script to prevent any aspect error when resizing (rounded to the nearest whole pixel for the preview).
An input pixel aspect ratio or display aspect ratio must be specified for anamorphic sources.

pCropResize(640, 480, 30, 4, -24, -4, InDAR=15.0/11.0)
or
CropResize(640, 480, 30, 4, -24, -4, InDAR=15.0/11.0, CPreview=true)





The old cropping preview - CPreviewB.
The transparent yellow borders show the manual (specified) cropping, while the blue borders show any additional cropping applied by the script.

CropResize(640, 480, 30, 4, -24, -4, InDAR=15.0/11.0, CPreviewB=true)





The same cropping and resizing as above, only with the cropping preview disabled and Info=true.
The source has been cropped and resized before the information is displayed.
CropResize(640, 480, 30, 4, -24, -4, InDAR=15.0/11.0, Info=true)





If you don't want a particular aspect ratio or resolution, you can simply specify a width and zero for the height (or specify a height and zero for the width) and let the script take care of the rest. The script will resize to the appropriate height (or width) while cropping a little picture if need be to prevent any aspect error.

[Selur]

The script automatically color corrects when resizing from HD to SD or from SD to HD with colormatrix.dll, although colormatrix isn't required as if it isn't loaded the color correction is bypassed. It can also be disabled with ColorCorrect=false.

How? I mean which color matrices are converted to what? Is the color matrix of the input guessed somehow?
Not every SD content uses color matrix X (remembering https://forum.doom9.org/showthread.php?t=133982) and thus assuming a color matrix could be bad.

Cu Selur

Ps.: Any plans to support HDR -> HD/SD conversions? (If done like madVR does it, THIS would be cool)

[hello_hello]

The script automatically color corrects when resizing from HD to SD or from SD to HD with colormatrix.dll, although colormatrix isn't required as if it isn't loaded the color correction is bypassed. It can also be disabled with ColorCorrect=false.

How? I mean which color matrices are converted to what? Is the color matrix of the input guessed somehow?
Not every SD content uses color matrix X (remembering https://forum.doom9.org/showthread.php?t=133982) and thus assuming a color matrix could be bad.

I tend to think not assuming a color matrix is likely to be worse, so SD is assumed to be rec.601 and HD rec.709, but I did give it a bit of thought before adding it, and the help file states clearly what the script will consider to be HD and what's SD. I even included instructions on how to disable the color correction by default if that's what you'd prefer. It's easy to do.

Plus any ambiguity probably only applies to upscaling. I think all HD is rec.709 so there shouldn't be an issue when downscaling, but you can also use Info=true to check whether any color conversion is taking place. It can only happen when resizing (the script has non-resizing modes) and only when going from HD to SD or from SD to HD. You can use the script to encode SD to SD all day long and the colors won't change. I think the moral of the story is don't upscale, but I could add an option to make it automatic when downscaling but not when upscaling... or something along those lines if it's really an issue.

Color ambiguity is not really anything new. Xvid doesn't save colorimetry info so if you downscale and don't convert the colors when encoding with Xvid they'll undoubtedly be wrong on playback and chances are the majority of people don't specify it even when encoding with x264.

To be honest the deciding factor for including it by default was I do a bit of downscaling myself and remembering to add color correction to the script is one thing I won't have to worry about any more.

Ps.: Any plans to support HDR -> HD/SD conversions? (If done like madVR does it, THIS would be cool)

At the moment I wouldn't know where to start. I've not worked with any HDR content yet (I'm still happily living in 4k denial), but if it's do-able with an Avisynth plugin or something along those lines it's not out of the question.

[Selur]

I think all HD is rec.709 so there shouldn't be an issue when downscaling, ...

HD also isn't always BT.709. At least I from time to time get content which isn't.

the help file states clearly what the script will consider to be HD and what's SD.

Yes it does:

If the source width (after resizing to square pixels if anamorphic) is greater than 1056, OR the source height is greater than or equal to 600, then the source is considered to be high definition.
If the output width (including any borders) is less than or equal to 1056, AND the output height is less than 600, then the output is considered to be standard definition.

it does not however state which this means in regard to what color matrix changes are applied.
Personally I would recommend to add two additional parameters which allow to set the HD and SD color matrix and define the defaults of those parameters with the defaults you assume in you script.

[hello_hello]

it does not however state which this means in regard to what color matrix changes are applied.
Personally I would recommend to add two additional parameters which allow to set the HD and SD color matrix and define the defaults of those parameters with the defaults you assume in you script.

I'll confess it never occurred to me when making a colorimetry assumption, the world wouldn't assume that'd be rec.601 for SD and rec.709 for HD (would anyone assume the assumption isn't that?). When color correction is applied, Info=true does display "Rec.709 -> Rec.601" or "Rec.601 -> Rec.709" accordingly.

I don't mind adding those options, although I'm still not convinced it's much of an issue. Do you really think that'd be easier than simply using ColorCorrection=false, or setting false as the default though? If you know enough to realise when the color correction is happening and decide yourself if it should be, wouldn't enabling/disabling it as appropriate achieve the same thing? That'd only leave the possibility of converting the colors when not upscaling or downscaling, as the script never does, and adding that to a script manually could be done just as you'd have to do it when not using the CropResize() function.

[Selur]

Do you really think that'd be easier than simply using ColorCorrection=false, or setting false as the default though?

Since folks tend to not think much about color matrices and color corrections and assume the scripts they sure are always correct, I would recommend to either add those parameters or either at least write it clearly in the documentation what you assume and what will happen when you set ColorCorrection=true.
Personally I would only use the script for the general resizing and do the color correction by hand, but I thought this is an issue I should bring up.

Cu Selur

[hello_hello]

I added a couple of sentences to the ColorCorrect description to make it clear what the script assumes for HD and SD and updated the link in the opening post, but the script itself hasn't changed. Aside from that, I still think providing instructions for disabling the color correction by default and including an option to set ColorCorrect=false is sufficient. And of course if you don't load colormatrix.dll, no color correction can take place anyway.

[Selur]

Yup, should be fine with those comments.

[hello_hello]

Oddly, I didn't expect anyone to be too unhappy with the ColorCorrection option, but I thought the Aspect option mightn't float everyone's boat, which is why I also included instructions for disabling it by default.

All it does, is if you only specify a width or a height, ie CropResize(1280, 0) and the cropped source aspect ratio falls within a particular range, the script will crop a bit more so it can resize to exactly 16:9 or 4:3. The range is between 1.739 and 1.829 for 16:9 and between 1.27 and 1.35 for 4:3. Even then, it'll only have an effect if the specified mod allows the resizing to achieve exactly 16:9 or 4:3.

Trouble is, if you want exactly 16:9 or 4:3 you could just specify those dimensions, ie CropResize(1280, 720), so in hindsight maybe Aspect should've been disabled by default. Then again, maybe others will mostly prefer to have it enabled. I'm open to suggestions regarding that one.

[hello_hello]

I had a bit of a play with the Aspect option so I could be sure what it's doing in the real world. I started with a PAL DVD with exact 16:9 (or 4:3) resizing and cropped from the width to see how much I'd have to crop before the script would give up cropping extra from the height to make sure the output was 16:9 (or 4:3) and then I did the same again while only cropping from the height.

For a 16:9 DVD it's around 16 pixels either way. Once you crop more than that from the height the Aspect option gives up cropping extra from the width to output 16:9 and likewise once you've cropped more than 14 pixels from the width it stops cropping extra from the height.

For a 4:3 source the Aspect option is biased towards making the picture wider, so for a PAL DVD you only get to crop a total of 6 pixels from the height before it stops reducing the width for 4:3, but you have to crop more than 34 pixels from the width before it stops reducing the height, although that was intentional because I try to avoid outputting an aspect ratio that's less than 4:3. If I remember correctly, AutoGK's 4:3 option stayed in effect until the cropped picture was less than 1.24. I didn't get quite that carried away and cut the Aspect option off at 1.27.

And of course Aspect still only applies when the specified Mod permits exactly 16:9 or 4:3 and only when you don't specify both an output width and an output height yourself.

I did make Info=true a little more informative. If Aspect=true, in addition to showing when Aspect isn't having any effect because the cropping/resizing would have resulted in exactly 16:9 or 4:3 anyway, it now shows what the output aspect ratio would have been had Aspect=false.

So.... I've added that little tweak to Info=true, expanded the description of the Aspect option in the help file and put a note near the top of the help file instructing users to read what the ColorCorrect and Aspect options do in case they'd prefer to disable them. The link in the opening post has been updated although I haven't changed the version number because the script functionality hasn't changed.

[hello_hello]

There's a new version of the script (2018-01-05) attached to the opening post.
(The 2018-01-05 version of the CropResize8 script wasn't using the Resize8 script for resizing as it should. That's fixed and the link in the opening post updated to 2018-01-06)

I fixed a bug that caused the script to throw an error if the AutoCropping preview was enabled while AutoCrop was enabled.
The layout of the information displayed when Info-true has changed to hopefully make it a bit easier to read.

Two more preview options have been added to make previewing cropping easier (more GUI-like).
When MCPreview (manual cropping preview) is enabled, the script now adds transparent yellow borders to aid with setting cropping manually. Resizing is temporarily disabled.
When TCPreview (total cropping preview) is enabled, the script adds the same yellow borders to show the manual cropping, but it also adds transparent blue borders to show any extra cropping being applied to prevent any aspect error.

There's new wrapper functions to make enabling/disabling the TCPreview mode nice and easy. They're explained at the end of the help file.

As an example of the new preview mode, if you were to take a 16:9 NTSC DVD and crop 40 pixels from each side while specifying 16:9 output dimensions, the first screenshot demonstrates the result (not that you'd want to crop so much in this case, it's only an example).
CropResize(704, 396, 40, 0, -40, -16, InDAR=20.0/11.0)

The second screenshot shows the new cropping preview mode with the yellow borders showing the manual cropping and the blue borders showing the additional script cropping required for 16:9.
CropResize(704, 396, 40, 0, -40, -16, InDAR=20.0/11.0, TCPreview=true)

[hello_hello]

A new version of the script (2018-01-07).

The CropResize() and CropResize8() functions are now merged into a single script. The CropResize8() functionality remains the same and still uses the Resize8 script for resizing.

Luma and chroma resizers can now be specified for the CropResize() function. If they're not specified, the script uses Spline36Resize for resizing and the Resize8 script is not required. If either are specified the script switches to using the Resize8 script for resizing, as it does for the CropResize8() function.

The cropping preview has been tweaked to make the yellow and blue cropping borders a bit darker and easier to see.

A link for the 2018-01-07 version has been added to the opening post.

[hello_hello]

The new version is dated 2018-01-12 and is attached to the opening post.

Changes in this version:
The "Frosty" option was calling a function in the stand-alone FrostyBorders script, and therefore wouldn't have worked without the FrostyBorders script loaded. That's been corrected and it now calls the function included with the CropResize script.

The option for enabling the preview of both the manual cropping and any additional script cropping has been renamed to TCPreview (total cropping preview).

The TCPreview option has been tweaked a little to possibly make it faster. Previously it used Overlay() twice to create the preview. It now only uses Overlay() once.

[hello_hello]

I made some changes to the cropping preview and there's a link to the new version of the script dated 2018-03-17 in the opening post.

The screenshots in post #2 have been updated to show the new cropping preview.

- The text is now easier to read.
- The preview options previously named MCPreview and TCPreview are gone. In hindsight, a preview displaying only the manually applied cropping doesn't seem very useful.
- The default cropping preview option is now called CPreview. It only overlays lines rather than coloured borders. It makes it easier to see what you're cropping as the area being cropped isn't coloured.
- The old cropping preview showing coloured borders is renamed CPreviewB. If you prefer the old preview and want to make it the default (when prefixing the function name with "p"), there's instructions in the help file.
- A new option "CLine" sets the width of the lines overlayed on the video by CPreview (no matter how wide the lines, they're included in the area to be cropped, not the remaining picture).