View Full Version : CropResize script
hello_hello
16th December 2017, 05:49
This thread is outdated. The current version of CropResize can be found here (https://forum.doom9.org/showthread.php?t=176667).
My new cropping/resizing script. If anyone tries it and finds a problem, please let me know.
The idea is to be able to crop and resize without having to calculate aspect error, as the script will automatically crop as required to prevent the picture from being distorted. It uses an Avisynth resizer to apply sub-pixel cropping.
CropResize 2018-01-12.zip (https://files.videohelp.com/u/210984/CropResize%202018-01-12.zip)
New version. Only one very minor change. See post #3 for details.
CropResize 2018-02-15.zip (https://files.videohelp.com/u/210984/CropResize%202018-02-15.zip)
New version due to changes to the cropping preview. See post #4 for details.
CropResize 2018-03-17.zip (https://files.videohelp.com/u/210984/CropResize%202018-03-17.zip)
There's a few dependencies if you want to enable auto-cropping or colour correction, or specify the resizing method. There's links in the help file but the script can be used without them.
Edit 2018-01-13: Removed old screenshot and updated the link.
hello_hello
13th January 2018, 05:59
I've ironed out some minor gremlins and hopefully the script's at the "final" stage.
The main change since the initial version is the addition of a GUI-like cropping preview. I missed having one as it makes fine tuning the cropping easier. The cropping preview can be enabled simply by adding "P" to the beginning of the function name (or when using any of the wrapper functions).
The script has non-resizing modes and it can also add borders etc, but 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:
https://s10.postimg.org/r0ib5xnzd/source.jpg
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)
https://s10.postimg.org/ii8v1lp6h/CPreview.jpg
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)
https://s10.postimg.org/ii8v1lww9/CPreview_B.jpg
The same cropping and resizing as above, only with the cropping preview disabled and Info=true.
CropResize(640, 480, 30, 4, -24, -4, InDAR=15.0/11.0, Info=true)
https://s10.postimg.org/py84nf015/Info.jpg
If you don't want a particular aspect ratio or resolution, you can simply specify a width (or height) 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.
This time only specifying a width of 640, but due to the amount of cropping and the Aspect option being enabled, the script still resized the height to 480 anyway.
CropResize(640, 0, 30, 4, -24, -4, InDAR=15.0/11.0)
https://s10.postimg.org/oj6jyor89/CPreview_Disabled.jpg
hello_hello
15th February 2018, 02:37
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.
It makes using the preview a little easier, as for example, when specifying only a width and letting the script take care of the height, you don't have to disable the cropping preview to determine what the final output resolution will be.
The new version is dated 2018-02-15. There's a link in the opening post.
hello_hello
17th March 2018, 01:39
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 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 to preview the cropping 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 called CLine sets the width of the lines overlayed on the video by CPreview.
The screenshots in post #2 have been updated to show the new cropping preview.
Metal-HTPC
16th March 2019, 10:32
dear hello_hello,
I was just trying your script (CropResizePicDar.avsi) but it doesn't seem to work
I'm getting the error there is no function named "CR_IsReallyFloatOld" (CropResizePicDar.avsi, line 93). I couldn't find any solution for that error.
My avs script: https://ufile.io/ydzap
The CropResizePicDar.avsi you sent me: https://ufile.io/6jqyl
thanks in advance for your help
StainlessS
16th March 2019, 11:59
CR_IsReallyFloatOld
By the name, looks like some old test function that is left in-situ by mistake, ie no longer functional.
Maybe just remove the OLD bit from the end of function name so that uses new version instead (temp stopgap measure until fixed, maybe).
[Assuming that there is a new version and by similar name]
Metal-HTPC
16th March 2019, 12:18
doesn't work. hello_hello probably has an idea ;-)
StainlessS
16th March 2019, 12:26
ABC = DGDecode_mpeg2source("E:\Projects\MOVIE\Geschichten aus der Gruft\video.d2v")
function DoThis(clip XYZ) {
XYZ\
.FrameRateConverter(48000,1001)\
.AssumeFPS(50)\
.SeparateFields()\
.SelectEvery(4,0,3)\
.Weave()\
.QTGMC(FPSDivisor=2) }
function DoThat(clip XYZ) {
XYZ\
.TFM().TDecimate()\
.QTGMC(InputType=1, EzDenoise=1)\
.AssumeFPS(25) }
This = ABC.Trim(0,1212).DoThis().CropResizePicDAR(720,576,12,0,-10,-4,InDAR=15.0/11.0)\
That = ABC.Trim(1213,0).DoThat().CropResizePicDAR(720,576,12,0,-10,-4,InDAR=15.0/11.0)\
This ++ That
GradFun3()
You seem to be developing nasty habits from Wonkey_Monkey ( :devil: )
Like this is better
ABC = DGDecode_mpeg2source("E:\Projects\MOVIE\Geschichten aus der Gruft\video.d2v")
Function DoThis(clip c) {
c
FrameRateConverter(48000,1001)
AssumeFPS(50)
SeparateFields()
SelectEvery(4,0,3)
Weave()
QTGMC(FPSDivisor=2)
}
Function DoThat(clip c) {
c
TFM()
TDecimate()
QTGMC(InputType=1, EzDenoise=1)
AssumeFPS(25)
}
This = ABC.Trim(0,1212).DoThis().CropResizePicDAR(720,576,12,0,-10,-4,InDAR=15.0/11.0)
That = ABC.Trim(1213,0).DoThat().CropResizePicDAR(720,576,12,0,-10,-4,InDAR=15.0/11.0)
This ++ That
GradFun3()
EDIT:
Yeh, I'm getting the same with this
Import(".\cropresizepicdar.avsi")
Avisource("D:\Parade.avi")
Trim(0,1212).CropResizePicDAR(720,576,12,0,-10,-4,InDAR=15.0/11.0)
StainlessS
16th March 2019, 12:38
If you comment out this lot (except in blue) should work until HH gets back.
MISTAKE DELETED
EDIT: Whether or not it works correctly though, I dont know [all the asserts are just legality checks].
EDIT:
Mistake, just comment out this lot
#assert(CR_IsReallyFloatOld(InDAR), """ CropResizeOld: "InDAR" must be floating point (4.0/3.0 or 1.7778 etc) """)
#assert(CR_IsReallyFloatOld(PixelAR), """ CropResizeOld: "PixelAR" must be floating point (64.0/45.0 or 1.4223 etc) """)
#assert(CR_IsReallyFloatOld(PicDAR), """ CropResizeOld: "PicDAR" must be floating point (4.0/3.0 or 1.7778 etc) """)
EDIT:
Looks like CR_IsReallyFloatOld(InDAR) is a missing RaffRiff42 avsi function,
and it will only work as intended on v2.58, not v2.60+,
In v2.60+, Float args where user supplied as Int, they are forcibly converted to Float by Avisynth, and so that function has no purpose in v2.60 or Avs+.
Due to this forcible conversion, you cannot tell whether or not user called with float or int arg.
[I would have been happier if had been left as it was originally]
EDIT:
Function test(float "f") {
S = (f.Defined) ? "Defined" : "NOT Defined"
f=Default(f,42)
s = S + " F="+String(f) + "\n"
Return S
}
S0=VersionString+"\n"
S1=Test()
S2=Test(1)
S3=Test(2.0)
S= S0 + S1 + S2 + S3
BlankClip(width=240,Height=100)
Subtitle(S,lsp=0)
Avs v2.58
https://i.postimg.cc/tJ5jkSLK/Avs258.jpg (https://postimages.org/)
Avs 2.60(+)
https://i.postimg.cc/mDWWsWRx/Avs260-Plus.jpg (https://postimages.org/)
EDIT: In v2.60+, if the guy that wrote the script function supplied the default arg as an int, then can still produce problems and so the original fix conversion to float arg
still dont work ideally, ie maybe should also convert Defaulted args to Float where the formal arg type (think thats what its called) is of eg type float.
If this was done, then I would be happier.
EDIT: Even Gavino ( hi there big G :) ) on occasion used to use defaulted Int where type Float would have been better choice, so is easy mistake to make.
Metal-HTPC
16th March 2019, 13:21
thanks for the help and explanation Stainless. I'm using a 2.60 version.
The command is working now but as a feedback I have to say that it's cropping a bit too much. I made a comparison:
Without cropping:
https://s16.directupload.net/images/190316/fotti3hm.png
with cropping:
https://s16.directupload.net/images/190316/2qq9lzkb.png
StainlessS
16th March 2019, 13:42
Perhaps its cropping mod 4, see Mod and HMod args.
EDIT:
Mod = default(Mod, 4)
HMod = default(HMod, Mod)
wonkey_monkey
16th March 2019, 19:04
You seem to be developing nasty habits from Wonkey_Monkey ( :devil: )
Hmm? :confused:
hello_hello
16th March 2019, 20:22
dear hello_hello,
I was just trying your script (CropResizePicDar.avsi) but it doesn't seem to work
I'm getting the error there is no function named "CR_IsReallyFloatOld" (CropResizePicDar.avsi, line 93). I couldn't find any solution for that error.
My avs script: https://ufile.io/ydzap
The CropResizePicDar.avsi you sent me: https://ufile.io/6jqyl
thanks in advance for your help
That'll teach me to upload a "hacked" version. It was a quick hack to support anamorphic resizing. It'll crop to the specified PicDAR (or the InDAR if no PicDAR is specified) then it'll resize to the original dimensions, unless you specify something else.
In that respect, it appears to be working. The script crops to prevent any aspect error. You specified cropping of (12,0,-10,-4), but that's not 15:11. In order to crop to 15:11 so you can resize back to 720x576 it's cropping an extra 13.6 pixels from the height (total 17.6). Use Info=true to see what's going on, or CPreview=true to preview the cropping.
558.4 * 15/11 = 761.454546
761.454546 / (12/11) = 698
(12/11 is the pixel aspect ratio for a 15/11 PAL display aspect ratio)
That's what the script cropped to: 698 x 558.4, then it resized back to 720 x 576.
The screenshot is the CropResizePicDAR script. The last official CropResize function only resizes to square pixel dimensions (or you can disable resizing), but it crops to prevent aspect error in the same way. Now this thread's a mess and the pics are missing from the opening post, I should pull my finger out and finish the new version. There's quite a few changes and I'm still testing.
CropResizePicDAR(720,576,12,0,-10,-4,InDAR=15.0/11.0, Info=true)
The "Output Picture Aspect Ratio" shown is actually the output Storage aspect ratio. The original script expected square pixel dimensions and I didn't change the text. Everything else should be correct though.
https://i.postimg.cc/HLpCrZ3F/CR.jpg
It's good to see the new version of the script agrees.
CropResizeNew(720,576,12,0,-10,-4,InDAR=15.0/11.0,OutDAR=15.0/11.0, Info=true)
https://i.postimg.cc/dDTXLX7P/CR2.jpg (https://postimg.cc/dDTXLX7P)
Sorry about the error. I'd renamed functions in the old script and to be honest, I've no idea why the missing function wasn't included. I must've copied and pasted an added function for the "hack" over the missing one, or something.....
This is the function you need. Just add it to the bottom of the CropResizePicDAR script.
function CR_IsReallyFloatOld(val v) {
return !IsInt(v) && IsFloat(v) }
hello_hello
16th March 2019, 20:32
EDIT:
Looks like CR_IsReallyFloatOld(InDAR) is a missing RaffRiff42 avsi function,
and it will only work as intended on v2.58, not v2.60+,
In v2.60+, Float args where user supplied as Int, they are forcibly converted to Float by Avisynth, and so that function has no purpose in v2.60 or Avs+.
Due to this forcible conversion, you cannot tell whether or not user called with float or int arg.
[I would have been happier if had been left as it was originally]
I had a penny dropping moment a while back and realised RaffRiff42's function could be reduced to this:
function IsReallyFloat(val v) {
return !IsInt(v) && IsFloat(v) }
How does Avisynth+ handle something like this as a float argument? ie InDAR = 4/3
Would it still do integer maths like classic Avisynth, and then convert it to float?
That's the problem I was trying to avoid.... forcing the use of 4.0/3.0 or 1.33333 instead of 4/3.
Hopefully the IsReallyFloat function will still work for Avisynth+ as none of the float arguments are of the "float" type. They're all "val" arguments. I think I mainly did that (rather than make them float) so using the wrong argument type would give a more informative error, rather than the generic "xxxx is of the wrong type" Avisynth error.
If Avisynth+ is no different to Avisynth classic for "val" arguments, the IsReallyFloat function should still do it's job. I'll have to check it out later.
StainlessS
16th March 2019, 21:27
Hmm? :confused:
I was referring to this quite ghastly example of your prowess :) :- https://forum.doom9.org/showthread.php?p=1864264#post1864264
version.\
fliphorizontal.\
flipvertical.\
killaudio
StainlessS
16th March 2019, 21:40
function IsReallyFloat(val v) {
return !IsInt(v) && IsFloat(v) }
Above would work I think on v2.58, but as optional args are already force converted to float, then is quite obsolete to do any test in v2.6+ (the reason that I would have preferred to remain as was).
[EDIT: Above, ignore the word "optional".
That's the problem I was trying to avoid.... forcing the use of 4.0/3.0 or 1.33333 instead of 4/3.
4/3 is 1, which when forced to Float is 1.0.
Only way to to set DAR reliably is to use eg numerator, denominator ints.
Some DAR type stuff intended to set DAR for MeGUI
Function GetDAR(clip c, float SAR) { return Float(c.width) * SAR / Float(c.height)} # Gets the DAR from the SAR
Function GetSAR(clip c, float DAR) { return DAR * Float(c.height) / Float(c.width) } # Gets the SAR from the DAR
Function SignalDAR(float DAR) { global MeGUI_darx = Round(1000 * DAR) global MeGUI_dary = 1000 } # Signals DAR for MEGUI
Function GetCropDAR(clip c,float DAR,float "X",float "Y",float "W",float "H") {
# Call prior to Crop/Resize with (possibly fractional) cropping to calc resultant DAR, X,Y,W,H are cropping coords
# DAR = FAR * SAR ::: FAR = DAR / SAR ::: SAR = DAR / FAR
#
X=Float(Default(X,0.0)) Y=Float(Default(Y,0.0)) W=Float(Default(W,0.0)) H=Float(Default(H,0.0))
W=W<=0.0?c.width+W-X:W H=H<=0.0?c.height+H-Y:H
# Irrespective of what various resizers in various Avisynth versions silently correct/allow, we dont allow eg -ve X
Assert(X>=0.0&&X < c.width, "GetCropDAR: Invalid X("+String(X)+")")
Assert(Y>=0.0&&Y < c.height,"GetCropDAR: Invalid Y("+String(Y)+")")
Assert(W> 0.0&&X+W<=c.width, "GetCropDAR: Invalid W("+String(W)+")")
Assert(H> 0.0&&Y+H<=c.height,"GetCropDAR: Invalid H("+String(H)+")")
Return c.GetSAR(DAR) * W / H
}
Function SignalDAR2(int DARX,int DARY){
Assert(DARX>0 && DARY>0, "SignalDAR2: Error, DARX and DARY must be greater than zero")
Global MeGUI_darx=DARX Global MeGUI_dary=DARY
}
EDIT: Above, note the eg Float(c.Width) ensures that result of calc is Float, but in v2.58 would be better to also check that SAR was type float and produce error if not.
and In GetCropDARX the Float(Default(X,0.0)) the conversion to Float, which is only necessary in v2.58. [but Default(X,0) in v2.58 AND v2.60 would by default be Int 0].
Although would do no harm to do some checking eg
Function SignalDAR(float DAR){ # Signal DAR for MEGUI (Name change from SetDar)
Assert(!IsInt(DAR), "SignalDAR: Error, DAR must Type Float") # EDIT: Added, Only of use in v2.58 on type Float.
Assert(DAR>0.0, "SignalDAR: Error, DAR must be greater than zero")
Global MeGUI_darx=Round(1000*DAR) Global MeGUI_dary=1000
}
Above taken from a couple of different posts, first posted here:- https://forum.doom9.org/showthread.php?p=1576193#post1576193
EDIT: By the Way, IsFloat() produces true for both types Float and Int, whereas IsInt() produces true only for type Int.
So IsFloat() really means IsNumberOfSomeType().
hello_hello
16th March 2019, 22:03
I checked and it's working like this (Avisynth+ r2772):
function IsReallyFloat(val v) {
return !IsInt(v) && IsFloat(v) }
The following returns true.
function Test(clip c, float "InDAR") {
return c.subtitle(string(IsReallyFloat(InDAR))) }
Test(4/3)
The following returns false.
function Test(clip c, val "InDAR") {
return c.subtitle(string(IsReallyFloat(InDAR))) }
Test(4/3)
The following returns true.
function Test(clip c, val "InDAR") {
return c.subtitle(string(IsReallyFloat(InDAR))) }
Test(4.0/3.0)
So IsReallyFloat() does work for "val" arguments, even if it doesn't for "float" arguments. Chances are that's why I used "val" in the first place.
PS. Avisynth 2.60 is exactly the same.
StainlessS
16th March 2019, 22:14
So it looks like IsReallyFloat() will keep working for "val" arguments, even if it doesn't for "float" arguments.
Correct, only Float arg supplied as Int converted. [EDIT: Removed the word Optional Float]
EDIT: Added this line to prev post [ More succinct than IsReallyFloat() ], But only of use in v2.58, and NOT on type val (as if eg clip given then no Assert error, crash error instead).
Assert(!IsInt(DAR), "SignalDAR: Error, DAR must Type Float") # EDIT: Added, Only of use in v2.58 on type Float
Metal-HTPC
17th March 2019, 11:24
thanks hello_hello
I inserted
function CR_IsReallyFloatOld(val v) {
return !IsInt(v) && IsFloat(v) }
and then your script worked without additional disabling of specific commands.
I don't understand much of your "programmer conversion" with stainlesss ;-), so my simple question would be
should I replace it with "function CR_IsReallyFloatOld(val v) {
return !IsInt(v) && IsFloat(v) } " now ?
I used it for a DVD which was originally 720x480. So I guess there is really no way to crop it and resize it to prober 720x576 without loosing
some information if I want to keep the ratio intact
https://s16.directupload.net/images/190317/7ugmwqap.png
So the script works and does what it does right. It crops and resizes without destroying the original ratio through stretching.
StainlessS
17th March 2019, 13:22
should I replace it with "function CR_IsReallyFloatOld(val v) {
return !IsInt(v) && IsFloat(v) } " now ?
If you plan on Never using v2.58 again, then comment out or delete the lines entirely, they serve no purpose at all in v2.60+.
I'm sure though that HH will make some decision on how to handle it, but for now might as well delete/comment out the lines.
I started using Type Val args for this reason (you could detect problem args) but sort of gave up as its a little more tedious to do.
hello_hello
17th March 2019, 17:30
thanks hello_hello
I inserted
and then your script worked without additional disabling of specific commands.
I don't understand much of your "programmer conversion" with stainlesss ;-), so my simple question would be
should I replace it with "function CR_IsReallyFloatOld(val v) {
return !IsInt(v) && IsFloat(v) } " now ?
Yeah, just add the function to the end of the CropResizePicDAR script.
I used it for a DVD which was originally 720x480. So I guess there is really no way to crop it and resize it to prober 720x576 without loosing
some information if I want to keep the ratio intact
You can resize to a 4:3 aspect ratio and add borders, which would require less height cropping. For a DVD with a 15:11 display aspect ratio it always works out if you crop 8 pixels from each side, the remaining 704x480 or 704x576 is exactly 4:3.
CropResizePicDAR(704,576, 12,0,-10,-4, InDAR=15.0/11.0, PicDAR=4.0/3.0, Info=true)
AddBorders(8,0,-8,0)
The added borders aren't included in the info as the script doesn't know about them.
https://i.postimg.cc/SsD7Hn8t/CRPicDAR.jpg
The script can normally add borders for you, but I disabled a lot of stuff for the hacked version so I didn't have to spend time testing it.
Here's how the new version will do it. :)
When you specify a CropDAR, the picture is cropped to that display aspect ratio (or as close as possible for mod dimensions, depending on the resizing). If you also specify an OutDAR and it's different to the CropDAR, the script automatically adds borders to make up the difference.
CropResizeNew(720,576, 12,0,-10,-4, InDAR=15.0/11.0, CropDAR=4.0/3.0, OutDAR=15.0/11.0, Info=true)
https://i.postimg.cc/qqFcMW1s/CRNew.jpg
Or something a little more silly.
CropResizeNew(720,576, 12,0,-10,-4, InDAR=15.0/11.0, CropDAR=16.0/9.0, OutDAR=4.0/3.0, Info=true)
https://i.postimg.cc/CKSph2Bn/CRNew2.jpg
So the script works and does what it does right. It crops and resizes without destroying the original ratio through stretching.
Correct.
hello_hello
17th March 2019, 18:52
If you plan on Never using v2.58 again, then comment out or delete the lines entirely, they serve no purpose at all in v2.60+.
I'm sure though that HH will make some decision on how to handle it, but for now might as well delete/comment out the lines.
I started using Type Val args for this reason (you could detect problem args) but sort of gave up as its a little more tedious to do.
They do serve a purpose. The script already uses the val type for any argument that must be supplied as float, so the IsReallyFloat() checks do work.
StainlessS
17th March 2019, 20:06
The script already uses the val type for any argument
Oops yes, that escaped me.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.